Understanding Byzantium & What it Represents to the Ethereum Network
Today, at 1:22AM ET, Byzantium was activated on the Ethereum Network.
Byzantium is the first version of the Metropolis, Ethereum’s second major update. Given the breadth of changes proposed by Metropolis, the update was split into two distinct hard forks, Byzantium and Constantinople. A hard fork requires all participants of the network to update the software that they use to interact with the Ethereum blockchain. If a percentage of these participants refuses to update, two Blockchains are created and the network is split. Thankfully, as of 11:30AM ET, the Ethereum blockchain remains unified, and the majority of the network is using the update.
Although activation appears to have been successful, there still seems to be some confusion as to what Byzantium represents. Below we will attempt to explain this update, and give our perspective on what it represents to the Ethereum Network.
The main goal of the Byzantium update is to remove inefficiencies identified in the current version, incorporate improvements identified since the release of Homestead, and lay the foundational infrastructure for major projects currently being researched by the core development team. The update has been highly anticipated as it incorporates multiple Ethereum Improvement Proposals (EIPs) that have been developed and tested following the release of Homestead, Ethereum’s current version.
Some of the changes being introduced by Byzantium include:
1) Instituting a Blockchain difficulty delay and a reduction in block rewards (EIP 649)
Since the launch of the Ethereum Network, it was clear to the core development team that, for Ethereum to truly scale, it would have to change its consensus mechanism from Proof of Work to Proof of Stake. Because Ethereum has thousands of nodes that reach consensus via Proof of Work, the team has studied different incentive structures to encourage miners to update their client to Proof of Stake once it becomes available. One of the incentives laid out by Ethereum’s core development team was to gradually increase the difficulty associated with mining under Proof of Work and launch a separate algorithm that is easier to validate through Proof of Stake. As difficulty increases, transactions will eventually become too difficult to validate via Proof of Work. The team hopes that this increase in difficulty will give miners no choice but to migrate to Proof of Stake, or spend computational resources on a gridlocked blockchain. This has been referred to as the “Ethereum Ice Age” since its blockchain will essentially freeze once such difficulty level is reached. The Byzantium update delays the Ethereum Ice Age by 18 months and during this period, a version of Ethereum’s Casper Project will most likely be introduced. In addition to the delay, EIP 649 also reduces block rewards from 5 ETH per block to 3 ETH per block, further disincentivizing Proof of Work mining.
2) Enabling a level of parallel computation (EIP 98)
EIP 98 proposes to eliminate the requirements related to when a transaction can be processed. Current rules require previous transactions to be referenced for processing to begin and, by removing such referencing requirement, transaction processing can be run in parallel by nodes in the network.
3) Increasing certainty when using light clients, or wallets (EIP 658)
Currently, light clients are unable to verify whether transactions broadcasted to the Ethereum Network were in fact executed. This proposal adds a confirmation number to each transaction receipt, thereby confirming that such transactions were in fact executed.
4) Making the total supply of ether more predictable by increasing the precision of block rewards (EIP 100)
Network miners receive block rewards for validating transactions and maintaining the blockchain. In Bitcoin, when miners complete a full block, they need to broadcast to the rest of the network that a new block was found so that every network node is up to date with the most current block. The process of broadcasting a new block, however, is dependent upon several factors, including the geographical location of the miner who finished the block and the combined bandwidth of all nodes. These factors can result in latency and the first miner to solve and broadcast a new block may have this work invalidated if another miner completes an equally valid block and is able to broadcast it to the majority of peers in the network more quickly that the first miner because of the previously identified factors.
Ethereum manages this by accounting for uncle blocks, which are blocks that have been completed, but are not added by the majority of network participants. Because these uncle blocks are composed of valid transactions, they are added to the block adopted by the majority of network participants and miners are rewarded for their work in mining the uncle block. This reward system has resulted in a slight change in the amount of reward that can be expected for each block. Over time, the block reward began to grow greater than the anticipated 5 ETH block reward, and developers acknowledged that such increased supply emission rate would dramatically increase the total supply of ether. EIP 100 attempts to solve this problem by changing the formula that calculates difficulty to account for network latency, which affects the rate that at which uncle blocks are created.
5) Adding compatibility with cryptographic primitives that increase privacy (combination of EIP 198, EIP 212 and EIP 213)
Cryptographic primitives are encryption functions that, in this context, may enable higher privacy and lay the foundation for new Ethereum use cases. Developers have looked specifically at the functions employed by the Zcash project that enable fully private peer-to-peer transactions. Zcash uses a variant of Zero-Knowledge Proofs which is arguably the most well-researched method for privacy-preserving transactions. Zcash’s variant, zk-SNARKs, enables its blockchain to provide cryptographic proof that a transaction has occurred, without having to reveal the identity of the transacting parties, or the amount transacted. This lays a foundation for privacy-preserving mechanisms that may enable novel use cases for Ethereum, such as private smart contracts.
6) Making the interactions between smart contracts safer (EIP 214)
It is very challenging when developing Ethereum smart contracts to fully predict how these contracts will perform once they are deployed to the Blockchain. This unpredictability has resulted in security breaches that have enabled hackers to steal funds (e.g. The DAO hack). EIP 214 attempts to remedy this by making contract calls more predictable and creating a safer environment in which smart contracts interact with unknown counterparts.
7) Making interactions between smart contracts more efficient (EIP 211)
When smart contracts interact, developers need to hard code the amount of data that is expected to be received from the smart contract, which generates problems with how gas is charged for the operation. This proposal attempts to solve this problem by introducing two new opcodes that specify the amount of data expected to be received by the contract that is being interacted with.
8) Making interactions between users and smart contracts more inexpensive (EIP 206)
When an Ethereum user transacts with a smart contract, the transaction may fail for several reasons. For example, if a smart contract represents the distribution of an Ethereum-based token or an Initial Coin Offering, and users send funds to the address before the ICO commences, the transaction will fail. Although no funds are transferred in the failed transaction, the gas used for the attempted transaction will be consumed. This improvement will block premature or erroneous transactions, and will provide the party sending funds with the reason for why the transaction failed.
9) Preventing contracts from being overwritten (EIP 684)
Although it is not an issue with Ethereum’s current version, Byzantium will change the way that contract addresses are created and stored. This change can potentially create conflicting contract addresses, which may result in several problems. EIP 684 is designed to prevent such conflicts from occurring.
Ultimately, we believe the changes introduced by Byzantium are positive for the health of the Ethereum ecosystem and we look forward to the new use cases that Metropolis may enable.
However, it is important to note that major vulnerabilities in the update were discovered on October 16, triggering a number of last minute corrective measures. Such measures required network participants to download yet another update that patched these vulnerabilities. As of this hour, not all participants have downloaded that version and part of the network is still subject to attacks. We are continuously inspecting the Ethereum blockchain and we will send alerts to our newsletter subscribers if we perceive an attack underway.
