Witness Statement for @reggaemuffin – Proposing Hardfork Adoption Requirements
Let's all be real, hard fork 20 did not go as well as we all would have liked. And witnesses have their share of the responsibility for this. As I already said on the utopian radio show I think all us witnesses should publicly state our expectations, requirements, and obligations for future hard forks.
This way the community can vote on what they want to see, Steemit inc. can prepare and ensure new forks are meeting these requirements, and the community developers can actually themselves develop forks that can be adopted. We all need to actually use the decentralized decision features that this wondrous blockchain has, and have discourse over it. I think this will be a great step to improving Steem as an ecosystem.
So without further ado I would like to state the first draft of my public witness statement:
My Hard Fork Adoption Requirements
- A code freeze with a tagged release
- meaning once testing started no new code changes.
- If a new change happens, testing may have to be restarted completely to account for it
- A testnet that mirrors the main net
- where all consensus witnesses run a server on the old version and migrate to the new version to properly simulate a fork
- where users interact and try to break things
- where enough tools work so that everyone can connect just like they would to the main net
- where DApps can be used on in a beta stage
- that has all the blocks from mainnet from at least the last 7 days applied in normal time and then undergoes a fork (so the process will take 7 days per fork)
- where we simulate the hard fork at least three times after the code freeze and before the real hard fork date
- Documentation on the changes and what code parts to look at
- with developer discussions on the changes that explain magic numbers and thought processes that went into the code
- for example how the RC parameters came to be
- with developer discussions on the changes that explain magic numbers and thought processes that went into the code
- If possible only one major change per fork and rather more forks.
- Give witnesses the possibility to do a full code audit of the changes. This means it has to be a manageable amount of changes.
- If something changes the way the Steem blockchain works in fundamental ways, it should be it's own fork.
- For example instead of the current HF 20:
- Fork 20: SBD print rate changes
- Fork 21: Voting Mana introduction
- Fork 22: Resource Credit system
- Fork 23: Discounted accounts
- For example instead of the current HF 20:
- This will motivate everyone to ensure the existence of better tools and systems supporting frequent hard forks and change the whole process into a routine.
- Even though exchanges will also have to participate in more forks, having a routine could also benefit them feeling save while upgrading.
As a witness I pledge to do these things for each new fork:
- Evaluate the fork to my requirements and do a public statement at the start of the code freeze, if I accept it to go into testing.
- Test the fork and at the earliest possible moment publicly state, if I will adopt it and why.
- Document my process of testing to keep everyone informed.
- Do a code audit of all changes to the best of my abilities.
- Run a testnet node, backup, and seed and contribute to testing.
- Develop my own publicly stated testing protocol that I will follow, and document all results.
- Always have one node on the old version, should problems arise, and be prepared to roll back changes.
- Always be available for any questions users may have about the network.
If I become a top 20 consensus witness, I additionally pledge to:
- Follow with the changes on github as they evolve and review/participate in the process.
- Implement community requested changes into patches/forks.
- Always do a full code audit with public results of new changes.
- Run a staging version of all my apps on the testnet.
So far I am witness rank #34 which is quite high but still no place to have my opinion heard. So I hope that this post can spark a discussion, and other witnesses do similar statements. We should not forget that the top 20 consensus witnesses are the ones making most of the decision, and they are under the most amount of pressure. But they also earn the most amount of rewards, so I would welcome them having public statements on what their stance is.
Update to @therealwolf: I will pitch to all the witnesses, so that they make their own list of requirements and pledges. My list is just a suggestion, please don't take it as the only way to do it. And I think in the near future I will try to have my witness votes reflect if someone has a pledge or not.
As always, feedback is highly appreciated and I will post updates to this as discussion evolves.
I will follow closely what the other witnesses will share in terms of self reflection, learnings and what they pledge to implement and/or request. I will then adapt my votes accordingly.
Thanks for initiating this!
(I will vote your post when my
VPmana has recovered from the HF20 wipe-out)Sounds like some common sense to me. A lot of this is just best practise for software development.
I'd personally like to see an agile development methodology adopted where we have a formal product backlog that people can vote on and actually have some relatively transparent and perpetual development going on via fixed sprints (ala scrum).
There has been far too long between updates for STEEM and the development processes that are being used are incredibly immature. For an ecosystem this large (and valuable!) it really is inexcusable.
Which is why I think establishing such standards in a decentralized manner is important. If all witnesses state how they want development to happen then voters can make an informed decision about it in their witness votes.
I already had plans to make a post similar to this and have been calling for many of the very things you’ve mentioned here. This would be a great start for all witnesses, but especially for those who have been raking in vast amounts of witness rewards for a very long time.
I’ll have my own post on this matter soon. Thanks for bringing this to my attention. It’s a solid plan for any witness to adopt.
Looking forward to your post then! I would enjoy if you would tag me in it so I get a notification :)
I knew poking you to come onto the show was a good idea. Just didn't know how good. <3
Great to hear your thoughts on the radio show last night, even better to see this statement as a follow up.
I hope to see similar statements from the other witnesses. Solid list of ideas to create a robust testing environment. Thanks.
This sounds very good to me. We can all agree that HF20 didn't go as well as it could have, so I'm all for any measure that might prevent this problem from happening during the next hardfork.
One thing I was thinking about though, that I haven't seen anyone talk about, is the potential for witnesses to add bounties to people who can break the testnet. From what I understood, the testnet didn't really have a lot of data, but a bounty might attract a lot more people to test it. I'm sure the top 30 witnesses would not have too much trouble pooling in for a bounty. This last part is obviously directed towards all witnesses on the blockchain, not only @reggaemuffin, but it was something that popped into my mind when I read the post and comments here.
On the radio show @jedigeiss and @techslut suggested that Utopian could post a bounty for users to break things. Which is a great idea so my witness pledge factors it in and asks for an environment where such a bounty can actually have an effect.
Ah, it's great to hear that other people also had this idea. Let's hope something like that could happen then. I can definitely see some people trying their best to break the testnet if they could get a few hundred STEEM or so for doing it.
I also agree with everything.
I would be happy to mirror a real blockchain testnet on my machines and run tests on it, provided there are clear instructions on how to do it. Will obviously modify steem.supply to work on both networks, the way ETH uses mainnet, Rinkeby, etc.
Probably the only way I would differ is about the incremental hardforks, like one feature per hardfork. There are many factors to be considered, and one big upgrade every few months is easier to be adjusted to than just smaller things. I think mostly in terms of user's expectations here, and not in technical or coding terms, because in those terms it obviously makes sense to go baby steps. But as a regular Joe I want to have less of a cognitive pressure on the actual usage (oh, shit they changed this thing again, when did it happen, etc..)
All in all, I agree HF 20 was actually a failure and should be recognized by everybody involved as such.
As an entrepreneur, I know oh very well that the most important and long lasting lessons (which served me so well along the path) were learned from failures recognized as failures and not disguised in "successes".
You got my attention @reggaemuffin. My personal take is to reset my witness votes. I have 28 witness votes awaiting for people with competence in the software industry. So far we have no competent witness sitting on the top 20, because all they accepted to release HF20! We need the right witnesses making the right decisions!
So... just following you for now but I hope to see your promises becoming reality!
Great ideas @reggaemuffin which is why I know that @ned and Steemit Inc will completely ignore everything you have said in this post because they have made it clear they like their rogue fluid approach to development and releases.
The problems we are seeing are sadly not problems witnesses alone can fix, they are fundamental issues inside Steemit Inc itself. The problem is the code that makes its way to the witnesses is broken and Steemit Inc provides very little guidance or support for a testing and release phase.
The blog post they put out where they kept saying they didn't know how things were going to go and they would "wait and see" was really concerning to read and knowing the issues we saw at launch were not easily addressable, HF20 should have been wound back.
A company like STINC which has the funds to hire developers and proper resources seems to be happy hiring friends and people they know instead of the best candidates possible. From what I can see, there are two main developers at Steemit Inc doing all of the work.
The real fixes are:
https://api.staging.steemit.com/as well as a staging environment for Steemit itself:https://staging.steemit.com/From what I know Steemit Inc. would really appreciate the witnesses to give such a pledge. But that is for them to state. If all witnesses are saying that they will not adopt a fork with X then Steemit Inc. knows what is up and won't do X, as we saw with HF17.
From the things you mention. Many of these are already there or not possible in the way you said them. Depending on Steemit Inc. to cure us all is in my opinion not the way to go. And yes, we need to hold witnesses responsible. And to be honest that is the task of all witness voters. Like in politics, if you dislike something, talk about it.
But I digress, this post was about the witnesses owning up to their part of the responsibility and publicly stating their stance on how development goes. If a witness will take your list as requirements, then definitely vote for it :)
I have to admit I agree more with @beggars than with you when it comes to the responsibilities of the witnesses. AFAIK few of them are experienced developers or sysadmins while many Steemit users have such a background. Requiring witnesses to run a test node seems absolutely reasonable to me but it's a major change in how witnesses are chosen and that's why I'm afraid it ain't gonna happen. Because for 35 years we all expect computers to work, not to be maintained heavily.
What should not be forgotten is that all of this could be a blue-print for other blockchain-based projects but I suppose you're already aware of that ...