Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fast, deterministic, and verifiable computations with WebAssembly


Published on

Mike Voronov @ Wasm on the Blockchain
June 09, 2019 – Berlin

Published in: Software
  • Be the first to comment

  • Be the first to like this

Fast, deterministic, and verifiable computations with WebAssembly

  1. 1. Fast, deterministic, and verifiable computations with WebAssembly Mike Voronov
  2. 2. • Run databases (Redis, SQLite) and stateful lambda functions in the 
 trustless decentralized environment
 • Charge developers for computational complexity only: no hash mining
 • WebAssembly as the platform for fast & verifiable stateful computations 2 Objective
  3. 3. Fast Deterministic Verifiable 3 Computation machine
  4. 4. What does it mean – verifiable? 4
  5. 5. Problems: • nodes running the same code got different computation results • nodes got same results but claim to have spent different amounts of gas Solutions: • consensus algorithms, ZK proofs, hardware enclaves • we use verification game (a part of a special kind of consensus) 5 Verifiable computations
  6. 6. • Verifier finds an incorrect state transition and opens a dispute on Ethereum • Verification game narrows the dispute to a single WebAssembly instruction • Ethereum smart contract repeats the instruction and penalizes the bad node 6 Verification game
  7. 7. Execution mode: fast execution • JIT/AOT compilation is essentially mandatory • Only final state (VM memory) matters
 Dispute mode: granular execution • JIT/AOT compilation is highly desirable • Intermediate states (VM memory, stack, instruction pointer) matter too • Ability to take & load VM snapshots, stop at k-th instruction • Ability to extract the data needed to execute single instruction on Ethereum 7 Execution duality
  8. 8. WAVM: .wasm => LLVM IR => native [AOT] Asmble: .wasm => JVM bytecode => native [JIT] 8 Two-stage compilation
  9. 9. WebAssembly to JVM compilation 9
  10. 10. • Each Wasm module is compiled to JVM class by Asmble • Both JVM and Wasm are stack-based VMs => straightforward conversion 10 WebAssembly to JVM bytecode
  11. 11. 11 Another example С++ Wasm Java
  12. 12. 12 Conversion table WebAssembly JVM Bytecode {i32, i64, f32, f64} –> {int, long, float, double} Wasm module –> JVM class Wasm function –> JVM function Wasm memory –> ByteBuffer global variables –> Class fields calls –> invoke{Exact | virtual | dynamic}
  13. 13. 13 Benchmark
  14. 14. Code instrumentation 14
  15. 15. 15 Dispute resolution: k-ary search • Need to record in Ethereum virtual machine state on every search step • Need to find the instruction which was executed differently: 😇 VMp–1 = 👿 VMp–1 😇 VMp ≠ 👿 VMp • Then, need to send this instruction along with required data to Ethereum
  16. 16. 16 Virtual machine state Need to track: • memory • stack • instruction pointer (ip) • executed instructions counter (eic) • used gas
  17. 17. Need to collapse all the required data into a single record Need to generate proofs for: • memory chunks and stack frames • instruction pointer and executed instructions counter • used gas HVM = hash(Hmem, Hstack, Hip, Heic, Hgas) Hmem = merkle(memory) ... Hgas = hash(gas) 17 VM state hash
  18. 18. Standard Merkle hash: • needs to rehash the entire memory region even if only a single byte was changed • is not optimal for multiple computations during k-ary search • is not optimal for large-scale state updated by simple request processing code 18 Linear memory hash
  19. 19. Idea: • track memory chunks that were made dirty 
 during the state transition VMi => VMi+1 • once the state transition is complete, all chunks are clean again • store a cache of intermediate hashes in the Merkle tree • when requested, recompute hashes (including Merkle root) on dirty paths only 19 Incremental memory hash
  20. 20. Algorithmic complexity: • need to recompute the dirty chunk hash • need to recompute all hashes on the dirty path O(chunk_size + hash_size * log(total_chunks)) 
 Additional memory usage: • dirty chunks bitmap index: 1 MB • tree hashes cache: 2 * 32 * 10242 = 64 MB 20 Incremental hash: complexity memory = 4 GB, chunk = 4 KB, hash = 32 B
  21. 21. 21 Attack: malicious code updates 1 byte in each memory chunk How much should we charge? The node had to rehash the 
 entire 4 GB memory, but the code has written just 1 MB. Solution: charge fixed price for each chunk that was dirtied algorithms taking into account page caching should not be hurt too much Incremental hash: gas usage
  22. 22. Normally, WebAssembly stack is implicitly supported by the JVM stack However, there is no easy way to access JVM stack data Stack emulation can be used to retrieve values from the WebAssembly stack 22 Shadow stack
  23. 23. 23 Execution mode: implicit stack
  24. 24. 24 Dispute mode: shadow stack
  25. 25. Structured control flow
 It is impossible to arbitrarily change instruction pointer in WebAssembly Basic block
 A code sequence with no branches in except at the entry and no 
 branches out except at the exit Control instructions
 Basic block in WebAssembly can begin or end with: • br/br_if/br_table • if/else • loop • return • end 25 Basic blocks
  26. 26. 26 Gas metering Gas metering and counting of executed instructions can be done statically by basic blocks { { 11¢ 13¢
  27. 27. Execution mode: • count spent gas and update executed instructions counter by basic blocks
 Dispute mode: • count spent gas by basic blocks until need to stop inside the block • then, count spent gas instruction by instruction 27 Dispute mode gas metering
  28. 28. Deterministic computations 28
  29. 29. • External function calls • VM resource exhaustion • NaN floating point payloads 29 Non-determinism sources in Wasm
  30. 30. Our approach: • imports from the host environment are not allowed • to obtain persistence, WebAssembly memory is backed to disk by the host system 30 External function calls In the future we plan to add support of a subset of WASI syscalls: 
 for example – time, filesystem, random number generation operations
  31. 31. Our approach: • developer configures desired memory and stack size • allocation of all dynamic Wasm parts (heap, stack, table) is performed at the virtual machine initialization • grow_memory always returns –1 31 VM resource exhaustion
  32. 32. NaN (not-a-number) – is a special type of a floating-point value 32 NaN payloads
  33. 33. Popular platforms have different behavior regarding NaNs
 New NaN value: • x86 – NaN with the sign bit set • ARM and others – produce with it unset 
 Operations with multiple NaN inputs: • x86 – first NaN input • ARMv8 – NaN depending on the signaling and quiet state 
 some hardware architectures prefer to return a NaN with a fixed bit pattern 33 NaN payloads
  34. 34. 34 NaN payloads Any arithmetical operations with NaNs produce NaNs
  35. 35. 35 NaN payloads Idea: instrument all floating-point operations – convert non-canonical NaNs into canonical NaNs Better idea: instrument only those operations that transfer floating-point values outside of the floating-point domain
 Outside transfer operations: • {f32,f64}.reinterpret_{i32,i64} – converts float value to integer • {f32,f64}.store – stores float value to the linear memory • copysign – copies the sign bit into a non-NaN value
  36. 36. Bottomline To obtain deterministic WebAssembly execution, we: • block syscalls (in the future: provide a subset of deterministic syscalls) • preallocate all dynamic resources • use the canonical NaN pattern when transferring floats outside 36
  37. 37. Few words about Fluence 37
  38. 38. 38 Fluence: hybrid security approach Speed layer On-demand database (Redis/SQLite) clusters Security layer DB transaction history validation for 
 the entire network Data availability layer DB transaction history storage in Swarm/Filecoin Dispute resolution layer Verification game with Ethereum as the final judge
  39. 39. Speed layer • Ethereum holds the registry of deployed databases • Consensus-based (BFT) replication between nodes • Direct frontend <–> database interaction • TX history is uploaded to Swarm/Filecoin
 Tendermint WebAssembly 39
  40. 40. Security layer Composition: • TX history is verified segment by segment • Segments are sequentially verified by several validators Validators: • Are randomly selected from the shared network pool • Verify that preceding validations were autonomous • Do not know if there will be a subsequent validation 40
  41. 41. 41
  42. 42. Thanks!