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:

https://github.com/WebAssembly/meetings/blob/master/2020/presentations/2020-02-rossberg-continuations.pdf

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.