On July 30, 2015 Vitalik Buterin, a cryptography researcher, published the Ethereum White Paper. The Ethereum White Paper outlined a blockchain implementation that was Turing complete and stateful, two attributes that the first blockchain implementation Bitcoin did not have.[1] In this paper, I will provide an overview of Ethereum and blockchain technology, as well as a system design analysis of Ethereum.
The difference between traditional distributed database systems and blockchains is that participants in a blockchain network are assumed to be bad actors, whereas distributed database systems require trust amongst the nodes. Attempts to develop Byzantine Fault Tolerant distributed database systems such as Byzantine Paxos require multi-stage messaging processes that are not scalable for internet size deployment.[2]
At the most basic level, a blockchain is a linked list data structure. In Ethereum, each node within this list has a variety of parameters, including the hash of the previous node in the list and three tree data structures.[3] These trees store the state of the Ethereum blockchain, a list of transactions, and a receipt log. The state of Ethereum is made up of accounts: externally owned accounts and internal accounts known as smart contracts. External accounts hold balances of the native cryptocurrency Ether, while smart contracts hold code. To add code to a smart contract or execute a contract’s function, a transaction that originates from an external account is sent. When a transaction is processed, a state change occurs. The third tree data structure stores event logs. Just decentralized databases have logs, Ethereum smart contracts will emit events that write to a log after performing some action.
In order to maintain this data structure in a decentralized manner, an incentive scheme for validators is required. The validators of transactions in Ethereum are known as miners. When a transaction is sent to the network, it is stored in a pool of unconfirmed transactions. Miners will choose a set of transactions from this pool to validate. Validating a transaction involves running each transaction and ensuring that the transaction adheres to the rules of the Ethereum protocol. After validation, the miners will hash a group of transactions together into a block. If the resulting hash is lower than a required level, the miner can share this block with the rest of the network.
This process of validation is known as Proof-of-Work. Requiring miners to produce a hash that is lower than a certain value ensures network security because miners must spend computational power and electricity to produce these calculations. Miners will conduct these actions in exchange for the opportunity to earn a monetary reward.
Other nodes in the network will run these shared transactions, which is a non-computationally expensive process. The transactions will either be accepted, if they adhere to Ethereum’s protocol, or rejected. Other nodes in the network have an incentive to accept the first valid transactions they receive because they will be interested in building off them as the next node in the linked list.
Another way to think of Ethereum is as an incentive scheme. Simply put, miners who validate transactions are awarded a reward by validating transactions. Some miners may attempt to publish transactions that fraudulent i.e. sending a transaction from an account that does not have a large enough balance. When this transaction is propagated throughout the network, other nodes will see that the transaction does not abide by the Ethereum protocol and will not build off of it in their linked list. These malicious transactions will end up being a waste of work for the malicious miner because they will not receive a reward for these transactions.
System Analysis: Forward Compatibility Vs Backward Compatibility
With any distributed systems, versioning and managing upgrades can be difficult. Since Ethereum is a decentralized network, software upgrades are very difficult. There are two different ways to upgrade blockchain software: soft forks and hard forks.
Soft forks occur when backward compatible upgrades are made to the protocol. This means that the new protocol is more restricted than the legacy protocol.[4] Nodes that have upgraded their software will see that the new blocks conform to the new consensus protocol. Old nodes will also see that these new blocks conform to the legacy protocol since the new protocol is a subset of the old protocol. If the majority of nodes have upgraded to the new software and an old miner submits a block, this block will be viewed as invalid by the network because it does not adhere to the stricter protocol. Miners who have not upgraded their software will have an economic incentive to do so, as their blocks will not be accepted by the network.[5]
Hard forks expand the existing protocol rules. During a hard fork, nodes that upgrade their software and nodes that do not upgrade their software will operate on two different chains. Legacy nodes will view the newly mined blocks as invalid because they correlate to a different consensus protocol and vice versa.
Soft forks are viewed as less dangerous to a network, as a chain split is less probable. In the case that a majority of miners do not upgrade their software and a majority of nodes do, a chain split will occur. In this situation, nodes will most likely be forced to downgrade their software.
Within the cryptocurrency community, soft forks have developed mixed opinions. Individuals such as Mike Hearn, a Bitcoin core developer, view soft forks as trickery. He argues that the forward compatibility of soft forks really just tricks legacy nodes into thinking updated transactions still follow the legacy protocol when they are actually different in nature.[6]
Vitalik Buterin and Jeff Garzik, a Bitcoin core developer, believe that soft forks do not let users opt into the new consensus rules.[7] In a blog post, Vitalik states, “[W]hat matters is not whether or not individual users have to perform the simple bureaucratic step of clicking a “download” button, but rather whether or not the user is coerced into accepting a change in protocol rules that they would rather not accept.”[8] Vitalik argues that within the blockchain space, individuals think that soft forks are less coercive because the individual does not need to actively upgrade their software. Instead, Vitalik argues that by being passive in a soft fork an individual accepts the new protocol changes, which they may be unaware of. Bitcoin core developer Eric Lombrozo offers a differing opinion. He states that the Bitcoin Improvement Process (BIP) that implements soft forks is community driven and individuals always have the choice to run different software if they are not pleased with the current iteration of the software.[9]
Historically, hard forks have been more contentious to implement than soft forks. This is due to the fact that chain splits diminish the network effects of a particular blockchain and hard forks tend to evolve around contested governance and philosophical issues. For example, Ethereum conducted a hard fork in the summer of 2016 after a hacker exploited a bug in an Ethereum application that took $50 million dollars from users.[10] This hard fork resulted in a chain split producing Ethereum and Ethereum Classic, the blockchain that did not return the lost funds to users. This hard fork decision raised questions amongst community members about the immutability of blockchain systems and the governance processes for decentralized networks.
Andrew Poelstra, a Bitcoin developer and employee at Blockstream, wrote an email thread arguing that hard forks increase the cost to maintain a node, which will lead to centralization. The reasoning for this statement is that hard forks will require individuals to actively monitor their software, which they might choose to outsource.[11] Others argue that forking allows a network to iterate faster and solve governance issues that a subsection of the community may have with the current network.[12]
Apart from the diminishing network effects of splitting a network and determining who gets to use the original network name, legacy blocks remain valid on the new hard forked chain. This opens up the Replay Attack Problem. A replay attack occurs when an individual sends a transaction on the original chain at the time of a hard fork. Since this transaction will be valid with respect to both chains, this transaction can be broadcast to the new chain. The original sender may not know about this transaction that has been maliciously broadcast, which will result in the same state change.[13]
Naming:
Right now, each type of account is identified by a unique 40-character hexadecimal representation. In an attempt to make these account names human readable and easier to interact with, a group of developers has begun working on the Ethereum Name Service (ENS). The ENS acts as a decentralized DNS system.
The ENS is made up of three Ethereum smart contracts: the registrar, the ENS registry, and the resolver. Nick Johnson, the lead engineer for the ENS system, stated that by breaking up the services of a DNS into three simple pieces, upgradability and forward compatibility are easier to maintain throughout the ENS.[14]
The ENS registry is a contract that maps the hash of a name to the name’s owner’s address and the address of the specified resolution contract. The registry will return the address of the resolution contract, which will then return the address of the object the owner has mapped the given name too. The registrar is responsible for assigning owners to top-level domain names.[15] (Currently, a multisignature account of the lead developers is the owner of the .eth TLD within the ENS registry contract.)
The current implementation of the ENS is very primitive. For example, names can only be registered under the .eth TLD, and no name shorter than 7 characters can be registered. This is because there is no effective dispute resolution system for names within the registrar contract. J. Maurelian, an ENS contributor, wrote in a Medium article, “Who should control a name like microsoft.eth, bankofamerica.eth, or vitalik.eth? How should a registrar allocate these names?” 15 The developers have effectively kicked the can down the road by waiting until a full registrar with dispute resolution has been implemented so more desirable names can be owned.
Within the ENS registry, a hash of the desired name is registered to the corresponding owner. This allows any type of foreign characters and upper and lowercase characters to be used in a .eth name.[16] Similar to the DNS, owners of a given .eth namespace are allowed to operate on any subdomains of that name.[17]
Compiler Versioning:
All Solidity code, the programming language for Ethereum, requires that the source code includes a compiler version. As explained in the Solidity specs, “Source files can (and should) be annotated with a so-called version pragma to reject being compiled with future compiler versions that might introduce incompatible changes.”[18] The most current version of the compiler is 0.4.12. Any code written with a compiler version 0.4.0 or greater will be compilable with 0.4.12. When version 0.5.x is introduced, code with earlier compiler versions will not remain forward compatible.
From a development perspective, compiler versioning is inconvenient because individuals have to have multiple versions of the compiler installed. Legacy source code may not remain supported far into the future, as individuals will remove those compilers from their systems. While researching this paper, I came across a Github comment section where individuals wanted the compiler version to be included in the binary of the Solidity code. The rationale is that any individual would then be able to validate the given smart contract code.[19]
While Ethereum is a truly decentralized database, many of the same system design problems of centralized systems exist within its implementation. While it is still in the early days for blockchain implementations, blockchains enable systems to be built that do not require permission, centralized points of control or trust.
[1] https://github.com/ethereum/wiki/wiki/White-Paper
[2] https://www.quora.com/Why-would-you-use-blockchain-over-a-distributed-consensus-protocol-like-Paxos-or-Raft
[3] https://github.com/ethereum/wiki/wiki/White-Paper#merkle-trees
[4] https://lightco.in/2017/07/30/bitcoin-fork-split/
[5] https://www.coindesk.com/information/hard-fork-vs-soft-fork/
[6] https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7
[7] https://bitcoinmagazine.com/articles/understanding-soft-forks-a-core-developer-s-view-on-network-monopoly-1474990034/
[8] https://vitalik.ca/general/2017/03/14/forks_and_markets.html
[9] https://bitcoinmagazine.com/articles/understanding-soft-forks-a-core-developer-s-view-on-network-monopoly-1474990034/
[10] https://www.coindesk.com/ethereum-executes-blockchain-hard-fork-return-dao-investor-funds/
[11] https://lists.launchpad.net/mimblewimble/msg00249.html
[12] http://unchained.forbes.libsynpro.com/unconfirmeds-first-episode-olaf-carlson-wee-of-polychain-capital-on-governance
[13] https://cointelegraph.com/news/if-hard-fork-happens-chain-backed-by-majority-of-miners-will-likely-win
[14] https://www.youtube.com/watch?v=pLDDbCZXvTE
[15] https://medium.com/the-ethereum-name-service/explaining-the-ethereum-namespace-auction-241bec6ef751
[16] https://docs.ens.domains/en/latest/faq.html
[17] https://docs.ens.domains/en/latest/userguide.html
[18] https://solidity.readthedocs.io/en/develop/layout-of-source-files.html#version-pragma
[19] https://github.com/ethereum/solidity/issues/529
