Tech update:
https://rchain.atlassian.net/wiki/spaces/DOC/pages/1287421953/Community+Update+132
Wed, 8/12 11:57PM • 35:15
Greg Meredith 00:04
All right, good. Looks like we’ve got a good smattering of folks. We have an exciting debrief today. As as people know, we’ve been rolling over the network to the next epoch that has unveiled some interesting aspects of, of the code. So what we’ll do is we’ll give a round give the sort of normal debrief, and then I’ll pick it up and talk about the last 24 hours or so. And then we will move on from there to business aspects of staking that are public or can can go into public channel and then we’ll move from there to the community in review and rounded out with any additional questions for the community. So hopefully that that works as a shape for the meeting. So without further ado, let’s turn the mic over to Rao.
Rao Bhamidipati 01:10
Okay, um, I think that everybody should be seeing my screen that says Community Update 132 dated today. So, basically, as of last week, we were running 0.9.25.1 on the main net. We updated all the nodes to 0.9.25.1. At the moment the main net is closed. Like Greg said, we’ve been trying to get ready for the epoch change at the 250 k block size. And that means we need to get the new validators bonded and the request for unbinding the validators at the 250 k block they all need to be in before the before we reach that epoch change limit or block size. And to that extent we started working on that, as of right now, the main net is that, I think 52 blocks short of the epoch. So we started to work on this bonding and on bonding requests, and then I’ll talk to that in a little bit more detail after I do an overview of where we are with the different relases and then Greg will cover that in a lot more depth. So, basically, as we were doing these changes, I mean, if you recall from my previous like last week’s update, I did mention That, 0.9.25.2 is a release in which we’re working on some security bugs as well as testing and improving bonding and onbonding process. The intention was that we would have been able to release this, as you know, before, yesterday, but as it happens, this testing and improving the bonding and onboarding process took more time and still revealed some issues yesterday, as we were getting ready for the epoch. So what we now did is that we have the issues that are identified are resolved, now in a PR, and then that we’re releasing as 0.9.25.1.1 I know there’s a lot of sub release numbers, which I don’t personally like but we will standardize that numbering scheme to the, there is a thing called semantic versioning, which is the industry standard for release names, or release tags. So we will change to that over the next couple of months. But for now, we wanted to leave 0.9.25.2 to indicate this milestones when everything is complete, including the security bugs. 0.9.25.1.1 is the intermediate release we’re doing now that you can see that’s kind of tagged already, and is on the GitHub. So this is the one that will be running now on the main net, and has been tested on the test net and dev net. And this includes improvements to the bonding and unbonrding process. So that’s what those are, will speak to in a little bit. So that’s where we are relative to the media. It releases and then the bigger are the other kind of longer term or not longer term but near term. larger scope really is this on 0.9.26 release, which will complete the last finalizes state. But as you can see, we have 0.9.25.2 to go through, and then 0.9.26. So that’s kind of where we are with releases. Nothing has changed in terms of planning for release 26 or 27. So I’m not going to cover that in a whole lot of detail. Where we are with the main net now: the main net is going to have 20 validator nodes, most or all of them on the IBM cloud in multiple regions and in terms of other things last week, In the tech governance, we discussed quite a few of the issues that were entered originally way back in 2018 by the development team at the time as potential things to resolve now, as it turns out, many of those are related to the kind of how many validators do you need for a certain number of blocks and how much stake deo you need for certain number of blocks, and things like that, essentially, what’s the relationship of network security to the number of validators and the amount of stake and things like that, and there has been also in the community there has been quite a bit of conversation and we’ve been working on that as part of the strategy group with some of the community members so we discussed models of how we may be able to get a grip on that as to what are the floor and ceiling if you would, within which we need to operate to ensure network security as it relates to validator economics, and stake, percent of stake in relation to what’s issued – all of that. So that was part of the discussion in the tech governance last week and the notes or at that link that’s provided. And we discussed the Excel model I said last week that we are going to get some of the community members are preparing an Excel model. That initial version of that was discussed in the tech governance last week. Other things there seems to be quite a bit of movement on the RChat, there is still help needed there so if folks are willing to help, there is a separate repository for RChat in the RChain community repository, feel free to pick any items you can work on over there. That’s the effort that’s based on zulip. Now, I want to kind of start the conversation on really what was going on with this, staking and preparing the main net for the pot change, and then hand it over to Greg to go into more detail.
Greg Meredith 08:42
Actually, we should check and see if there are any questions about what you’ve covered so far. Yeah,
Rao Bhamidipati 08:47
yeah. Are there any questions on any of these releases? So and whatever I said, so far.
Greg Meredith 08:58
Coolio.
Arthur 08:59
I have a question – it’s Arthur.
Greg Meredith 09:02
Yes.
Arthur 09:02
In the discussion with you Greg on all the Z k knowledge stuff. I’m not sure I’m seeing that. Can I get involvement somehow?
Greg Meredith 09:13
Sure, sure. Absolutely. You can you can help help me if you want. I’m working on a summary of RChain’s position on this stuff. So yeah, great. I’m happy we can set up some time to chat. Okay,
Rao Bhamidipati 09:31
so Arthur, I didn’t hear you completely what you’re talking about the privacy and zero knowledge proof stuff for
Arthur 09:38
Greg creating a position statement on the zero knowledge. You just got. Yeah.
Rao Bhamidipati 09:43
Yeah,yeah. Okay. Yeah. All right. Any other questions? Okay, um, so This 0.9.25.1.1 which is the release for improving bonding and unbonding process. We what we discovered as we were the main net was chugging along and then we shut it off for external deploys, and then started doing the bonding and unbonding deploys on that. And as we started doing that, we saw that the main net was getting a very high CPU and memory utilization. So slowing things down which surprised us so we started looking into that and the fix that is in there now for that situation is improving the dag store so that it doesn’t the whenever the as you do bonding and bonding, it doesn’t have to go all the way back to the Genesis to check for information. So that’s the fix that the team is working on right now,
Greg Meredith 11:21
actually, if I might jump in this Yeah, this this two layers to that, so. So, the the source of the problem, which we were able to verify is the fact that when a bonding request for a new validator comes in, the freshly bonded validator needs to be given sort of a, a Genesis like block right when the block upon which they can start proposing blocks until they have received blocks from other validators. If you don’t do that, then if you were to unbond everybody and attempt to rebond then they’d all be stuck waiting for everyone else to send them a block. And this is the same thing that happens with Genesis at the Genesis moment right at the Genesis moment nobody has any blocks, but they can they can proffer the Genesis block as as their own. So, this is the same idea: they have to have sort of a rock to stand on. So a Genesis like thing, and you know, you can debate as to which thing that is but the existing code use the Genesis block which meant that as soon as there was, the fork choice tip triggered a calculation from the estimator. Then it would traverse all the way back to Genesis to do the calculation. And that was causing all of the nodes to be slammed in terms of a CPU usage. So that’s that’s not a good thing. So the first step is to fix the existing dag store. So that the bonding request that’s already thereRao in the store doesn’t point back to Genesis, but points back to a much more recent block. Then the next change, and then you know, restart the network, make sure that they’re not slammed in terms of computation, which I believe has already happened is that correct, Rao?
Rao Bhamidipati 13:58
They tested on the dev net and test net, but they’re they’re beginning to do that on the main net. Okay, great, great.
Greg Meredith 14:06
So then the next step after fixing the dag store is to, is to fix the line of code. So and then there’s there’s some wiggle room, in terms of which blocks you can choose. There are two natural blocks to choose. One is more recent in history, in fact, as recent as you can possibly get for that newly bonded validator and the other is a little further back in time. So the one is the, the block that contained the bonding requests for the newly bonded validator is a natural place for that validator to begin with. There’s a little bit of you have to convince yourself that that’s okay, and the reason is that you can imagine that that block got orphaned. Well, if that block was orphaned, then the validator would never actually be bonded. And if it’s not bonded, then no blocks that are using it as a validator will be will ultimately be accepted by the majority of the stake. So in if the bond, if the validators actually bonded, then the block that had, you know, had their bonding request must have been finalized. And so that’s a reasonable beginning point. To kind of avoid all of that fancy reasoning. You can go further back in time and, and give the newly bonded validator the last finalized block, as was the case at the time of the bonding when the bonding request was packaged in a block. That’s a lot to take in. Any questions about what I just said? It’s all crystal clear then. It wasn’t it wasn’t, it wasn’t clear to us we had to argue for for quite some time before we convinced ourselves what the different choices were. But that’s, that’s essentially the minimal change that will make so that we don’t get this sudden spike in CPU usage, and the network remains usable. So those changes are being rolled out over time. We want to get a little bit more subtle about some of the things associated with the newly bonded validators and, but this really won’t hit us until the next epoch change, and/or when we have 100 nodes that are validating, so those are two conditions whereby, at which we absolutely have to have a couple of subtle points nailed down. And so we have a little bit of time to get those changes in. So we don’t have to roll those out at this time when we’re rolling the network over and keep the network down longer than is strictly necessary. Um, does that make sense to folks? Any questions about that?
Jim W 17:32
My question goes back to a change in the DAG or something that is changing history is like, like a fork?
Greg Meredith 17:41
it’s sort of like a fork, except that nobody has seen those blocks, right, those blocks. The block we’re talking about changing was the last block issued. And it’s the one that contains the bonding requests for one of the new validators. There’s only one new validator bonding request went in. And that’s when we saw the problem. And so we so that validator its last message, which is essentially its genesis, points all the way back to Genesis. So we’re going to change the DAG, so that instead of pointing to Genesis, it points to the block that was associated with its bonding requests. Does that make sense?
Jim W 18:35
Okay, so this is, like you’re changing the most recent block,
Greg Meredith 18:39
We’re changing the most recent block. Yeah. Okay. Yep. And, and that’s because, you know, and it’s the only one with a bonding request in it. So, so we’re not we’re not going back in time and rewriting history. It’s not quite like that. But I understand the concern. So, but this turns out to be like, the fastest way to get the network up with the least amount of risk. So that’s why we’re taking that path.
Jim W 19:11
Thank you.
Greg Meredith 19:11
Sure. No, thank you for the question is very important. Any other questions on this matter or related matters?
Darryl Neudorf 19:20
Well, I guess one question would be when is the ETA for when mainnet’s back up?
Greg Meredith 19:27
Um, I can’t I can’t give you a good estimate right now. It’s, it’s imminent, but I don’t I don’t want to you know, I don’t want to say anything and then have you know, some surprise come along, but it’s imminent you know. I wouldn’t be surprised if it’s up today or tomorrow. Should be today.
Darryl Neudorf 19:52
Okay, thanks.
Greg Meredith 19:53
Yeah, but do do note that Tomislav for example, worked a good 30 hours straight without stop. So and their time zones are shifted with respect to hours. So it might be the case that some members of the team actually have to get some sleep before we complete all the pieces of work.
Darryl Neudorf 20:13
That’s no excuse.
Greg Meredith 20:20
Any other questions, folks? Okay, Rao, did you have any more you wanted to add?
Rao Bhamidipati 20:32
Um, no, nothing, nothing on this at this time. But they are, they’re working to get the main net up. There. They are restarting the nodes and testing a few at a time just to make sure that both the testing is fast and also complete and thorough. So that’s kind of where we are at this point in time. So they’ll be testing that a few times before they go. Implement the change.
Greg Meredith 21:04
So we are in a position where so there’s, I think roughly 72 million are staked for epoch 2, so a lot of people have decided to stake. I think there was on the order of about three or 4 million withdrawn from the previous stake. So I think there’s some total there’s about 68 million fresh stake coming in. From the community. We will be as soon as the main net is back up, we will be sending out as a courtesy to the members who sort of joined in early and took on a lot of risk. We will be rather than waiting the quarantine period we will be sending out the steak. So we’re just waiting for Main net to get back up for those people who are withdrawing. Be aware that, you know, if you didn’t pay your fees up front, you’re not going to get your full senior edge will only get about 85% of your senior edge. I’m trying to think any other points about the the staking returns Rao that I’m not covering.
Rao Bhamidipati 22:24
Um, it just occurred to me that because I think we are like more than four months, right? It’s about 12 days or so over the four months. Yeah, so I think we need to pay see our do seniorage calculations with the extra days to even
Greg Meredith 22:47
or notice that we talked up the rewards, right? So that might balance it out. So that’s, that’s another thing is because the rewards were so small. We ended up with adding a little bit of slosh into that, again, when this is completely controlled by POS, and when the COP is not extending a courtesy, we won’t be able to do this except by some out of band process but because the co op is is providing this, this courtesy we have the flexibility to add a little bit more in terms of the transaction fees and which which we took the benefit of doing but that raises the specter we do need to have a conversation about raising the price of flow for some period of time. Just so that we can start to have validation be more convincing as a sustainable business. I mean, obviously the the right side of this to work on is to get more and more and more people working on dapps and using dapps on the network. And I have some some points to make about that shortly, but, but, you know, we can proceed on multiple fronts. So while we’re, while we’re working on that, we should, as we’ve said, since the formation of the Co Op, it’s probably a good idea to raise the transaction fees. We don’t want to do this right away, because that will impact the wallets that might have built in phlo price assumptions. And it will affect exchanges that also might have, you know, hard coded phlo price assumptions. So, so we want to roll that out carefully. But, but it’s, it’s a change that’s most likely to come. We definitely want feedback from the community, right? This affects everybody. And so the community you know, needs to weigh in and say whether or not you know, or what their what their opinions are about raising the transaction fees while we’re trying to build up the the volume of transactions.
Rao Bhamidipati 25:10
Yeah, I just wanted to add that the conversation really is about how do we ensure decentralization and network security is really the goal. So the validator economics and everything else is part of that to be able to say if you don’t have proper validator economics at any given point in time, you won’t get either decentralization or stake on the network. And hence that impact’s security. So that’s really the main driver.
Greg Meredith 25:47
Indeed, indeed. So So please, please, you know, don’t be silent on this point. You know, think about it, weigh in, give us your give us your thoughts, right, we need to tap into the collective intelligence. And, and make sure that this is this is a move that has, you know the support of the community all right with that unless there any other questions I’ll turn it over to Darryl to do the community in review Darryl
Darryl Neudorf 26:22
Hey everybody. I’m here is the community we can review for this past week. Uh, last Thursday in the Governance Committee meeting, the committee completed discussions on validator rewards, liquid democracy and multi stakeholder issues. The strategy improvement Working Group provided updates on their discussions with regards to sustainable economics for network security and decentralization. Also, on Thursday, the DAP developer Working Group developed and tested rholang log class to trace execution in production in lieu of access to stdout and stderr. I don’t know if I’m pronouncing that right. On Friday on the climate and coordination call Steve Ross Talbo t presented an idea around eco villages and how they could utilize RChain to globally and locally coordinate. Then I asked Greg some layperson questions about Operational Semantics in Logical Form aka OSLF, and how it applies to RChain. On Saturday was the RChat call where they developed sequence diagrams for voting with RChain and zulip chat. On Monday in the CASPER stand up call, Greg covered a small piece of Operational Semantics in Logical Form. Namely, the correspondence between bisimulation and logical equivalence for plain old Lawvere theories. And they talked about how to turn Lawvere theories into bi directional rewrite systems. Also on Monday on the Blockchain Art call they looked at gaming card Art daps and the hexagon RChain Dappy dapp use of non fungible ERC 1155 style tokens. Yesterday in the communications working group, we discussed updating the coinmarketcap info, working on or Instagram presence and Steve Henley suggested we use a Google Doc planner spreadsheet and we discussed searching out open source project management collaboration software that we could start using, and eventually even put on RChain similar to what we’re doing with zulip to RChat. Also, on Tuesday, the DAP developer Working Group completed work on new locker contract employing Deployer ID. And this morning on the members hangout in Jim’s room, Steve Henley presented some research he’s doing in regards to open source hardware. The group also discussed various open source project management tools that can be used by RChain. And Gary showed the hexagon game that they’re developing to run on RChain using Dappy. And that brings us to now.
Greg Meredith 29:09
Awesome. Any questions for Darryl? Very good. Any questions, topics, thoughts that people want to address? While we’re all gathered here together.
Theo 29:34
While we were still on the subject of proof of stake and an increasing amount of nodes to 100. I kind of reminds me when I was suggesting to change the proof of stake contract to kind of act more more as delegated proof of stake where people can actually appoint validators to it And but back it up with their own stake. So, essentially like as like a like staking but telling like this is the way this is gonna do all the signing and putting blocks on the chain. So, I was thinking is it since it has issues like we saw with steamit maybe we could kind of make a mix between the two and kind of, where for example, validator has to stake his own portion. And if people can, for example, create a staking pool and join the staking pool as a validator. For example, if I was to stake like 1 million REV right, I can also take in 1 million REV for other people, but I will not be actually holding those REV, but instead a smart contract will basically hold the REV and distribute rewards.
Greg Meredith 31:03
Well, you know, what I would suggest is to write up the details and give us a sketch of an argument as to why it’s correct. So with respect to Casper, we know why it’s safe. We have a proof of its safety. I have a sketch of a proof of how to ensure that it’s live. Yeah.
Theo 31:23
Okay. It’s staking pools, that’s kind of where the security issue coming comes in, because people have to actually trust the validator. Because why do they have to hold all the REV up upfront before bonding?
Greg Meredith 31:36
No, that’s not the case at all. You can write a smart contract on top of the chain that does all of that for you. That’s that’s completely outside of the co op. Right? That has nothing to do with the co op proper. If you just want to put build up sophisticated staking pools, I strongly encourage you to write up a smart contract that manages the staking pool. REV in a way that makes people feel confident and, and works with respect to the epoch changes. So, no, that would be that would be a fantastic effort. I think, you know, the more contracts we have like that, especially if we have some contracts that kind of lead the way so that people can start with that and go, Oh, well, what if you change it this way? Or what if you change it that way? And then that would be like, an excellent development of the technology.
Theo 32:34
Okay, that’s great, because I saw like, what if contract contracts as its own birth, could join the bond cannot do the bonding request and do all the staking that someone has to hold the private key and sign the transaction so I don’t know how it’s Yeah, but
Greg Meredith 32:54
yeah, so if you have multisig you can do that. Right. But then ther are issues associated with multisig, right? Because, you know, if you can’t get the community to agree on, you know, various time critical actions in time, then that there’s that’s a vulnerability. So that’s, that’s, I think it’s a really it’s a great problem to go tackle. have any other questions or comments?
Frank 33:23
I had just a general question about funding. But has there been any effort to try to get REV listed on Coinbase?
Greg Meredith 33:33
Not yet. As I mentioned before, I’m not pursuing any additional exchanges until after last finalized state is done and dusted. As soon as that’s actually running live. Then I will pull out the stops and approach several other exchanges. Especially Coinbase.
Frank 33:57
Okay, sounds good.
Greg Meredith 33:59
Yep. No, it’s a really good suggestion. And now is the time to do it for sure. Just, you know, waiting on the code to be there. Any other questions?
Darryl Neudorf 34:13
I just want to thank Tomislav, Ian, Rao, yourself, nutzipper. And anybody else who’s been like putting in all those hours over the last 48 hours or so.
Greg Meredith 34:24
Will, Gurinder. Exactly. Lilia Yeah. Oh, yeah. The team is so inspiring. It is such a joy and a pleasure to work with these folks. They’re, they’re tireless, they’re dedicated, they’re focused, you know, it’s like it, you know, it definitely makes me raise my game. So I’m really, really pleased to be working everyone on the team. All right, unless there is anything else to cover. Thank you so much for your time and attention and there will be so Some important updates in the Friday closed door session, which are, yeah, things I can’t talk about here, but we’ll talk about there.
Darryl Neudorf 35:10
Thanks, Greg. Thanks, everybody.
Greg Meredith 35:12
Think Thank you.