基于原生 Rollup 的区块构建管道

基于 Vanilla 的 Rollup 的区块构建管道

TLDR

• GMEV-Boost 是 MEV-Boost 的一个直接替换软件。它的主要目标是实现 L2 管道和 L1 管道之间的连接。
• 该设计将管道分离为单个主管道和多个次管道。主管道处理 L1 区块构建。次管道处理 L2 排序交易的生产。
• 主管道通过 Conditions API 扩展——外部区块构建 API 的一个扩展——在 relays 中实现，并被提议者（通过 GMEV-Boost）和构建者使用。它允许提议者指定对其区块的有效性条件，relay 需要强制执行。有效性条件表示为完整的交易。
• GMEV-Boost 需要访问验证者密钥库（或其他签名方法，例如 Web3Signer），以便主管道的 relays 在提交有效性条件时对验证者进行身份验证。
• 次管道用于生成 L2 排序交易。GMEV-Boost 公开了一个经过身份验证的 Pipelines API，各个次管道可以在其中提交各自的条件。GMEV-Boost 结合各个条件并将它们提交到主管道。

介绍

本文档的目标是概述 L1 的外部区块构建管道和各种 L2 区块构建管道如何在基于 Vanilla 的排序的背景下融合。目标是展示为了实现这种管道融合，对现有软件的添加和修改的要求。

选择 Orchestrator

基于排序的目标是使 L1 提议者成为 L2 排序者。这意味着 L2 排序交易需要提交到现有的 L1 管道中。接收此提交的参与者需要协调将这些交易纳入 L1 区块中。在本节中，我们将此参与者称为“orchestrator”。

有两个非常适合的参与者可以选择作为 orchestrator。一方面，有实际构建区块的参与者——L1 构建者，另一方面，有实际的提议者。

L1 构建者具有已经很成熟的天然优势，L2 排序交易可以成为其区块构建管道的一部分，几乎不需要修改——就像 L2 排序器是另一个搜索者一样。

然而，选择 L1 构建者作为 orchestrator 会引入和/或加剧几个风险因素。

首先，在实践中，L1 构建者的群体规模很小，并且需要巨大的技术和业务复杂性才能进入。这使得新的Based Rollup 的创建和运营依赖于一小群参与者。不幸的是，这种风险以前已经在一些主要的区块链网络开发堆栈中实现——一个新的网络需要花费大量资源来说服主要的验证者加入并支持他们即将到来的网络。类似的场景在Based Rollup 中也极有可能出现，并且会损害 rollup 的主权——任何 rollup 都希望具有的特性。

其次，这小群构建者的地缘政治风险转移到了 rollup。任何实现的地缘政治风险（即，国家引起的审查）都会转移到 rollup 本身。对于面向隐私的 rollup 及其排序者来说，这可能尤其有问题，因为他们会面临自己没有过错的活跃性故障风险。例如，主要构建者可能会制裁此类 rollup 交易。

本文探讨的第二种方法是指定 L1 提议者作为 orchestrator。这种方法需要对现有软件和交互进行更多修改，但最终是基于广泛、多样化、去中心化的以太坊 L1 提议者群体。

L1 提议者作为 orchestrator 能够实现 vanilla based rollup 的无需许可的创建和运营。rollup 团队需要 rollup 来吸引各种理性的参与者——l1 提议者。此外，他们甚至可以自己产生 L1 提议者，并成为他们的引导排序者——这对于构建者来说实际上是不可能的。这保护了 rollup 的主权。

此外，这种方法可以防止对 L1 构建者的控制和权力整合的进一步扩大。L1 提议者要求包含 L2 排序交易，而 L1 构建者被迫遵守或失去构建当前区块的机会，这种方法将排序控制权交给提议者。这种系统利用了 PBS 的安全性——只要有 1 个区块构建者愿意满足要求，系统就会按预期运行，即使没有构建者想要构建此区块，也可以使用标准的回退到本地区块构建。重要的是

系统架构 - 高级概述

该架构建议使用一个新的软件 GMEV-Boost——一个可以直接替换 MEV-Boost 的软件。 它的主要目标是实现 L2 管道融合到 L1 管道中，并使 L1 提议者能够指定针对外部构建管道的有效性条件。

该架构引入了主管道和次管道的概念。

只有一个主管道——L1 管道。主管道的目标是构建和广播 L1 区块。它目前已投入使用，并通过 MEV-Boost 实现。GMEV-Boost 将完全兼容 MEV-Boost，并且只想服务于 L1 管道的 staker 可以使用 GMEV-Boost 作为 MEV-Boost 的直接替换。

系统设计支持多个次管道。次管道的目标是生成 L2 排序交易。然后，生成的排序交易作为条件传达给提议者的 GMEV-Boost 软件。然后，GMEV-Boost 处理它们的组合并将它们传播到主管道中，以便包含在 L1 区块中。

为了促进这些通信，引入了两个新的 API——Conditions API 和 Pipelines API。

Conditions API 是 Ethereum Builder API 的扩展。 它的目标是使提议者能够通过 GMEV-Boost 向外部构建者传达他们对外部构建区块的有效性条件。 实际上，这意味着 Conditions API 必须在 relays 中实现，以便构建者和提议者能够相互交流这些要求。

提议者和 relay 之间的通信需要经过身份验证。 这是为了使 relay 能够对来自提议者的有效性条件提交进行身份验证，并减轻模仿攻击。

这种身份验证的形式是提议者的加密签名。 这使得 GMEV-Boost 软件需要能够访问提议者的验证者密钥。 由于 GMEV-Boost 是 staker 自己运行的软件，因此可以通过验证者软件使用的相同机制来访问密钥——即，访问密钥库文件或 Web3Signer。 重要的是，GMEV-Boost 是 staker 自己运行和控制的软件，没有第三方可以访问他们的验证者密钥。

Pipelines API 的目的是实现 L2 rollup 节点和 GMEV-Boost 之间的通信。 它使次管道既可以发现连接到此 GMEV-Boost 实例的验证者，又可以传达每个管道的各个条件。

为了使 GMEV-Boost 软件信任来自次管道的请求，两个组件之间的通信需要经过身份验证。 与共识层和执行层客户端之间的身份验证方式类似，rollup 节点需要通过 JWT Token向 GMEV-Boost 进行身份验证。

一旦提交了各个条件，GMEV-Boost 软件就有责任将次管道的各个偏好组合和聚合为主要管道的组合条件。

主管道

主管道的目标是生成 L1 区块。 它是通过 MEV-Boost 软件和外部区块构建 API 已经投入使用的管道。

现有的管道经过扩展，允许从提议者到区块构建者（通过 relays）指定有效性条件。 通过此 API，提议者可以表达他们对在 L1 区块内包含 L2 排序交易的要求，以确保履行他们的职责。

Conditions API 的规范可以在后面的章节中找到。

交互流程

1. 当以下两个条件都存在时，GMEV-Boost 会触发该流程：
   1. 验证者被选择为提议者 并且
   2. 有次管道表明需要执行的条件。
2. GMEV-Boost 组合次管道的有效性条件并对其进行签名
3. GMEV-Boost 通过 /eth/v1/builder/conditions/{slot}/{parent_hash}/{pubkey} 端点提交它们。 relays 验证新的有效性条件，记录它们并丢弃所有现有投标。
4. 构建者通过 /relay/v1/builder/conditions 端点不断轮询 relays 以获取有效性条件的更新。 每当构建者正在构建的插槽的 conditions_hash 发生更改时，构建者都需要构建符合指示条件的新投标。

外部区块构建管道交互的其余部分保持不变。

对于提议者来说，一个重要的考虑因素是提交有效性条件的时间。 提议者需要考虑在有效性条件发生变化后，区块构建管道生成区块所需的时间。 实际上，这意味着提议者必须设置有效性条件提交截止日期，否则可能会错过一个插槽。

次管道

次管道的目标是生成 L2 排序交易并将其提交给提议者，以便包含在 L1 区块中。 每个管道都由汇总节点表示，并通过汇总节点和 GMEV-Boost 软件之间的 JWT 身份验证进行身份验证，这是 Pipelines API 的一部分。

Pipelines API 的规范可以在后面的章节中找到。

交互流程

1. 为了发现哪些验证者与此 staker 连接，次管道使用 Pipelines API 的 /gmev/v1/validators 端点。 这使 rollup 节点能够知道何时被选为排序器（主要或备用选择）
2. 在排序器的运行过程中，他们会收集交易列表（例如，预确认），并生成需要包含在 L1 中的排序交易。
3. 排序器通过 Pipelines API 的 /gmev/v1/conditions 端点将交易提交给 GMEV-Boost

排序交易的后续生命周期在 GMEV-Boost 软件的范围内。

GMEV-Boost

GMEV-Boost 软件的目标是成为各种次管道和主管道之间的 orchestrator 和融合点。 GMEV-Boost 软件有几个重要的职责。

首先，它实现了 Pipeline API。 一方面，这为次管道提供了一种发现在此 staker 注册的验证者的方法。 另一方面，它是次管道提交其各个条件的方法。

其次，它有责任根据当前的验证者状态接受或拒绝各个条件。 例如，如果在当前（或后续）插槽中没有选择验证者作为提议者，则次管道不应提交各个条件。

第三，它有责任促进条件组合、签名和提交过程。 它聚合各种单独的条件，并准备用于签名和提交的数据，促进身份验证签名的生成，最后，它使用新组合的有效性条件调用 relays。

最后，GMEV-Boost 负责处理同步边缘情况。 这种情况可能是延迟提交有效性条件，其中 GMEV-Boost 可能需要回退到本地区块构建，因为没有投标可以及时到达。

GMEV-Boost 组件是进一步扩展Based Rollup 的生态系统以及所需功能（如通用同步可组合性）的理想点。

Conditions API - Builder API 扩展

在由 relays 实现的构建者 API 中引入 1 个新端点，并在 relay api 中引入 1 个新端点。

数据模型

ValidatorConditionsV1

class ValidatorConditionsV1(Container):
    top: List[Transaction, MAX_TOP_TRANSACTIONS],
    rest: List[Transaction, MAX_REST_TRANSACTIONS]

注意

对 L2 交易进行排序的 L1 交易不需要区块定位的 top ，但是，等效的管道和 API 可以重新用于外部 L2 区块构建管道。 这可以使排序器指定执行预确认作为 L2 区块构建者的区块顶部条件。

SignedValidatorConditionsV1

class SignedValidatorConditionsV1(Container):
    message: ValidatorConditionsV1,
    conditions_hash: Hash32,
    signature: BLSSignature

端点

提交条件

端点：POST /eth/v1/builder/conditions/{slot}/{parent_hash}/{pubkey}

描述：通过提议者为该插槽设置有效性条件。 需要签名的消息。

请求：SignedValidatorConditionsV1

注释：

• 可以将条件提交为 JSON 或 SSZ，并且可以选择使用 GZIP 编码。 为了清楚起见，有四个选项：JSON，JSON + GZIP，SSZ，SSZ + GZIP。 如果为 JSON，则内容类型应为 application/json。 如果为 SSZ，则内容类型应为 application/octet-stream。
• 要为请求正文启用 GZIP 压缩，HTTP 内容编码应为 gzip。 压缩是可选的。
• conditions_hash 是 SSZ 编码的 message 的 keccak 哈希。 调用方可以使用它来快速识别有效性条件是否已更改。
• 提议者通过对 conditions_hash 的签名进行身份验证。
• relay 将模拟区块提议并丢弃不符合条件的区块提议。
• 更新条件会丢弃所有当前的投标。

示例请求：

"message": {
    "top": [
            "0x02f878831469668303f51d843b9ac9f9843b9aca0082520894c93269b73096998db66be0441e836d873535cb9c8894a19041886f000080c001a031cc29234036afbf9a1fb9476b463367cb1f957ac0b919b69bbc798436e604aaa018c4e9c3914eb27aadd0b91e10b18655739fcf8c1fc398763a9f1beecb8dddddd"
    ],
    "rest": [
            "0x02f878831469668303f51d843b9ac9f9843b9aca0082520894c93269b73096998db66be0441e836d873535cb9c8894a19041886f000080c001a031cc29234036afbf9a1fb9476b463367cb1f957ac0b919b69bbc798436e604aaa018c4e9c3914eb27aadd0b91e10b18655739fcf8c1fc398763a9f1beecb8eeeee",
    ]
},
"conditions_hash": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"
"signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"

获取条件

端点：GET /relay/v1/builder/conditions

描述：获取计划在当前和下一个 epoch 中提议的验证者的指示条件列表。 希望构建者定期轮询这些，以便满足要求。

注释：

• 构建者使用它来了解即将到来的提案必须包含什么才能被接受。
• 返回即将到来的提议者及其当前设置的条件的数组。
• 每个条目都包含一个插槽、验证者和验证者表达的条件

示例响应：

[
  {
    "slot": "1",
    "validator_index": "1",
    "entry": {
        "message": {
            "top": [
                "0x02f878831469668303f51d843b9ac9f9843b9aca0082520894c93269b73096998db66be0441e836d873535cb9c8894a19041886f000080c001a031cc29234036afbf9a1fb9476b463367cb1f957ac0b919b69bbc798436e604aaa018c4e9c3914eb27aadd0b91e10b18655739fcf8c1fc398763a9f1beecb8dddddd"
            ],
            "rest": [
                "0x02f878831469668303f51d843b9ac9f9843b9aca0082520894c93269b73096998db66be0441e836d873535cb9c8894a19041886f000080c001a031cc29234036afbf9a1fb9476b463367cb1f957ac0b919b69bbc798436e604aaa018c4e9c3914eb27aadd0b91e10b18655739fcf8c1fc398763a9f1beecb8eeeee",
            ]
        },
        "conditions_hash": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2"
        "signature": "0x1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505cc411d61252fb6cb3fa0017b679f8bb2305b26a285fa2737f175668d0dff91cc1b66ac1fb663c9bc59509846d6ec05345bd908eda73e670af888da41af171505"
    }
  }
]

Pipelines API

GMEV-Boost 提供了两个新的终结点供次管道使用。 两个终结点都需要通过 JWT Token进行身份验证。

数据模型

ValidatorDataV1

class ValidatorDataV1(Container):
    validator_index: uint256,
    pubkey: utring

端点

获取验证者

端点：/gmev/v1/validators

描述：获取在此 GMEV-Boost 实例中注册的验证者

回复：List[ValidatorDataV1]

注释：

• 由次管道使用以获取此 GMEV-Boost 实例中已注册的验证者。
• 返回验证者数组。

示例回复：

[
  {
    "validator_index": "42",
    "pubkey": "0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a"
  }
]

提交条件

端点：/gmev/v1/conditions

描述：为当前插槽提交条件

请求：ValidatorConditionsV1

注释：

• 可以将条件提交为 JSON 或 SSZ，并且可以选择使用 GZIP 编码。 为了清楚起见，有四个选项：JSON，JSON + GZIP，SSZ，SSZ + GZIP。 如果为 JSON，则内容类型应为 application/json。 如果为 SSZ，则内容类型应为 application/octet-stream。
• 要为请求正文启用 GZIP 压缩，HTTP 内容编码应为 gzip。 压缩是可选的。
• 次级管道通过 JWT 进行身份验证
• 同一插槽的后续条件提交将丢弃之前的条件提交

示例请求：

"message": {
    "top": [
            "0x02f878831469668303f51d843b9ac9f9843b9aca0082520894c93269b73096998db66be0441e836d873535cb9c8894a19041886f000080c001a031cc29234036afbf9a1fb9476b463367cb1f957ac0b919b69bbc798436e604aaa018c4e9c3914eb27aadd0b91e10b18655739fcf8c1fc398763a9f1beecb8dddddd"
    ],
    "rest": [
            "0x02f878831469668303f51d843b9ac9f9843b9aca0082520894c93269b73096998db66be0441e836d873535cb9c8894a19041886f000080c001a031cc29234036afbf9a1fb9476b463367cb1f957ac0b919b69bbc798436e604aaa018c4e9c3914eb27aadd0b91e10b18655739fcf8c1fc398763a9f1beecb8eeeee",
    ]
}

Relay API 修改

Relay API 对其当前行为的修改最少。 唯一可选的更改是在投标提交端点 /relay/v1/builder/blocks 中，可以将可选的字段 conditions_hash 添加到请求中。

该字段将使构建者能够指定其投标针对哪个 conditions_hash，并将涵盖条件在飞行中发生变化的竞争条件边缘情况。

"message": {
    ...
    "value": "1",
    // Optional
    "conditions_hash": "0xcf8e0d4e9587369b2301d0790347320302cc0943d5a1884560367e8208d920f2" 
  },
  ...
}

Builder API 修改

Relay API 对其当前行为的修改最少。 唯一可选的更改是在验证者注册端点 /eth/v1/builder/validators 中，可以将可选的字段 conditions_version 添加到请求中。

省略或值为“ 0”表示不支持条件提交，而非零值表示管道 API 的版本。

示例请求：

 {
    "message": {
        ...,
        // Optional
        "conditions_version": "1",
        "pubkey": "0x93247f2209abcacf57b75a51dafae777f9dd38bc7053d1af526f220a7489a6d3a2753e5f3e8b1cfe39b56f43611df74a"
    },
    "signature": "..."
  }

所需的 Rollup 节点修改

rollup 节点的主要修改是需要使用 Pipelines API。

获取验证者

端点：/gmev/v1/validators

在启动时进行查询，以获取 GMEV-Boost 实例中已注册的验证者的列表。 这是必需的，以便 Rollup 节点确定何时选择它们作为排序器并启动列表构建过程。

提交条件

端点：/gmev/v1/conditions

当 GMEV-Boost 中的一个注册验证者被选择作为排序器并且通过 主要的选择机制时， 除了公开广播排序交易之外，rollup节点还应通过“提交条件”端点将其提交给 GMEV-Boost。

进一步的研究方向

• 次级管道提议者 - 构建者分离

• 原文链接： github.com/LimeChain/bas...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～