# A Paradigm shift in smart contracts

These idea presented to me from my conversations with Tracy over at Pluto. Great team working on some really cool applications of zkVMs. I am not going to claim these are completely novel ideas, but I really wanted to lay out the potential future ahead of us with zkVMs.

## The EVM is a constrained environment to write software

The EVM is showing its age.

- A key example here is that the curve used for Ethereum PoS consensus, BLS12-381, cannot be used efficiently in the EVM. This curve requires working with 381 bit integers, and the EVM does not have a efficient way to represent such a number.
- You don’t have access to the normal libraries for non-web3 stuff like HTML/JSON/Protobuf parsing, DKIM/JWT etc.
- Each operation has a cost, and so financial activity like DEX trading is selected for over other applications we want to see built.
- All deployed smart contracts require audits, and there is added cost to any direct execution solidity implementation to have it reviewed. I can’t just write HTML parsing willy nilly.

The point I am trying to make is that all these issues can be side stepped without changing the EVM, all which robust zkVMs.

## Why solidity is a good choice for a zkVM

It’s pretty clear why. That’s the language smart contracts are written in, and so it’ll be easy to interact with the EVM state. You can write a script that simply interacts with another contract’s surface.

My argument is solidity is only the best choice when working with the history of the EVM state. This is one of the things Pluto is trying to achieve, among other things. When it comes to making updates to state, using solidity inherits all of the same constraints as the EVM into your zkVM.

## The idea

So a zkVM can be written for any set of op codes. WASM, RISC-V, x86 etc. Some choices are better than others, and it’s context specific.

The EVM is a Turing complete system, and so it can run any other Turing complete system. A brave engineer could implement WASM execution with EVM op codes. Doing this on-chain is a terrible idea for obvious reasons, and is probably why this doesn’t exist.

Imagine that this was implemented. I can write the surface of the contract in solidity. For every function I can execute the hard parts in WASM (originally rust, for example) and get the state updates. From the output I can make the necessary changes to the EVM state.

Now imagine that we have a zkVM implemented for WASM. I can compute a ZKP of some output outside of the EVM, and then provide the proof to the smart contract. The contract checks the output matches the WASM code it trusts, and makes the necessary state updates.

Furthermore, you could implement a library that acts as a bridge between the EVM and WASM, so WASM can interact with the EVM state directly. At the typescript/rust level you can even mimic RPC calls like eth_call, or eth_getStorageAt. You can wrap low level calls into higher level APIs like interacting with an ERC20/721 contract. Any state updates within the WASM VM can be bubbled up to the EVM layer to mutate the state.

## Why its a paradigm shift

With this idea the full landscape libraries is opened up for smart contract development. Take the zkEmail example, I can write well tested rust code for verifying email signatures, as well as parsing it for the relevant data. All without having to touch much solidity.

Beyond opening up different languages for smart contract development, it fundamentally changes the relationship b/w the EVM state and execution layer. The contract reduces to the data availability layer, while the actual execution is done off-chain. Basically building Celestia but from the opposite direction.

To minimize gas costs, txs can be batched off-chain in a recursive manner and then brought to update the state with the cost being amortized. This batching can actually be done over many different contracts, creating a separate mempool for zkVM txs. Account abstraction paymasters and bundlers can be extended to facilitate this.

## This isn’t an L2

Just to clear up any possible confusion, this is not an L2. This can be implemented with a L1 contract with the full state being stored on the L1. Or an L2 for that matter. Since L1 state updates have a high cost, there is still a reason for L2s.