I’ve spent time recently playing around with WebAssembly (WASM) and waPC. Rust and WASM were born at Mozilla and there’s a natural affinity with writing WASM binaries in Rust. In the WASM examples I’ve been using for WASM Transparency, waPC and MsgPack and waPC and Protobufs. I’ve created 3 WASM binaries: complex.wasm, simplex.wasm and fabcar.wasm and each is about 2.5MB when: cargo build --target=wasm32-unknown-unknown --release The Rust and WebAssembly book has an excellent section titled Shrinking .

I’ve been playing around with a proof-of-concept combining WASM and Trillian. The hypothesis was to explore using WASM as a form of chaincode with Trillian. The project works but it’s far from being a chaincode-like solution. Let’s start with a couple of (trivial) examples and then I’ll explain what’s going on and how it’s implemented. 2020/08/14 18:42:17 [main:loop:dynamic-invoke] Method: mul 2020/08/14 18:42:17 [random:New] Message 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [random:New] Message 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [random:New] Float32 2020/08/14 18:42:17 [Client:Invoke] Metadata: complex.

As my reader will know (Hey Mom!), I’ve been noodling around with WASM and waPC. I’ve been exploring ways to pass structured messages across the host:guest boundary. Protobufs was my first choice. @KevinHoffman created waPC and waSCC and he explained to me and that wSCC uses Message Pack. It’s slightly surprising to me (still) that technologies like this exist with everyone else seemingly using them and I’ve not heard of them.

A digression thanks to Sal Rashid who’s exploring WASM filters w/ Envoy. The documentation is sparse but: How to write WASM filters for Envoy… There is a Rust SDK but it’s not documented: proxy-wasm-rust-sdk I found two useful posts by Rustaceans who were able to make use of it: Extending Envoy with WASM and Rust Extending Istio with Rust and WebAssembly Here’s my simple use of the SDK’s examples. wasme curl -sL https://run.

Following on from waPC & Protobufs, I can now remotely invoke (arbitrary) WASM functions: Client: The logging isn’t perfectly clear but, the client gets (a previously added) WASM binary from the server (using the SHA-256 of the WASM binary as a unique identifier). The result includes metadata that includes a protobuf descriptor of the WASM binary’s functions. The descriptor defines gRPC services (that represent the WASM functions) with input (parameters) and output (results) messages.

Following on from waPC & Protobufs and a question on Stack Overflow about Cloud Functions, I was compelled to try running WASM on Cloud Functions no JavaScript. I wanted to reuse the WASM waPC functions that I’d written in Rust as described in the other post. Cloud Functions does not (yet!?) provide a Rust runtime and so I’m using the waPC Host for Go in this example. It works! PARAMS=$(printf '{"a":{"real":39,"imag":3},"b":{"real":39,"imag":3}}' | base64) TOKEN=$(gcloud auth print-identity-token) echo "{ \"filename\":\"complex.

I’m hacking around with a solution that combines WASM and Google Trillian. Ultimately, I’d like to be able to ship WASM (binaries) to a Trillian personality and then invoke (exported) functions on them. Some this was borne from the interesting exploration of Krustlet and its application of wascc. I’m still booting into WASM but it’s a very interesting technology that has most interesting potential outside the browser. Some folks have been trailblazing the technology and I have been reading Kevin Hoffman’s medium and wascc (nee waxosuit) work.

I’ve been spending some time this week with Krustlet. I’m working on documenting how to run Krustlet(s) alongside GKE. I’ve been running a Krustlet with MicroK8s. The Krustlet demos reference WASM assemblines stored in Azure Container Registry as OCI containers. Google Container Registry supports OCI format and so I tried (successfully) using GCR instead of AZR. There may be an easier approach but this is how I got this working.