Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

force L1 origin to be finalized L1 block #3

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

claymega
Copy link
Collaborator

@claymega claymega commented Oct 15, 2024

此PR需要解决的问题是: 强制让l1_origin是 finalized block, 这样即使l1发生reorg, l2也不会发生reorg.

mega-reth match branch: https://github.com/megaeth-labs/mega-reth/tree/clay/feature/l1_origin_finalized

修改位置:

  • 初始化rollup.json, 获取的l1-latest -> l1-finalized
  • 修改op-node启动参数, "--sequencer.enabled", "--sequencer.l1-confs", "10", "--verifier.l1-confs", "10";

对第2点修改的解释: 通过 --sequencer.l1-conf = 10这个值来保证获取的块一定是finalized, 换句话说,如果现在l1-latest=100, 那么l2的l1origin最多是90, 那么在第90个块必定是finalized, 生产环境可以设置为64(一个块的finalized最长时间是2个epoch = 2 * 32 slot = 2 * 32 * 1 个块 = 2 * 32 = 64;

img_v3_02fm_40c4c699-ca50-4891-862a-f985bbfc777h
img_v3_02fm_6121c023-9fa2-452e-b245-f30cc970cbeh

另外一种方法是在findL1origin这个函数里加一个 eth_getBlockByNumber('finalized', false)获取最新finalized区块比较;(这个相对保险但感觉没必要);

@claymega claymega requested review from yilongli and Troublor October 15, 2024 15:40
@claymega
Copy link
Collaborator Author

claymega commented Oct 15, 2024

PR对l1充值交易到l2的影响: 按照原有逻辑l1-unsafe的块中deposit会被马上跨链进入l2, 现在会延迟 depth个块; PreparePayloadAttributes函数会根据传入l1origin搜查对应deposits

image

@yangl1996
Copy link
Member

一个块的finalized最长时间是2个epoch

这是不对的,Casper共识算法的延迟没有人可以预测

另外一种方法是在findL1origin这个函数里加一个 eth_getBlockByNumber('finalized', false)获取最新finalized区块比较;(这个相对保险但感觉没必要);

根据前面的描述,这是必要的

@yangl1996
Copy link
Member

Silas提到derivation逻辑已经在维护finalized header,所以我们不用自己去调RPC

@yangl1996
Copy link
Member

还有个问题待确认:我们的sequencing window是相对L1 finalized block定义的吗?如果不是的话,L1迟迟不finalize block可能将我们逼出sequencing windows。

@Troublor
Copy link
Collaborator

我也同意要用L1那边给出的finalized block做L1 origin,而不能自己用--sequencer.l1-confs指定这个“delay”。

还有个问题待确认:我们的sequencing window是相对L1 finalized block定义的吗?如果不是的话,L1迟迟不finalize block可能将我们逼出sequencing windows。

我的理解是的,所以我们要根据需要增加sequencing window的大小。
sequencing window的定义是[L1_origin, L1_origin + sequencing_window_size),并且这个window中需要包含这个L1_origin的所有L2 block的batcher transactions。此外,每个L1 block都应该对应一个sequencing window(window之间会有overlap)。确实如果L1 finalized不往前走,但是L1 latest却在往前走的情况下,会有可能在sequencing window内无法满足batcher transactions被完全提交的要求。
不过只要L1 latest和L1 finalized会同步increment,那么就不会挤出sequencing windows,因为sequencing windows size的定义是L1 block的数量。
我画了一个L1 block和L2 block关系的时序图(如下)供参考。
CleanShot 2024-10-15 at 23 11 00@2x

@claymega
Copy link
Collaborator Author

一个块的finalized最长时间是2个epoch

这是不对的,Casper共识算法的延迟没有人可以预测

另外一种方法是在findL1origin这个函数里加一个 eth_getBlockByNumber('finalized', false)获取最新finalized区块比较;(这个相对保险但感觉没必要);

根据前面的描述,这是必要的

已经修改为通过rpc获取的finalized block来保证

Copy link
Collaborator

@Troublor Troublor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our current devnet setting does not have a drift between L1 head (latest) and L1 finalized blocks -- the finalized and latest block are always the same in Reth's dev mode. We may need to setup a separate testing environment (or modify current devnet) to test this PR.

l1Finalized := c.l1Finalized()
if num > l1Finalized.Number {
return eth.L1BlockRef{}, ethereum.NotFound
}
// Don't apply the conf depth if l1Head is empty (as it is during the startup case before the l1State is initialized).
l1Head := c.l1Head()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since l1Head is always ahead of l1Finalized, the following code (the original logic) is effectively dead code. I am not sure whether we should remove them in this PR or just keep them for reference.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dead code是指37行以后吗?如果是的,它不会是dead code, 因为num = previous_l1_origin + 1,正常运行情况下是走37行后面逻辑的

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

我意思是其原来的获取l1Head的相关的逻辑。我们现在应该是不需要l1Head这个函数了对吧?

@yangl1996
Copy link
Member

yangl1996 commented Oct 17, 2024

确实如果L1 finalized不往前走,但是L1 latest却在往前走的情况下,会有可能在sequencing window内无法满足batcher transactions被完全提交的要求。

这里可以做的是让sequencer在发现自己很可能没有时间提交(比如现在的L1 latest和sequencing window右边界相差不到12小时时)主动停止出块(开启新的epoch)

@yangl1996
Copy link
Member

sequencing drift可能也要调

@tynes
Copy link

tynes commented Oct 28, 2024

I would be open to merging the usage --sequencer.l1-confs finalized which would enable this behavior

@yangl1996
Copy link
Member

I would be open to merging the usage --sequencer.l1-confs finalized which would enable this behavior

Great! We will add the command line option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants