Understand the Ethereum whitepaper in 15 minutes

Learn enough Ethereum to get dangerous

Understand the Ethereum whitepaper in 15 minutes

Similar to the Bitcoin whitepaper, the Ethereum whitepaper is now a seminal paper in the field of cryptocurrency. Today, we shall explain the Ethereum whitepaper in 15 minutes. Before we get started, it is highly recommended that you read our previous breakdown of the Bitcoin whitepaper as it lays out the foundational technologies.

Ready? Let's get the timer going.

Vision

Vitalik emphasized that it is important to move beyond money and currency, and to look at the underlying blockchain technology that allows the network to achieve distributed consensus. This will allow users to open up many more applications, including smart contracts and decentralized autonomous organizations.

To achieve this, Vitalik plans to build a Turing-complete programming language on top of the blockchain technology.

Quick aside: What is a Turing-complete programming language?

A Turing-complete programming language is a language that allows you to write a program to solve any computational problem. If you use a Turing-complete programming language, you can write a program to find the shortest path between any two places, but you can't write a program to solve your love problems (unless they are computational in nature ;)).

Vitalik also noted that it is not feasible for most applications to write their own blockchain from scratch (since most applications will only serve a few users). Thus, Ethereum can help developers develop apps for the blockchain faster.

Key weakness of Bitcoin's scripting language

1. Lack of Turing-completeness- specifically, loops are not allowed. However, loops are very common in computer programs, think of the sending email to an email list. The 'for loop' is commonly used in such a case.

2. Value-blindness- if we want to send an unspecified amount that still falls within a range on a later date, the only way to do this in Bitcoin is to create many transactions that have all the possible values, then have a third party sign the correct transaction on that later date. This is highly inefficient!

3. Lack of intermediate states- if we want to have a script that has multiple steps (e.g. you want to sell stock X and use the profits to buy stock Y should stocks X and Y reach a certain price), Bitcoin is unable to keep track of the intermediate states. We have to actively monitor and sign the transactions only when the desired intermediate events occur.

Ethereum

Key features for developers

As mentioned earlier, Vitalik had developers in mind for his initial vision. Ethereum is meant to provide the following key features:

• Rapid development time

• Security for small and rarely used applications

• Ability of different applications to interact efficiently

Common terminologies

Accounts

Accounts are the objects that make up the state at each time point in the Ethereum ecosystem. Each Ethereum account contains the following information:

1. Nonce, a counter used to make sure each transaction can only be processed once (think of this as your id)

2. Ether balance

3. Contract code, if any

4. Storage (empty by default, but can be used to store other meta-information such as the temperature in a city)

In Ethereum, we have 2 types of accounts- transactions (think of them as from people) and messages (think of them as from programs). They are actually quite similar. Both of them will have:

1. Recipient

2. Signature (to identify the sender)

3. Amount of ether to be transacted

4. Optional data field (to send more details, e.g. price of a stock)

5. STARTGAS (maximum number of computational steps the transaction execution is allowed to take)

6. GASPRICE (fee the sender pays per computational step)

State transition function

We shall refer directly to the state transition function written in the original white paper as it has been expressed clearly.

1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error.

2. Calculate the transaction fee as STARTGAS * GASPRICE, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error.

3. Initialize GAS = STARTGAS, and take off a certain quantity of gas per byte to pay for the bytes in the transaction.

4. Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas.

5. If the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees, and add the fees to the miner's account.

6. Otherwise, refund the fees for all remaining gas to the sender, and send the fees paid for gas consumed to the miner.

Blockchain

Unlike Bitcoin, the Ethereum blockchain contains the most recent state (recall that Bitcoin stores just the transactions). However, memory is still efficient as from state to state, most of the accounts should remain the same. Using a special data structure called Patricia tree, the Ethereum blockchain can 'store once' and 'point twice' (i.e. at the current block, we can just point to the unchanged accounts in the previous block).

Concerns

Shorter block intervals leading to more stale blocks

With shorter block intervals, there will be more stale blocks as miners may perceive that they were the first to solve the proof of work when the accepted solution has not propagated to it. The threat of more stale blocks is that a mining pool with sufficient resources (but without having to have more than 50% of computational resources) can dominate the subsequent blocks in the chain. This leads to centralization of power. In addition, smaller miners may be disincentivized to

mine since their blocks are rarely included in the main chain. This further leads to increasing power in the hands of the bigger mining pools.

To solve this problem, Ethereum has adopted 2 solutions:

1. Include stale blocks in the total proof of work (as opposed to just non-stale blocks)

2. Provide block rewards to stale blocks to incentivize smaller miners to continue to mine

Infinite loops disrupting the system

To prevent the possibility of infinite loops from disrupting the system, Ethereum has adopted 2 solutions:

1. Charges execution fee regardless of whether the code finishes running

2. STARTGAS notifies miners of the number of computation steps

These measures disincentivize running an infinite loop as huge fees will be incurred, while miners will know in advance the length of a program.

Conclusion

So this is it! The Ethereum whitepaper is actually pretty easy to understand provided that you have read the Bitcoin whitepaper. In following issues, we will proceed to break down Ethereum's competitors' whitepaper, such as Solana and Cardano. Subscribe to not miss an issue from us!