(1) Ethereum Virtual Machine
The Ethereum Virtual Machine (EVM) is the runtime environment for smart contracts in Ethereum. It is another major innovation in the Ethereum project. Some people say that the EVM is "on top of the blockchain", but it actually consists of many interconnected computers. Anyone can upload programs and have those programs execute automatically, while guaranteeing that the state of each program now and all previous ones is always publicly visible. These programs run on the blockchain and continue to execute strictly as defined by the EVM. So anyone can create business logic for ownership, transaction formats, and state transition functions.
(2) Account
There are two types of accounts in Ethereum that share the same address space. External accounts, which are controlled by public-private key pairs. Contract accounts, which are controlled by the code stored in the account. The address of the external account is determined by the public key, and the address of the contract account is calculated from the address of the contract creator and the number of transactions sent by the address when the contract is created. The only difference between the two types of accounts is that an external account has no code, and people can send messages from an external account by creating and signing a transaction. Whenever a contract account receives a message, code inside the contract is activated, allowing it to read, write, send other messages, and create contracts to the internal storage.
An Ethereum account consists of 4 parts: ① a random number, a counter used to determine that each transaction can only be processed once; ② the account’s current ether balance; ③ the account’s contract code (if any); ④ the account’s Store (default is empty).
(3) News
Ethereum's message is somewhat similar to Bitcoin's transaction, but there are 3 important differences between the two.
1) Ethereum messages can be created by external entities or contracts, while Bitcoin transactions can only be created externally.
2) Ethereum messages can optionally contain data.
3) If the receiver of the Ethereum message is a contract account, it can choose to respond, which means that the Ethereum message also contains the function concept.
(4) Transaction
A "transaction" in Ethereum refers to a signed packet that stores a message sent from an external account. The transaction contains the recipient of the message, a signature to confirm the sender, the balance of the ether account, the data to send, and two values called STARTGAS and GASPRICE. In order to prevent exponential explosions and infinite loops in the code, each transaction needs to limit the computational steps caused by the execution of the code. STARTGAS is to limit the calculation steps by the fuel that needs to be paid, and GASPRICE is the price of the fuel that needs to be paid to miners for each calculation step.
（5）Gas
Every transaction on Ethereum is charged a certain amount of gas, which is set to limit the amount of work required to execute a transaction, while paying a fee for the execution of the transaction. When the EVM executes a transaction, Gas will be gradually consumed according to certain rules. The gas price is set by the transaction creator, and the prepaid transaction fee for the sending account = GASPRICE*Gas amount. If there is still Gas remaining at the end of the execution, these Gas will be returned to the sending account. An out-of-gas exception is triggered once the gas is exhausted, no matter where the execution is. At the same time, all state modifications made by the current calling frame will be rolled back.
(6) Storage, main memory and stack
Each account has a permanent memory area called storage, which is in the form of key-value, and the length of both key and value is 256 bits. In the contract, the storage of the account cannot be traversed. Compared with main memory and stack, the read operation overhead of storage is larger, and the modification storage is even more expensive. A contract can only read and write to its own storage.
The second memory area is called main memory. Each time the contract executes a message invocation there is a new piece of main memory that is cleared. Main memory can be addressed in bytes, but the minimum unit for reading and writing is 32 bytes. The overhead of operating main memory increases as main memory grows.
EVM is not register-based, but a stack-based virtual machine. So all computations are performed in an area called the stack. The stack has a maximum of 1024 elements, and each element has 256 bits. Access to the stack is limited to its top, allowing copying of one of the top 16 elements to the top of the stack, or swapping the top element with one of the 16 elements below. All other operations take only the top element or elements and push the result on the top of the stack. Of course, you can put elements on the stack into storage or main memory. However, it is not possible to access only the element at the specified depth in the stack. Before that, all elements above the specified depth must be removed from the stack.
(7) Instruction set
The EVM's instruction set is deliberately kept to a minimum to avoid bugs that could lead to consensus issues as much as possible. All instructions operate on the basic data unit of 256 bits, with common arithmetic, bit, logic and comparison operations, and can also perform conditional and unconditional jumps. Additionally, the contract can access relevant properties of the current block, such as its number and timestamp.
(8) Message call
Contracts can call other contracts through message calls, or send ether to non-contract accounts. Message calls and transactions are very similar in that they both have a source, a destination, data payload, ether, gas and return data. In fact each transaction can be thought of as a top-level message call, which in turn spawns more message calls.
A contract can decide the distribution of the remaining Gas. For example, how much Gas is used when the internal message is called, or how much Gas is expected to be retained. If an out-of-gas exception or other exception occurs during the internal message call, the contract will be notified and an error code will be pushed onto the stack. This situation is just gas exhaustion for internal message calls. In solidity, the contract making the call in this case will trigger an artificial exception by default, which will print out the call stack.
As said before, the called contract (and the calling contract as well) will have fresh main memory and be able to access the calling payload. The call payload is stored in a separate area called calldata. After the call is executed, the returned data will be stored in a block of memory pre-allocated by the caller. The number of call layers is limited to 1024. So for more complex operations, we should use loops instead of recursion.
(9) Code calls and libraries
There is a special type of message call in Ethereum called callcode. It is almost identical to a message call, except that the code loaded from the target address will run in the context of the contract that made the call. This means that a contract can dynamically load code from another address at runtime. Storage, current address and balance all point to the calling contract, only the code is fetched from the called address. This allows Solidity to implement "libraries". Reusable library code can be applied to the storage of a contract and can be used to implement complex data structures, thereby making smart contracts more powerful.
2. State transitions in Ethereum
The state transition of Ethereum refers to the transition process of Ethereum from one correct state (S) to the next correct state (S') when a transaction (TX) occurs, as shown in Figure 2-15. For transactions, in order to prevent exponential explosion of code and infinite loops, each transaction needs to limit the computational steps caused by executing the code. STARTGAS is the limit, and GASPRICE is the fee price that miners need to pay for each calculation step.