-
Notifications
You must be signed in to change notification settings - Fork 853
Identity (dataCopy) precompile #1396
Identity (dataCopy) precompile #1396
Conversation
Finished the 1st round review. the framework seems good for me. (small code style suggestion: move the CallContext xxx rws inside bus-mapping identity.rs into a common file like util.rs or precompile.rs since later precompiles needs these too) |
( | ||
CallContextFieldTag::LastCalleeReturnDataLength, | ||
// return_data_len.expr(), | ||
1.expr(), // TODO(rohit): fix this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
todo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have updated this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM, only have some questions about step state transition.
let address = BinaryNumberGadget::construct(cb, callee_address.expr()); | ||
|
||
cb.condition(address.value_equals(PrecompileCalls::Identity), |cb| { | ||
cb.constrain_next_step(ExecutionState::PrecompileIdentity, None, |cb| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these require_equal
necessary if we already read the call context from rw table in precompile step? I feel we only need to make sure the next step is the precompile execution step read from the precompile info by callee address.
// Save caller's call state | ||
for (field_tag, value) in [ | ||
(CallContextFieldTag::LastCalleeId, callee_call_id.expr()), | ||
(CallContextFieldTag::LastCalleeReturnDataOffset, 0.expr()), | ||
( | ||
CallContextFieldTag::LastCalleeReturnDataLength, | ||
// return_data_len.expr(), | ||
1.expr(), // TODO(rohit): fix this. | ||
), | ||
] { | ||
cb.call_context_lookup(true.expr(), None, field_tag, value); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For each precompile, their return data length should be different, should we set them in the precompile step? Or we can also handle them one by one here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have updated this part. It was a TODO while I was debugging/fixing something, but later forgot to update the code.
call_gadget.rd_address.offset(), | ||
call_gadget.rd_address.length(), | ||
) | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'd need to do step state transition here to callee's state here, and restore that in callee's step, right? Otherwise I don't see any constraint to enforce that.
This commit introduces the support for precompiled contracts. For more information, check the appendix E of the Ethereum Yellow Paper. It is a simplified version of the identity precompile PR of PSE. It strips the implementation of the identity precompile variant, leaving only the skeleton for the lookup table calls. [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) [Identity (dataCopy) precompile privacy-scaling-explorations#1396](privacy-scaling-explorations#1396)
This commit introduces the support for precompiled contracts. For more information, check the appendix E of the Ethereum Yellow Paper. It is a simplified version of the identity precompile PR of PSE. It strips the implementation of the identity precompile variant, leaving only the skeleton for the lookup table calls. [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf) [Identity (dataCopy) precompile privacy-scaling-explorations#1396](privacy-scaling-explorations#1396)
Status: This PR needs to be updated to address Han's review and also to rebase against main. @roynalnaruto do you have some estimation on when you plan to continue working on this? No pressure! |
@darth-cy already working on this |
closed for the new one #1628 |
### Description This is a follow-up PR for [PR#1396](#1396) from @roynalnaruto. After merging in 1396's changes to a fresh fork, the branch is compared with Scroll's develop head to incorporate latest patterns on precompile-related development. ### Issue Link [Aggregating precompile issue 924](#924) ### 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 ### Design choices See [documentation](https://www.notion.so/scrollzkp/PR-1396-Follow-up-Precompile-Identity-for-Upstream-3624af055d9b4820a0354e9af4fa7918) --------- Co-authored-by: Rohit Narurkar <rohit.narurkar@protonmail.com> Co-authored-by: Zhang Zhuo <mycinbrin@gmail.com>
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: