Witness: Implement optimisation where touched code can be skipped#4099
Draft
kdeme wants to merge 1 commit into
Draft
Witness: Implement optimisation where touched code can be skipped#4099kdeme wants to merge 1 commit into
kdeme wants to merge 1 commit into
Conversation
Implementation of optimisation where touched code can be skipped from the witness if that same code was deployed in an earlier transaction in the same block. In this scenario the witness can be smaller as that code is technically not required for the stateless execution, as it is already available via the transaction in the block, and thus in stateless execution will already be there after executing the earlier transaction. Not fully sure however if this added complexity is worth the optimisation. As in, I have no view on how often a case like that occurs, and maybe more edge cases exist, but it is however a scenario tested in EEST zkevm tests. We could of course decide not to implement this, as the bigger witness will also work as input in practice.
Member
✔️ nimbus-hive/PRs/PR-4099#1 🔹 ~24 min 🔹 f17eba6 🔹 📦 null package |
Member
✔️ nimbus-eth1/prs/linux/x86_64/hive/PR-4099#1 🔹 ~24 min 🔹 f17eba6 🔹 📦 null package |
This file contains hidden or 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
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.
Implementation of optimisation where touched code can be skipped from the witness if that same code was deployed in an earlier transaction in the same block.
In this scenario the witness can be smaller as that code is technically not required for the stateless execution, as it is already available via the transaction in the block, and thus in stateless execution will already be there after executing the earlier transaction.
Not fully sure however if this added complexity is worth the optimisation. As in, I have no view on how often a case like that occurs, and maybe more edge cases exist, but it is however a scenario tested in EEST zkevm tests.
We could of course decide not to implement this, as the bigger witness will also work as input in practice.
More details:
The test that currently fails on this is
tests/fixtures/eest_zkevm/blockchain_tests/for_amsterdam/amsterdam/eip8025_optional_proofs/witness_bytecodes_contract_creation/witness_codes_create_same_hash_then_read.jsoncode
0x00can be optimised away there.As stated in description of the test case:
"description": "Tx1 deploys a contract, tx2 calls a pre-state contract with same code.\n\nThe pre-state contract's bytecode must not appear in\nexecutionWitness.codes because the same code hash was already\nwritten by tx1's CREATE. A stateless verifier observed\nthe bytecode from the CREATE transaction data, so including it\nin the witness is redundant.",The test vector contains this account pre-state
With code "0x00"
And with these transactions:
So:
You can see the same thing if you check BAL accesses in the test vector.
Now, regarding this solution in the PR:
I did not just add the code in the Witness keys as is done now, and then additionally filter out on the witness build as it is order dependent. If tx1 and tx2 are inverted, the code MUST be included.
There is a test case for this:
tests/fixtures/eest_zkevm/blockchain_tests/for_amsterdam/amsterdam/eip8025_optional_proofs/witness_bytecodes_contract_creation/witness_keeps_prestate_code_read_even_if_later_created_with_same_hash.jsonI did not apply the hashset directly on ledger either because it can still rollback (contract call reverted)
There is a test case for this too:
tests/fixtures/eest_zkevm/blockchain_tests/for_amsterdam/amsterdam/eip8025_optional_proofs/witness_bytecodes_contract_creation/witness_codes_reverted_create_same_hash_then_read.jsonHence the current suggested solution. Although not sure if we MUST do this, considering the extra complexity it might not be worth optimising for this edge (?) case?