Han

> In a meeting today, @ ebfull noted a specific soundness requirement for this: the prover must only be able to assign to columns involved in a challenge prior to...

I think an approach could be adding the 2 methods in `Circuit` but with default implementation for them, and don't use them in `halo2_proofs` crates for now (keep the same...

Ah just saw this, you are right, now I see the refund is added back to gas left so the reward to coinbase should minus that.

This PR should be part of https://github.com/privacy-scaling-explorations/zkevm-specs/issues/230 and will be nice to have (as a spec refactor PR). Just a reminder that in circuit we are handling `{EQ,LT,GT}` [in the...

@ed255 Thanks for the comparing table! I made some naming change and I should add the reference directly in the pseudo code.

> Seems like it would be possible to do the padding by just filling up the block with zero length bytecodes by doing Length -> Length state transitions. The end...

Yes, the refactor doesn't change the `bytecode_table`, only trying to simplify the constraint of Bytecode circuit.

Currently we store the information of return data only with a tuple `(LastCalleeId, LastCalleeReturnDataOffset, LastCalleeReturnDataLength)`, then read the memory from last callee directly only when `RETURNDATACOPY` is called. It works...

> for Blockhash need separated handling regarding to Keccak256 circuit. I think we would have built block hashes in layer1 contract for fast retrieval instead of calculating previous block hashes...

Ah cool, `EIP2935` makes things much cleaner and less public inputs. For other static data I think using copy constraint from instance column would be easy and clean to implement.