Conversation
|
This is still partially in progress but the bulk of the work is done now. I want to rework tx assembly a bit to improve ergonomics and maybe clean up tests some more. |
bewakes
left a comment
There was a problem hiding this comment.
Skimmed through the changes.
|
|
||
| impl SnarkAccountUpdateTxPayload { | ||
| pub fn new(target: AccountId, update_container: SnarkAccountUpdateContainer) -> Self { | ||
| impl SauTxPayload { |
There was a problem hiding this comment.
SauTxPayload
This is not a good name. Let's not invent acronyms like this which are confusing and not widely known.
Can we drop Snark instead?
There was a problem hiding this comment.
Dropping "snark" from the name implies that it could be valid to update other types of accounts (like EE sequencer fee accounts) using this transaction type. I'm open to hearing other suggestions.
1ff1919 to
f7c4e5c
Compare
|
Commit: a11f1ca SP1 Execution Results
|
Codecov Report❌ Patch coverage is
@@ Coverage Diff @@
## main #1508 +/- ##
===========================================
- Coverage 84.34% 65.40% -18.95%
===========================================
Files 802 802
Lines 75697 76340 +643
===========================================
- Hits 63846 49927 -13919
- Misses 11851 26413 +14562
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 390 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Description
This PR is VERY INCOMPLETE.
This cleans up a bunch of issues that escaped notice with the tx types, especially meshing the chain types with the snark account update types. This more cleanly splits out the accumulator proofs that accompany update data into a separate structure as part of the full transaction, so that we can define a "txid" concept independently. There was a pretty significant issue where we separately describe the entry hash in an accumulator twice, once in the claim and once in the proof. This makes it easy for us to accidentally check one value but use a different one, when the value should simply not be provided twice.
Unfortunately this is quite more complicated than I anticipated, as it touches multiple crates and I haven't even gotten done finishing the main change itself yet!
Changes include:
MessageEntrytostrata-acct-typesRawMerkleProofin more placesstrata-ol-chain-types-newType of Change
Notes to Reviewers
Is this PR addressing any specification, design doc or external reference document?
If yes, please add relevant links:
Checklist
Related Issues