You might have heard that on the Ethereum blockchain, there’s gonna be a very important event soon, called the Byzantium hard fork. But before explaining what this is, let’s talk about what is a hard fork.
What is a hard fork?
First this is not a code fork, but a data fork.
In software development, what we generally talk about when we mention a fork, is when a project’s code gets replicated into a new code base that evolves independently of the original project. This is something that versioning systems like Git make very easy.
But this is a software fork. It does exist in the blockchain ecosystem too, like Litecoin’s code being a fork of Bitcoin’s code. But what we are going to talk about today are data forks.
In blockchain, a fork happens when you change the way blocks are fabricated, and hence the rules that govern whether a new block should be accepted into the chain or not.
So as you probably know by now, a blockchain instance is a mash-up of some code and a database, both being distributed in the sense that the software runs on every node of the network, and every node of the network holds a copy of the entire database.
Another important aspect of this is that certain nodes in the network, called miners, have the power to create blocks that they can broadcast to the whole network. And each node only accepts a block into its copy of the blockchain once it has validated it. So again, miners create blocks and validate blocks they receive from other miners. And non-mining nodes simply validate blocks that come to them.
So if only some part of the network upgrades their software to change the way blocks are created and validated, you can end up with two different versions of the ledger being built and validated, two different versions of reality. Very scary stuff.
So you might ask « why take such a risk? » Well, quite simply because software is never right the first time. It needs to evolve, it needs to adapt. It’s almost a fact of life. Every software system in the world evolves from version to version. Now, in a centralized system, it’s pretty easy to do: you just upgrade a few servers and you’re done. But in a decentralized network where you have no way to control all the nodes, it’s a whole different story.
Softfork versus Hardfork
Now what’s also important to understand is that in the blockchain world, there are 2 kinds of forks: soft forks, and hard forks.
Softforks
They restrict block acceptance rules compared to older versions.
The new rules are a subset of the old ones. Which means that every block accepted by the new rules, will also be accepted by the old rules.
That’s why we say that soft forks are forward compatible.
The only thing that’s needed for a soft fork to be successful is to have at least 51% of the mining power of the network upgrade to the new software.
With such a soft fork, miners that don’t upgrade will start building blocks that are not validated by the upgraded nodes, whether they are miners or simple nodes. In particular, upgraded miners will not mine on top of these old blocks since they don’t recognize them as valid.
That’s why it’s very risky for miners not to adopt a soft fork, and such forks are usually temporary, and less risky.
Hardforks
Hardforks on the other hand, ease block acceptance rules compared to old versions.
The new rules are a superset of the old ones, meaning that some blocks that were invalid according to the old rules become valid by the new rules.
And it also means that some blocks produced by the new software will not be validated by nodes running the old software.
So this kind of fork is not forward compatible, and if a majority of non-mining nodes stay on the old version of the software, even if more than half of the mining power upgrades, we will have a blockchain split, meaning 2 ledgers coexisting in parallel, where the first blocks up to the forking block are the same, but later blocks are different.
Differents philosophies
So hardforks are dangerous, but sometimes they are necessary. It’s not like developers decide to hardfork on purpose. It’s just that sometimes, the improvements they want to bring to the network tend to losen the block acceptance rules, and then we have a hard fork.
In the Bitcoin world, hardforks are feared, and really a measure of last resort. In the Ethereum world, they are considered as a natural thing, and a series of hardforks was even anticipated from the get-go, when the network was first initiated. And some mechanisms were even baked into the protocol to incentivize miners and users to upgrade their software and adopt hardforks as quickly as possible.
The Story of Ethereum Forks
When Ethereum was first designed, 5 major versions were anticipated: Olympic, Frontier, Homestead, Metropolis and Serenity.
Olympic was only a test network. It launched in May of 2015.
Frontier was the first version of the production network, the main net, and it launched on July 30th 2015.
The Homestead upgrade went live on March 14th 2016, and it is the version that’s still running the main net as of today, October 8th 2017.
The next big upgrade to the network is called Metropolis, and one of its main objectives was to abstract away the notion of account security. But this account abstraction logic, theorized in EIP#86, is not yet ready for prime time.
So instead of further delaying the Metropolis release, that also contains a few other important improvements to the network, the Metropolis release was split into 2 sub-releases if you want: Byzantium and Constantinople.
The Byzantium upgrade already went live on Ropsten testnet a couple of weeks ago, and is set to go live on the main net on block 4,370,000, which should be mined on October, 17th 2017.
Anyway, the Byzantium release is going to bring a few improvements to the Ethereum blockchain. let me explain them to you.
4 new EVM Opcodes
The EVM, or Ethereum Virtual Machine is like some sort of generic processor running in software instead of hardware, just like the Java Virtual Machine or the Microsoft CLI. This makes it possible to run Ethereum nodes on any kind of computer on top of which we can implement this EVM. And of course it makes it possible to change how this processor works over time.
As any processor, the EVM uses a series of instructions also called Opcodes. And you probably know that, in Ethereum, each opcode has a given cost in gas, to make sure that smart contracts don’t run crazy and paralyze the network.
When you compile a smart contract written in Solidity, it gets transformed into those instructions or opcodes. And Byzantium brings 4 new such opcodes to the EVM:
- REVERT
- RETURNDATASIZE
- RETURNDATACOPY
- STATICCALL
The first three are going to be a big improvement in terms of error handling in smart contracts.
Originally, when you had an error in a smart contract, you used the “throw” instruction, that reverted all the state changes and consumed all the gas sent by the caller.
Now let’s say you are participating in an ICO, you want to send some Ether to a contract to buy some tokens, but there is a lot of people on it so you want to go first to be sure your participation is recorded into the blockchain before the ICO closes. To do that, you send some gas to the ICO contract with a very high gas price to incentivize miners to prioritize your transaction. Unfortunately, everyone does the same thing, the network slows down, your transaction doesn’t get processed in time, and by the time it’s executed, the contract execution throws and consumes all the gas you sent at a very high gas price. Not only didn’t you get your tokens to participate in the ICO, but you still lost some money in the form of gas. In recent months, with all the crazyness around ICOs, some people lost several thousands of dollars each that way.
Another consequence of a “throw” consuming all the gas is that you don’t have any gas left to actually return some valuable data like an error message explaining the reason why the contract execution failed. Which makes smart contracts very hard to debug and analyze.
Now, in Solidity 0.4.10, a new keyword was introduced called “assert”, that, when compiled, translates into its own opcode, but an opcode that doesn’t exist. The treatment of this invalid opcode by the EVM is exactly the same as the invalid jump with the throw: all state changes are reverted and all remaining gas is consumed.
But another keyword also introduced in Solidity 0.4.10 was “require”. Functionally, require checks that a given condition is met, and if not, it interrupts the execution of the contract. In the current version of Ethereum, “require” gets compiled down into an invalid opcode, just like “assert”, but a different one.
Byzantium will add support for this opcode called REVERT. So “require” will get compiled down into the REVERT opcode, and this opcode will behave differently now: it will still halt the execution of the contract and revert all changes to the state, but it will not consume all the remaining gas.
So “require” will be cheaper than “assert”, and it will leave the door open to error messages by leaving some gas for that. And that is exactly what the new RETURNDATASIZE and RETURNDATACOPY opcodes will be useful for. Now don’t get your hopes up just yet, because Solidity doesn’t support those yet. But in the near future, you can expect the “require” function to accept some extra parameters in addition to the condition to be checked, in order to return some error details. How exciting is that? A programming language where exceptions can cost actual money, that finally supports proper exception messages.
The fourth opcode that gets added to the EVM is called STATICCALL. Basically it will make it possible for one contract to call another contract with the explicit requirement that the collaborating contract cannot modify the blockchain state. This is very important because when you call another contract from your own contract, you might not know what this contract does exactly, and this target contract might modify the state of your contract by calling another function back on it, which might cause a reentrancy bug. This kind of reentrancy bug has become very famous on the Ethereum blockchain as the hack on TheDAO contract was caused by such a bug. So essentially, what STATICCALL will allow for, is to make calls that are guaranteed NOT to modify the state of the blockchain in any way, even if they redirect to other contracts. Such functions will be pure queries, and functions that do modify the state of contracts will be commands. So STATICCALL will enable the Command-Query Responsibility Segregation, or CQRS paradigm, on the Ethereum blockchain. Very powerful concept.
4 new native contracts
Another thing that Byzantium is bringing is 4 new native contracts. But before explaining those, let’s explain what a native contract really is.
In Ethereum, a normal smart contract is a piece of code that is running inside a virtual machine, the Ethereum Virtual Machine, that runs on top of the Ethereum node software, like Geth for example. And Geth itself runs directly on the hardware processor of the host machine it’s running on.
In other words smart contract code runs really slow compared to the code of Geth itself. Now for most smart contract operations, that’s not a big problem since smart contracts are not designed for computing-intensive operations anyway. But there are some operations that smart contracts will do a lot, that are very computing-intensive, like cryptography-related functions.
These generic operations can be hardcoded into the node software itself, and put at the disposal of your own smart contracts, via specific addresses. These are what’s called native contracts. They are contracts that are not deployed inside the EVM, but implemented inside node software itself to run directly on the host’s hardware processor in order to be more efficient.
In the current version of Ethereum, there already are 4 such native contracts that mostly deal with hashing and elliptic curve cryptography. Byzantium will add 4 new functions. The first one will make RSA verification more efficient. The other 3 will make it possible to efficiently implement something called zero-knowledge proof. I will not go over the details of this here, but suffice it to say that zero-knowledge proof, implemented in the form of a mathematical construct called zkSnarks, is at the heart of the privacy feature offered by another blockchain implementation called zCash. So thanks to those new native contracts, zkSnarks will be ported to the Ethereum blockchain, making it possible to make completely untraceable transactions. How cool is that? Here is the link to the Geth code that shows the implementation of these native contracts.
Delaying of the Ice Age
Now let’s talk about difficulty. As you may already know, the Ethereum blockchain currently uses a consensus algorithm of type “proof-of-work”. The way this algorithm basically works is that in order to add a new block to the chain, miners have to prove that they solved a specific mathematical puzzle based on hashing. And the difficulty of that puzzle is dynamically adjusted by the network so that solutions are found at an almost constant rate, whatever the mining power that gets added to or removed from the network. In Bitcoin, this difficulty adjustment occurs every 2 weeks, leaving it vulnerable to difficulty manipulations. In Ethereum, this difficulty adjustment is made for every single block.
In Bitcoin, a new block is produced every 10 minutes or so. But in Ethereum, the theoretical block time is 12.5 seconds, and every block a miner adds, he can look at the average block time over the past few blocks and adjust difficulty upward or downward for future blocks to keep the same average. Well, almost the same average. Because in practice, right from the start, a specific mechanism was implemented into Ethereum clients that is meant to increase the average block time exponentially after a certain block number. This mechanism, called a difficulty bomb, or “Ice Age”, is a way to incentivize miners to adopt hardforks, because each hardfork can potentially change the block number starting from which the difficulty bomb kicks in. So if a miner does not adopt a given hardfork, if he doesn’t upgrade his software, he is forced to keep the difficulty bomb timer as it is, which will lead him to create blocks at a slower and slower pace, which is not good for business. You got to recognize the elegance of that incentive mechanism.
Now if you go to a site like EthStats, you will notice that we are already far away from this 12.5 second theoretical average block time. At the time of this recording, it’s actually closer to 34 seconds. So in effect, the difficulty bomb already kicked in, as you can see on this graph, and we already are in the Ice Age.
So effectively with Byzantium, the difficulty bomb timer is gonna get reset and we will go back to a faster network with a shorter block time of 12.5 seconds, and the Ice Age will get delayed another 1.4 years, to give some time for the next hard fork to be ready.
Decreasing the block reward
Right now, the block reward is 5 ETH. At the beginning of this year, 1 ETH was worth around 10 dollars. At the time of this recording, it’s closer to 300 dollars, hence a 30-fold increase over less than 10 months. Of course it brought more miners to the network, but as the difficulty was adjusted accordingly, it means a lower probability for each miner to find the next block. In other words, a bigger cake to share between more people, but a bigger cake nonetheless.
On the other hand, you might have already heard that, even though Ethereum is currently using a Proof-of-Work kind of consensus algorithm, its long term plan is to switch to a Proof-of-Stake algorithm, which should solve plenty of potential issues when scaling up the network. This Proof-of-Stake initiative, codenamed Casper, is full of promises, but it is far from ready for prime time. Its implementation is proving to be way more complex than originally anticipated, which means that its release is getting pushed back.
Now originally, a lot of miners invested in mining gear knowing that they would get a certain reward over a certain period of time, proportional to the hashrate they contributed to the network, up to the release of Casper. At that point, they can throw away their gear because Proof-of-Stake won’t need it anymore. But as Casper’s release is getting pushed back, that period extends as well and mining becomes a lot more interesting overall. So to balance that out a little bit, Byzantium will decrease the mining reward from 5 ETH to 3 ETH. At least that’s the official explanation. But I like Jordan Leigh’s interpretation.
Basically what he says is that this decrease in mining reward is also a way to make sure that, when Casper does get released in more than 2 years, it is not too much of a blow to miners’ revenues, a blow that would essentially motivate them to reject the hardfork and stay on the proof-of-work version of Ethereum.
Anyway, this means that Ether will get created at a slower pace from Byzantium on, since mining rewards are the only mechanism by which crypto-currency gets minted in a blockchain.
Speeding up transaction processing
Last but not least, due to the way transactions are currently stored in a block, they can only be validated and processed sequentially.
In Byzantium, the structure of transaction receipts will change slightly to make transactions independent from one another and make it possible for mining software to validate and process these transactions in parallel, which should speed up the network and make it more efficient. And of course there will be some gas incentives to motivate nodes to use that new transaction receipt structure.
Conclusion
And that concludes our review of the most exciting changes that will be implemented with the Byzantium release.
So again, keep an eye out for block 4,370,000, on October 17th 2017.
If you’re watching this video on our blog, chainskills.com, or on our Youtube channel, you might not be aware that we created a Udemy online course that shows how to get started with Ethereum development and takes you through the whole process of creating a Dapp project, coding your first smart contract, creating a frontend for it, and deploying the whole thing to private network, test networks and even the main net. And of course, we will make sure our course material will remain up-to-date regarding all the changes in Byzantium and beyond.
And if you are not registered for our course yet, here is a little gift for your patience and curiosity: to celebrate the Byzantium release and until October 17th, you can use the BYZANTIUM coupon to get our course for an exceptional price of 10$ or 10€ instead of 195.
We sincerely hope that our course, along with this video, and all the other material we have in the pipeline will keep driving more people to this incredible ecosystem that is the blockchain. So feel free to subscribe to our Youtube channel or to the newsletter on our blog. Of course there is also our Facebook page and Twitter where we share interesting news on a regular basis. So share this post with your developer friends, and let’s change the world together, for real this time…
