scroll-tech / scroll-tech/ceno

Add comment about what's supposed to be not serialised

Open
#485 0 comments 0 reactions 1 assignee View on GitHub

@hero78119 is already working on this.

Since Oct 28, 2024.

Dominant language
Rust
Stars
153
Forks
43
Avg merge
3d 13h
Merged PRs (30d)
4

Description

In almost all the case, unifying source of truth and less error prune make much sense!
But in this case I will say not.

We expect ConstraintSystem
https://github.com/scroll-tech/ceno/blob/79bb73bb89c7a1f503b0838711acaa4d7e7679f2/ceno_zkvm/src/circuit_builder.rs#L82
to be serialized into proving/verifying key. So, we expect some fields scope should be move to cfg[test] or just under some feature flag toggle on
All the "xxxxx_map" fields is one of the example. Those debug info are

  1. from prover perspective, only push those name strings in non-release build. Those variable debug name shouldn't be in release build nor in binary.
  2. from verifier perspective, neither debug nor release need this information, so they should have them "serde skip".

With above 2 points, I will say this PR change is unnessesary, because source of truth shouldn't reverse release info to depends on debug info

@hero78119 Could you please add that reasoning as a comment in the code? And perhaps make it so that witin_namespace_map actually only show up in debug mode? (Or otherwise leave a TODO-comment to that effect?)

Btw, I don't think we should spend effort removing variable names from a release build. It's better to leave them around for debugging, because things can go wrong with the release build, too.

(That's all assuming that constructing the circuit is far from the most expensive thing we are doing. I expect (recursive) proving to take the majority of the runtime.)

Originally posted by @matthiasgoergens in https://github.com/scroll-tech/ceno/issues/465#issuecomment-2441251845

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.