[Feature Request] Using Move in a Layer 2 setup

[runtian-zhou]

🚀 Feature Request

Motivation

Scalability of blockchain system has always been a huge concern for the community. As a result, blockchain systems usually relies on a so-called layer 2 sctructure to offload some computation to a less decentralized system in order to get greater throughput. A question then arise, if Move and MoveVM can provide any unique value to the Layer 2 scaling solution? Specifically, how we might put Move ecosystem in the famous 2x2 matrix in the Layer 2 scaling.

Pitch

There are following questions we would like to understand about Move:

1. How easy would it be to construct a zero-knowledge based solution for Move, either via:
   a. Using existing zk based VM such as MidenVM to execute Move contracts, now that the Move team is working on a cross compiler from Move to Yul
   b. Build a VM plugin for MoveVM to support generating traces of MoveVM execution to generate zero knowledge proof of execution correctness?

Moreover, is current zk proof generation process efficient enough for executing Move codes? Can we bring Move to a Validium based roll up solution?

2. Will the unique account structure of Move bring any unique value to the Plasma framework based solution??

Plasma based protocols are known to be more friendly to a UTXO based scheme as UTXO is naturally easier to prevent double spending on the child network. Moreover, generic smart contracts execution are usually considered not feasiable on Plasma. It would be nice if we have deeper understanding of this issue. Specifically, is it because of the limitation of EVM's state model or it's more of a generic issue that's going to plague the scale-up of Move based ecosystem as well.

Related work

StarCoin has started their optimisitc rollup proposal for a Move ecosystem.

There's also a zk based solution for Move that's been developed here.

[runtian-zhou]

On question 2, what intrigues me is the following statement I found in the discussion:

The Plasma framework effectively relies on something I call “state objects.” Each of these objects are pieces of state that can only be modified under certain conditions.

Was wondering if the unique resource model of Move can bring any unqiue value to this known issue.

[sblackshear]

A couple of thoughts on rollups for Move:

• Optimistic: my inclination would be to look into Arbitrum Nitro, which alleges to provide fraud proofs for arbitrary WASM code. Engineering an optimisitic rollup is very challenging, whereas compilation from Move bytecode to WASM is probably not so bad, and might be useful elsewhere. In particular: designing fraud proofs for the verifier seems very difficult, but if you compile the verifier to WASM this problem goes away.
• ZK: I know @bobbinth is thinking about supporting Move while designing Miden--definitely something to keep up-to-date on

Moreover, is current zk proof generation process efficient enough for executing Move codes?

Probably not, but it's also incredibly slow for producing execution proofs for existing transaction types or other langs, which is something that the ZK zealots are not always very transparent about...

[sblackshear]

Will the unique account structure of Move bring any unique value to the Plasma framework based solution??

I think it's possible. However, I think Plasma-based designs have fallen out of favor due to more fundamental design problems that Move (or more generally, Plasma with a non-EVM language) can't address. Understanding these problems requires going pretty far into the weeds, but this podcast has an approachable explanation of some of them.

[bobbinth]

Yes, I'd love to support Move on Miden VM - so, would be very interested in understanding what would be needed from Miden VM side for this. A few notes:

• We are currently working on the v0.2 release of Miden VM (in the next branch). This will support everything described in the latest Miden assembly specs. One notable thing that is absent from the v0.2 release is storage, which is slated for v0.3 release.
• There is a project for transpiling Yul to Miden assembly called Scribe. If there is work being done on compiling Move into Yul, then it might be possible to do: Move → Yul → Miden assembly. Although, direct compilation Move -> Miden assembly would probably be a better approach.
• In terms of performance, Miden VM currently runs at 10K cycles/sec on a single CPU core (this includes ZK proof generation time). This scales pretty well with additional CPUs. For example, on 16 cores it can run at about 100K cycles/sec, and we are working on further improvements to make it faster.

[sblackshear]

CC @wrwg on the Move -> Yul -> Miden path

[wrwg]

Yes, the Move-to-Yul path is expected to be ready (basically) in Q1.

[jolestar]

Optimistic: my inclination would be to look into Arbitrum Nitro, which alleges to provide fraud proofs for arbitrary WASM code. Engineering an optimisitic rollup is very challenging, whereas compilation from Move bytecode to WASM is probably not so bad, and might be useful elsewhere. In particular: designing fraud proofs for the verifier seems very difficult, but if you compile the verifier to WASM this problem goes away.

Is it possible to support dispute_resolution in MoveVM, like it in AVM?