Eduard S.
Eduard S.
Currently we're only handling the spent gas related rewards to the coinbase address (this is done in EndTx). We should also handle the fixed reward in EndBlock (as described here,...
See https://github.com/privacy-scaling-explorations/zkevm-circuits/pull/843#discussion_r1001776817 It would be good to document clearly how the previous block hashes are arranged to avoid future confusions.
Currently different opcode gadgets use different number of bytes for RLC encoding depending on the type of data when doing lookups. For example, for CALLER we use 20 bytes, for...
The current design involves the verifier to precomputed values based on the block public data (block headers, transaction fields, etc.) This data i precomputed by the verifier following the tx...
Copied from a comment by @han0110 in https://github.com/privacy-scaling-explorations/zkevm-specs/pull/237#pullrequestreview-1066368872 > But just realized that in other circuits to use `{block,tx}_table` we'd still multiply the `q_{block,tx}_table` to make sure prover doesn't put...
- [x] CallContext - [x] TxRefund - [x] TxAccessListAccount - [x] TxAccessListAccountStorage - [ ] AccountDestructed Circuit implementation related issue: https://github.com/privacy-scaling-explorations/zkevm-circuits/issues/568
The EVM circuit tracks all accesses to the execution state that happen during a transaction via lookups to the `rw_table` in the state circuit. The only accesses that should be...
In `src/zkevm_specs/opcode` we have some opcodes python implementations following an outdated API: these opcodes don't receive an `Instruction`, and they don't perform any bus-mapping lookup. They are implemented in the...
Extended discussion related to https://github.com/privacy-scaling-explorations/zkevm-specs/pull/220#discussion_r897784551 We have a few tables that are shared between circuits; where one circuits enforces some constraints on the table, and the other circuit does lookups...