scroll-tech / scroll-tech/ceno
Make hint padding 'inaccessible'
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 153
- Forks
- 43
- Avg merge
- 3d 13h
- Merged PRs (30d)
- 4
Description
In our VM we have reserved a specific memory region that the prover/host can map private hint data into.
The size of that region is an upper limit, but most of the time we have less data. In that case here's what we are currently doing:
- We map the provided data, so that its start aligns with the start of the memory region.
- In the emulator, we fill the rest of the entire hint memory region with zeroes.
- In the prover/circuits, we pad the end of the given data with zeroes to hit the next power of two in size, then we fill the rest of the hint memory region with 'inaccessible'.
(To be clear, most of that 'filling' happens lazily behind the scenes, ie memory reads act as-if we filled the memory as described.)
'Inaccessible' means that trying to access the memory in question leads to a program abort / failure to prove.
I suggest we unify that behaviour, amongst other things, to make guest development easier: if it runs, it should prove.
For technical reasons, our circuits will always fill the vast majority of the unused hint memory with 'inaccessible'. Thus the simplest unification is:
- Fill the entire rest of the memory region with 'inaccessible'
That means treat both prover and emulator the same, and also don't worry our users about padding to a power of two. That's a much simpler interface.
(As far as I can tell, for technical reasons we have to pad to the next power of two internally in the circuits, but we can pad that with 'inaccessible', instead of padding with 0.)
Original thread at https://github.com/scroll-tech/ceno/pull/622/files#r1855846990
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the emulator and prover/circuits handling of the reserved hint memory region, then review the discussion in issue 628, issue 630, and PR 622. Trace how unused hint space is filled and how power-of-two padding is handled. Done means both emulator and prover treat the remaining region as inaccessible rather than zero-filled, while preserving the circuits' internal padding requirements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, cryptography
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100