This repository was archived by the owner on Jul 5, 2024. It is now read-only.
WIP: merge proof chunk #1751
Closed
WIP: merge proof chunk #1751
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
…-explorations#1693) ### Description covered item - [x] supercircuit simplify instance columns related to chunkctx to just one column - [x] first chunk instance: chunk continuity related fields should be constraints as constant. - [x] aggregate multiple super circuit proof chunk with chunk consistency check . - [x] compute permutation fingerprint challenges `alpha,gamma` from rw_table advices commitments and assert its equality - [x] generalized `challenge([column_indexs], challenge_column_index)` to a new protocol structure so more challenges in the future can be added. TODO - [ ] verify multiple chunk from bus_mapping => rely on privacy-scaling-explorations#1690 ### Issue Link privacy-scaling-explorations#1603 ### 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 ### Tests Light tests pass. integration test failed due to challenge computation in witness not implemented yet, which will be done in bus mapping chunk PR.
…cy-scaling-explorations#1690) ### Description Instantiate circuits with `Block` and specified `Chunk` from bus-mapping. Refactor `CircuitInputBuilder` to generate given number of `Chunk`s with fixed or dynamic params. Note that one instance of the circuit corresponds to one chunk instead of one block. <img width="606" alt="Screen Shot 2023-12-08 at 11 37 30 PM" src="https://github.com/privacy-scaling-explorations/zkevm-circuits/assets/45245961/84eac662-5adf-49d6-99bf-eefc295cf5aa"> ### Issue Link privacy-scaling-explorations#1696 ### 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 ### Contents - Initialize the `CircuitInputBuilder` with either `FixedCParam` or just specify the total number of chunk and dynamically derive parameter after a dry run. - In `handle_tx` split the chunk whenever the local `rwc` exceeds the target amount, specifically by setting the `EndChunk` and proceed to the next `BeginChunk` if needed. - Commit the `ChunkCtx` for each chunk at the end, which tracks the global `Rw` range & local `rwc` later used in the State circuits. - After the block is handled, generate witness for a specific chunk with `builder.chunk_convert(idx)`, analogous to `builder.block_convert()`. - Config the circuit with both block and chunk, which leads to API changes in `SubCircuit<F: Field>` trait including `new_from_block(&block, &chunk)` and `min_num_rows_block(&block, &chunk)`. ### Workflow For `CircuitInputBuilder` chunk is needed to build **all** circuits: ``` let builder = BlockData::new_from_geth_data(geth_data.clone()) .new_circuit_input_builder() .handle_block(ð_block, &geth_traces) .expect("handle_block"); let block = block_convert(&builder); let chunk = chunk_convert(&builder, 0); let circuit = SuperCircuit::new_from_block(&block, &chunk); ``` For `CircuitTestBuilder` **modifier** is applied to both block and chunk, and you can run with fixed or dynamic params: ``` CircuitTestBuilder::new_from_test_ctx( TestContext::<2, 1>::simple_ctx_with_bytecode(bytecode).unwrap(), ) .modifier(Box::new(move |block, chunk| { // do something.. })) .run_dynamic_chunk(4, 2); ``` ``` CircuitTestBuilder::new_from_block(block) .params(FixedCParams { total_chunks: 2, max_rws: 60, ..Default::default() }) .run_chunk(1); ``` Default `run()` still works since it runs one chunk internally. ``` CircuitTestBuilder::new_from_block(block).run() ``` --------- Co-authored-by: sm.wu <[email protected]>
github-actions
bot
added
crate-bus-mapping
|
Update source branch in PR #1785 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
No description provided.