Byzantium Fork: What It Means, How It Works, and Goals

What Was the Byzantium Fork?

The Byzantium hard fork was an update to Ethereum's blockchain, implemented in October 2017 at block 4,370,000. It consisted of nine Ethereum Improvement Protocols (EIPs) designed to improve Ethereum's privacy, scalability, and security attributes.1
The Byzantium hard fork was an essential and critical update to Ethereum's blockchain. It was implemented to enable faster transactions and greater security on its blockchain while making smart contracts suitable for business transactions.

KEY TAKEAWAYS

• A blockchain hard fork is a change that introduces incompatibility between the new and old blockchain.
• The 2017 Byzantium Fork was an update to Ethereum's blockchain and network that implemented changes for the existing and upcoming frameworks.
• There were nine changes in the Byzantium Fork.

Understanding the Byzantium Hard Fork

A hard fork of a cryptocurrency blockchain splits the blockchain in two, creating an old and new version. The new and old versions are incompatible, and all new transactions are recorded on the new chain.2
The changes implemented in the Byzantium hard fork were designed to make Ethereum lighter, faster, and more secure. Additionally, they continued to build the framework for the eventual switch to the proof-of-stake consensus mechanism.

Goals of the Byzantium Fork

When implemented by a community and blockchain developers, a hard fork generally has specific goals or improvements that make the fork necessary. There were nine upgrades in the Byzantium fork that were general improvements, some of which helped set the stage for future upgrades:

• Added REVERT opcodes to the blockchain to allow smart contracts to be stopped without consuming all the gas paid for a transaction (EIP 140) if an error occurred
• Added a status field to transaction receipts to indicate transaction success or failure (EIP 658)
• Added a new mathematical model (EIP 196) and pairing checks that allowed zk-Snarks to operate correctly (EIP 197)
• Added support for certain signature verifications (EIP 198)
• Added support for variable values (EIP 211)
• Added STATICCALL opcode to allow for calls to nodes that do not request a state change (EIP 214)
• Changed the formula behind the difficulty adjustment to account for ommer blocks—blocks mined at the same time as another block but not accepted by the network (EIP 100)
• Delayed the difficulty bomb designed to make mining so unprofitable miners would switch to proof-of-stake (EIP 649)1
• Reduce the block reward from five to three ETH

Here's a quick rundown of some of the changes implemented in Byzantium.

Smart Contract Stops

Before the update, smart contracts could throw an error, and the initiator would still be charged the gas fees for the entire transaction. Gas fees for smart contracts can be costly, so this update kept contract creators from losing gwei—the small ether denomination used to pay for transactions—for a contract that didn't fully execute.3
4

Embedding Transaction Status Code in Receipts

Previously, transactions referenced a root parameter within the Merkle tree—the blocks that build on each other and secure the chain. The Merkle tree is a data structure that uses data within preceding blocks to create verification information that allows one block to be checked rather than checking every block every time there is a transaction.5
This update enabled transactions to communicate success or failure rather than looking for the parameter, which theoretically allowed Ethereum’s blockchain to process transactions faster.6

Enhancing Cryptography

The Byzantium upgrade included coding native to Ethereum's blockchain designed to lessen power requirements for the implementation of zk-Snarks.7
8
 This is a zero-knowledge cryptography, where each party in a transaction can verify the other, but the information cannot be seen. Zero-knowledge is increasingly becoming the privacy standard for cryptocurrency transactions.9
The update introduced mathematically intensive computations that enabled systems to prove that they held the requisite cryptographic keys without divulging the contents of those keys.1
9

State Changes

Transactions change the state of the blockchain, and smart contracts execute transactions. Therefore, it was necessary to implement a way for a user to call—or query—contracts without initiating a state change through a STATICCALL function.10

Ommer Blocks

In a proof-of-work mechanism, miners open new blocks on a blockchain—it's possible for more than one block to be opened at the same time due to the distributed nature of the blockchain and time lag. When this happens, the network chooses which block to add to the chain. In previous versions of Ethereum, the blocks that were not chosen were called ommer blocks—ommer is the gender non-specific term for a child's parent's sibling (sometimes called uncle or orphan blocks).11
On blockchains, block relationships are often referred to using familial relationships—that is, each block has a parent block, and it is the parent block's child. Two blocks mined at the same time are considered sibling blocks. So, imagine that there were two block 24s mined at the same time—consider them sibling blocks. One of the blocks was added to the blockchain, and another block was created from it: its child block, Block 25. This makes the second Block 24 the ommer block of Block 25.
Previously, ommer blocks were not accounted for when the difficulty was adjusted. This update included ommer blocks in the block count to ensure the difficulty could not be manipulated by adjusting the ommer rate (previously called the uncle rate).12

Under Ethereum's proof-of-stake consensus mechanism, implemented in September 2022, ommer blocks are no longer an issue because only one block is proposed at a time.13
11

Difficulty Bomb

Ethereum developers had been working towards implementing a proof-of-stake (PoS) consensus mechanism since the beginning. However, PoS wasn't as easy to implement as other upgrades because many changes were required. It also requires users to stake their ether (ETH) as collateral for the privilege of becoming a network validator.13
The difficulty bomb was a significant increase in mining difficulty, designed to discourage a fork in the chain after the blockchain transitioned to PoS.14
 The bomb was delayed in the Byzantium update.15

Is Ethereum 2.0 a Hard Fork?

The Ethereum transition to proof-of-stake was referred to as Ethereum 2.0. However, it is no longer called that by the developers and community. The upgrade to the blockchain was not a hard fork, but hard forks such as EthereumPOW emerged from the upgrade as some users did not want to switch to PoS.16
17

What Happens to My ETH After a Fork?

In a soft fork, your ETH is still yours and in your wallet. In a hard fork, your ETH is still yours and in your wallet. However, some hard forks award the cryptocurrency that emerges from that hard fork to existing wallets hoping to attract those users. In that case, you'd have your ETH and some new cryptocurrency.

Why Did ETH Classic Fork?

In 2016, Ethereum was attacked in what became known as The DAO attack. The Ethereum Foundation hard-forked the blockchain and reverted it to its state before the attack to give the DAO contributors their funds back. However, some users didn't believe this was the right action to take because it violated the concept of blockchain immutability. Ethereum Classic is the continuation of the state of the Ethereum blockchain after The DAO attack.

The Bottom Line

The Ethereum Byzantium fork was a change in Ethereum's coding that implemented nine changes. These improvements helped pave the way for the eventual transition to proof-of-stake in the blockchain and addressed other issues.
The comments, opinions, and analyses expressed on Investopedia are for informational purposes only. Read our warranty and liability disclaimer for more info. As of the date this article was written, the author owns BTC and LTC.