The last installment briefly introduced some of the basics of rollup and the process of executing an aritrun transaction.This issue introduces the core technology of aritrum -- interactive single-step proofs.
This installment deals mainly with the validation nodes of the arbitrum
arbitrum architecture
The function of the validator node is twofold
- rblock by pledging assets out of L2
- Send single-step proofs to illegitimate blocks
The validation nodes of an arbitrum can be summarized as follows
-
Rpc server : Provides arbtirum rpc service (a superset of ethereum rpc).
-
Geth: Executive Layer
-
AVM : Verification Layer (the verification process is the translation of evm opcodes to avm)
Rpc module for accepting requests in Ethernet format (user experience L2 differs from L1 only in that L2 fees are much lower and there is hardly more than one configuration)
The Geth module is the execution layer of L1 and is used to execute L1 opcodes
AVM module is the verification layer of L2, used to verify the L2 opcode, not every transaction will go to the verification layer, the reality is that arbitrum has been running for more than a year, there has not been a transaction to the verification layer
Of course not going to the validation layer doesn't mean that the validation layer is useless, but that there is currently no good way to bypass the validation layer or to make the validation layer wrong (after all, in a blockchain system, mistakes are generally malicious)
AVM state machine
VM states are no more than these: the special state Halted (suspended), the special state ErrorStop, or other extended states.
The extended state contains the following:
-
Current Codepoint: represents the codepoint at which the current run is taking place.
-
Data Stack: This stack is the primary workspace for operations.
-
Aux Stack, Auxiliary Stack: this stack provides auxiliary storage space
-
Register: A variable storage unit that stores a single value.
-
Static: an immutable value that is determined at VM initialization.
-
AVMGas Remaining: A shaping that tells how many AVMGas can be consumed before an error occurs.
-
Error Codepoint: The codepoint to which Error corresponds.
-
Pending Message: A tuple of inbox messages (if any) to be processed.
When the VM is initialized, it is located in the extended state.The Data Stack, Aux Stack, Register, AVMGas Remaining, and Error Codepoint are initialized to None, None, None, MaxUint256, and Codepoint (0, 0), respectively. The entity that creates the VM provides the values of Current Codepoint and Static.
The final state of the vm is the concatenated hash of the above states
AVM opcode case
| Opcode | NickName | descriptive |
|---|---|---|
| 0x01 | add | Pop two values (A, B) from the data stack. If both A and B are integers, press the value A+B (truncated to 256 bits) onto the data stack. Otherwise, an error is raised. |
| 0x70 | send | Pop two values (A, B) from the data stack. If both A and B are integers, press the value A+B (truncated to 256 bits) onto the data stack. Otherwise, an error is raised. |
| 0x72 | inbox | If the pending message is not an empty tuple, the pending message is pushed onto the data stack and then the pending message is set equal to the empty tuple. Otherwise, it blocks until the virtual machine's inbox sequence is non-empty. The first item is then removed from the inbox sequence provided by the runtime environment and the result is pushed onto the data stack. |
AV M Data Structures Case
codepoint
Indicates the currently executing instruction. the code point of the instruction at some PC value in the arbitrum is (opcode at PC, Hash(CodePoint at PC+1)). If there is no CodePoint at PC+1, then 0 is used.
Data Stack
Indicates the stored data stack. When an instruction code is executed, a specified amount of data is removed or pressed into the data stack according to the logic of the instruction code. The data stack uses a similar chain structure.
Note: codepoint is a chain structure, the execution process will not change, data stack to meet the stack operation logic.
interactive proof
Split agreement (simplified)
Alice defends her claim that, starting from the state of the parent block, the state of the virtual machine can advance to the state on block A that she claims. Essentially, she is claiming that the virtual machine can execute N instructions, consume M messages in the inbox and convert the hash from H' to H.
Alice's first action requires her to slice her assertion from the beginning (0 instructions executed) to the end (N instructions executed) by the midpoint. The protocol requires Alice to slice her assertion in half, posting the state of the midpoint after N/2 steps of instructions have been executed.
After Alice has effectively bisected her assertion into two N/2-step assertions, Bob needs to choose one of these two segments and declare it wrong.
Here we are back to the previous state: Alice asserts an assertion and Bob disagrees. But now we have shortened the length of the assertion from N to N/2. We can repeat the previous action again, with Alice bisecting, and Bob choosing the half he disagrees with, shortening the scale to N/4. We can continue that action, and after pairs of rounds of gaming, the point of contention between Alice and Bob is reduced to a single-step operation. Since then, the splitting protocol terminates, and Alice must generate a single-step proof for EthBridge to detect.
A as the speedster, c as the challenger
- A asserts that the L2 state machine undergoes N opcodes in the H0 state before arriving at the Hn state (H0,Hn denote the final state of vm mentioned above)
- C asserts that H0 does not become Hn after N operations
- A dichotomizes the N-step operation Show that H0 becomes H(n/2) after N/2 operations
Note that it is implied here that H(n/2) becomes Hn after the remaining N/2 operations, and C needs to point out the error in one of the two paragraphs.
- C denotes that H0 does not become H(n/2) after n/2 operations
- A denotes that H0 becomes H(n/4) after n/4 operations
- C denotes that it does not become H(n/4) after N/4 operations from H(N/4)
.
.
. - The representation Hi does not become H(i+1) after an operation.
- A submit Hi state of the world information (that is, those stacks mentioned above, codepioint of that information, but not all, for example, Add opcode only two operands, then the data stack is only two, since the whole stack is hashable, so A can not do evil)
The flowchart on the code behaves like this
single-step proof
The initial state AVM state is the same, as follows:
Different status after one step
The verifier obtains information about the other party from the chain and learns that the other party has the same state as the local state before executing the add, and a different state after executing it
The verifier submits the pre-execution state, the state hash of each of the other unchanged stacks, the codepoint of the add instruction, the first two elements of the data stack, and the post-execution state of the add instruction to the chain. (The pre- and post-execution state is used to ensure that the step is indeed problematic and to imply that the verifier agrees with the pre-execution state, and the unchanged stacks are uploaded because they will be used later to compute the final state.)
The result of the validation is announced after the add operation is performed on the chain