Parallel custom VM instead of changing the EVM

[PaulRBerg]

So far we have only explored the "change the EVM" approach for enabling MNTs and streaming operations. But what if we can skirt around this approach by having the SabVM run in parallel to the raw EVM?

My source of inspiration is Stylus:

Note that this is just a random idea I had now, and I haven't put much thought into it. I don't know if two VMs can be run in parallel when only one of them implements MNTs and streaming ops (some invariants may be broken).

[IaroslavMazur]

I don't know if two VMs can be run in parallel when only one them implements MNTs and streaming ops (some invariants may be broken)

In other words, we'd need to address this question first for any other discussion regarding the matter to make sense. 🤔

[PaulRBerg]

Yep. The SabVM is still very much at the R&D stage.

[razgraf]

I'm skimming the docs and what stands out to me is:

Solidity programs and WASM programs are completely composable. If working in Solidity, a developer can call a Rust program or rely on another dependency in a different language. If working in Rust, all Solidity functionalities are accessible out of the box.

Does this relate to our questions around precompiles #86? Does implementing streaming in the WASM offers us functionality more or less similar to those "facade contracts" contemplated in that discussion? It looks like you can also export Solidity ABIs form those WASM contracts.

Memory can be 100-500x cheaper when using Stylus, unlocking new use cases now that consuming RAM is viable on the blockchain.

Stream termini computation and graph-optimization is heavy duty, if their stuff is as optimized as they say this could be.. huge.

---

On one hand, a concern with this (even if it offers the same functionality we can achieve with precompiles) is second order effects caused by too many dependencies. We're already pretty clear on the fact that we have to alter the EVM given the need for special storage space (for the stream termini) so wouldn't this just add too much complexity to our system for the first versions?

On the other hand, using out of the box tooling (things like OP-stack or ARB-Stylus) means we're somehow using stuff more tailored to custom functionality - so easier to adapt new features instead of building them directly over the EVM?

[PaulRBerg]

Does this relate to our questions around precompiles #86?

Not really. We could decide to offer the precompile interface in a Rust/ WASM interface, but that would be an arbitrary feature. It wouldn't directly help us.

Our precompiles will be written in the client itself.

Stream termini computation and graph-optimization is heavy duty

Those computations are already performed in the client itself (in Rust). WASM is for smart contracts.

so wouldn't this just add too much complexity to our system for the first versions?

IDK. I would say that we would try to do too many things at the same thing. Too much experimentation can be detrimental.

[IaroslavMazur]

Be it in the same or parallel VM, the MNTs & Streaming logic would be tightly connected to the standard EVM opcodes, state, etc. And given that this logic would have to be run on the very same machines as the EVM logic (being a part of the same Rollup client), I don't understand how we could do things more efficiently/save up on the required resources.

---

At the first glance, a parallel VM sounds like an appropriate solution for some completely independent logic which you'd like to be executed in a fundamentally different way than that of the EVM opcodes (e.g. execute several opcodes at once, allow opcodes with the arguments having some default values, etc.). I believe our case doesn't fit this description.

---

I second @PaulRBerg on treading it safely with the amount of experimentation we are willing to accept. A parallel VM sounds like an unreasonably-high added complexity w/o some justified advantages of doing so.

[razgraf]

Agree! Should we close this discussion?