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

1. Fast, deterministic, and
verifiable computations
with WebAssembly
Mike Voronov
twitter.com/@vms11

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. Fast
Deterministic
Verifiable
3
Computation machine

4. What does it mean – verifiable?
4

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. • 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. 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. WAVM: .wasm => LLVM IR => native [AOT]
Asmble: .wasm => JVM bytecode => native [JIT]
8
Two-stage compilation

9. WebAssembly to JVM compilation
9

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
Another example
С++ Wasm Java

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
Benchmark
https://link.medium.com/PwslNPOSiX

14. Code instrumentation
14

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
Virtual machine state
Need to track:
• memory
• stack
• instruction pointer (ip)
• executed instructions counter (eic)
• used gas

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. 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. 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. 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
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. 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
Execution mode: implicit stack

24. 24
Dispute mode: shadow stack

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
Gas metering
Gas metering and counting of executed
instructions can be done statically by
basic blocks
{
{
11¢
13¢

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. Deterministic computations
28

29. • External function calls
• VM resource exhaustion
• NaN floating point payloads
https://dl.acm.org/citation.cfm?doid=3062341.3062363
29
Non-determinism sources in Wasm

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. 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. NaN (not-a-number) – is a special type of a floating-point value
32
NaN payloads

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
NaN payloads
Any arithmetical operations with NaNs produce NaNs

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. 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. Few words about Fluence
37

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. 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. 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

42. Thanks!
dash.fluence.network