Yesterday, @blocktrades put out another one of his updates for the work his team was doing at the Hive's core, and not only.
What's different from the previous updates? We have a hived
release candidate for hardfork 26. Hived is that part of Hive that needs the witnesses' consensus to upgrade (i.e. a hard fork).
Once a release candidate is set, we are in the final line before the hardfork happens. No more new features are added to the release candidate, only bugs are fixed, if any are found in the final testing phase when more parties get involved. Blocktrades made a call to Hive app devs to get involved in testing their dapps before the hardfork.
There is now a mirrornet available that "mirrors" transactions from the mainnet (the current activity on Hive), so devs have real use case situations to test their apps in HF26 conditions before the hardfork happens. To be honest, I believe that mirrornet is very special, and I saw Dan (i.e. blocktrades) is proud of the testing setup Hive currently has:
All-in-all, I suspect we now have the most robust testing environment among all blockchain projects of any complexity.
In the release candidate for HF26, the date when the fork should happen is hard-coded as October 11th (2 days after Splinterfest is over), but Dan said the date remains to be discussed with more parties to see if everyone agrees upon it.
He also linked a Gitlab merge request, where the summary of changes since the last hard fork will be (currently incomplete).
The summary already includes enough elements, many of them of little interest to the regular reader.
From the elements that are already added to the summary, I'd like to list some that may have an impact on the regular user of Hive.
One-Block Irreversibility
That means all transactions should become final within a block (3 seconds), in most cases. Down from 45 seconds now. In practice, even now apps do consider transactions completed after a few blocks at most, but it's different when assurance comes directly from layer 1 and they can rely on the irreversibility of those blocks, taking zero chances.
For users, I hope this will mean a little speeding up of transaction times (particularly the financial ones), even though Hive is already very fast at this. What I hope (although I don't know) is this will increase a bit the speed of operations on the 2nd layer (DLUX, Hive-Engine).
RC Delegations
This one has been developed by @ howo, possibly in collaboration with some members of the Blocktrades team for certain aspects (like testing).
RC delegation has multiple benefits. First of all, regular Hivians who have a good chunk of HIVE Power usually only use a small portion of their RCs. That can be delegated to someone else who needs it.
The direct consequence of RC delegation: the separation of voting power and resource credits. RC-intensive accounts that don't vote don't need Hive Power, only RCs. Curation accounts and those that vote on governance need HP.
RC delegations will also help many projects better manage their delegations to users who need help interacting with the chain.
By my logic, there should be no expiration period on undelegating RCs (right, @howo?). It doesn't have to be. There is one for HP (5 days) because that could be abused for multiple voting. But since RCs do not give voting power, that risk is eliminated.
Automatically, if there is no expiration time for undelegating RCs, they can be used much more efficiently than HP where voting power is not implicated.
Also related to RCs, is the next point.
RC Cost Recalculation
All RC costs for all operations will be revised. Dan says they will better reflect the true costs of these operations. I admit I didn't understand much after reading the details on this, but what I do understand from the previous point and this one is that HP is important! :)
If you want a Splinterlands analogy, HP owners will be like card owners in Splinterlands, and using RCs without having HP is like using starter cards, or later renting cards to play. Not a perfect analogy, but I hope those involved in Splinterlands understand what I try to transmit here.
Increase haircut ratio of HBD/Hive from 10% to 30%
This gives a higher buffer for the HBD marketcap to grow.
Right now, and before HF26, the HBD marketcap can't be higher than 10% of HIVE's marketcap. If it does, the haircut rule goes into effect, meaning no more HBD is printed until the marketcap of HBD relative to HIVE goes back below 10%.
This changes the limit from 10% to 30%. This is a good change because some temporary wild market conditions could activate the haircut rule at 10% much easier than at 30%. And that means stopping interest payouts for HBD in savings too.
30% is still safe and gives a better margin for unexpected market conditions, I believe. Fyi, the marketcap of HBD is 4% of the HIVE's marketcap now. Here's where you can check it in real-time.
Users can vote more than once every 3 seconds
This restriction no longer makes sense, as it was introduced to stop voting bots, which aren't the same big problem as in the past. So it will be removed from HF26.
Eliminate Vote Edit Penalty
Currently, if you change your vote, you lose your curation. This will be fixed in HF26.