L2 builder preparation

[adaki2004]

No description provided.

[adaki2004]

@Brechtpd Could you please have a look on the above comments:

1. Is it the correct understanding ? Is the comment valid ?
2. Currently i'm trying to distinguish based on chain_id, tho i could not find a way to extract it from Signature Maybe it is not even the best approach to distinguish tho seems obvious ?

[Brechtpd]

I would guess ideally the node is configured differently in some way between L1 and L2. With L2 having a somewhat custom payload builder likely, and then instead of propegating the block through the network like done on L1, it would instead propose the block to the gwyneth smart contract (probably something related to the engine api, but haven't looked up the normal flow for this).

On the other hand, we can also just make it easy for now and just collect the tx here and propose the block to the smart contract when it's configured as an L2 node and then we can see later. Normally, the block building wil be done through something like rbuilder, so reth itself only really needs to be able to sync with a given tx list (and the internal payload builder would only be a fallback path).

[adaki2004]

@Brechtpd some debug observations regarding L2 block building. Currently we are building L2 blocks 2 ways:

If i trigger the TaikoL1's ProposeBlock event with make propose number=1:

1. bin/reth/src/payload.rs functions are only called when I trigger a proposeBlock() call (aka a BlockProposed event) -> So it is kind of a post-happening thingy, where we actually already built the payload already within our L2 exex, then sent over to L1, then derived it (again) from the L1 contract.. (Now i'm triggering this obviously with the make script.) -> I'm not surebut i think maybe not the best, because there is another way currently to advance our L2 chain (tested it with RPC eth_blockNumber and indeed 2 ways now).

If i sent some ether from Bob to Alice via a python script, directly via the L2 rpc. (send_raw_transaction):

2. crates/ethereum/evm/src/execute.rs file's execute_without_verification() is called when i send some eth from Bob to Alice on L2 exex. (Obviously according to the logs in the execution client i can see it debug message chain id:L1, and chain id:L2 separately, so it is a common core function for L1 and L2).

AFAIK we shall only allow one way of advancing our chain (maybe the former !?) and not sure which one is the desired, best but we also need to go thru L1 ProposedBlock.

For now i just put some debug prints into the code if you wanna try out all and inspect!

(For sending raw eth transaction triggered via rpc, you can run in taiko-reth/packages/protocol/scripts/L2_txn_simulation the command: python3 sendATxnToL2Rpc.py -p L2_PORT_NR)

My 0.02:
We need to get rid of the "post-event-execution" as everything is handled already within the L2 Exex rollup (which is good) and maybe the post-event thing could be used to trigger proving (?). -> In that case we still need to somehow hack into the code to send a TaikoL1 prposeBlock() transaction. (Somewhere in the crates/ethereum/evm/src/execute.rs file)

[Brechtpd]

1. is definitely the way to go because this is how nodes need to sync, not all nodes will get the same transactions in the mempool through send_raw_tx so 2. cannot work for syncing nodes, only to for nodes to build new blocks and advance their own local chain.

I think the two things we need to support (syncing nodes and proposing nodes) are not special and the same that also needs to happen for standard Ethereum nodes, which is why I would prefer us doing the exact same thing that is done for that (which I currently do not know the exact mechanism).

On the other hand, if supporting block building inside reth is tricky, may as well just do all block building using rbuilder because that's how it will likely only be done in practice, and inside the reth node directly we only support syncing from L1 through proposeBlock events/calls like we currently already do.

[adaki2004]

Other observations during today debug.

For some reason block building is failing if we do it in this order:

1. python script
2. make propose number=1

I know i shall get rid of the rpc_type block building,but just not modified the code yet because i'm still figuring out the best place to interrupt the background process and hijack it with an L1 contract proposeBlock() forwarding.

Maybe it is in blockchain_tree.rs, where i put my debug print ? (I think that is the closes point before execution process starts). Can you double check for me if this understanding is correct ?

[adaki2004]

Closing as rbuilder will serve our needs.