由 George 和 Vlad 合著，来自 Gattaca。特别感谢 Aestus、bloXroute 和 Ultrasound 中继提供的意见。
概述
在早期的中继架构（乐观 V1 和 V2）中，构建者必须预先向中继传输完整的区块负载以进行验证。这意味着显著的数据开销：每次区块提交都包含所有交易和 blob 数据，可能每次提交达到兆字节级别。这导致大量冗余的网络流量，因为除了一个提交的负载外，其他都不会被返回，给中继带来了繁重的数据传输、处理和成本负担。
乐观 V3 旨在通过避免在非绝对必要时传输完整的区块数据来消除这种开销。关键洞察是仅发送拍卖所需的基本数据，即区块头、出价跟踪和签名，同时将繁重的负载推迟到区块实际被选中时。这种设计大幅减少了带宽使用量并降低了区块提交延迟。随着区块大小的持续增长，特别是 blob 限制的增加，这种方法变得越来越至关重要，以确保中继能够处理不断增长的吞吐量需求。
从乐观 V1 到 V3 的演进回顾
- 乐观 V1：引入了延迟区块验证，中继乐观地考虑出价，而不立即验证完整区块。
- 乐观 V2：将头与负载解耦，允许小型头部立即处理，而较重的区块数据异步到达。尽管头部提交有延迟收益，但构建者仍然被迫并行向中继发送完整区块负载，导致重复的头部数据和更多带宽使用。
- 乐观 V3：构建者仅提交区块头并包含一个用于从构建者按需检索负载的地址。中继按需获取完整区块数据，几乎消除了所有冗余数据传输。
结构体 头部提交V3 {/// 指向构建者服务器端点的URL，用于在选择此头部时检索/// 完整区块载荷。公开 url: 向量<u8>,/// 已签名的头部数据。这是与/// 乐观V2 '已签名头部提交'相同的结构，包含：/// - 执行头部/// - 出价追踪/// - 签名公开 提交: 已签名头部提交,}URL必须是一个网络地址（例如，https://builder.example.com），该地址提供 get_payload_v3 路径，中继可以在该路径检索完整区块。
载荷检索（构建者端点）
路径： POST /get_payload_v3
如果/当中继想要检索 头部提交V3 的区块载荷时，它将向提供的URL的 get_payload_v3 路径发出POST请求。
结构体 获取载荷V3 {/// 来自 `已签名头部提交` 的区块头部哈希。公开 区块哈希: B256,/// 中继发出此请求的时间戳（毫秒）。公开 请求时间戳: u64,/// 用于创建 `已签名获取载荷V3` 中 `签名` 字段的签名密钥的Bls公钥。公开 中继公钥: Bls公钥,}结构体 已签名获取载荷V3 {公开 消息: 获取载荷V3,/// 中继用于签署 `获取头部` 响应的密钥的签名公开 签名: Bls签名,}区块哈希 字段是请求的区块哈希。请求时间戳 是中继发出此请求时的UTC毫秒时间戳。
响应正文
构建者必须返回与标准构建者提交相同的 已签名构建者出价 类型的完整区块载荷。
