Do we want/need to support the "no std" environment in SabVM?

[IaroslavMazur]

revm, on top of which we're building SabVM, supports both the the "std" and "no std" Rust environments.

While it's clearly a worthy endeavor for a project like revm to also support the "stripped", "no std" environment (mostly targeting the eventual execution of revm in embedded systems, from what I could understand), it doesn't feel like it'd be worth it in our case. Unless I'm mistaken, SabVM is not intended to be run in an embedded environment, nor built on top of by some projects that also want to support "no std".

The clear downside of supporting the "no std" workflow is that we can only use the already-implemented tools from the Rust Standard Library in the "optional" SabVM features built specifically for the std-enabled configuration - and not throughout the whole codebase.
For example, I've found the HashSet from std to be very suitable for checking the uniqueness of the Native Asset ids passed in the tx - and the use of HashSet is currently failing the cargo check no_std step of the Tests (Stable) job.

The downside of the alternative (not supporting the "no std" configuration) is that SabVM won't be able to run in a "no std" environment, such as an embedded system or some other Rust crates that work in both "std" and "no std" modes.

Am I wrong and do we, in fact, need/want to support "no std"?

PS: if "no std" turns out to be a thing we'll decide is worth supporting, we should be able to move SabVM from "std only" to "both std and no-std" in the future (by manually re-implementing the std tools we use).

@sablier-labs/everybody, curious about your takes on this subject

[PaulRBerg]

We need to support no-std because of ZK proofing reasons. ZK VMs such as Risc0 depend on no-std. See:

• https://github.com/risc0/risc0
• https://github.com/risc0/bonsai-foundry-template
• https://youtu.be/ZFVjooWdXVE?si=vh8lTenDhad8P-E6

Unless I'm mistaken, SabVM is not intended to be run in an embedded environment, nor built on top of by some projects that also want to support "no std".

Can confirm that we don't plan on supporting embedded environments (e.g. Raspberry Pi).

we should be able to move SabVM from "std only" to "both std and no-std" in the future (by manually re-implementing the std tools we use).

Sounds good.

@sablier-labs/everybody, curious about your takes on this subject

As discussed here, we should only tag you, me, and @razgraf in the foreseeable future.

[IaroslavMazur]

We need to support no-std because of ZK proofing reasons. ZK VMs such as Risc0 depend on no-std. See:

• https://github.com/risc0/risc0
• https://github.com/risc0/bonsai-foundry-template
• https://youtu.be/ZFVjooWdXVE?si=vh8lTenDhad8P-E6

Not sure (yet) how we'll include the ZK proofing into SabVM, but if it's correct to talk about it (ZK proofing) as a "dependency" of SabVM, then, I don't see why it'd be problematic to connect the 2, without the latter also supporting the no-std environment. 🤔

If ZK proofing can function in both the std and no-std environments (and if it supports the latter, it, by definition, also supports the former), then, it's compatible with SabVM that only supports std.

The only problematic situation would be the one that involves ZK proofing "consuming"/"depending on" SabVM. However, even in this case, we could just make the final solution only support std, in order not to have to support no-std down in SabVM.

Am I mistaken?

Can confirm that we don't plan on supporting embedded environments (e.g. Raspberry Pi).

Thanks for the confirmation!

As discussed here, we should only tag you, me, and @razgraf in the foreseeable future.

Note taken.

[PaulRBerg]

if it's correct to talk about it (ZK proofing) as a "dependency" of SabVM
...
The only problematic situation would be the one that involves ZK proofing "consuming"/"depending on" SabVM

That's not an accurate description. ZK proving is not about the VM itself - it's an emergent property required by the rollup design.

So, I would put it like this: "We want to deploy Sablier as a rollup. That requires the SabvVM to be ZK-provable. Thus, we need to implement the VM in such a way that it can be ZK-proved".

If ZK proofing can function in both the std and no-std environments (and if it supports the latter, it, by definition, also supports the former)

It is not true that if something supports the latter (no-std), it also supports the former (std).

It would be helpful if you had a quick look at the Risc0/ zkVM documentation.

[IaroslavMazur]

It is not true that if something supports the latter (no-std), it also supports the former (std).

What I meant to say is that, in general (not risc0 specifically), if ZK proofing can work in the no-std environment, it should also work in the std one (which is a superset of no-std). If no-std is enough for ZK proofing, then, the std that SabVM comes with would be more than enough, too.

Wouldn't this make sense?

---

re: risc0

I've gone through the whole RISC Zero @ ZK HACK III workshop, as well as the What does RISC V have to do with RISC Zero's zkVM presentation, the risc0 documentation and several articles on the lower-level stuff (such as RISC-V and ZKP).

As a result, I've concluded the following:

• risc0 has got a custom implementation of an abstract concept of a "zkVM", and their implementation allows you to generate proofs that a certain sequence of RISC-V instructions (i.e. any language that can be compiled for this target) has been correctly executed - and has produced a certain output.
  At the same time, it's not necessary to also share the details such as the inputs submitted to the function/"method" running the respective code - or the intermediary steps of the execution.
• Bonsai is a tool to which we can delegate the proof generation (which is a computationally-intensive task) if we don't want/cannot do this locally.
• Having said that, it's still unclear to me whether we'd like to use risc0 specifically and, if yes - how exactly we'd like to use it. 🤔
  I've spent some time reading their documentation, but before diving deeper into it, I'd like to confirm we're, actually, going to use/seriously consider using them.
• The std support was (in December of 2022 when the videos have been released) experimental, but was not discouraged (see this time reference)
  • one bug (related to the String data type) is specifically mentioned, but with a workaround present.

I suggest we get in contact with the risc0 team - and question them about the current support for std. Enough time has passed since that workshop was released - and, maybe, they've fixed the std-related problems. If you agree, I'll look for a way to approach them.

[PaulRBerg]

f no-std is enough for ZK proofing, then, the std that SabVM comes with would be more than enough, too.

Wouldn't this make sense?

That's not how ZK tech works. ZK requires a lightweight environment.

That std is a superset of no-std is irrelevant.

---

I've gone through the whole RISC Zero @ ZK HACK III workshop, as well as the .. presentation

Awesome

Bonsai is a tool to which we can delegate the proof generation

IIRC, Bonsai works with pure EVM only. It wouldn't work for SabVM.

it's still unclear to me whether we'd like to use risc0 specifically and, if yes - how exactly we'd like to use it.

You would need it for generating proofs that get verified in the L1 smart contract that handles the native bridge between the L1 and the SabVM-powered rollup.

I suggest we get in contact with the risc0 team

Let's do it - you can ask questions here:

https://github.com/risc0/risc0/discussions

[IaroslavMazur]

ZK requires a lightweight environment.

That std is a superset of no-std is irrelevant.

If ZK "requires" no-std, then, I don't understand how risc0 could support std, at all (be it experimental or not) 🤷‍♂️

IIRC, Bonsai works with pure EVM only. It wouldn't work for SabVM.

Created the following discussion to, hopefully, clarify both of the topics above: risc0 std support and making Bonsai work with other VMs (not just EVM) #1412

---

You would need it for generating proofs that get verified in the L1 smart contract that handles the native bridge between the L1 and the SabVM-powered rollup.
🙌

[PaulRBerg]

Created the following discussion to, hopefully, clarify both of the topics above

Beautiful, thanks

[IaroslavMazur]

While it still remains to be seen whether we have to go the no-std way (I have open discussions re this on GitHub and Discord), we have received a confirmation that Bonsai is a general-purpose tool and is not limited to EVM.

[PaulRBerg]

Awesome

[PaulRBerg]

Potentially relevant:

https://twitter.com/gakonst/status/1757834025065197733

[IaroslavMazur]

Here what a Risc 0 team member told me about our std/no-std question:

To me, "no known bugs" sounds like a green light for not limiting ourselves to just the no-std environment. Especially given the fact that by the time we get to actually be implementing ZK for SabVM, the std support of Risc 0 will, likely, be considered even safer than right now.

The fact that they've even built a ZK prototype on top of revm inspires even more hope into me.

@PaulRBerg, if you agree, then, we should, probably, edit the SabVM GitHub jobs, removing the parts that require the repository to also support the no-std environment.

[PaulRBerg]

I will defer to your judgement.

[IaroslavMazur]

Created an issue to update the SabVM GitHub jobs and assigned it to myself: #71.

Closing this discussion in favor of the new issue.