- Have issues with scalability:
- Every miner needs to emulate every execution step for the VM
- Thus, charges gas for those who want to advance state of VMs
- To compensate miners
- The complexity of contracts is capped by the global gas limit
- All contract code and data can only be public
- Total throughput is ultimately limited to the number of steps a single miner can emulate in one block (plus margin of error)
- Spoiler: Yes.
- SNARKs
- Require trusted setup for every contract
- Off-chain proof generation is very expensive
- Incentivized verification (TrueBit)
- No privacy
- Serious incentive compatibility problems (i.e., not game theoretically sound)
- State channels
- Assumes unanimous off-chain agreement
- Dispute resolution is slow and expensive
- Uses a combination of:
- Protocol design
- Incentives
- Innovative virtual machine architecture (making dispute resolution cost extremely low)
- Could implement Bitcoin-style miners, central authority, PBFT, etc.
- We're agnostic in Arbitrum, and just call this a "Verifier"
- It publishes a log of acceptable transactions, but their algorithm is a pluggable module
- When you make a VM, give a list of managers for it
- The job of managers is to track the VM's computation and data, and ensure it's behaving correctly
- "Any-trust" guarantee:
- As long as at least one manager of a VM is honest, then VM will execute correctly according to its code
- You can trust a VM will execute correctly so long as you trust at least one manager!
- How do managers cooperate off-chain in order to advance the state of the VM?
- It offers incentives to agree unanimously about what a VM will do
- If they all agree, the system accepts the assertion
- Managers get together and create a "unanimous assertion"
- A set of preconditions:
- The hash of the state of the VM, and the hash of the VM's incoming transactions
- Then the VM executes N steps of computations
- And the VM executes a particular set of side effects & messages
- The resulting state is a hash of the state of the VM, and a hash of the VM's remaining incoming transactions
- A set of preconditions:
- If this will be signed by all managers, then users can agree that this is the current state.
- But what if all managers don't agree?
- Then we fall back to "disputable assertions"
- Any manager who makes a claim puts down a deposit
- During that time, any other manager can challenge them, deposit funds
- Whoever wins the dispute wins some of the other's deposit
- Creates incentives around making correct assertion
- Any manager who makes a claim puts down a deposit
- Then we fall back to "disputable assertions"
- A timer starts after any assertion; if timer expires without a challenge, then it is accepted as unchallenged and correct.
- They perform a bisection game, a la TrueBit
- This ends in a final one-step proof
- How costly is it to create and verify a one-step proof?
- Here's why this is easy:
- The Arbitrum VM allows all instructions to be emulated in small constant time
- One-step proofs are of small constant size and can be created and verified in small constant time (a few hundred bytes, verified in a few milliseconds)
- How?
- Four principles in the VM design:
- The entire state is in a Merkle Tree
- The tree is of limited degree (branching factor <= 8)
- Every leaf is of limited size (no more than 32 bytes)
- Instructions only ever affect items near the top of the tree
- Four principles in the VM design:
- In a conventional architecture, this is not easy
- Memory is usually flat
- Changing anything in a normal Merkle Tree requires a logarithmic number of steps in the size of the state
- In Arbitrum, memory is handled differently
- Large flat memory -> now instead, fixed size blocks ("tuples")
- Emulator managing tree -> now instead, application level code manages the tree
- Memory-read instructions -> now instead, a library call
- 1 instruction * O(log n) cost -> O(log n) instructions * O(1) cost
- O(log n) proof / verification -> O(1) proof/verification
- In other words, the cost of verification and emulation is same in total, but reads are broken down into multiple instructions to allow each instruction to be O(1)
- Code is also handled differently:
- Store code in a list -> now instead, we store code in a stack
- Advance the program counter -> now instead, we pop the instruction stack
- Jump -> now instead, we replace the instruction stack with a new one
- Call a function -> now instead, you push a reference to the current instruction onto a call stack
- All of this happens in constant time!
- There's a single state root
- Beneath that is the instruction stack, the data stack, the call stack, static variables, and registers
- Laid out as follows:
- root := { Top: 5, Rest: ptr_to_next }
- next = { Top: 4, Rest: ptr_to_rest_of_tree }
- State of VM is revealed only to VM's managers
- All that appears onchain is:
- Saltable hashes of VM state
- Number and timing of steps are executed
- Messages and money sent and received by VM
- Runtime and protocol
- VM emulator, assembler, and loader
- Honest manager that makes/defends assertion
- Supports pluggable consensus algorithm
- Arbitrum standard library
- Built to interoperate with Ethereum
- Can compile VM code from Solidity
- VMs can handle Ether or other ERC20 / ERC721 tokens
- Arbitrum tokens ("Arbs") used for deposits
- In development by Offchain Labs
- 1 Arbitrum VM performs 970K SHA2 hashes/second
- Native machine performs about 1.7M hashes/s
- Ethereum supports about 10K hashes/s globally
- Arbitrum enables scalable, private smart contracts
- Basically, TrueBit on steroids, with a custom-built VM and full economic model + partial privacy