Ethereum at Scale, part 0

0
40

Ethereum at Scale-Part 0

The Bacino di San Marco on Ascension Day, Canaletto, 1733.

Bucintoro (the red and gold ship) returns from the Sposalizio del Mar (the Wedding of the Sea), an annual ceremony where the Doge drops a ring into the harbor to symbolize the marriage of Venice to the sea. In this painting, Canaletto observes the basin of San Marco from the docks in front of the Zecca. He captures the scene and scales everything on display with lifelike precision. Canaletto’s biographer wrote in 1771 that he used a camera obscura for his preparatory drawings. That fact was taken as true for centuries until a recent study by the Royal Collection Trust contradicted it using infrared scans. Instead, the works in their collection were confirmed to have been sketched with pencil and ruler! It was mind-blowing to me that this level of realism was not the result of a cutting-edge technology, but of old-school geometry and artistic craft.

When it comes to Ethereum, scaling has been an open topic since the early days, with a roadmap to switch the consensus algorithm from PoW to PoS and proposals to distribute the throughput across shards. This topic suddenly became very hot in mid 2017 when successful applications began testing the limits of the network while the progress on the roadmap wasn’t keeping the expected pace. In a series of articles, I intend to present the currently available scaling solutions and a way forward for scaling Ethereum. Some of these methods are essential knowledge for the preparatory drawings of decentralized applications, using the existing pencils and rulers to bring impressive throughput results. Other methods are breakthrough tools that can bring orders of magnitude greater precision, just like the camera obscura, which pioneered an evolution that led to the photographic camera and later to cinematography. This first post draws the line between the expectations and challenges of scaling a blockchain and outlines the possible solutions.

What makes the best blockchain?

Which characteristics are desirable for a blockchain?

  • multiple replications of the ledger;

=> As many nodes as possible (1.)

  • new modifications of the ledger to be appended fast and permanently;

=> Short blocktime, fast finality (2.)

  • the whole protocol to be cheap.

=> Cheap to run a node and to make transactions (3.)

Importantly, participants also want the blockchain protocol to be decentralized (for more, see the meaning of decentralization). The nodes of the network manage to come to consensus on the state of the ledger. In a blockchain, the ledger is constructed by aggregating blocks one after the other where transactions are batched. The blockchain protocol specifies rules about how the nodes of the network should select the next block. Some nodes are actively following the protocol by verifying the validity of newly received transactions, notably checking the associated signature and the account’s balance, but also preparing the next block. These nodes can be called validators. Let’s consider the following as minimum viable decentralization for a blockchain protocol:

Anyone willing to become a validator can become one and being a validator requires a reasonably low time and capital commitment.

Why do we pursue the ideal of decentralization?

To express the baseline of decentralization using economics language, the validators should be as contestable as possible and therefore the protocol should keep the barriers to entry to holding a validator position as low as possible. Ethereum’s philosophy as defined in the whitepaper (following those principles: Simplicity, Universality, Modularity, Agility, and Non-Discrimination) seems well-aligned with this definition. But… here comes the scalability debate:

We want a high throughput of transactions, but a blockchain cannot process more transactions than a single node can, and we do not want to compromise on decentralization. See the Eth Wifi on this and Zamfir’s triangle:

The common sense approach

A blockchain is a chain of blocks; if you want higher throughput, you can just put more transactions in each block (bigger blocks), or make more blocks (faster blocks), or both.

On Ethereum, transactions can range from the very basic transfer of ether from one address to another, to something more complex, such as requesting computation on a smart contract and triggering other transactions. Ethereum uses gas as a measure of the computational intensity of a transaction, where users pay fractions of ether (known as the gas price) as a fee for their transaction to be included in a block (learn more on gas here). Blocksize on Ethereum is represented by the amount of gas a block contains (gas limit) and validators (the miners) can vote the amount up or down. It’s worth noting that some major events in the history of Ethereum appear on the GasLimit chart:

Test your knowledge of Ethereum history by finding on this chart the CryptoKitties usage spike, the DAO hack, the Shanghai attack, the ICO bubble, and the Homestead hard fork.

Can the blocksize grow more?

The bigger the blocks, the lower the propagation. Blocks have to be executed and propagated by each node, and nodes have limited computing resources. Extending the gas limit implies gradually excluding consumer grade computers from becoming nodes on the network (there goes As many nodes as possible). This study identified 28% of Ethereum nodes as data-centers. I tend to consider this number as an indicator of the Ethereum protocol’s accessibility. A lower gas limit is particularly important for lightweight devices like IoTs or smartphones running the protocol using a specific lightnode protocol to easily find peers in the network.

You might think that the miners wouldn’t mind kicking out some of their peers and would push the gas limit higher if need be. That is not the case, because miners have a strong incentive to care: Ethereum’s low blocktime relies on the GHOST protocol. Increasing the blocksize leads to more uncles, or rewards for miners who find duplicate transactions (there goes the Short blocktime, fast finality), and thus lower rewards for miners, since uncles are less lucrative. Side note: there has been improvement on block propagation recently. See the daily uncle count chart:

Keep in mind that every day ~6000 blocks are included in the blockchain, adding to the canon transaction history and rewarding miners in the process (2 ether per block). At the peak of the market, there were 2000 uncles per day with a lower reward than a canon block, so you can understand why miners can be reluctant to risk cutting their rewards when congestion times mean earning more (there goes the Cheap to run a node and to make transactions):

Where do we go from here?

The ideal public blockchain should aim for: as many nodes as possible, as little as possible time between blocks, and a low cost to run a node and record transactions. Pursuing all three in tandem leads to a trilemma that the Ethereum community has been working to address with pragmatic, incremental changes and intense research.

The camera obscura opened new perspectives and led to the invention of the cinematography. New techniques in painting may not only improve the precision of the rendering, but can introduce radical changes in the usage of colors, shades, and shapes, ultimately creating whole new dimensions in the depiction. We can do the same to address the scalability trilemma in blockchain: creative solutions and workarounds are already in progress.

Venice, the Piazzetta with the Ceremony of the Doge Marrying the Sea — Joseph Mallord William Turner c.1835

This series will cover them in future articles outlined below.

  • Part one: Optimizing the Ethereum Virtual Machine so that nodes could handle more transactions.
  • Part two: Moving some of the computing off-chain.
  • Part three: Moving some transactions onto sidechains.
  • Part four: Ethereum 2.0, staking & sharding the chain

Ethereum at Scale, part 0 was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.