zkevm circuit 1559 support

[smtmfft]

Describe the feature you would like

Enable 1559 in evm to align witness data between client & zkevm circuit Background: https://www.notion.so/taikoxyz/1559-Development-Thinkings-a84ac894fb984b71ad847913ae031378

Dev base: https://github.com/smtmfft/zkevm-circuits/tree/eip-1559-base-dev (based on taiko main recursion branch)

Phase I: empty access list task list (ETA: ~3 weeks)

• [ ] evm: base fee changes only (John)
• [ ] rlp_decoding_circuit: 1559 support and force 0xC0 (empty) accesslist. (Yue)
• [ ] rlp_encoding_circuit: skipped
• [ ] tx_table: 0xC0 access_list, so far we don’t decide tx_table format for 1559, but old format is easily upgrade if access list is pure 0xC0. (John/Yue)
• [ ] Anchor tx: tx format change only. (John)
• [ ] block tx: block formant change only (if have) (George?)
• [ ] standalone zkevm integration test (Ruby/John/Yue)
• [ ] internal devnet support (Kriztof/Yue/David)

Additional context

No response

[johntaiko]

Check list:

• [x] Confirm the size of the Witness?
  • [ ] Size in extreme cases, like: Cheap opcode with full gas limit
  • [x] According to the size, if it is necessary to pass it in the form of a file.
• [ ] When degree is equal to 23, How many opcodes does the EVM circuit support and can it cover extreme cases?
  • [ ] How to deal with opcode out of limit? like: Notify the Oracle node
• [ ] How much does adding the evm circuit affect the proof time?
  • [ ] Do you need to rewrite the scheduling service?
• [ ] How about the DDL?
  • [ ] Before A4 and Singapore conf(the end of Augest)

[smtmfft]

Confirm the size of the Witness?

For witness data size/networking bandwidth concern, a simple stat of 5% blocks in our testnet shows that normally the witness has ~500M with both storage & stack. like:

block_num=706121, tx_cnt=20, time_cost=0.072s, op_cnt=13241, resp_size=586.9Mb, trans_time=31.27s
block_num=706186, tx_cnt=43, time_cost=0.072s, op_cnt=13236, resp_size=70.88Mb, trans_time=6.166s
block_num=706258, tx_cnt=28, time_cost=0.072s, op_cnt=13241, resp_size=410.3Mb, trans_time=21.31s

but if we don't dump storage & stack, the size reduces largely. like

-rw-r--r--  1    305M Jul 27 15:51 block_trace_211899.json
-rw-r--r--  1     26M Jul 27 16:23 block_trace_211899_no_stack.json
-rw-r--r--  1    264M Jul 27 15:49 block_trace_213673.json
-rw-r--r--  1     27M Jul 27 16:23 block_trace_213673_no_stack.json
-rw-r--r--  1     14M Jul 27 15:49 block_trace_214015.json
-rw-r--r--  1    2.6M Jul 27 16:23 block_trace_214015_no_stack.json
-rw-r--r--  1     17M Jul 27 15:49 block_trace_226239.json
-rw-r--r--  1    3.4M Jul 27 16:24 block_trace_226239_no_stack.json

So if a prover has a way to re-construct stack & storage locally, the networking bandwidth will no longer be a problem. Should there be a way as geth does it pretty easy, but it takes some time to impl & integrate into prover bin.