Block Builder 深度解析：Ethereum BuilderNet（一）

当前仍有两个中心化组件：

• BuilderHub：
  • 负责节点身份、密钥下发和 peer 发现
  • 节点启动时携带 TEE attestation 向 BuilderHub 请求配置
  • BuilderHub 校验 measurement 和 IP 白名单后，下发 coinbase key、relay signing key 等敏感信息
• Redistribution Archive：
  • 存储 orderflow、bid 和区块结果
  • 用于退款计算与审计
  • 以 50% 出块率估算，数据规模约 30GB/天

BuilderNet 节点不是 Docker 容器，而是基于 Yocto 构建的完整 Linux TDX VM 镜像（.vhd 格式） 可运行在支持 TDX 的环境，例如 Azure TDX Confidential VM 或 Intel 4th Gen Xeon Scalable 及以上硬件。

流程：

1. 启动系统服务（network、fs、cron）
2. 时间同步（NTP daemon，v1.2 后增强）
3. 启动 cvm-reverse-proxy（处理 TEE attestation）
4. 从 BuilderHub 拉取 secrets 与 config（包含 attestation 验证）
5. 挂载加密磁盘
6. 启动 Operator API（system-api，端口 3535）
7. 启动 Prometheus/Fluentbit（可观测性）
8. 启动 Lighthouse（共识层客户端）
9. 执行 Reth snapshot sync
10. 启动 Reth（执行层客户端）
11. 启动 rbuilder + bidding service + HAProxy
12. 启动 orderflow-proxy，开始接收交易

当前是许可制。

流程：

1. 提交申请
2. Flashbots 审核
3. 白名单通过
4. 节点上线

官方 roadmap 提到会向 permissionless 方向推进，目前还没完全落地。

关键组件是 orderflow-proxy，部署在两端：

• Flashbots 基础设施侧（汇聚多渠道流量）
• 各个 TEE 节点内（接收、广播、归档、转发）

• orderflow-proxy 转发的交易和 bundle
• MEV-Share hint（部分暴露的交易信息）
• 本地 Reth mempool

1. 模拟与有效性检查：验证交易可执行性、gas 等约束
2. Bundle 合并排序：按收益最大化策略组合订单流
3. MEV 提取：执行 backrun、套利等策略
4. 合规过滤：按运营商 blocklist 过滤特定地址或模式
5. Gas 优化：调整交易顺序提升区块收益

封装阶段：

1. 应用 withdrawals
2. 执行 post-block 调用
3. 计算 state root hash
4. 打包完整区块

提交阶段：

1. 由私有 bidding 模块决定竞标价格
2. 提交到多个 MEV-Boost relay
3. extra_data 字段标注 BuilderNet (operator_id)，用于链上识别来源

v1.3 版本的主要优化：

• 仅提交到 regional relays，减少跨区网络时延（约 50ms）
• 支持 bundle cancellation
• p99 端到端延迟约下降 2 倍

• 为用户、钱包、应用、搜索者提供更透明的 MEV 处理方式
• 降低每笔交易的上链净成本
• 维持网络长期运行能力

1. BuilderNet 在 MEV-Boost 拍卖中竞争出块
2. 若区块价值更高但出价低于真实价值，会形成可分配差额（remainder）
3. 对通过 eth_sendBundle, mev_sendBundle, eth_sendPrivateTransaction 进入且最终上链的交易，回溯模拟其 contribution
4. 按 contribution 比例分配 remainder

补充说明：

• 这里的退款逻辑和 eth_sendBundle 自带的 refund 不是一回事

eth_sendBundle 退款参数示例：

refundPercent   // Integer: 1-99
refundRecipient // String: refund recipient address

为防止用多个身份拆分 bundle 套取更多退款，引入联合边际贡献约束。

给定：

• v(T) = 10 ETH
• c = 7 ETH
• μ_A = 1.5 ETH
• μ_B = 1 ETH

计算：

1. Remainder = v(T) - c = 3 ETH
2. Σμ_j = 1.5 + 1 = 2.5 ETH
3. 可分配金额 = min(3, 2.5) = 2.5 ETH
4. 退款结果：
   • φ_A = (1.5 / 2.5) * 2.5 = 1.5 ETH
   • φ_B = (1 / 2.5) * 2.5 = 1 ETH

在这个例子里，如果某参与者的边际贡献等于其支付，且 remainder 足够，其净支付可以接近 0。

数据查询入口：

• BuilderNet Dashboard
• Flashbots Protect Dashboard
• BuilderNet 相关 API（按官方开放范围）

退款地址与 ENS（示例）：

影响简述：

• 对 Validator：短期收益变化通常有限，长期可能有更多价值回流到 orderflow 提供方
• 对 Operator：后续规则预计会考虑节点运行成本补偿

使用 attested-get 验证节点身份：

go install github.com/flashbots/cvm-reverse-proxy/cmd/attested-get
attested-get \
  --addr=https://rpc.buildernet.org:7936/cert \
  --expected-measurements=https://measurements.buildernet.org \
  --out-response=builder-cert.pem

该过程会在 TLS 握手阶段校验 TEE measurement，再导出与特定 VM 镜像绑定的证书。

每个节点暴露 3535 端口运行 system-api，通常通过 HTTP Basic Auth + TLS 访问。

# 重启 rbuilder
curl --insecure --user admin:secret \
  https://ip:3535/api/v1/actions/rbuilder_restart

# 上传 blocklist
curl --insecure --user admin:secret \
  --data-binary "@blocklist.json" \
  https://ip:3535/api/v1/file-upload/rbuilder_blocklist

各运营商维护独立 blocklist，同一笔交易可能被 A 节点过滤、被 B 节点打包。

• rbuilder：区块构建引擎
• bidding service：竞价策略执行模块（私有分发）
• orderflow-proxy：交易接入、P2P 广播、归档转发
• system-api：节点运维接口
• HAProxy：流量分发与高可用
• Prometheus/Fluentbit：指标与日志采集

• Titan：中心化程度高，路径更短，延迟通常更低
• BuilderNet：多运营商共享订单流，强调透明性和抗垄断

1. 独家 orderflow：与头部钱包/机器人有更深合作
2. 延迟优势：中心化架构在极限时延下更占优
3. 中立叙事：强调不做 searching，吸引部分 bundle 流量

有公开材料提到，Titan 的链上交易费里有较高比例来自独家流量。

Titan 提供 titan_getBundleStats 查询接口，BuilderNet 目前没有完全对齐的公开能力。

curl -X POST -d '{"method":"titan_getBundleStats","params":[{"bundleHash":"0x..."}],"jsonrpc":"2.0","id":1}' \
  https://stats.titanbuilder.xyz

MEV-Boost 是 Flashbots 开发的开源中间件，用来实现 PoS 时代的 PBS。 Validator 通过 builder 市场获取更高价值区块，而不是完全自己构建。

公开统计常见口径是：当前绝大多数以太坊区块通过 MEV-Boost 路径产出。

• Searcher：构造可提取价值的 bundle
• Builder：组装候选区块并报价
• Relay：验证并托管区块，在拍卖中转发最高报价
• Validator：盲签名并最终广播区块

1. Validator 预先向 relay 注册
2. 到达 slot 后，Validator 请求最高报价区块头（不含完整交易）
3. Validator 进行盲签名
4. Relay 验证签名并返回完整区块
5. Validator 广播区块

盲签名设计的核心是：签名前看不到完整区块，降低 validator 抢跑或替换区块的空间。

1. 聚合多个 builder 的区块提交
2. 模拟验证区块有效性和支付约束
3. 在签名前隐藏完整区块内容
4. 在签名后释放并广播区块
5. 对外提供历史数据 API

部分 relay 采用 optimistic 模式换取更低时延：

• 先返回区块，再异步完成部分验证
• 若后续发现区块无效，builder 需承担对应惩罚

• builder 往往会并行提交到多个 relay，以提高中标概率
• 不同 relay 对敏感交易（如 OFAC 相关地址）策略不同
• Validator 可通过多 relay 连接和 min-bid 参数降低单点审查影响

Relay 是 PBS 的关键基础设施，但目前普遍缺乏直接收费机制，长期可持续性仍是行业问题。

流程：

1. bidding service 生成出价
2. 使用 relay 签名密钥完成签名
3. 并行提交到多个 MEV-Boost relay
4. extra_data 写入 BuilderNet (operator_id)

• 仅提交 regional relays，减少跨区链路耗时
• 支持 bundle cancellation
• p99 端到端延迟约优化 2 倍