barryWhiteHat

> One thing that may affect a lot is to know if will be included in Shanghai or Cancun network updates. Here @barryWhiteHat might have some more insight. I suppose...

This makes sense. I think that we should start by building a table (block_constants_table) of these constants in the verifier contract similar to [here](https://github.com/appliedzkp/zkevm-circuits/issues/122) From there we have two choices...

I think it would be good to wait on doing EIP2935 for now. I want to avoid adding more changes to geth if we can avoid them. > I think...

> So if EIP2935 is not adopted for now, and if we don't want to add more tables or lookup arguments, Why don't we want to add more lookup tables...

Maybe good testnet parameters are `gasBlockLimit` < 1 M gas and disable `EXTCODESIZE` For `Keccak256` this is rows in the keccak circuit right ?

I think Root is still important for deposits and things like that. Also some smart contract use the current or previous roots to look things up. Same with tX_hash Totally...

I would say that we should treat the irrelevant block feilds like post merge eht does https://github.com/appliedzkp/zkevm-specs/issues/98 That way its easier for devs to deploy their apps without worrying about...

Can we move this to halo2 repo ?

> Does anyone know if the ci machine supports x86 instructions? @AronisAt79 Could you also chekc why the bench i snot running here :)

> thought that halo2 optimizations would be submitted via branches sourcing from kzg-rebase. Was that not the case? Nah we switched to schplonk you can get that by just removing...