You may recognize me for my work or steempress or on my previous proposal which is coming to an end in a few days, so here I am with another proposal.
As you are probably aware Steemit recently released their testnet for SMTS This is great news because this means that it's also time for us (the community) to conduct tests and try to find all the problems beforehand, and this time it's special, this is the biggest hard fork that they have ever done. Basically every functionality is impacted one way or another. Which means there are lots of ways this can go wrong.
So it is crucial to test as much of it. Hence this proposal.
To me there are several components when it comes to "prepare for the hard fork"
Obviously testing, There are already some scripts that are running but I will be writing automated tests, spinning up various SMTS with various configurations to try to test as many SMTS (and others) configurations as possible.
I will test every functionality one by one and write complete test suites that anyone can run.
But testing doesn't stop here, we also need to test that the libraries are ready and up to date, so I will also test that libraries don't break when you execute those new endpoints. I will also test the most used libraries and submit pull requests to fix bugs that I find.
Reviewing the code
Reviewing the code is one of, if not the most important step, It's a long and tedious process that requires a lot of c++ knowledge in the case of the steem blockchain code. But if done correctly it allows you to spot bugs before they happen. It's important that the one reviewing the code is another person than the one who wrote the code because when coding you tend to tunnel vision and it's easy to miss that one edge case that will make the whole chain crash. This is why it is very important to have reviews from people outside of steemit to think outside the box and try to spot bugs, or not even bugs. It's also important if you want to suggest code improvements if you find a place where you believe there will be a scaling issue. It is also very important to do when writing tests because you can they find the pain points where you know the system might fail.
A big part of testing is that you get to have first hand experience with all the end points, which can be turned into great pieces of documentation. This is very important because without documentation, a lot of features will go un-noticed or unused because developers won't know how to use them. It is also very important to make sure that we make it as easy as possible for developers to build on steem and on SMTS. This is a crucial step to the SMT's success !
I have a lot of experience writing documentation, I will probably write a lot of examples on the steemsnippets repository : https://github.com/drov0/steemsnippets It's a repository that I have maintained for two years now and I have always been adding examples for the latest hard fork updates. So I am quite used to it.
I will test all of the new operations, review the code for each of them, write tests and document them. Once that's done, I will make an "SMT test factory" where I generate tests to try as many SMT configurations as possible and see if I can break them.
I will write reports on my progress every 7 to 10 days on chain, and you will be able to track my progress on a dedicated public github repository where I will share all of my code for the tests, my results and my reports.
I expect to be working on this for the whole duration of the testnet, and I expect that it will last about 3 months. Starting from the 24th of october to the 24th of january. If the testnet ends sooner I will delete this proposal.
I am asking for 180 SBD per day.
Some might say that testing hard forks is the role of the witnesses but not all the witnesses have the technical capabilities or the time to perform a lot of tests. This kind of proposals are very important for the ecosystem because it means that they can then read on my reports to see what I tested, take my open source code and modify it to test other things or an edge case that they might have spotted or make a more educated decision on whether or not they should support this hard fork.
More testing is never a bad thing, especially when the chain's health is at stake. Nobody wants to see the chain stop like in hard fork 20 or spend another all nighter waiting for their nodes to replay like in hard fork 21. I think that this shouldn't be the only "test hf23" proposal.
Finally this is not only about making sure the hard fork works well and then throw everything out. It's also about making documentation that will be useful for the whole community for the months and years to come.
Here is a few easy links to vote on the proposal :
You can view all View all the proposals on:
If you have any questions or suggestions, feel free to leave a comment.
Thank you for reading,