-
Notifications
You must be signed in to change notification settings - Fork 809
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EVM Circuit and trait OpGadget #26
Conversation
2deada3
to
1767301
Compare
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.
First round of review. Added a nitpick
} | ||
|
||
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)] | ||
enum Case { |
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 think the name Case
is a bit too general. Maybe use ErrorCode
to be more specific?
35586b4
to
52a55d6
Compare
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 it looks good if what we plan is to have a Layout example.
But I have several questions:
- Seems that we still need to integrate
bus-mapping
in here. Do we plan do do it in a follow-up PR? - The
Opcode
trait should (IMO) contain one or multipleExecutionStep
s so that we can basically have all of theCaseConfig
data an all the other stuff extracted from there. Case
andCaseConfig
as well asCallContext
should probably be migrated tobus-mappign
and obtained during the parsing process.- We should document more. Even if are not polished docs. But at least to help improve the general idea that the development path follows.
CaseConfig
as said in the comments should probably not be an associated const and instead be the result of a fn or similar. The reason is that multiple instances of the same Opode trait object can result in differentCaseConfig
.
const CASE_CONFIGS: &'static [CaseConfig] = &[ | ||
CaseConfig { | ||
case: Case::Success, | ||
num_word: 1, | ||
num_cell: 32, // for PUSH selectors | ||
will_resume: false, | ||
}, | ||
CaseConfig { | ||
case: Case::StackOverflow, | ||
num_word: 0, | ||
num_cell: 0, | ||
will_resume: true, | ||
}, | ||
CaseConfig { | ||
case: Case::OutOfGas, | ||
num_word: 0, | ||
num_cell: 0, | ||
will_resume: true, | ||
}, | ||
]; |
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.
This kinda reforces my previous argument that it doesn't seem to fit really well to have CaseConfigs as a const associated to the gadget since it can change depending on the instance.
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.
LGTM.
We will need to address all of the issues that have been raised here BTW. Not sure if before or after the first opcode impls. But the more we add the bigger the refactor will become.
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.
The ideas used and the implementation both seem very nice to me. I was thinking about possible optimizations but nothing came to my mind that hasn't already been considered. I have one question though - would we need one additional constraint to make sure that execution_step.opcode and the opcode selector (talking about 80 cells) are in sync? Wouldn't be now possible to set execution_step.opcode to ADD and set the opcode selector to PUSH (the one of 80s that corresponds to PUSH) which would make some attacks possible?
@miha-stopar According to your question, currently in |
@han0110 yes, that's ok. What I meant are these assignments: https://github.com/appliedzkp/zkevm-circuits/blob/f0bd8afe2607abfb428c5fb171730625448ddd25/zkevm-circuits/src/evm_circuit/op_execution.rs#L484. Not sure if there is a check that these assignments correspond to the actual opcode? |
@han0110 I can see it now - opcode number cell is used only as kind of a hint and the 80 cells determine the branching. Sorry, all good! |
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.
LGTM. Just a few minor comments
meta.advice_column(), // global_counter | ||
meta.advice_column(), // target | ||
meta.advice_column(), // is_write | ||
meta.advice_column(), // val1 |
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.
Add comment for actual meaning.
meta.advice_column(), // val1 | |
meta.advice_column(), // val1, call_id |
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.
These val*
mean different things depends on the target, so I left it arbitrary instead of concrete meaning. For stack or memroy it would be call_id
but for storage it would be account address cause the storage update is not scoped in a single call but in a block. Will try to document it in a better way to clarify.
ce345d5
to
a8e4d6f
Compare
Implement LT & GT opcode
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've not looked through this whole PR and am just submitting a few nits -- please don't block on my review.
zkevm-circuits/src/evm_circuit.rs
Outdated
// Value in wei of call. | ||
Value, | ||
// If call succeeds or not in the future. | ||
IsPersistant, |
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.
IsPersistant, | |
IsPersistent, |
zkevm-circuits/src/evm_circuit.rs
Outdated
// relative position to selector for synthesis | ||
column: Column<Advice>, | ||
rotation: usize, |
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.
// relative position to selector for synthesis | |
column: Column<Advice>, | |
rotation: usize, | |
column: Column<Advice>, | |
// relative position to selector for synthesis | |
rotation: usize, |
|
||
// Number of cells used for each purpose | ||
// TODO: pub const NUM_CELL_CALL_INITIALIZATION_STATE: usize = ; | ||
pub const NUM_CELL_OP_EXECTION_STATE: usize = 7; |
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.
pub const NUM_CELL_OP_EXECTION_STATE: usize = 7; | |
pub const NUM_CELL_OP_EXECUTION_STATE: usize = 7; |
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.
Fixed with all above suggestions in 702039d
.
|
||
construct_op_gadget!(add_gadget); | ||
construct_op_gadget!(push_gadget); | ||
let _ = qs_op_idx; |
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.
let _ = qs_op_idx; |
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.
This is intended for escaping the clippy warning since the macro increases qs_op_idx
even it's the last one.
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.
LGTM. Added some nitpicks
This PR aims to provides:
AddGadget
for reference (Closes [EVM]ADD
example #9)Todo:
OpGadget
linear_combinations
configured byOpGadget
lookups
configured byOpGadget
AddGadget
andPushGadget
as examples.Feed-> Next PRExecutionStep
by cratebus-mapping
into circuit