`thiserror` doesn't allow `risc0_zkp` to compile with `no_std`

[SkymanOne]

`thiserror` doesn't allow `risc0_zkp` to compile with `no_std`

[flaub]

I was under the impression that wasm targets do support std, is that not possible here?

We haven't had any explicit requirement yet that risc0-zkp or risc0-zkvm works under no_std, so this is a good data point that we can use to adjust our assumptions. It should be really easy to make verify run in no_std but the prover would be much harder.

[SkymanOne]

I know that this was not the original design. ink! smart contracts are compiled in no_std environment and target wasm32-unknown-unknown.

I have come across several problems while trying to verify the proof on-chain:

• thiserror dependency on std which was mentioned earlier
• Since 0.16 the risc0-zkvm causes the contract to compile with floating-point operations that are not supported and discouraged to be used on-chain.
• Dowgrading to 0.15.3 solved the issue above, and allowed to deploy the contract on-chain. However, it failed to deserialise the slice into SessionReceipt using from_slice() (example) causing the function and the contract to panic (even though the function is expected return Result). I could not investigate the cause of this, but the same code worked in std environment

I am very excited about this project and would love to see some support for ink! smart contracts. What I would ideally like to see is a no_std lightweight crate for verifications of proofs with some functionality (or extension) allowing deserialisation.

[flaub]

Since 0.16 the risc0-zkvm causes the contract to compile with floating-point operations that are not supported and discouraged to be used on-chain.

I don't know of any reason floating-point would be used or related to version 0.16. Maybe there's some new dependency that makes this happen. Could you provide more context on how this is manifesting?