Verifying offchain computations using TrueBit. Sami Makela
1 like192 views
This document discusses the TrueBit protocol for verifying offchain computations on the Ethereum blockchain. It describes how computations can be done offchain but still guaranteed to be correct through a process of solvers posting solutions and verifiers checking them. If a solution is incorrect, verifiers can challenge it. The protocol uses a technique of binary search to efficiently locate points of disagreement between solvers and verifiers, which can then be adjudicated onchain. It aims to enable virtually any computation to be verified in this way.
Verifying offchain computations using TrueBit. Sami Makela
- 1. Verifying offchain computations using TrueBit Sami Mäkelä
- 2. Onchain computation ● To execute smart contracts, we have to have a way to perform trusted computations ● Blocks include transactions ● Every full node executes all transactions ● So miners will have to be honest, or their blocks are rejected
- 3. Problems with increasing the limit ● Currently 6Mgas available for each block ● For example too little to be able to compute scrypt hash ● If the computations are too long, nobody will have time to check them ● Other problem is that if the computations become costly, perhaps eventually the miners will try to save by making incorrect computations ● There are over 20000 nodes, so when you make a transaction, you are buying a lot of computation power ● Longer computations in current Ethereum blockchain could be very expensive
- 4. TrueBit ● Computations can be done offchain ● But they can still guaranteed to be correct ● Examples of verifying offchain computations ● Square root ● Ordered list ● Any computation
- 5. Square root ● For some reason our smart contract has to know square root of variable N ● Instead computing it, calculate it offchain, and verify it in the smart contract ● √N*√N<= N && N < (1+√N)*(1+√N)
- 6. Ordered list ● The complexity of maintaining and ordered data structure is O(log(N)) per operation ● For example a balanced tree might be complex to implement ● Use linked list, calculate offchain to after which cell the new value should be inserted
- 7. Example 12 at 0xf382 34 at 0xa424 132 at 0x1357 64 at 0x627e
- 8. Any computation? ● Any computation can for example represented as bytecode or the merkle root of the byte code ● Then there is the input ● How can we verify that a given output is the result of the computation? ● The bytecode and input are passed to the TrueBit contract ● TrueBit will return verified output
- 9. Solvers and verifiers ● There are two kinds of tasks that are needed for the system to operate ● Solving a task: post a solution for the task ● Verifying a task: check if the posted solution is correct ● If the solution is incorrect, verifier can challenge it ● Not all Ethereum nodes have to compute everything, because it can be assumed that small fraction of nodes will be enough to produce fraud proofs
- 10. Basic idea ● Computations can be divided into simple steps or state transitions ● Each state has a deterministic next state ● Only a small amount of data is needed to calculate the next state (Merkle trees) ● Each transition can be verified onchain 0xacb..23 0xcab..31 0xa2b..f3 0x5cb..62 0x4cb..25
- 11. Binary search and judges ● Everybody agrees on the initial state ● Solvers and verifiers can use interactive protocol to find the first state where they disagree (binary search) ● This state can then be posted to a smart contract that can determine what is the next state (judges)
- 12. Example (binary search) 1 2 3 4 5 6 7 8 9 10 1 2 3 6 7 8 9 10 11 12 13 2 Different results Judge will check the transition from 3rd state to 4th state
- 13. Example of judging (memory access) 1. Check correctness of machine state wrt. hash 2. Check if the opcode is actually a memory access opcode 3. Check what is the value of the memory cell in the position given by the address register 4. Write the value to register 5. Calculate new root hash
- 14. Machine state (simplified) Op code: LOAD R1: 3 R2: 0 Mem: 0x234..123 PC: 2 123 234 543 23 45 56 23 554 h(123,234) h(543,23) h(45,56) h(23,554)
- 15. Forced errors ● Verifiers can be rewarded from finding errors ● To incentivise the verifiers, there has to be errors that they can find ● If the probability of errors is too low, the expected return for verifiers is negative ● Some tasks will be randomly selected to have a “forced error”, where the solver will have to post a wrong solution ● The verifiers that detect this error will get a special reward ● This ensures that it is profitable to run verifiers
- 18. WebAssembly ● Basically a generic compilation target like LLVM bitcode ● Can be efficiently ran using JIT compilers ● Intended for web applications, for example games ● For interpreters, there are some challenges
- 19. Emscripten and filesystem ● Emscripten is the system that is used to compile from C (or some other language) to WebAssembly ● Emscripten has runtime written in JavaScript ● So for TrueBit we need our own runtime ● Some kind of access to files etc. ● The file system represents the input and output for the task
- 20. TrueBit VM ● Simple to convert from WebAssembly (most instructions are the same) ● Special instructions for handling file system ● Efficient to interpret ● Can output merkle roots (hashes) of intermediate states ● Can generate the proofs needed for judges
- 21. What kind of computations can be verified ● Hardest part is getting the programs to compile ● After that, basically any program can be first ran locally, and then it can be posted into TrueBit for verification ● Nondeterministic system calls like “gettimeofday” can just be recorded and replayed to make the computation deterministic
- 22. Offchain data ● IPFS, Swarm, etc. ● Because of hashes, in principle the programs can safely refer to IPFS ● Data availability problem
- 23. Example applications ● DogEth: scrypt for Ethereum ● Other more complicated cryptographic algorithms ● Machine learning ● Data markets ● Solidity compiler ● General scaling