Witness Statement for @reggaemuffin – Proposing Hardfork Adoption Requirements

in #witness-update6 years ago (edited)

image.png

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
  • 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
    • 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.


image.png


image.png

Sort:  
Loading...
Loading...

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 VP mana has recovered from the HF20 wipe-out)

A testnet that mirrors the main net
...

  • where users interact and try to break things

This is where we should add a decent bounty and anyone discovering a bug should be rewarded. Then you will see lot of people jumping in and trying to break things.

I also would add a topic:

  • communication ... communication ... communication.

The super-secret-witness-channel is a closed black-box that should be at least read-only for other witnesses.

Wouldn't we need to implement some kind of Worker Proposals to be able to offer a Bug Bounty from the Reward Pool? Or are you saying Steemit and the Witnesses should fork out for it?

Yes for the bug bounty...its the only way to align interests...

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".