feat(taiko-client): updates for protocol preconfirmation changes

[davidtaikocha]

No description provided.

[Brechtpd]

Probably some placeholder code, but this data will need to be settable by the block builder somehow because it will need to match the values he used while building the block incrementally as transactions come in and are preconfirmed. (the current logic will also only work if an L2 block is proposed in each L1 block because otherwise it will start running behind the L1, and L2 block s can only used L1 data that is at most 64 L1 slots old)

[YoGhurt111]

Probably some placeholder code, but this data will need to be settable by the block builder somehow because it will need to match the values he used while building the block incrementally as transactions come in and are preconfirmed. (the current logic will also only work if an L2 block is proposed in each L1 block because otherwise it will start running behind the L1, and L2 block s can only used L1 data that is at most 64 L1 slots old)

Is there some way to calculate or get from rpc?
I think it should be unacceptable to set it up manually each time.

[YoGhurt111]

And the value should be less than currentL1Height - 64 and larger than parentBlock.L1StateBlockNumber, right?

[Brechtpd]

I think it should be unacceptable to set it up manually each time.

The proposer will have to give the same values here that he used to build the block with. So the values could be set automatically on the building side, but they will need to be passed through the propose function here so they match.

And the value should be less than currentL1Height - 64 and larger than parentBlock.L1StateBlockNumber, right?

Right now, yes. Though the larger than parentBlock.L1StateBlockNumber is kind of tricky so maybe we'll want to drop that requirement (same for timestamp, but that's even trickier).

[YoGhurt111]

In the test phase, when we build L2 block, we set l1StateBlockNumber = parentBlock.L1StateBlockNumber + 1 to meet the need of contract.
And in the future production phase, we give the value by calling L1 preconfer's rpc endpoint.
Same logic as above, we send proposeBlock tx to L1 preconfer's rpc endpoint instead of public L1 rpc endpoint, so L1 preconfer can decide to bundle tx in their own block or broadcast it to public.

Is that what we all agree on?

[YoGhurt111]

we = taiko-client = L2 preconfer

In the test phase, when we build L2 block, we set l1StateBlockNumber = parentBlock.L1StateBlockNumber + 1 to meet the need of contract. And in the future production phase, we give the value by calling L1 preconfer's rpc endpoint. Same logic as above, we send proposeBlock tx to L1 preconfer's rpc endpoint instead of public L1 rpc endpoint, so L1 preconfer can decide to bundle tx in their own block or broadcast it to public.

[Brechtpd]

In the test phase, when we build L2 block, we set l1StateBlockNumber = parentBlock.L1StateBlockNumber + 1 to meet the need of contract.

This won't work because if there isn't an L2 block proposed in each L1 block, l1StateBlockNumber = parentBlock.L1StateBlockNumber + 1 will start lagging behind L1. L1 will only accept an L1StateBlockNumber that is at most (right now) 128 slots old compared to the tip of the L1 chain. With the l1StateBlockNumber = parentBlock.L1StateBlockNumber + 1 formula, if an L2 block is only proposed every other L1 block, the contract will reject the L2 block after only 256 L1 blocks, because L1StateBlockNumber will only have increased by 128 while L1 is already 256 slots further.

The logic would be good and the same to previous behavior if you change parentBlock to be the latest L1 block (and the proposed block gets in in the next L1 block, but that is not required) like this:

• l1StateBlockNumber = latestL1Block.header.number
• timestamp = latestL1Block.header.timestamp + 12

And in the future production phase, we give the value by calling L1 preconfer's rpc endpoint.
Same logic as above, we send proposeBlock tx to L1 preconfer's rpc endpoint instead of public L1 rpc endpoint, so L1 preconfer can decide to bundle tx in their own block or broadcast it to public.

There will be no need to sent them our blocks, they will not use them. The preconfer will build its own blocks and choose its own L1StateBlockNumber and timestamp value, and they will propose the block themselves. They only need us to forward the user's transactions (and return the receipt), everything else they will do themselves.

we = taiko-client = L2 preconfer

I think likely that we won't be a preconfer at least at the start, maybe later if we're interested in doing so? We'll have to run similar block building code that the preconfers will be using though, not how blocks are currently built in taiko-client.

[YoGhurt111]

Thanks for the detailed explanation!