Debriefs Weekly Debrief

RChain Co-op Weekly Community Debrief #187 Jul 15 2020

Tech Update 128: Rao Bhamidipati

Transcript of call:

Greg 0:00

We can go ahead and get started. Looks like we have a quorum. I’m sure others will join. So, we have a lot to talk about, especially technically and otherwise, do we have a demo scheduled for today or not?

Rao Bhamidipati 0:29
We don’t we’re kind of waiting for for Raphael to do the next iteration of the. Okay.

Greg 0:38
Sounds good. Sounds good. All right. No worries. Okay, well, I’ll hand it over to you Rao and then we’ll pick it up from there.

Rao Bhamidipati 0:48
All right, I’m, I just pasted the link to update Community Update 128 in the chat. Let me share my screen.

So, in terms of releases, the validator nodes on the main net are currently running 0.9.25. And we are in the process of moving some of the main net validator nodes from the Google Cloud to the IBM cloud that has not started yet but should start soon. The 0.9 test net is also running on 9.25 right now, but we will soon be testing on that. is the second part. And and I would say that this has a bunch of the work, most of the work that’s needed for last finalized state. We’ll start testing on the test net, probably starting tomorrow. Where we are with 0. 9.25.1: we have a total of 19 prs 16 of them are merged. Two of them are about to be merged either later today or early tomorrow. And the last one is tests on one of the pr’s that nutzipper created. So that will come in a little bit later. But we want to get started on the testing of on the different environments as soon as possible. It’s been running on the sandbox for a few days now and also on the main net observer nodes. The test net was stuck for a little bit of time. That’s why we didn’t get started on the test net, but I will speak to that in a little bit. So the observer nodes are one of the observer nodes on the main net is running on right now. The Observer node. And we’re also going to start testing it on the exchange node on the main net, this is the one that’s being used live by the exchanges for the transactions, and so on and so forth. So what we will do initially is we’ll create a duplicate of that if you would, and try testing it on that and then do it on the main exchange node, on the main net. It may be confusing to people as to why so many iterations of testing and what’s the difference between the observer nodes and the exchange nodes and validator nodes, and why we’re being so careful. And why there are so many tests, steps to the testing. Basically the main difference between testing on observer nodes or exchange nodes versus validator nodes is that when we test and I mean much of the code is getting tested when we are running it on the observer nodes, but there are a couple of pieces that only occur, the code gets executed only on the validator nodes, but not on the observer nodes. So that’s the main difference. The key piece that gets executed on the validator nodes, but not on the observer nodes is the block creation code. So, as a block part of the block creation, there is the significant portion of the runtime manager runs as part of the block creation. So playing the deploys, which is what happens in the runtime manager, happens on the validator nodes, but not on the observer nodes. So this is the chunk of code if you were the block Creation code and the machinery that it uses, that does not get tested when we test on the observer or exchange nodes. This is the reason why we want to test both on the observer our exchange notes as well as on the test net. Because on the test net, we executed on the validator nodes also, and doing it on the main net observers in exchange gives us sort of an early inkling of Okay, how is this gonna behave on the main net, as opposed to the test net? So that’s the reason why we do it that way. We have these kind of three four different scenarios, if you would, that we test before we touch the main net validators because when we get to the main net validators, we want to make sure that yes, the validators have been tested on the test net, and we know that there are no hiccups on the main net relative to the observers and exchanges. So that’s kind of how we do that after some amount of testing on the sandbox. So with, we are going to be starting testing on the test net. And then once that all works, at some point, we’ll move that on to the main net validators.

So that’s the the work on, again, the main portion or content of is the last finalized state There are still a couple of pr’s that are related to last finalized state but we will be getting out in the 0.9.26. But this is a significant chunk of work of the last finalized state but it’s going in.

In terms of the other work that we have in progress, we noticed an issue on the test net, where one of the blocks was corrupt. I talked about tuple space mismatch earlier and that was being addressed or is being addressed separately in in the prs. But this one was this block corruption is a new one that also shows up as a tuple space. I mean, basically, when we set up a space problems, it’s roughly saying there is a problem in the state somewhere. So this is something that we’re investigating as to why this is being caused. So we went ahead even though this is just on the test net we went ahead actually created Tomislav created a proposal to say, well, if a similar thing happens on the main net, how do we proceed? So that one incorrect block doesn’t stop the network. So he’s he has put together a proposal, the team has reviewed that the proposal is to correct and proceed in a situation where a block is corrupt for some reason. So we’ll probably have a little bit more discussion on the tech governance meeting about that. But with at least the team’s review at this point in time, we’re happy with the proposal and we will proceed to implement that after the last finalized state. There was also a discussion on once contracts are up on the main net, you know, what is the methodology to get them updated. So there was a, Greg will speak more to this. But basically to distinguish between what is a shard level configuration versus what is a contract or protocol level contract change, and how do we go about that. So Greg will be speaking more to that. Everything else I had mentioned earlier in the previous week in the last week, so earlier, so some of that work is ongoing. I already spoke to the SRE piece about the fact that we are moving some of the validator nodes from Google to IBM. We already moved the observers and we’ll ultimately exchange, one exchange node over to IBM. In the tech governance meeting last Thursday, which this is normally a 10 Eastern or it’s open to the whole community or anybody else that wants to join. 10 Eastern 7am Pacific. So what we what we covered in the last session was we agreed to expose the RChip process in a broader way in the same repository where the RChip issues are being entered discussed and or prioritized and dealt with. So that’s we’re taking the, the RChip process that’s on Atlassian, creating a modern version of it and putting it on on GitHub. And any new variations and or changes to that would also be on the same RChip repository so people can review that or comment on it. We discussed the risk of someone sending many deploys without sufficient Rev for each potentially causing a network slowdown and spamming the log, those kinds of side effects may be caused. So there was discussion on this and potential ways of remedying this, we did not quite conclude on what should be done. But this is something that we will continue and perhaps either create a task in the development repository or on as an RChip depending on what needs to happen there. And then nutzipper is adding a couple of RChips, specifically relating to this shard configuration and what can can be changed or configured at the shard level? What is what is a core contract? And how can the POS contract be made mostly untouchable, meaning it doesn’t have to be touched for shard configurations, so it would read the shard configuration and continue with that. So this is part of what Greg is going to address now. So that’s what happened on the tech governance. And then I was not able to attend the RChat meeting this last Saturday but I understand there was progress made and green there is more involved with helping that effort off RChat and then Raphael at some point when he’s ready, he’s going to do the next demo of is going to demo the next iteration of Dappy and also teach people how to use Dappy to create their own pages and blogs or whatever on on Dabby. So that’s my update. Are there any questions on any of this before I hand over to Greg to discuss the items I mentioned?

right over to Greg.

Greg 13:42
Thanks for I appreciate that. That was a good summary. So kind of most important for this community, I think is that we want to make a distinction between things that are governed at the protocol level which means that we will need to, you know, that’s the raison d’etre for the cooperative, right? The cooperative is here and people can join the cooperative easily. So that everyone has a shot at participating in the governance of the protocol. And we want to distinguish that governance from specific parameters that are associated with a particular shard. So the the the main dividing line, sort of one that we can easily get our hands around is configuration parameters are shard level things and smart contracts are protocol. So code code represents protocol. configuration parameters are shard level things that should be relatively straightforward to understand, relatively easy to discriminate and determine. So that does, one of the consequences of that however, is it doesn’t mean that someone Who launches a shard in which one of the smart contracts has been modified? For example, the most important one is the proof of stake contract. So you could imagine that it you know, someone launches a version of the shard and they modify the proof of stake contract, does that immediately disqualify them from participating in the shard tree? And the answer is no. What it means is that everyone has a chance to review whether or not they want to engage in or participate in transactions that touch resources in that chart. So and you need to think to one way to put this in perspective, I guess is the best way to say it is the sharding mechanism is also the mechanism for interoperability with other networks. So the the idea is that we will be able to integrate and interoperate with etherium and other other kinds of block chains, as if they were shards mounted on our chain. So, so obviously they don’t have the same protocol. They don’t have the same smart contracts running, they don’t have the same code running, essentially. And so so, so this dividing line doesn’t protect doesn’t prevent shards that do change the protocol from participating. But it gives anyone who wants to engage which transactions that involve resources in that shard the opportunity to decide whether or not that’s something they want to participate in. Any questions about that sort of basic policy framework? This is where it’s really important that as Co Op members you understand what this means and our rights and obligations with respect to maintaining the protocol.

Okay, I guess this is perfectly clear and no one has any questions about this.

All right, moving on to the the other piece of the puzzle, what Rao was talking about in terms of our in terms of sequencing and resources on the on the dev side, we want to make sure that before we go any further with block merge, and things like that, that we have nailed down what we believe to be these critical bugs. So the corruption of blocks and the and things that are related to that. So there is some work that we will be putting first to make sure that that’s taken care of. The team was, we did a review of the design proposal to address this issue. And we’ll be, you know, as we have more estimates on what that will take, we’ll make sure that the community knows but this is the right thing to do. And this is related to other decisions. So, for example, until we have blocked merge, we will still be having blocks submitted in Round Robin and because of that, it does not make sense except in a few exceptional cases, you know, members who are close to home to have nodes outside of the fold. So for example, if there was an exchange that wanted to run their own nodes, for the next couple of epics will be the co op who will run the nodes on their behalf. So that the co op is the one that’s on the hook to make sure that those nodes are up and responsive so that the network doesn’t get stuck because one of the nodes is stuck. But then after block merge comes online, then it will make sense to transition nodes that the COP is running on behalf of other parties over into their care. Again, there are some exceptions here. Some some folks who who braved braved the the early, early stages, who will be running their own nodes. And that’s also an important part of the mix because it gives us key information about environmental conditions that we can’t simulate except bye bye You know doing it. So but but by and large, that’s the policy. And so some of these decisions bear more weight. So if we can’t have a critical bug, like the block corruption bug with validators in the wild suffering that potential situation, so better to have the nodes under the co op control, and, and then as we nail this bug, and then we get blocked merge, then we can have nodes being outside of the control. Hopefully that makes sense. Any questions or comments about tha

Ian Bloom 20:47
Going back to shard configurations, because there were no questions there. Could you perhaps elaborate and paint to maybe a couple other scenarios you mentioned, perhaps shards are running ethereum, but if you go into a little more detail and even where there might be conflicts or what has to be agreed upon between shards,

Greg 21:10
So in general, what you’ve got is you’ve got the backing contracts. So if we just keep it homogeneous, so it’s just RChain shards, then the relationship is that the parent rev, backs the child’s rev in the case of a heterogeneous network, then there will be an essentially a contract enforced exchange rate. And corresponding contract that provides the, the atomic swap, so to speak. Um, so we’ve we’ve talked about this quite a bit over the last couple of years. Are there any specific questions that you have here? Yeah.

Ian Bloom 22:08
No, but but that that helps. The example you just gave.

Greg 22:12
Okay, cool. So then in that case, as long as the transactions stay within a particular shard, so they involve only resources in that shard, then they effectively don’t have to go up the tree, right? They’re validated at the child. If the transactions involve resources across two different charts, then you have to go up to the common ancestor to get proper validation. So the more more resources that you have that are crossing shard boundaries, the slower and more complicated you get in in terms of the consensus apparatus, so obviously, if you start having lots of transactions that cross these shard boundaries, then it becomes at economically advantageous for those resources to the shards that govern those resources to join forces and and become a single shard, essentially to merge in some way. And we’re hoping that market forces are sufficient to drive that but if not, then we can start looking at looking at automation of those kinds of processes to the to the extent that that’s possible. But that’s pretty far down the line, but hopefully people understand some of the implications here right. So transactions that are limited to a particular shard, stay within that shard and as a result don’t have don’t have the same kind of cost in terms of consensus. Transactions that cross shards have to go as far up the tree as the common ancestor. And then potentially all of the shards are involved in the consensus for those transactions. And so rejiggering the shards for popular transactions that involve resources across shards is the right thing to do to optimize the network. Any questions about that?

Okay, then, so those are the main technical, the main technical updates, we appreciate all those who have sent in their Rev. addresses. I think that we’re going to be putting out a tutorial video for how one might go about creating a rev address in this case. Ian’s posted in the chat about the the incentives for getting your REV address in before the 31st of July. Okay, and we’ll be putting out a tutorial for those people who are, you know, possibly, you know need some help generating a rev address.

And with that, let me turn it over to Darryl, who will do the community in review segment.

Darryl Neudorf 25:50
Hey, everybody. So here’s the community Week in Review for Thursday, July 9 to today, Wednesday, July 15. On Thursday July 9, it was the Governance Committee meeting, the committee discussed the process of providing Governance Committee meeting summaries to the members via Google Docs and Discord. Steve Henley presented the RChain Co Op strategic plan and how it relates to the Governance Committee. In addition, the committee discussed how to improve the quality of the strategic plan and identify individuals with whom to engage to accomplish this.

On Friday, the climate coordination RCast. This week, we discussed the recent flooding in Newport Beach and an increase of plastic pollution in the oceans due to COVID. This was followed by a discussion on fractals as well as how Tesla is now worth more than Exxon, furthering the signal that a major shift has occurred away from a fossil fuel dominated economy.

On Saturday, July 11, there was the RChat call. The discussion revolved around logistics of minimum requirements of the voting dap, Jim questioned how Dappy, Zulip and RChain all interconnect and the relation between Theo’s anonymous functional voting with liquid democracy decision making. More digging into how DAppy, Zulip and RChain all interconnect. Dan is going to work on mapping out a flow to find the path of least resistance. On Monday, July 13 was a Casper stand up. And this week’s Casper standup related sharding to the world wide web. Also on Monday was the blockchain art call, and the discussion revolved around the logistics of turning Eric’s work on his master’s degree into a viable software project. Also on Monday was the China team call and the China team work towards finalizing contracts for both the financial and development community marketing proposals. On Tuesday, the RChain education meeting, there was a presentation of the design of a simple Rholang language written in Scala. The main focus is to describe the state and operations which manipulate the state. The example also defines structural equivalence and simple reduction rules. And also yesterday, the communications working group meeting, we mainly discuss the China marketing plans and how to develop and integrate with them. And there was also the app developer working group meeting where they built an updated Zulip voting bot as a potential starting point for Co Op voting in November. And then today, this morning’s dev stand up they did a walkthrough for each of the wallets and went through the process of how to generate a rev address for voting. And just an hour ago and Jim’s room the members Hangout, we discussed the concept of creating a hardware chip for our chain. HJ brought up the news that Tunisia is launching their own cryptocurrency we discussed Preparing walkthrough vids to demonstrate how to create and submit REV addresses for the upcoming AGM voting process. And Jim showed his efforts towards building a Zulip voting bot. And that brings us up to now.

Ian Bloom 29:15
That’s a lot of activity. Thank you.

Greg 29:18
Indeed. Any questions for Darryl about the community and review?

Nora Germain 29:25
Only if he has ever considered a career in the mainstream news?

Darryl Neudorf 29:33
I don’t look good enough.

Nora Germain 29:34
That was done so well, as Theo also said in the chat.

Greg 31:01

Very good. So in terms of additional outreach outside of the RChain community, so yesterday, Mike, stay Christian Williams and I had a very good engaging comment. versation with Gregory Rosso and one of his graduate students, Gary rose, who is the principal behind the K framework and matching logic. And so we were we were sort of comparing notes about Operational Semantics in Logical Form which used to be called LADL. And, and matching logic and the, you know, sort of differences in approaches and what our, what our aims and goals were. So that’s that was a surprisingly animated and engaging conversation. So, we look forward to additional engagement there. And then, this Friday we’ll be having an AMA with Bihu, which is a blockchain media operation in China.

So the topic for the AMA is the role of types in refactoring the internet, which is that will give me a chance to sort of warm up more detailed technical talk that I’ll be giving to protocol labs in August. So any questions about those? But that’s I think so. Yeah. I, they’re largely. Yeah, I think so. They’re Chinese operations. So it’s hard for me to ascertain You know what is their properties versus another companies. Okay. Any questions or comments from the community? Going once, twice. All right. Thank you so much for your participation today and hope everyone is staying safe. And I will be seeing some of you on Friday. I’m sure.

Weekly media to check out:

Watch the Co-op’s past “Debriefs” and Co-op Podcasts at

Watch weekly Casper (Proof of Stake) meetings (YouTube Link)

Listen  to weekly Co-op Podcasts (RCasts) or on youtube:

Subscribe to RCast on iTunes | Google Play | Stitcher | Spotify

Co-op Led Events: members can join via Discord

Mon 7AM PST / 2PM UTC: Casper POS Standup (Youtube)

Tues 7AM PST / 2PM UTC: “Teach Out”

Wed 11AM PST / 6PM UTC: “Community Debrief” (Youtube playlist) (@leiterhaus#0430)

Th 7AM PST / 2PM UTC: Tech Governance

Th 9AM PST 4PM UTC: Governance Working Group (@jimscarver#5578)

Fri 8:30AM PST / 3:30 PM UTC: Climate & Coordination RCast (Youtube playlist)

Friday  11AM / 6PM UTC Member Q&A (@leiterhaus#0430): See weekly #friday-qa-xx-xx channel for details

Join us on the Co-op’s Discord