feat: add sload op#97
Conversation
|
i guess after adding sstore, we can use bus-mapping to generate sload test case? |
Still no.. we don't have CallContextOp for now:
(I could deal with TxAccessListAccountStorageOp, but CallContextOp requires a lot of work.) |
|
and that's why I originally had #79 but then gave up and submit this PR. |
| F::from(*tx_id as u64), | ||
| address.to_scalar().unwrap(), | ||
| RandomLinearCombination::random_linear_combine(key.to_le_bytes(), randomness), | ||
| F::from(*value as u64), |
There was a problem hiding this comment.
do need to random_linear_combine of value value_prev or already done when passing as parameter ?
There was a problem hiding this comment.
in TxAccessList, both value & value_prev are boolean instead of word.
as in TxAccessListAccount we don't do random_linear_combine, so I don't think we should do random_linear_combine in TxAccessListAccountStorage here
| }, | ||
| ExecStep { | ||
| execution_state: ExecutionState::STOP, | ||
| rw_counter: 17, |
There was a problem hiding this comment.
should check result for next step rw_counter ? just like above step rw_indices: (0..8 + if result { 0 } else { 2 }).collect(),
There was a problem hiding this comment.
I think we don't need to check for revert.
Like we don't check for revert in BEGIN_TX.
in StepStateTransition we use rw_counter: Delta(8.expr()), and here we only have 1 case, instead of also considering revert case
|
moved to privacy-ethereum#334 |
3 participants
reference:
privacy-ethereum/zkevm-specs#106
BTW, I would like to separate
sloadandsstorePR. because the gas calculation and the TxRefund calculation forsstoreare more complicated.