Detailed explanation with multiple pictures: How does Ethereum work? (Part 2)

Continuing from the previous article "How Ethereum Works (Part 1)"

Gas and Payments

A very important concept in Ethereum is the concept of fees. All the computations consumed by transactions on the Ethereum network will incur fees. As the saying goes, there is no free lunch in the world. The fees paid are calculated in "gas".

Gas is a unit used to measure the cost of a particular computation. The gas price is the amount of Ether you are willing to spend per unit of gas, measured in "gwei". "Wei" is the smallest unit of Ether, 1^018 Wei represents 1 Ether. 1 gwei is 1,000,000,000 Wei.

For each transaction, the sender (transferer) sets the gas limit and gas price. The gas price and gas limit represent the maximum number of Wei the sender is willing to pay for the transaction. For example, let's assume the sender sets the gas limit to 50,000 and the gas price to 20gwei. This means the sender is willing to pay a maximum of 50,000*20gwei=1,000,000,000,000,000 Wei, or 0.001 Ether, to execute the transaction.

Remember, the gas limit represents the maximum fee the sender of the transaction is willing to pay. If their account balance can cover this maximum, there will be no problem. At the end of the transaction, the sender will receive a refund for the unused gas funds and the transaction will be completed at the original price.

If the sender of a transaction does not provide enough gas to execute the transaction, the transaction will run out of gas and the transaction will be invalid. In this case, the transaction process is aborted and any state changes that occurred are reversed so that the transaction ends and returns to the state of Ethereum before the transaction. In addition, the transaction failure is recorded, showing what transaction was attempted and where it failed. At the same time, since the machine has already spent effort to perform the calculation before running out of gas, logically, this spent gas will not be refunded to the sender of the transaction.

Where do the gas funds go? All gas funds spent by the sender of a transaction are sent to a "beneficiary" address, which is usually the address of a miner. Since miners expend effort to calculate and verify transactions, miners receive gas fees as a reward.

Generally, the higher the gas price that the sender of a transaction is willing to pay, the more value miners get from the transaction. Therefore, miners will also choose transactions with high gas prices. In this way, miners freely choose the transactions they are willing to verify. In order to guide transaction senders to set gas prices, miners can choose to advertise the minimum gas price they will execute transactions at.

Storage also costs money.

Gas is used not only to pay for computational steps, but also for storage. The total cost of storage is proportional to the smallest multiple of 32 bytes used.

There are some nuances to storage fees. For example, since increasing storage increases the size of the Ethereum state database for all nodes, there is an incentive to keep the amount of data stored small. Therefore, if a transaction has a step that can clear an entry from storage, the fee for performing this operation is waived, and the fee can be refunded in order to free up storage space.

What is the purpose of the fee?

An important aspect of Ethereum's operation is that every operation performed by the network is affected by every full node simultaneously. However, computational steps on the Ethereum Virtual Machine are very expensive.

Therefore, Ethereum smart contracts are best suited for simple tasks, such as running simple business logic or verifying signatures and other cryptographic objects, rather than more complex uses such as file storage, email, machine learning, etc., which would put pressure on the network. Imposing fees can prevent users from overusing the network.

Ethereum is a Turing-complete language. In simple terms, a Turing machine is a machine that is able to simulate any computer algorithm. This allows loops and makes Ethereum vulnerable to the halting problem, a problem where you cannot be sure if a program will run infinitely. Without fees, malicious actors could easily try to disrupt the network by executing infinite loops in transactions without worrying about the cost. Therefore, fees protect the network from malicious attacks. You might be thinking, "Why do we also need to pay for storage?" Well, just like computation, storage on the Ethereum network has a cost, and the entire network has to bear the burden for it.

Transactions and messages

We note that Ethereum is a transaction-based state machine. In other words, transactions between different accounts drive the global state of Ethereum from one state to another.

In the most basic sense, transactions are cryptographically signed instructions that are generated by an external account, serialized, and then submitted to the blockchain. There are two types of transactions: message calls and contract creations (i.e. transactions that create new Ethereum contracts).

All transactions, regardless of their type, contain the following components:

• Nonce: A count of the number of transactions sent by the sender of a transaction.

• Gasprice: The number of Wei the transaction sender is willing to pay for each unit of gas required to execute the transaction.

• Gaslimit: The maximum amount of gas the sender of a transaction is willing to pay to execute the transaction. The amount is set and prepaid, determined before any computation is completed.

• To: The recipient’s address. If it is a transaction to create a contract, the contract account address does not exist yet, so a null value is used.

• Value: The total amount of Wei transferred from the sender to the receiver. In a transaction that creates a contract, this value is used as the initial balance of the newly created contract account.

• V,r,s: used to generate a signature that identifies the sender of the transaction.

• Init: A transaction that is used only to create contracts. It is a snippet of EVM code that can be used to initialize a new contract account. Init is only allowed once and then is discarded. When init is run for the first time, it returns the body of the account code, which is permanently associated with the contract account.

• Data: An optional field used only for message calls. It refers to the input data (i.e. parameters) of the message call. For example, if the smart contract acts as a domain name registration service, the call to the contract may require input fields such as domain names or IP addresses.

In the account chapter, we learned that transactions, such as message calls or contract creation transactions, are always initiated by external accounts and submitted to the blockchain. Another way to think about it is that it is these transactions that act as a bridge between the outside world and the internal Ethereum.

But this doesn't mean that these contracts can't communicate with other contracts. Contracts that exist within the scope of the Ethereum state can talk to other contracts that exist within the same scope. The way they communicate is through "messages" or "internal transactions". We can think of messages or internal transactions as being similar to transactions, with the main difference being that they are not generated by external accounts. Instead, they are generated by the contract. They are virtual objects, and unlike transactions, they are not serialized and only exist in the Ethereum execution environment.

When a contract sends an internal transaction to another contract, the code associated with the recipient contract account will be executed.

It is important to note that internal transactions or messages do not include a gaslimit. This is because the gaslimit is set by the external creator of the original contract, i.e. some external account. The gaslimit set by the external account must be high enough to execute the transaction, including any sub-executions that are caused by the transaction, such as contract-to-contract messages.

If, within a chain of transactions and messages, a particular message execution runs out of gas, the message execution is reverted, along with any subsequent messages triggered by that execution. However, the parent execution does not need to be reverted.

Block

All transactions are grouped together into blocks. The blockchain consists of a series of blocks linked together. In Ethereum, a block contains:

• Block header

• Information about the set of transactions contained in a block

• A set of other block headers of the current block's ommers

About Ommers

What exactly is ommer? An ommer is a block whose parent block is equivalent to the parent block of the parent block of the current block. Let's quickly understand what ommer is used for and why blocks contain ommers in the block header?

Because of the way Ethereum is built, the block time is shorter than other blockchains, for example, it is about 15 seconds/block, while Bitcoin's block time is 10 minutes/block. This allows it to have faster transaction speeds. However, one disadvantage of shorter block times is that miners will find more competing blocks. These competing blocks are also called "orphan blocks" (that is, the blocks mined did not enter the main chain).

The purpose of ommers is to help reward miners for including these orphan blocks. The ommers that miners include must be "valid", meaning within six generations or less of the current block. After six generations, old orphan blocks are no longer referenced because including older transactions would complicate things.

Ommer blocks receive less reward than full blocks, but there is still an incentive for miners to include these orphan blocks and receive the reward.

Block header

Let's go back to the block. We mentioned before that each block has a block header. What is it?

The block header is a part of the block, including:

• parentHash: The hash value of the parent block header (this is also what makes the blocks connected into a chain)

• ommersHash: The hash value of the ommers list of the current block

• Beneficiary: Account address that receives mining fees

• stateRoot: hash of the root node of the state trie (the state trie is stored in the block header and is more convenient for light clients to verify any information about the state)

• transactionsRoot: The root node hash value of the trie containing all transactions listed in the block

• receiptsRoot: The root node hash of the trie containing all transaction receipts listed in the block

• logsBloom: Bloom filter (data structure) that contains log information

• difficulty: difficulty level of the block

• number: the count of the current block (the block number of the genesis block is 0, and each subsequent block thereafter increases in sequence)

• gasLimit: The current gaslimint per block

• timestamp: Unix timestamp of the start of the block

• extraData: additional data related to the block

• mixHash: is also a hash value, which, when combined with nonce, proves that the block has performed enough calculations

• nonce: It is also a hash value. When it is combined with mixHash, it proves that the block has performed enough calculations.

Notice how each block header contains three trie structures:

• State (stateRoot)

• Transaction (transactionRoot)

• Receipts (receiptsRoot)

These trie structures are just the Merkle Patricia tries mentioned earlier. In addition, some terminology in the above description needs to be clarified.

Logs

Ethereum allows logs to facilitate tracing of transactions and messages. Contracts can clearly generate logs by defining "events", where "events" are what you want to log.

The log entry contains:

• The account address of the logger

• A series of topics representing different events in the execution of this transaction

• Any data related to these events

Logs are stored in bloom filters which store endless log data in an efficient manner.

Transaction Receipt

The log stored in the block headers is derived from the log information contained in the transaction receipts. Just like you get a receipt when you buy something at a store, Ethereum also generates a receipt for each transaction. As you would expect, each receipt contains some information about the transaction. The receipt contains the following:

• Block number

• Block Hash

• Transaction Hash

• The gas used by the current transaction

• The cumulative gas used by the current block after the current transaction is executed

• Logs created when executing the current transaction

• ......etc

Block Difficulty

The "difficulty" of a block is used to achieve consistency, so that the time it takes to verify a block is roughly the same. The difficulty of the genesis block is 131,072, and a special formula is used to calculate the mining difficulty of each block thereafter. If a block is verified faster than the previous block, the Ethereum protocol will increase the difficulty of the block.

The difficulty of producing a block affects the nonce, which is a hash value that miners must calculate using the PoW algorithm when mining a block. The relationship between block difficulty and nonce can be formalized mathematically as follows:

Where Hd is the difficulty.

The only way to find a nonce that meets the difficulty threshold is to use the PoW algorithm to exhaust all possibilities. The expected time to find a solution is proportional to the difficulty - the higher the difficulty, the harder it is to find the nonce, and the harder it is to verify the block, which will cause it to take longer to verify new blocks. Therefore, by adjusting the difficulty of the block, the protocol can control the time it takes to verify the block.

On the other hand, if the verification time becomes longer, the protocol will reduce the difficulty. In this way, the verification time adjusts itself to maintain a constant rate - one block every 15 seconds on average.

Trade Execution

We come to one of the most complex parts of the Ethereum protocol: the execution of transactions. Assuming you send a transaction to the Ethereum network for processing, what happens when the state of Ethereum is transformed to include your transaction?

First, all trades must meet an initial set of setup requirements before they can be executed. These include:

• Transactions must be in the correct RLP format. "RLP" stands for "Recursive Length Prefix" and is a data format used to encode nested arrays of binary data. RLP is the format used by Ethereum to serialize objects.

• Valid transaction signature

• Valid transaction nonce. Recall that an account's nonce is a count of transactions sent from that account. To be valid, a transaction nonce must be equal to the sender's account's nonce.

• The gas limit of a transaction must be equal to or greater than the intrinsic gas used by the transaction. Intrinsic gas includes:

1. A predefined cost of 21,000 gas to execute the transaction

2. The gas fee for the data sent with the transaction (4 gas per byte of data or code equal to zero, 68 gas per non-zero byte of data or code)

3. If the transaction is a contract creation transaction, an additional 32,000 gas is added

• The sender's account balance must have enough Ether to cover the "predetermined" gas cost, which the sender must pay. The calculation of the "predetermined" gas cost is simple: first, the gas limit of the transaction is multiplied by the gas price of the transaction to find the maximum gas cost. Second, the maximum cost is added to the total value, which is the total value transferred from the sender to the receiver.

If the transaction meets all of the above validity requirements, we proceed to the next step.

First, we deduct the scheduled execution cost from the sender's balance and increase the sender's account nonce by 1 to account for the current transaction. At this point, we can calculate the remaining gas, which is the total gas limit of the transaction minus the intrinsic gas used.

Next, the transaction begins to execute. During the execution of the transaction, Ethereum tracks "substates". This substate is a way to record information generated during the transaction, which is needed immediately after the transaction is completed. Specifically, it includes:

• Self-destruct set: A set of accounts that are abandoned after the transaction is completed (if any)

• Log series: Archive and indexable checkpoints of virtual machine code execution.

• Refund Balance: The amount of money that is refunded to the sender's account after the transaction. Remember when we mentioned that Ethereum storage costs money, and that senders are refunded for clearing storage? Ethereum keeps track of this using a refund counter. The refund counter starts at zero and increments every time the contract clears storage.

Next, the various calculations required by the transaction are processed.

Once all steps required by the transaction have been processed, assuming there are no invalid states, the final state is achieved by determining the amount of unused gas to be refunded to the sender. In addition to the unused gas, the sender can also receive some allowance from the "refund balance" mentioned above.

Once the sender gets a refund:

• The Ether for gas has been given to the miners

• The gas used by the transaction is added to the block gas counter (which keeps track of the total gas used by all transactions in the block and is useful when validating the block)

• All accounts in the self-destruct set will be deleted (if any)

Finally, we are left with the new state and a set of logs of transaction creation. Now that we have covered the basics of transaction execution, let’s look at some of the differences between transactions and message calls that create contracts.

--To be continued---

The author of this article is Preethi Kasireddy, from medium.com, translated by "Leo" from the Blue Fox Notes community.