Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client side proving implies no_std #431

Open
tdelabro opened this issue Mar 4, 2024 · 7 comments
Open

Client side proving implies no_std #431

tdelabro opened this issue Mar 4, 2024 · 7 comments

Comments

@tdelabro
Copy link

tdelabro commented Mar 4, 2024

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
Copy link
Contributor

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

@tdelabro
Copy link
Author

tdelabro commented Mar 6, 2024

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
Copy link
Contributor

weikengchen commented Mar 19, 2024

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
Copy link
Author

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
Copy link
Contributor

^ 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
Copy link
Contributor

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants