Earlier this month I spent several days in The Bay Area to attend the WebAssembly summit and WebAssembly CG meeting. There were two reasons for me to attend, the first one a potential WebAssembly interpreter for Tezos, and the second one a WebAssembly backend for OCaml. The WebAssembly interpreter for Tezos would most likely need the following extensions to WebAssembly: reference types, typed function references, and type imports, which are also steps towards WebAssembly GC - a requirement for the WebAssembly backend for OCaml. For the interpreter, the conditional sections and constant time extensions are also interesting. Besides WebAssembly GC, the WebAssembly backend for OCaml also requires the following extensions: exception handling, tail calls, and at a later point also effects. In this article I will mainly focus on these extensions.
Reference Types
The Reference Types proposal adds an anyref type next to the existing int32, int64, float32 and float64 types. Anyref is an opaque type and allows for a more efficient interop with the host environment. The proposal also sets the stage for several other proposals: typed function references, type imports, garbage collection, and exception handling.
During the WebAssembly summit, Luke Wagner told me about the possibility of emulating WebAssembly GC with the help of anyref if you move all memory management to the host environment.
Although the reference types specification is almost finished, at the WebAssembly CG meeting there was discussion on if the subtyping from anyref to funcref should be removed to allow for different representations. This would however also indicate different null values. As a result the reference type specification remains stuck in the implementation phase of the standardization process, which as result also prevents other specifications from moving forward.
Presentation slides: https://github.com/WebAssembly/meetings/blob/master/2020/presentations/2020-02-rossberg-ref-type.pdf
Typed Function References
From the WebAssembly MVP there is only the funcref type which can be used for indirect calls, which requires a runtime check to see if the function type is correct. With the typed function references extension it will be possible to directly do indirect calls without doing a runtime check.
Typed Function References were not directly discussed during the CG meeting. Andreas Rossberg mentioned this was next on his list, but it got delayed due to the discussion mentioned above regarding reference types. He did mention that a slightly controversial part of the current Typed Function References proposal is that it introduces func.bind which creates a closure and therefore implies garbage collection.
As work on Typed Function References is just about to start, it also seems like a good opportunity to help out.
Type Imports
Anyrefâs are opaque and all anyrefâs are seen as the same type: anyref. As a result we canât give the same guarantees as Michelsonâs high level types provide in Tezos. To have the same functionality in Tezos we need support for type imports. Type imports allow for importing different types which allow us to emulate Michelsonâs behaviour.
Note that Type Imports proposal builds upon the Reference Types and Typed Function References proposals.
Type Imports were not discussed directly.
Garbage Collection
One goal of WebAssembly is to support languages with garbage collection, GC, at some point.
The specifications upon which GC specification builds are reference types, typed function references, and type imports.
Targeting WebAssembly with GC support requires considerable work on the producer side as itâs quite different from native backends. There is no support for manipulating the operation stack due to security reasons, and therefore data structures need to be changed into ones that the GC can trace. As a result, using WebAssembly GC will most likely require a separate runtime.
The discussion on WebAssembly GC at the CG meeting was about structural vs. nominal types. Structural types match when the structures are equal and nominal types match when the names are equal. Most languages use a combination of both. There wasnât a real conclusion to the discussion, but I believe ideally both should be supported by WebAssembly to properly support different languages.
Iâm skeptical that this will go anywhere soon and I wouldnât be surprised if it will take another two years. To me it also seems that people who have incentive to push this forward seem underrepresented.
Presentation slides:
https://github.com/WebAssembly/meetings/blob/master/2020/presentations/2020-02-rossberg-gc-pt1.pdf
https://github.com/WebAssembly/meetings/blob/master/2020/presentations/2020-02-rossberg-gc-pt2.pdf
Conditional Sections
The Conditional Sections proposal gives the ability to define engine requirements to a section in the binary format. This makes it possible for instance to have a condition âtezos-wasmâ and make sections that use this condition to indicate certain requirements and limitations. It wonât directly be important, but itâs a good way to distinguish us from ânormal wasmâ and might also be interesting when we mix âtezos-wasmâ with other forms of wasm.
To be honest I forgot exactly what was discussed during the CG meeting, besides that there were things to figure out which prevented the proposal from moving to the next stage.
Constant Time
Constant Time is an extension to WebAssembly that adds constant time operations. Operations that happen in constant time make it impossible to make guesses based on duration. Implementing this is challenging as it needs to happen at every layer from the program to the actual instructions on the CPU, but considering the security benefits definitely worth it. For example it will become possible to implement cryptography libraries in WebAssembly with this extension.
During the CG meeting one of the things that was discussed was reusing existing operations instead of creating a separate set of operations. Also the constant time proposal was moved to stage 0.
Exception Handling
This proposal does what the title says, and seems to be stabilizing nicely and moved forward to stage 2. It is dependent upon the reference types proposal, so the changes there also need to be implemented in this proposal.
Effects
Roughly speaking effects allow you to yield a piece of code and resume it at a later point. As a result itâs possible to create various complex control flows like async-await, iterators, parsers, concurrency, exceptions, etc.
I was disappointed not to see this extension move forward to stage 0. Hope this will change in one of the upcoming meetings.
Presentation slides:
Conclusion
The specifications surrounding WebAssembly are moving slowly but steadily forward.
The current state of WebAssembly proposals offers a nice opportunity to help out and move things forward for Tezos. Although there are multiple parties, also from the blockchain space, that have interest in WebAssembly - each party is pushing their own agenda forward and therefore not necessarily that of Tezos.
An actual WebAssembly backend with garbage collection for OCaml seems still far away. In the meantime itâs possible to move things forward by targeting WebAssembly with reference types and doing everything on the host environment. Another approach could be to target JavaScript instead. In both cases it will help with getting the OCaml internals ready for WebAssembly GC.
