Proof chunk pr #3
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nk (privacy-scaling-explorations#1641) ### Description [_PR description_] ### Issue Link privacy-scaling-explorations#1601 ### Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [x] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update ### Highlights - separate rw_table in evm_circuit/state_circuit and each have its own permutationchip. fingerprints checking will be deferred to root circuit. - disable rwtable first row check (by disable selector offset=0 in state_circuit, other offset toggle on as usual), since it will be copy constraints via public input. - keep `Rw::Start` and introduce `Rw::Padding` to support post-padding in address-sorted rwtable in last_chunk. - instance (new public input) column are design into two, one for prev_chunk context, another for current_chunk context to be used for next chunk. So in root circuit commitment of instance column can be used in snark-verifier without need to unwrap it. > Update on 18 Oct 2023: beginchunk/endchunk virtual step, inner_rw_counter, chunkctx - add Begin/EndChunk virtual step. BeginChunk is not mandatory in first chunk first step. while EndChunk is not mandatory in last chunk last step. - add `inner_rw_counter` which is local rw_counter within each chunk. This is used to count valid rw_row and assure Rw::Padding are append consecutively in `end_block.rs` logic => EndChunk should apply similar check later on - introduce chunkctx->{chunk_index, total_chunks} to tell first chunk (chunk_index==0) and last chunk (chunk_index + 1 == total_chunks) during witness generation/constraints assignment - add chunkctx_table to able to lookup chunk context (chunk_index, next_chunk_index, total_chunk, initial_rwc, end_rwc..etc) in exec step to allow various conditional check based on current chunk context ### How Has This Been Tested? [_explanation_] ### More context on Rw::Padding (Not cover in current PR, will be handled in later multiple chunk PR to make scope smaller) In new logic, `Rw::Start` will be insert in first chunk offset 0, while other holes are filled by `Rw::Padding` in last chunk(s). The address-sorted rwtable layout will be ``` address-sorted rwtable ## first chunk [ Rw::start, // offset 0, Rw::Start is only in first chunk, and only in offset 0, constrainted by public input ....(normal Rw), ...(Rw::Padding), // padding if there are only one chunk ] ## end chunk (if there are > 1 chunk) [ ....(normal Rw), // offset 0 are carry over from previous chunk, other are address sorted ...(Rw::Padding) // padding in end chunk ] ``` For chronologically rwtable, since there is no in-row constraints to check each Rw operation, so theoretically Rw::Padding rows can be filled in any offset. However, we also need to assure there is no malicious insertion other than Rw::Padding. To do that, we will rewrite this logic in later PR https://github.com/privacy-scaling-explorations/zkevm-circuits/blob/main/zkevm-circuits/src/evm_circuit/execution/end_block.rs#L86-L90 to lookup consecutive `Rw::Padding` at **chronologically** sorted table, at the END of EACH chunk. > A tricks: first Rw::Padding rw_counter need to be set as last (globally) valid row rw_counter + 1. This is to make sure in both chronologically rw_table or address-sorted rw_table it's always append in the end of rw_table. ``` chronologically rwtable, ascending sorted by `rw_counter`. ## first chunk [ Rw::start, // offset 0, Rw::Start is only in first chunk, constrainted by public input ...(normal Rw), ...(Rw::Padding), // first Rw::Padding rw_counter need to be set as last (globally) valid row rw_counter + 1, last means from last !!chunk!!. It assures Rw::Padding always append at the end of each chunk ] ## end chunk (if there are > 1 chunk) [ ....(normal Rw), // offset 0 are carry over from previous chunk, other are rw_counter sorted ...(Rw::Padding) // padding, also rw_counter sorted ] ```
…cy-scaling-explorations#1674) ### Description Depends on privacy-scaling-explorations#1641 with extra commit: adding fingerprint equality check on chronological/by address rw_table Fingerprint check gate will be enable in last chunk last row ### instance columns, top down order match instance array order chunk ctx - [current chunk index, total chunk, initial rwc] // equal with chunk_{i-1} - [next chunk index, total chunk, next rwc] equal with chunk_{i+1} pi circuit - [pi digest lo, pi digest hi] // same across all chunks state circuit - [prev permutation fingerprint] // equal with chunk_{i-1} - [next permutation fingerprint] // equal with chunk_{i+1} - [alpha, gamma] // same across all chunks evm circuit - [prev permutation fingerprint] // equal with chunk_{i-1} - [next permutation fingerprint] // equal with chunk_{i+1} - [alpha, gamma] // same across all chunks ### Type of change - [ ] Bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update
new from block with chunk cecilia-wip
… into proof-chunk-pr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
[PR description]
Issue Link
[link issue here]
Type of change
Contents
Rationale
[design decisions and extended information]
How Has This Been Tested?
[explanation]
How to fill a PR description
Please give a concise description of your PR.
The target readers could be future developers, reviewers, and auditors. By reading your description, they should easily understand the changes proposed in this pull request.
MUST: Reference the issue to resolve
Single responsability
Is RECOMMENDED to create single responsibility commits, but not mandatory.
Anyway, you MUST enumerate the changes in a unitary way, e.g.
Design choices
RECOMMENDED to: