Alexandre explains what a hard fork is, when one would happen, and why it would happen. Most importantly, he delves into how EOS is different from other blockchains in how hard forks affect it.
Still have questions? Join us in our Telegram channel.
Transcription:
What's up with hard forks on EOS?
On EOS, we're really lucky to have system contract-based upgrades. That means a boat-load of features are defined in a smart contract, in the, sort of, empty can that the blockchain is.
Core features live in the blockchain code, but most of it is in a smart contract.
And on EOS, you know, we can upgrade contracts. So for example, what's in there: all the voting mechanism, delegation of bandwidth, undelegation of bandwidth, refund, RAM market, and the producer schedule...
Everything of those things are defined in the smart contract called EOSIO, which is the system contract. It means that if we want to change those things, we will do it in a fully orchestrated way. 15 out of 21 Block Producers will vote, put in a change to the smart contract, and it's going to be rolling out at a given block. Everyone together. There's no breach of consensus, it's part of the design.
Now, let's say in the future there's a shiny new hashing algorithm called SHA-7-million, it's a great one, meow meow! And then you want to have that be accessible in your smart contracts. Let's say it's hardware accelerated, so you really want to expose it through the smart contract interface, so that it can call that function and have the hardware hash it. So it's not part of the current implementation. So we would need to change nodeos (the can right, the empty container there) to expose the smart contracts. So if they do that, they won't start rolling it out immediately, because in that case you would have a transaction that uses it, and it's put in a block. But the other producers that don't have that piece of code, they would refuse that block. So they would literally fork it away. So when the block producers will create a new functionality like that that would obviously create a hard fork, because the blocks would not be recognized the same on both forks. Now, 15 out of 21 decided they will honour the community's desire to have SHA-7-million in the nodeos software.
So they will start by rolling out changes to nodeos itself. Now, bear with me here. They don't need to all agree. 15 out of 21 need to. And they'll roll out that change to their nodeos software, exposing a new functionality. But wait, it's not going to be enabled right away. It's going to be behind a feature flag that can be enabled later on. But it's still going to be in the code. So they're going to roll out that change, and if 15 out of 21 decide on something, and they roll it out, those 6 other folks if they don't follow, when they're going to produce blocks that don't recognize that functionality, for example, they're just going to be forked off. They're going to be off on their own chain. And their chain is never going to be the longest chain, and their fork is going to die.
So you won't have two coins, and two different communities. That won't happen on EOS. So to finish up the story with the feature flag, is that once the software is updated, we can go inside the smart contract - the system contract - on a privileged account, we can flip the feature on and activate it. Once that's done at the same blockheight, in an orchestrated way, the feature will be enabled. This allows for very smooth upgrades.
In the past, Larimer-Blockchains upgraded many many times in this fashion without forking off the community. No separate coins, no separate community. It's just a very nice way to advance the features of a blockchain.
So, that's what you need to know about hard forks. That's hard, that's a soft work. We're good. But on EOS, you don't need to be overly excited about hard forks. It's going to be a great experience. And check out our stuff, check dfuse.io, you're going to be amazed!
Hey, see you next time!