The HF20 problems were anticipated by intelliguy -- no one listened. (Open Letter to STEEMIT)
I told @drakos that I thought it was too soon to fork:
My comment 5 days ago about delaying HF20:
https://steemit.com/witness-update/@intelliguy/re-drakos-to-fork-or-not-to-fork-20180921t192903448z
....and it turns out I was right.
In technology, when you disrupt your userbase... you don't follow through with your next upgrade immediately. People are still recovering from the last outage.
You have to bring some homeostasis to the platform.
HF20 could have been delayed until it was tested further.
Every time steem goes down -- what are we learning?
...and this replay thing --- needs to be re-engineered. I highly suggest this be done next.
I discussed some possibilities with Luke Stokes here:
So my open letter to Steemit is simply this:
If outages are going to occur... you can't have your witness nodes "replaying" old blocks from genesis for 5 or 6 hours... it's just ridiculous.
Want to make some major changes? How about getting rid of the replay procedure for blocks that have already reached consensus.
See this comment thread:
Now consider, when there is a bad release version, and an "emergency update"... this is usually the flow:
- HF takes effect
- Witnesses release something is wrong
- They downgrade or upgrade and then replay (5-6 hour delay)
- They then see if that worked. If not...
- They downgrade or upgrade and then replay (5-6 hour delay)
That's 10 hours of replaying... that is unnecessary when doing emergency upgrades.
That 10 hours is going to increase as the blockchain gets bigger. By creating a "snapshot" archive of the first 2 years of steem... you should never have to replay that initial period.
That snapshot can reach consensus by all nodes "once".
Keep in mind, once a witness node has downloaded its own version of the immutable blockchain, it should trust itself and what it has... Why does it need to do this AGAIN? That's blockchains -- they are immutable history that can't be changed. Why do they need to re-verify something that can't be changed once they have it?
I'm an unpaid steem person, with no delegation by massive whales for my thoughts, and my intelliwitness node had to be shut down due to financial reasons at the current time. It's too bad I couldn't be more involved. My free advice is going to be limited.
The one steem fork that seems to appreciate me is https://whaleshares.io -- I'll end up saving my greatest ideas for them.
I got a reply from dan a long time ago about this very thing.
He was adamant about just replaying from the beginning, even when he was talking about using blockchain for MMORPG backends. (when 99% of that data would be useless, as in your HP is at 100% most of the time, and the game doesn't care how much you lost in last week's fight)
And what really sucks this hard fork is that they were off by orders of magnitude.
yesterday - NEGATIVE 600 quadrillion
today - positive 400 billion (and falling fast, from manual commenting)
That there is missing the ball park.
And, i very much agree that back to back massive hits was a bad idea.
I sincerely appreciate your comment, thank you.
Replaying blockchains from genesis --- without snapshots -- is stupid. It's not sustainable, scalable, or an efficient use of bandwidth or resources.
When will we learn?
There is a way to sign, randomly verify snapshot data by asking for random blocks... using checksums, etc.
Real design and engineering needs to take place.
You have to walk, before you can run. For now... we seem to do a lot of running without realizing we're need the elementary stuff done first.
Time to go back to the drawing board, and fix what is not conducive to our future
Who should go back to the drawing board? The same guys that weren't experienced enough in the first place, hoping they learned 'all' lessons by now? If a team in a company were to do this we'd just replace them...
Whoever "can". It's never too late to realize what you should be doing.
Highly rEsteemed!
I’m now of the opinion that we should focus on multithreaded replays.