Feat/smt txn traces #206
Closed
Feat/smt txn traces #206
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
- Created type aliases for all `evm_arithmetization` types that we need to swap out depending on whether or not we are compiling for `mpt` or `smt`.
- Realized that there is no clean way to disable a default feature when it absolutely needs to be disabled (eg. when "smt" is enabled). - Also added a compile time check to enforce that one of these features is enabled.
- Prep for `mpt`/`smt` logic feature gating.
- Realized that we can link again both versions of the library at once without conditional compilation.
- It's going to make a lot of sense I think to split the logic that generates `mpt` & `smt` tries. This commit just renames a file and creates the module for smt tries.
- Because we're going to be dealing with feature flags for SMT stuff, it's going to be very worth while I think splitting the logic into seperate modules. - This commit does just that.
- We need to access this normally with a feature gate, but just to rush getting something going, we're going to copy it in for now.
- Waiting for Will's impl upstream first.
- Also moved them to `common`.
- Previously was using `Nibbles` for constructing the current key during traversal (this was wrong).
github-actions
bot
added
crate: evm_arithmetization
Closed
github-actions
bot
added
the
crate: proof_gen
github-actions
bot
added
crate: mpt_trie
- Required because we can only run the tests when the appropiate testing flag is enabled.
- A lot of the logic is pretty isloated, so I thought that this made more sense.
BGluth
force-pushed
the
feat/smt_txn_traces
branch
from
5356183 to
aa5dd4c
Compare
|
I think with @0xaatif taking this on, we can close my 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.
(WIP) Major refactor to trace decoder in order to add support for SMT & continuations.
Overview
While the original scope of this PR has changed overtime, the original plan was the following:
evm_arithmetization(one for mpt, another (branchfeat/type2) for smt).However, two design aspects have changed since this PR was started:
Implementation details
Module Splitting
Because initially the plan was to rely on feature gating to handle mpt & smt logic, the decision was made to separate logic for these areas into their own modules, as it's much cleaner to conditionally compile a module rather than individual types and functions. These modules use types/functions that are identical in name but differ in implementation between mpt & smt (eg.
GenerationInputs). A clean way to handle this is to use type aliases that change based on a feature flag (eg.GenerationInputspoints to the mpt or smt version depending on flags).Trace Processing Abstraction
As mentioned above, because the majority of the trace parsing logic is shared between mpt & smt trace processing, if we can abstract away the parts that differ, then we can achieve very high code re-usability. In the end, the trace pre-processing stage is nearly 100% identical, but the decoding stage, while still pretty similar, differs in a few more places. As an example, if a trace states that a storage slot is set with a new value, the only core difference is the logic that runs to update the internal trie state.
To handle this abstraction, the preprocessing & decoding stages both are parameterized with empty types that implement two corresponding traits. These traits define the types & methods that differ between the implementations.