Client side proving implies no_std

[tdelabro]

If we want users to be able to use stwo in the browser for client-side proving, we need to be able to target wasm, and therefore to compile in no_std.

In my opinion, it is a must-have that will unlock a lot of applications and my experience is that the earlier the project embraces no_std, the easier it is for everyone later on.

What is your plan regarding this?

[spapinistarkware]

This is not a priority for us right now, but if you have a good PR doing it, I'll check it

[tdelabro]

It was kinda my point: it's not a priority at the beginning, but the more you wait to implement it the more difficult and tedious it becomes.

[weikengchen]

My opinion is that it is useful to do no_std in a batch, so it is okay to wait. In the past, the major challenge with no_std is that some dependencies may fail to be no_std even if they claimed to be no_std and cause issues. Other than that, standard vec![], core::, println!... are one go.

[tdelabro]

The problem is that switching to no_std will imply some breaking changes, which is better to have when nobody is using the project, than when 10 different companies are using the lib in production.
The less sedimented the codebase is when doing it, the easier it will be.

Moving cairo-vm, cairo, blockifier and starknet-api to no_std took me months and it is still not merged entirely at this time, more than one year after I started pushing it. That's because it is not a priority for any of the team working on it (coz they now have code in production and prefer stability over anything), and now implies huge breaking changes (coz the codebase solidified in a way that is not compatible with no_std), that should be coordinated between multiple repositories that are all interdependent.

I'm talking from my own experience of doing this work across the whole Starknet rust crates ecosystem: it's an endless pit of despair.

So if we all agree that we want to be able to use STOW in the browser at some point in the future, which sounds like a reasonable usecase, the switch to no_std should be done as soon as possible.

[weikengchen]

^ I have the feeling that the key is also to narrow down to only the component that would be needed for the WASM prover. Do you think full no_std support for all the crates, including those for APIs or the compilers, would be necessary?

[weikengchen]

Because technically the crypto part shouldn't really require std features a lot, but when things involve filesystems databases and so on, and when FFI is involved, then it becomes almost impossible.

[tdelabro]

You are very correct: not everything needs to be executable in the browser. That is why it is important to start delimiting early the part that needs to be no_std so that we don't inadvertently mix those with some filesystem/ffi/... logic, as we carelessly build the lib.

That is what happened in most of the crates I had to convert to no_std, and it was a terrible experience to do this separation afterward when it was not thought from the beginning.