Gas, Payment:
In the first section, we introduce that $\Upsilon$ and $\sigma$ and the formula.
$$ \sigma_{t+1} = \Upsilon(\sigma_t,T) $$
Can compute anything in the Ethereum world. But in order to avoid network abuse and make sure any operation and calculation will stop eventually (preserve Turing complete characteristic) → therefore, fee is included in all operations and transactions.
The fee schedule is specified in units of gas . See more in https://www.evm.codes/ which have tables to specify how many gas minimum need for a low-level operation.
Every transaction have a specific amount of gas associated with it: gasLimit → the amount of gas implicitly purchased from the sender account balance and after execution refund unused gas (at the same rate at purchase). The user cost will be calculated = gasLimit * maxFeePerGas . If the transaction hits the gas limit before finishing → it will revert with error code “out of gas” and will not refund any gas.
Note: So this is importance to test and build locally first before broadcast on the chain.
After the introduction of EIP-1559 (London hard fork). All the transaction now will have a base fee which formular is referring the above section. The base fee is burned (destroyed) after the block concluded → it is removed from the total circulating supply of Ether
The priority fee is introduced (wei per unit of gas consumed) for the user who want their transactions to conclude faster. The priority gas will be delivered to the beneficiary address, the address of an account typically under the control of the validator or simply is the miner address - validator in current block output / backward compatibility before Paris Fork.
Type 2 transactions have 2 more field: maxPriorityFeePerGas and maxFeePerGas Which the condition that the maxFeePerGas must be ≥ base fee
Type 0 and 1 transaction only have gasPrice also must be ≥ base fee and in this type of transaction → the higher the gasPrice → more priority for that transaction.
Transactors can freely choose any priority fee but often choose the minimum value that maximize the change of include in the block. → minimax problem.
Transaction Execution:
This is the most complex part in the Ethereum protocol → define the state transition function $\Upsilon$:
Part 1: Assert the validity of the Transaction data:
- Transaction is well-form RLP: no trailing bytes
- Valid signature
- Valid nonce (equal with sender nonce)
- No contract code in sender account deploy
- Gas limit > intrinsic gas $g_0$
- sender balance cover the up front cost
- If type 2:
maxFeePerGas≥ block base fee $H_g$maxPriorityFeeGas$T_f$ ≤ $T_m$
- Type 0-1:
gasPrice≥ $H_g$
Substate: Any intermediate state during the execution will be logged. The format is this
$$ A \equiv (A_s,A_i,A_t,A_r,A_a,A_K) $$
Where:
- $A_s$: Self-destruct set → set off account will be discarded following the transaction
- $A_l$: Log set
- $A_t$: Set of untouch accounts → If empty acount → will be deleted.
- $A_r$: Refund balance
- $A_a$:
EIP-2929→ set of accessed accound address - $A_K$: Tuple of
(20 bytes address, 32 bytes storage slot)
The initial state $A_0$:
$$ A_0 \equiv(\varnothing,(),\varnothing ,0,\pi,\varnothing )
$$
- $\pi$ is the set of precompile contract addresses.
Part 2: Execution
- The execution follow a lot of rules and states/substates clearly define in Yellow paper.
- The final output remain will be:
- $\sigma’$ if run success or $\sigma$ if reverted
- Refund gas
- Logs
- Status: 1/0 (success/failure)
- Output: return data or revert error.
Execution Model - EVM:
The EVM is a simple stack-based architecture.
- Word size = 256 bit.
- Stack max size = 1024.
- Memory model = word-addressed byte array (volatile)
- Independent storage model: word-addressable word array (non volatile)
The machine does not follow standard von Neumann architechture
- Stored program code in virtual ROM interactable only by a specialized instruction
Fees overview: charged in 3 circumstances
- Fee intrinsic to the computation
- Deducted to form the payment for a subordinate message call / contract creation
- Increase usage of the memory
- The fee for this will be proportional to smallest multiple of 32 bytes that convert all memory indices include in the range.
Storage fees is expensive because it alters the permanent state of the blockchain, so it uses a dynamic pricing mechanism.
- Warm vs. Cold: Accessing a storage slot for the first time in a transaction is expensive; accessing it again is cheap.
- Refunds: Changing a non-zero storage slot back to zero issues a gas refund to the transactor, incentivizing state cleanup.
Here we only discuss the environment in which the EVM operates. For more detail, see Smart Contract Introduction.
Execution Environmemt:
Formal define as a tuple $I$
| Field | Meaning |
|---|---|
| $I_a$ | Address of the account owns the code. |
| $I_o$ | Sender address of the transaction originated this execution tx.origin |
| $I_p$ | Prices of gas paid by the singer of the transaction. Effected gas price $p$ |
| $I_d$ | Input data. If execution agent is a transaction → transaction data |
| $I_s$ | Address account that caused the code executing. msg.sender |
| $I_v$ | Value - in Wei |
| $I_b$ | Machine code |
| $I_H$ | block header of the present block |
| $I_e$ | Depth of the message-call / contract-creation |
| $I_w$ | Permission. |
Consensus mechanisms:
A consensus algorithm is a mechanism that allows users or machines to coordinate in a distributed setting. It needs to ensure that all agents in the system can agree on a single source of truth, even if some agents fail. In other words, the system must be fault-tolerant.
Component of a consensus mechanism:
- A set of participants to maintain a network
- PoW: miner
- PoS: Validators
→ To store the ledger → check new transactions → participate in the block creation process
- The Proposal Mechanism - ledger selection
- PoW: Solving the hash
- PoS: More staked → higher change of selection.
All the consensus algorithm will follow the same idea: The honest validator will make a coordinated decision that reflects the true state of the network, while malicious or failing nodes are penalized or ignored. And furthermore, the algorithms will favor for honest validator (give more benefits).
Proof of Work (PoW):
In Ethereum (before the Paris fork) utilizes proof-of-work as the mechanism that allowed the decentralized network to come to consensus. This make sure the double spending attacks or manipulates data become very difficult.
Work in Proof of Work:
It is all about solving a cryptographic challenge and giving the right answer using a computational expensive algorithms - bruteforces.
The proof-of-work protocol, Ethash, required miners to go through an intense race of trial and error to find the nonce for a block. Only blocks with a valid nonce could be added to the chain.
Briefly, Ethhash is an algorithms when input difficuilty and mixhash → bruceforce to find the correct nonce that satisfied the condition. The user (miner) who has the first nonce correct and verify by the chain will get the reward of 2 ETH
The ETH network is decentralized so there are many miners mining the same block. So another concept is created Ommer block .Ommer blocks are valid blocks created by a miner practically at the same time as another miner created the canonical block, which is ultimately determined by which chain was built on top of first. Ommer blocks usually happened due to network latency. And Ommer block is reward 1.75ETH
Security in PoW:
Blockchain rely on a single state as a source of truth. And because there are many miners participanting in the the process of mining and validating the new block. The famous 51% attack is hard to happend. Or if happend → the attack will need too much compute power that the ETH receive is not worth enough to get the compute power needed.
Pro and cons:
| Pros | Cons |
|---|---|
| Do not need ETH to start mining | Use a lot of enegry |
| It have been tested and proof to be secure | Big investment in equipment |
| Easy to implmement than PoS | Mining pools could potentially dominate the mining game, leading to centralization and security risks. |
Proof of Stake (PoS):
Proof of stake works by first we will have the Validators → To participate as a validator → must stake at least 32ETH and run 3 separate processes → next must join a queue (limit the rate of new validator)
- Execution client: For the execution layer - verify the transaction (sender has enough ETH to fulfill the transaction and they have signed it with the correct key)
- Consensus client: adding information and create the beacon block for the consensus layer
- Validator client: Validate the block.
Here is the full illustration of the ETH proof of Stake network with 2 layer:
- Execution layer
- Consensus layer
Fork choice:
- The fork-choice rule selects the next block using LMD-GHOST; see Combining GHOST and Casper.
- Finality: A transaction has “finality” in distributed networks when it is part of a block that can’t change without a large amount of ETH getting burned. The Proof of Stake Ethereum network define a epoch at that the first block appear is the “checkpoint” block and through a series of voting: Justification and Finalization (Casper-FFG algorithm)→ become immutable in the chain.
Pros and Cons:
| Pros | Cons |
|---|---|
| Staking makes it easier for individuals to participate in securing the network. More decentralization. Staking pools allow users to stake without having 32 ETH. | Proof-of-stake is younger and less battle-tested compared to proof-of-work |
| Staking is more decentralized. Economies of scale do not apply in the same way that they do for PoW mining. | Proof-of-stake is more complex to implement than proof-of-work |
| Proof-of-stake offers greater crypto-economic security than proof-of-work | Users need to run three pieces of software to participate in Ethereum’s proof-of-stake. |
| Less issuance of new ETH is required to incentivize network participants |
References
-
- Formal specification of the Ethereum execution layer.
-
- Paper describing Casper FFG together with the LMD-GHOST fork-choice rule.
-
Proof-of-stake (PoS) | ethereum.org
- Ethereum.org overview of proof-of-stake.
-
Consensus mechanisms | ethereum.org
- Ethereum.org overview of Ethereum consensus mechanisms.
-
Proof-of-work (PoW) | ethereum.org
- Ethereum.org overview of proof-of-work.