New Research Area: zk-wasm

tl;dr - we need to start hiring and researching zk-wasm now.

Logos is moving quickly with its research development on what I like to call “the agreements layer,” which is a network of nodes that can agree on arbitrary information. The design requirements of this network are such that it can support multiple execution environments (or Virtual Machines (VMs)) on top of it.

It is also part of Logos’ design goals to enable privacy in any way we can. So while we will easily be able to port over the EVM or any of the various VMs currently under development, we would also like to create a privacy-first implementation. Bonus points if it doesn’t suffer the same scaling limitations that the EVM does (See Pieter’s EthPrague talk for an overview).

I don’t think I need to justify the “why zk” part of the situation, but I’ll give a few points as to the WebAssembly part:

  • It’s cool
  • While Solidity (and yes Vyper too) are the main targets for writing smart contracts, they are limiting to a large portion of the developer community. Wasm allows for smart contracts to be written in many of the popular programming languages opening up Logos to a larger swath of people to contribute applications. Since it is a platform for building communities, forcing people to choose a limited set of programing technology to build is against the goals of the system. (Logos will be built in Rust and Nim)
  • the Ethereum ecosystem, which we will continue to stay close with, is also researching this direction, although I am not aware of the current thread of investigation from them.
  • lots of other reasons

Why start now, and why post this in Vac?

There is a tremendous amount of exploratory research to be done on this topic, and it is quite interdisciplinary. Logos will be employing researchers in areas that are more amenable to execution environments, but we lack zero-knowledge acumen. Vac has already laid out a roadmap to improve the capabilities you already have in this field so it stands to reason we work together on this. We’re both dedicated to providing as much privacy as possible, as low as possible, in the technology stack.

This thread is a start to us having a conversation on what that research and hiring roadmap looks like. While we don’t have all the appropriate questions to ask on how to do this yet, we can work together to find the right people to bring on that can not only ask those questions, but work to answer them, and then subsequently build the solutions.

So, here are some questions I already have, please add your own:

  • What are the primary skills someone should have that could lead such an endeavor?
  • Where tf do we find such a person?
  • What research can we learn from that has significant overlap? (both zkEVM approaches, eWASM, etc)
  • What is the minimum set of OPCODES we should be targeting for an execution environment, and how easy is such a thing updated?

Happy discussing.

What is the minimum set of OPCODES we should be targeting for an execution environment, and how easy is such a thing updated?

One could start keeping track of what OPCODES work on what implementation with a model (really a database of facts) of some kind. I started a general purpose N3 model of EVM OPCODES that while woefully incomplete at least gives the OPCODES a trivial naming scheme, so could be easily annotated with more current data. This work was done before the various zkEVM proposals, so would need to be updated for sure. And “General purpose” means that it doesn’t currently do anything interesting except start gathering facts.

Have a writeup on this here: zkWASM - CodiMD