Hello Steemians! This post relates to our witness and the tests we have carried out in preparation for hardfork 21 (HF21). As most of you hopefully know, @steempress operates a witness and is currently rank #24 on the witness list. With that comes the responsibility to participate in testing and contributing to updating the blockchain such as a hardfork. If you follow this account primarily for updates on our plugin and are not interested in a highly technical update, this post may not be for you. However, if you are interested in the contents of the next hardfork, in the technical details for it, or overall want to see what else we do as a witness, then please read on.
HF21 was released and tagged last week, meaning it's now or never to test everything. You can find the whole release notes here: https://github.com/steemit/steem/releases/tag/v0.21.0.
HF21 is scheduled for Tue, 27 August 2019 15:00:00 UTC (a date that may be subject to change depending on the number of found bugs or issues in the proposal). As it is crucial to test things thoroughly in advance before such a release, we figured that we would show some of our own findings and share with you the work that we have done testing HF21so far.
There are four new operations, the first three are linked to the new proposal system that we encourage anyone to check out here who haven't already.
- create_proposal
- update_proposal_votes
- remove_proposal
- account_update2
In order to test those, we went the stem-js route because it means we can test the whole pipeline from lib to rpc api. Since that's also how most developers will interact with the chain, it makes sense to test the libraries as well as the chain.
Account_update2
This is pretty much a mirror of the account_update operation, with the only difference being that it doesn't need the active_key. This is a great change because it means that apps can now offer trivial yet useful options such as changing a user's profile picture inside the app without needing their Active key.
Account_update2 has the same parameters as account_update, but we weren't sure what the rpc operation name is since there isn't another operation that ends with a number. account_update2 is the function name that was widely used everywhere in the c++ code, but it could be account_update_2 depending on how they interpret snake_case. So we went with account_update2 which seemed like the right choice.
Basically, since the parameters are the same, one should be able to take a working test case from account_update and just update it slightly to take a posting key instead :
const wif = steem.auth.toWif(username, password, 'active');
let ops = [];
let account = await steem.api.callAsync('condenser_api.get_accounts', [[username]]);
account = account[0];
ops.push([ 'account_update', {
'account': username,
memo_key : account.memo_key,
posting_key : account.posting.key_auths[0][0],
active_key : account.active.key_auths[0][0],
owner_key : account.owner.key_auths[0][0],
'json_metadata': "",
"posting_json_metadata" : ""
}]);
let tx = {operations: ops, extensions: []};
const result = await broadcast(tx, wif);
assert(result.error);
For reference broadcast looks like this :
function broadcast(tx, wif)
{
return new Promise(resolve => {
steem.broadcast.send(tx, {wif}, async function (err) {
if (!err) {
return resolve({error : false, err})
} else {
return resolve({error : true , err})
}
});
});
}
Which works perfectly.
But if we try to do the same with account_update2
const wif = steem.auth.toWif(username, password, 'posting');
let ops = [];
let account = await steem.api.callAsync('condenser_api.get_accounts', [[username]]);
account = account[0];
ops.push([ 'account_update2', {
'account': username,
memo_key : account.memo_key,
posting_key : account.posting.key_auths[0][0],
active_key : account.active.key_auths[0][0],
owner_key : account.owner.key_auths[0][0],
'json_metadata': "",
"posting_json_metadata" : ""
}]);
let tx = {operations: ops, extensions: []};
const result = await broadcast(tx, wif);
assert(result.error);
We get Assert Exception:itr != to_full_tag.end(): Invalid operation name: account_update2 which is odd, because if we remove the parameters memo_key, posting_key, active_key, owner_key it'll tell us that it needs those parameters (which is also odd since the documentation states that they are optional). This means that it does recognizes the operation account_update2 and it's needed parameters but where it somehow won't work if we include all.
After some back and forth with @justinw and @vanderberg, we found that the current testnet was deployed before
account_update2was added tocondenser_api. Which was causing the bug.
We then realized that there was an issue with steem-js, namely that it would make the parameter memo_key mandatory. I assume that since account_update2 has almost the same parameters as account_update, the same validation was used.
The issue is that if you include thememo_key parameter, then account_update2 requires the active key to execute (since you're trying to change your memo key). Which defeats the whole purpose of account_update2, an account_update with the posting key.
So since this is an actual problem, we've opened an issue here: https://github.com/steemit/steem-js/issues/446
Thanks to @vanderberg a fix was found quickly and we've opened a pull request to fix the problem:
https://github.com/steemit/steem-js/pull/447
create_proposal
As the name suggests, this operation allows you to create a proposal to the SPS. It's parameters are:
creator: creator of the proposal
- receiver: receiver of the daily sbd
- start_dat : starting date of the proposal
- end_date: end date of the proposal
- daily_pay: daily pay (in sbd)
- subject: basically a title
- permlink: permlink to an existing post describing your proposal
These parameters are pretty straightforward. We managed to create a proposal very quickly meaning that the base case works. We then checked the blockchain code to see what kind of verifications had already been done to know if some things were not tested yet. Those validations would be located in /libraries/chain/sps_evaluator.cpp. Then there's validation regarding the types themselves during casting, for instance, dates are verified by the time_point_sec.
So after reading a bit here's the tests regarding the parameters that are in the blockchain:
- end date must be in the future
- proposal creator has to exist
- proposals receiver has to exist
- permlink must lead to existing post exist
We went on to test the following cases to give you an idea:
create_proposal normal
create_proposal ends before today
create_proposal negative pay
Proposal permlink doesnt exists
Proposal daily pay overly large number
Proposal daily pay overly large title
Proposal start date does not exist (start date was set in -2018)
datetime underflow (start date is in 1501)
Proposal start date is far in the future (proposal payout is between 2040 and 2041)
Proposal duration is less than a day
Proposal duration is less than an hour
And the chain handled everything very well!
The only part we found questionable was the lack of any check to prevent a proposal from being entered that would end before a day has passed. This, however, is not a big problem in itself as it would hurt the user and not the chain and could be handled by and front ends through which most users would submit a proposal. It is worth noting though.
update_proposal_votes
There are way fewer parameters to this call and thus there is less to test, it works very much like witness voting.
the parameters are the following:
voter: Your username
proposals_ids: ids of the proposals you want to vote for (array)
approve: add or remove votes for the proposals_ids array (true or false)
And there were no problems as far as we could tell. Here is nevertheless a list of the tests that we conducted:
proposal vote
remove votes on one
vote with no proposal_id
vote nonexistent proposal id
vote with an id that overflows
vote on a list of existing and nonexisting proposal IDs
Side note on the total_votes value of the find_proposals operation.
One might want to test the result of voting with the find_proposals call.
Here's an example from the call:
Even if you vote for a proposal, the total_votes field will stay at 0. This is because vote calculations are not executed instantly but instead calculated during the "maintenance time" of the blockchain. For those who don't know, this is a time where the chain executes computationally intensive tasks and happens roughly once every hour.
As @blocktrades puts it: "think of it [the vote operation] like mailing in a vote then waiting for the election time for it to count"
Remove proposal
Since this operation only serves to remove a proposal, there are only two parameters, and thus not much to test. These two parameters are:
proposal_owner // self explanatory
proposal_ids // array of proposals ids
our test cases were as follow :
remove proposal
remove proposal that has already been removed
remove a proposal that we do not own
remove several proposals that we own
remove several proposals including one we don't own
remove a proposal that doesn't exist
In the end, we found no problems here, except perhaps the fact that one can remove proposals that never existed or that were already removed.
While this has no significant consequences, it is still a useless transaction for the chain.
SPS beneficiaries
One new feature in HF is the ability to fund the SPS through beneficiaries. However, since the SPS only operates with SBD, there is now a new logic that will automatically convert the STEEM and SP to SBD tha can be used for the SPS.
So we tried this out by creating a post with 100% beneficiaries to the SPS: The post went through without any problems and payout happened as expected with the SPS also converting everything properly.
Conclusion
In conclusion, the only "real" problem we found did not come from the blockchain but rather the tools above it. Which is a really good thing!
If you are interested in seeing our testsuite, here's a gist with all of it: ~~~ embed:efb8f0a134851030ac2b434520ba333b. Note that mocha is needed in order to run it. gist metadata:ZHJvdjAvZWZiOGYwYTEzNDg1MTAzMGFjMmI0MzQ1MjBiYTMzM2IuIE5vdGUgdGhhdCBtb2NoYSBpcyBuZWVkZWQgaW4gb3JkZXIgdG8gcnVuIGl0Lg== ~~~
We are continuously performing more tests of HF21 ahead of its release and will let you know if find anything else that is significant.
We see it as crucial that top witnesses participate in thoroughly testing new hard fork proposals and to also allow the community and stakeholders to know what has been tested in order to minimize potential issues following a fork. If you appreciate our contributions as a technical witness, do consider voting for @steempress through the witness page or through steemconnect here.
Is all this the reason to why the price of steem is having a hard time.cheers mike
good work, glad to see updates like this that try to close the technical gaps many have in the explanation. Thanks.
Ótimo, mas apesar de tudo atualizações como esta precisarão estar em constante movimento, já que, por si só, a metodologias tem se alterado a todo momento.
Que?
That a witness has this type of interest, demonstrates responsibility and commitment to steemit, that speaks very well of you, I just hope that the other witnesses take an example and perform tests before the official launch of the HF, and communicate the results of these tests The other important thing that witnesses should mention is to evaluate a projection of: how would the price of steem improve in the not too distant future as a result of the changes that would be experienced with the HF. Greetings and thanks for sharing.
What does this mean? How is steem converted to SBD. Is the steem being BURNED?
Yep, the steem is burned and SBD is printed instead.
Fun fact you can do this now yourself with the
convertoperation, it used to be available on the steemit wallet but got disabled when sbd was above a dollar, because the convert operation always assumes that 1 sbd = 1$, so people were converting and losing money.Now is actually a good time to convert though as sbd is below a dollar ;)
Thx for your answer. But how will it operate when we are at 10% Haircut Debt Ratio?
SBD is stopped being printed?
It will be printed regardless as far as I know.
I love to hear of actual testing. Thank you.
On that subject, the tests you describe are strictly functional. Do you or do you know of anyone regression testing basic functionality for your average steemian?
To expand a bit on regression testing, the testnet is mirroring the transactions on the mainnet so if there was an issue with features that are currently live, we would notice it thanks to that.
Cool. Is it just mirroring though or is there actual physical actions being carried out independently through the GUI. I have had bad experiences of mirroring!
Thank you for the kind reply! Yes, we would also love to see more witnesses carry out testing and also report their findings.
Yes, we have mostly been checking for bugs and ensuring that that the new features work well. For the implications of HF21 on things like upvotes and post payouts @jga did a very thorough guide in two parts that you can find here.
Aw, thank you for pointing me at that post! Excellent! I will have to check to see if you are on my witness votes! If not you will be!
Thanks for testing and sharing your results :-) I'd love to see more witnesses do this as it helps gaining confidence - I'm voting for your witness from now on. Cheers!
Thank you for the nice feedback! YES, we would also like to see many more witnesses both carry out tests (some of course do) and share it with the community. It's not only important to ensure a successful fork without frustration for the userbase, but also good for transparency and showcasing what each does.
Thanks a lot for the vote, it really does mean a lot!
You guys doing a great job! Highly appreciated!!
Thank you, not only for testing, but for communicating about what you found.
Really appreciate the work @steempress team. This would definitely ensure a smoother post fork experience. Cheers!
It is nice to see test updates, thank you.
great work!
This is very good update. Good to see that you guys are making progress.
Great
This post has been resteemed by @witnessnews.
Follow @witnessnews to keep up with active witness updates.
Congratulations @steempress! You have completed the following achievement on the Steem blockchain and have been rewarded with new badge(s) :
You can view your badges on your Steem Board and compare to others on the Steem Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPTo support your work, I also upvoted your post!
Vote for @Steemitboard as a witness to get one more award and increased upvotes!
Is there a version in plain English, for the content-creators?
Hahaha, plain english is : We tested the hardfork, found no bug in the blockchain and one bug in the tools used to interact with the blockchain (not good) which we reported and fixed.
Great news! I am impressed
good work.
Good job guys
Great! Things were already too complex for the average person and now they are even more complex and we will all earn even less lol... Mainstream adoption here we come!! 📉