optimism sequencer背后的魔法：L2派生（derivation）原理

作者：joohhnnn

opstack是如何从Layer1中派生出来Layer2的

在阅读本文章之前，我强烈建议你先阅读一下来自optimism/specs中有关派生部分的介绍(source^[2]) 如果你看完这篇文章，感到迷茫，这是正常的。但是还是请记住这份感觉，因为在看完我们这篇文章的分析之后，请你回过来头再看一遍，你就会发现这篇官方的文章真的很凝练，把所有要点和细节都精炼的阐述了一遍。

接下来让我们进入文章正题。我们都知道layer2的运行节点是可以从DA层（layer1）中获取数据，并且构建出完整的layer2区块数据的。今天我们就来讲解一下这个过程中是如何在codebase中实现的。

你需要有的问题

如果现在让你设计这样一套系统，你会怎么设计呢？你会有哪些问题？在这里我列出来了一些问题，带着这些问题去思考会帮助你更好的理解整篇文章

当你启动一个新节点的时候，整个系统是如何运行的？

你需要一个个去查询所有l1的区块数据吗？如何触发查询？

当拿到l1区块的数据后，你需要哪些数据？

派生过程中，区块的状态是怎么变化的？如何从unsafe变成safe再变成finalized？

官方specs中晦涩的数据结构 batch/channel/frame 这些到底是干嘛的？（可以在上一章03-how-batcher-works章节中详细理解）

什么是派生（derivation）？

在理解derivation前，我们先来聊一聊optimism的基本rollup机制，这里我们简单以一笔l2上的transfer交易为例。

当你在optimism网络上发出一笔转账交易，这笔交易会被"转发"给sequencer节点，由sequencer进行排序，然后进行区块的封装并进行区块的广播，这里可以理解为出块。我们把这个包含你交易的区块称为区块A。这时的区块A状态为unsafe。接下来等sequencer达到一定的时间间隔了（比如4分钟），会由sequencer中的batcher的模块把这四分钟内所有收集到的交易（包括你这笔转账交易）通过一笔交易发送到l1上，并由l1产出区块X。这时的区块A状态仍然为unsafe。当任何一个节点执行derivation部分的程序后，此节点从l1中获取区块X的数据，并对本地l2的unsafe区块A进行更新。这时的区块A状态为safe。在经过l1两个epoch（64个区块）后，由l2节点将区块A标记为finalized区块。

而派生就是把角色带入到上述例子的l2节点当中，通过不断的并行执行derivation程序将获取的unsafe区块逐步变成safe区块，同时把已经是safe的区块逐步变成finalized状态的一个过程。

代码层深潜

hoho 船长，让我们深潜?

获取batcher发送的batch transactions的data

我们先来看看当我们知道一个新的l1的区块时，如何查看区块里面是否有batch transactions的数据 在这里我们先梳理一下所需要的模块，再针对这些模块进行查看

首先要确定下一个l1的区块块号是多少

将下一个区块的数据解析出来

确定下一个区块的块号

op-node/rollup/derive/l1_traversal.go

通过查询当前origin.Number + 1的块高来获取最新的l1块，如果此块不存在，即error和ethereum.NotFound匹配，那么就代表当前块高即为最新的区块，下一个区块还未在l1上产生。如果获取成功，将最新的区块号记录在l1t.block中

将区块的data解析出来

op-node/rollup/derive/calldata_source.go

首先先通过InfoAndTxsByHash将刚才获取的区块的所有transactions拿到，然后将transactions和我们的batcherAddr还有我们的config传入到DataFromEVMTransactions函数中， 为什么要传这些参数呢？因为我们在过滤这些交易的时候，需要保证batcher地址和接收地址的准确性（权威性）。在DataFromEVMTransactions接收到这些参数后，通过循环对每个交易进行地址的准确性过滤，找到正确的batch transactions。

从data到safeAttribute,使unsafe的区块safe化