LUCID：面向分布式载荷传播的加密 mempool——执行层研究

以太坊中文 发布于 2026-02-06 阅读 203

本文提出 LUCID：一种面向以太坊的加密 mempool 方案，试图把 inclusion list、加密交易、auditable builder bids 和分布式 payload 传播组合起来，缓解 proposer 交易选择垄断、MEV 泄露与网络重复传播问题。

概览

本文介绍了 LUCID，这是一种加密 mempool 设计，它弥合了 includer 和 proposer 之间的差距，同时遵循现有的 Ethereum 机制，例如 ePBS、BALs 和可审计的 builder bids（ABBs）。该设计用途广泛，例如可用于发送方无信任自我解密、由受信任方解密，或用于 threshold 设计。LUCID 是一个首字母缩写词，概括了其关键特性：

  • IL – 该设计依赖于由 fork-choice 强制执行的 inclusion lists（ILs），类似于 FOCIL，但进行了试验性修改，以赋予 includer 更公平的 inclusion 权利，以及用于 MEV 保护的加密能力。因此，includer 的行为更像 proposer。ILs 可以错峰，以提高 censorship resistance，促进去中心化 inclusion preconfirmations，并在不引入网络低效的情况下奖励 includer。
  • U – 考虑了两种 IL 设计选项：一种是针对 inclusion lists 的 U niform price auction（UPIL），根据发送方为 inclusion 提供的 fee 对交易排序；另一种是 U nconditional ILs（UILs），由 includer 决定自己列表中的优先顺序。
  • C – ILs 可以携带 sealed transactions（STs）中的 C iphertexts，这些交易在加密 mempool 中传播并可被打包。STs 会在 ABB 中被承诺。
  • D – payload 以 D istributed 方式传播，在 network representation 中仅包含对 IL 交易的引用。consensus representation 仍然是一个自包含的 execution payload，并包含用于从 ST 发送方扣费的 ST tickets 以及解密后的 STs。

本文描述的许多组件都可以单独采用，也可以组合采用。例如，可以仅运行加密方案而不采用 distributed payload propagation（DPP）；唯一的缺点是广播效率较差。LUCID 的时间线如下所示。

第 2 节向读者介绍该方案所要解决的问题，第 3 节则更深入地介绍加密设计。第 4 节介绍 DPP，第 5 节讨论该设计如何处理 reveal optionality。第 6 节最后给出简要讨论，其中第 6.1 节详细说明最低可行 EIP 可以如何构建。附录 A 通过提出 staggered inclusion lists（SIL）完善了 DPP 的愿景，其中 includer 在 slot 期间逐步构建 payload。附录 B 提出了一种更紧凑的设计，其中待解密的 STs 在 payload 中指定，而不是在 ABB 中指定。附录 C 最后展示了一种 decryptor 可以部署的解密方案。

时间线

图 1 展示了 LUCID 机制的概览。

图 1

图 1. LUCID 时间线。Builder 生成带有 sealed transactions 承诺的 ABBs。这些 ABBs 被包含在 beacon block 中，以便 decryptor 在下一个 slot 开始前及时释放 key。ILs 中列出的交易可以通过引用被包含进 payload。

  • T_1 之前 – Includer 传播 ILs，除了 plaintext transactions（PTs）之外，还可以包含 STs。STs 可以单独包含，也可以作为一个 bundle（深蓝色背景）包含，并且可以来源于公共加密 mempool。每个 ST 由一个签名过的 ST ticket 和 ciphertext encrypted_tx 组成，ST ticket 用于向发送方收费并绑定到某个 decryptor，ciphertext encrypted_tx 也包含在 ST 中。encrypted_tx 解密后得到一个签名过的 PT，该 PT 的 from 字段可以与 ST 不同，同时还包含一个 ToB_fee_per_gas，在解密后用于对 PT 的 top-of-block（ToB）排序。发送方按照 decryptor 在协议外说明的开放设计对交易进行加密（如果适用，则使用其公钥），或者也可以以无信任方式自行解密。附录 A 描述了如何错峰 ILs 以获得更好的覆盖率，附录 C 给出了 decryptor 可以部署的加密设计示例。
  • T_1 – slot n 的 attesters（紫色）冻结其对已传播 ILs 以及前一个 block 的解密 key 的视图。
  • T_1 之后 – 一旦 builder 确信自己已经观察到所有相关 ILs 和 key（即大多数 attesters 冻结视图中的那些），它们就会提交 ABBs（扩展的 ExecutionPayloadBid），以获得构建 block 的权利（蓝色矩形）。这些 ABBs 包含 ILs 中 STs 和 ST bundles 的哈希“ST-commitments”。ABB 还会标记前一个 slot 中观察到的解密 key。
  • T_2 – 在 slot n 开始时，proposer 选择一个获胜的 ABB，该 ABB 至少与其自身所见到的所需 ILs 和 key 的视图一样完整。它将该 ABB 包含在 beacon block 中。
  • T_2 之后 – 观察到 ABB 后，节点开始请求任何缺失的 ILs，以及由 ABB 的 ST-commitments 引用的 ST 字节。发送方和 decryptor 此时也可以独立传播这些字节。
  • T_3 – slot n 的 attesters 对链的当前 head 进行投票。如果 beacon block 缺失，或者其中包含的 ABB 因遗漏其冻结视图中的 ILs 或 key 而未通过审计，它们会指向在其视图中作为链 head 的前一个 block。如果 ABB 通过审计，它们就乐观地对该 block 进行 attest。
  • T_3 之后（Payload release） – Builder 释放 payload，其中还携带 ST tickets。最前面的交易（白色矩形）是已解密的 STs，它们先前已在 block n-1 中被承诺，并按其解密后的 ToB fee per gas 排序。随后是当前 slot 的常规 PTs（黑色矩形），由 builder 自由排序。Builder 通过 IL 中的索引引用 IL 交易，而不是重新传播它们（在 network representation 中使用一个单独的列表）。
  • T_3 之后（Payload reconstruction） – 每个客户端将 IL 交易引用与其本地缓存中的 ILs 以及 ST-commitments 进行解析，并组装完整 payload。它计算并验证 payload root，然后继续执行 payload。所包含的 ABB 为下一 slot 解密而选中的 STs，在 execution payload 中表现为一个 ST tickets 列表，这些 tickets 会按照其完整指定的 gas_limit 被收费。
  • T_3 之后（Key release） – 每个 decryptor 观察包含在 beacon block 中的 ABB 内的 ST-commitments。它确认 ABB 为其自身的 ST-commitment 提供了正确的数据（例如与其 gas_obligation 有关，指明其消耗多少 gas），所有 gas_obligation 条目的总和在下一 payload 允许的份额（ToB_gas_limit）之内，并且 beacon block 已被 attest。然后它传播签名过的 key(s)，以揭示能放入下一个 block 的 STs。这些 key(s) 会在 P2P 中泛洪，并在下一个 block 的 attesters 截止时间 T_5 之前被观察到。此后，payload n+1 的 ToB 就可以用已解密的 STs 按 ToB 排序构建。
  • T_4 – payload timeliness committee（PTC）对 payload 的及时性进行投票。鉴于 distributed 设计，到此时，携带 payload 中引用的交易或已承诺的完整 STs/ST-bundles 的 ILs 也必须已到达 PTC 成员，投票才能表明 payload 及时。
  • T_4 或 T_5 – 已释放 key 的截止时间可以通过 PTC 对其及时性的 bitfield 投票来强制执行，或者通过 slot n+1 的 attesters 冻结他们对已释放 key 的视图并使用 view-merge 来强制执行。Attesters 会在满足 PTC bitfield 投票或冻结 key 视图中的任一项的前提下，对下一个 ABB 进行投票。
  • T_5 之后 – 该过程沿用与 T_1 之后相同的轨迹（针对前一个 slot）。来自 slot n 的已解密 STs 被加入 ToB，按 ToB fee 排序并收取该 fee。鉴于这些 STs 在 block n 构建之前就已解密，该设计与 BALs 完全兼容：block n+1 的 builder 正常执行并准备 BAL。

引言

对于像 Ethereum 这样的去中心化区块链，一个令人担忧的问题是，单个 proposer 对每个 block 中交易 inclusion 所拥有的垄断，这可能导致 censorship 和次优的用户福利。因此，人们提出了具有多个并发 proposer（MCP）的设计（1、2、3、4）。围绕 inclusion lists（ILs）的多年研究（例如，1、2）也并行推进，最终形成了由 Fork-choice 强制执行的 inclusion lists（FOCIL）设计。通过 EIP-7805，FOCIL 已逐渐成为促进 Ethereum censorship resistance（CR）的主要选项，它允许多个 includer 传播应在下一 block 中被包含的交易 ILs。然而，当 block 已满时，proposer 仍然有权 censor 交易，即便这些交易愿意支付比实际被包含的交易更高的费用。此外，为了避免 MEV，很大一部分可被 censor 的交易必须私下传播，因此不能依赖 FOCIL 来实现 CR。

已经提出了多种 IL 设计，它们让 proposer 在控制 block 内容方面拥有更少的回旋余地。Unconditional ILs（UILs）要求所有列出的交易都必须被包含，只要它们满足常规 inclusion 条件。EIP-8046 引入了针对 inclusion lists 的 Uniform price auction（UPIL），它确保 proposer 在 block 已满时不再能忽视 ILs。交易会按其愿意支付的 fee 排名，愿意支付最高费用的交易会被包含，并且每笔都支付相同的统一块内 base fee，该费用会被销毁。这为 CR 提供了强保障，并且对时间敏感交易和多维 fee market 有益。不过，UILs 和 UPIL 仍不能阻止 MEV，因为交易仍然必须公开传播。

为了防止 MEV，交易必须保持隐藏，直到它们被承诺。人们已经提出了多种 encrypted mempool 设计，例如可能利用 proposer commitments 的 threshold encryption、如 Sealed transactions 中的 commit–reveal 方案，或者二者的 hybrid。Sealed transactions 在 ePBS 下可以利用 ABBs。在 fork-choice 强制执行下的 commit–reveal 方案，如 sealed transactions，还可以进一步支持广泛多样的链下加密方案——这是一种广义 sealed transactions 的形式。最近还提出了一种该方向的设计，但采用 same-slot 解密，形式包括一篇研究帖和一项 EIP。另一种策略是依赖smart-account encrypted mempools，这也已被提议作为一项 EIP。

关于去中心化区块构建的一个Hayekian 论点是，更广泛的参与者集合共同拥有构建一个好 block 所需的知识。值得指出的是，只有通过保护单个参与者对该 block 的贡献免受 MEV 影响，并保证 viable 交易的 inclusion，我们才能真正使他们能够以无信任的方式“传递”这种知识。

Inclusion lists 通常会引入数据冗余：交易先在 mempool 中 gossip，然后通过 IL gossip，最后又在 execution payload 内再次 gossip。若改为把 inclusion list gossip 视为“预填充”步骤，则 payload 可以在整个 slot 持续时间内被有效分发，而不是在结束时突发传播。因此，在单个 slot 窗口内，可以避免同一字节被传输两次（一次在 IL gossip 中，一次在 payload envelope 中）。减小 ExecutionPayloadEnvelope 的大小可以最小化传播延迟，从而允许更短的 slot 时间、更大的 ILs 或更大的 blocks。该设计与 payload chunking 兼容（1、2），后者只需在 DPP 下对已经在一定程度上压缩过的 payload 进行操作即可。

尽管 DPP 提高了网络效率，但它并未解决多个 IL 传播相同交易所造成的低效。理想情况下，应提出一种协议内解决方案来降低重叠，而本文为此提出了 staggered inclusion lists（附录 A），它还促进了无信任 preconfirmations。为了限制执行前必须协调的独立解密 key 数量，STs 在被承诺之前可以先进行 bundle。本文提出了 LUCID，它实现了广义 sealed transactions（在 1、2 的基础上扩展），同时将 includer 升级为既能保护交易免受 MEV 影响、又拥有与 proposer 平等的 blockspace 权利，从而弥合 includer 与 proposer 之间的差距。

加密设计

加密设计首先基于 UPIL 机制进行说明，而 UIL 机制所需的修改将在第 3.10 节中介绍。普通的 FOCIL（conditional ILs）也可以在这一通用设计下使用。需要强调的是，第 3-4 节中概述的若干特性，例如 DPP、UPIL 和 bundles，对于基础版 LUCID encrypted mempool 并非关键要素，正如第 6.1 节中进一步讨论的那样。

Sealed transactions

一个 sealed transaction（ST）由一个已签名的 ST ticket 和一个密文 encrypted_tx 组成。ST 具有以下字段：

  • from：签署 ST ticket 并支付费用，
  • 常规字段 nonce、gas_limit、max_fee_per_gas、max_priority_fee_per_gas、max_ranking_fee_per_gas，
  • 负责解密的实体的 decryptor_address，
  • 在执行已解密的 plaintext transaction 时支付的 decryptor_fee，前提是 from 账户中有足够资金，
  • reveal_commitment，其中 reveal_commitment = hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas))，用于将被揭示的 plaintext payload 绑定到一个特定的已付费 ticket，
  • ciphertext_hash，其中 ciphertext_hash = keccak256(encrypted_tx)，用于绑定密文的字节内容，
  • encrypted_tx，其解密结果为 RevealedTransaction(plaintext_tx, ToB_fee_per_gas)。

本着推动通用解决方案的思路，基础设想是协议只规定客户端如何解析和打开 encrypted_tx，而将 decryptor 使用哪种 key-escrow/hybrid encryption 构造留给其在协议之外自行定义。具体而言，encrypted_tx 是一个 envelope：

encrypted_tx = header_len:u16 || header || ct_dem
ct_dem       = nonce || aead_ciphertext

header 对协议来说是 opaque 的，可能包含恢复 DEM key 所需的任何 decryptor 特定元数据（例如 hybrid public key encryption（HPKE）/KEM encapsulation、threshold decryptor key 下的 threshold ciphertext 等）。Decryptor 会在协议外发布说明，描述发送方如何填充 header，以及对于给定 ticket 如何派生 DEM key k_dem。在 reveal 时，decryptor 只释放这个按 ticket 区分的 DEM keying material（k_dem），这样任何人都可以解密 ct_dem，并根据 reveal_commitment 验证 reveal。

Decryptor 应确保释放的 k_dem 在上下文中绑定到已付费 ticket（例如，通过使用 (chain_id, ticket.from, ticket.nonce) 的域分离编码作为 KDF 输入（如果使用 HPKE 则为 HPKE info）和/或 AEAD associated data 来派生）。这使得被揭示的 key 仅对应特定 ticket，因此，即使 header 字节被复制到其他 ticket 上，释放某个 ticket 的解密材料也无助于解密附加在其他 ticket 上的密文（任何从 header 中恢复出的长期 secret 都绝不能被揭示）。附录 C 给出了这种构造的一个示例（h/t Benedikt Wagner）。对于无信任的自我解密，发送方可以保持简单（例如，将 header_len = 0，并直接为每个 ticket 选择一个新的 DEM key）。

class RevealedTransaction(Container):
    plaintext_tx: Transaction  # Type 2 transaction
    ToB_fee_per_gas: uint64

class RevealCommitmentPreimage(Container):
    ticket_from: ExecutionAddress
    ticket_nonce: uint64
    plaintext_tx: Transaction
    ToB_fee_per_gas: uint64

class STTicket(Container):
    from: ExecutionAddress
    nonce: uint64
    gas_limit: uint64
    max_fee_per_gas: uint64
    max_priority_fee_per_gas: uint64
    max_ranking_fee_per_gas: uint64
    decryptor_address: ExecutionAddress
    decryptor_fee: uint64
    reveal_commitment: Bytes32
    ciphertext_hash: Bytes32
    signature: Bytes65        # 由 `from` 对 ticket 字段签名

class SealedTransaction(Container):
    ticket: STTicket
    encrypted_tx: ByteList[MAX_ENCRYPTED_TX_BYTES]

gas_limit 必须足以覆盖 encrypted_tx 字节大小对应的 calldata 成本，且受 MAX_TRANSACTION_GAS_LIMIT 约束，并会被全额收费——执行后即使观察到实际 gas 使用量，也不会退款。RevealedTransaction 中解密得到的 plaintext_tx 是一个 EIP‑1559（type 2）交易，其 max_priority_fee_per_gas = 0、max_fee_per_gas = 0（因为解密后的交易已经由 ST ticket 预付），并且 gas_limit = ticket.gas_limit。

ST ticket 的 nonce 复用 Ethereum 的普通账户 nonce，并且无论该密文之后是否被揭示，都会被消耗，因为 ST 无论执行是否成功都要收费。ST 发送方对 ST ticket 进行签名。签名是基于一个域分离 digest 计算的，该 digest 包含 chain_id（以及 fork/version）和 ticket 字段的 hash-tree-root（不包括 signature）。

encrypted_tx 中的 plaintext payload 由 plaintext sender 作为 plaintext_tx 的一部分单独签名。节点通过验证 ticket 签名并检查 ciphertext_hash 是否与 encrypted_tx 的哈希匹配，来验证一个 ST。

Sealed transactions 的 Bundle

Sealed transactions 会在 ABB 中被承诺。若 encrypted mempool 变得流行，大量独立的承诺和解密 key 可能会给网络带来压力，尤其是在 Ethereum 扩展时。因此，有理由限制 ABB 中对 STs 的承诺数量，同时仍然保持高吞吐量。因此，STs 可以被打包在一起并联合承诺。

一个 bundle 中的所有交易必须具有相同的 decryptor_address，并且该 bundle 必须由控制该 decryptor_address 的实体签名。bundle 可以携带完整的 STs，也可以仅包含哈希以及对这些哈希的签名。这使得由 includer 来重建完整的 ST bundle。鉴于这些内容必须在 PTC 截止时间前可用，要求 ILs 携带完整的 ST 字节似乎是合理的。如果在 beacon block 中被观察到时，引用该 bundle 的 IL 不可用，则必须通过 P2P 传播完整的 bundle。

能够包含未打包的 encrypted mempool 交易仍然有价值，原因有三点：

  1. 任何 ST 只要被包含在 IL 中都可执行，从而为公共 mempool 提供 spam resistance，
  2. 类似 threshold decryption 的设计可以在没有 sequencer 预先将交易打包的情况下运行，
  3. 用户无需为他们希望无信任解密的单个 ST 传播 bundle。

ST-commitments

Sealed transactions 会在 ABB 中的“ST-commitments”里被承诺，可以单独承诺，也可以作为来自公共 encrypted mempool 的 bundle 的一部分被承诺（或者也可能由协议外提供，届时可能借鉴类似 MEV boost 的设计）。Inclusion lists 为 ST-commitments 提供了重要的纳入路径——builder 必须遵守其所提议的承诺。每个 ST-commitment 指定四个字段：

class STCommitment(Container):
    bundle: bool             # 如果是 ST 则为 False，如果是 ST-bundle 则为 True
    commitment_root: Bytes32 # 如果是 ST，则为 ticket_root；如果是 bundle，则为 bundle_root
    decrypt: Bitfield        # 用于释放解密该 tx 的 key 的索引
    gas_obligation: uint64   # 所有 decrypt=1 条目的 gas_limit 之和

一个 ST-commitment 通过 commitment_root 来标识，它要么是已签名 ticket 的 SSZ hash-tree-root，即 ticket_root = hash_tree_root(STTicket)，要么是已签名 bundle 的 bundle_root，该 bundle_root 覆盖 bundle 中所有 ticket_root 条目。第 6.3 节讨论了一个可能的 scheduled_root，它针对的是 decrypt=1 的 ticket_root 条目。需要注意的是，ciphertext 字节通过 ciphertext_hash = keccak256(encrypted_tx) 与 ticket 绑定，而该字段包含在已签名 ticket 中。

分配额和 ToB gas limit

每个 IL 都有一份 ST-commitments 配额，初始时可以设置得相当低；例如，每个 IL 可以承诺 MAX_COMMITS_PER_IL = 4 个 ST-commitments。也可以允许 builder 进行自己的承诺，例如同样承诺 MAX_COMMITS_PER_IL 个 ST-commitments。不过，为了简化设计，最简单的做法可能是直接给 builder 分配一个独立的 IL。每个 IL 都有一个 max_bytes_per_inclusion_list 配额，就像 FOCIL 中一样。它会随着 gas limit 变化，以便在区块的 gas_limit 增加时，includer 相对于 proposer 不会处于不利地位。其计算方式为 max_bytes_per_inclusion_list = gas_limit/(IL_COMMITTEE_SIZE * GAS_PER_AGG_IL_BYTES)。当 GAS_PER_AGG_IL_BYTES = 2**9，且采用与 FOCIL 相同的 IL_COMMITTEE_SIZE = 16 时，在 gas limit 为 60M 的情况下，IL 的字节大小为 7.15 KiB。ST-commitments 仍然计入 max_bytes_per_inclusion_list。

每个区块都有一个用于已解密交易的 ToB_gas_limit，其值设为前一个区块总 gas_limit 的某个比例，暂定为 1/4 * gas_limit。此外还有一个 ToB_marginal_ranking_fee_per_gas，其计算方式为：取当前区块的 marginal_ranking_fee_per_gas（如 EIP-8046 所定义）与下一块中因超出 ToB_gas_limit 分配而被排除的最高排名 ST 的 ranking_fee_per_gas 两者中的较大值。

可审计 builder bids（ABBs）

Builder 为获得构建 payload 的权利而提交可审计 builder bids（ABBs）。ABB 通过加入 ToB_marginal_ranking_fee_per_gas、ST-commitments，以及一个用于表示前一个 block 中 ST-commitments 的 key adherence 的位字段，对 ExecutionPayloadBid 进行了扩展：

class ILCommitments(Container):
    IL_root: Bytes32
    commits: List[STCommitment, MAX_COMMITS_PER_IL]

class ILKeyAdherence(Container):
    key_adherence: List[Boolean, MAX_COMMITS_PER_IL]

class ABB(Container):
    ... # ExecutionPayloadBid 中已有的字段
    ToB_marginal_ranking_fee_per_gas: uint64
    IL_data: List[ILCommitments, IL_COMMITTEE_SIZE]
    key_adherence: List[ILKeyAdherence, IL_COMMITTEE_SIZE] # 每个前序 IL 对应一个 bitfield，构成 bitfield 列表

Builder 会使用 (ticket.from, ticket.nonce) 对 ST-commitments 中的 STs 去重。去重后的集合中，对于相同 (ticket.from, ticket.nonce) 的 ST，只能有一个进入 payload，且其 decrypt 位必须设为 1。所有其他具有相同 (ticket.from, ticket.nonce) 的 ST，其 decrypt 位都必须设为 0。此外，若某个 ST 会为 ticket.from 生成无效的 ticket-nonce 序列，或在 ticket 收费开始时不可收费（第 3.9 节），也会以同样的方式被移除。去重时采用确定性规则来决定保留哪个 ST：选择所在 bundle 中 ST 数量最多的那个实例；若出现平局，则按 IL 的 committee_index 决定。

如果某个特定的 ST-bundle 存在多个 IL commitment，则重复的 commitment 会将 decrypt 设为规范的零编码 0（单 bit 0）以节省空间，并且只保留来自 committee_index 最高的 IL 的 ST-bundle。为避免 malleability，当 decrypt 没有任何置位 bit 时，必须将其编码为恰好 0（单 bit 0），并且无论 bundle 长度如何，都将其解释为全零 mask；其他全零编码均为无效。

对于 bundle 内重复的 STs，它们共享相同的 decryptor_address，因此去重严格来说只是 decryptor 的记账问题。还要注意，builder 并不能随意设置 decrypt 位。slot n+1 的 attesters、builders（以及所有其他节点）将检查 decrypt 位是否严格按照确定性规则设置（例如用于去重），且没有遗漏由 IL 提交的有效 STs。如果 payload 未通过审计，协议将进入 invalid payload 下的恢复过程，如第 4.5 节所述。

最后，通过将 decrypt = 1，把去重后的 STs 纳入其中，前提是它们的 ranking_fee_per_gas 超过 ToB_marginal_ranking_fee_per_gas，并以 ticket_root 作为平局判定规则。在确定要包含哪些 STs 之后，每个 ST-commitment 的 gas_obligation 会被设置为该 commitment 中所有 decrypt = 1 条目的 gas_limit 之和。ToB_marginal_ranking_fee_per_gas 还可用于压缩 decrypt bitfield，使其仅覆盖 ranking_fee_per_gas 足够高的允许交易范围。

ABB 中的 commitment_root 允许 decryptor 在观察到及时的 beacon block 时识别该 ABB，并在 payload 发布之前释放解密 key。每个 IL_root 都被包含在 ABB 中，以便在 equivocation 情况下消除歧义，这一点将在第 4.3 节关于 DPP 的内容中进一步讨论。

有两种方法可以避免 builder 为每次 bid 都传播完整的 ABB。Builder 可以在每个新的 bid 中指定相对于前一次 bid 的 delta，并附带一个用于引用的哈希。可以预期，ST-commitments 会在 bid 截止时间之前很早就已建立，这意味着后续 bids 中的 delta 只需要覆盖 bid 值以及由晚到的 PTs 带来的 payload 变化。另一种方式是采用 pull-scheme，使 builder bids 保持轻量，而 proposer 在发布前从获胜的 builder 拉取 ABB。

Attestations

Attesters 将 ABB 与他们观察到的 ILs 进行比较。他们会验证：

  • 所有 gas_obligation 条目的总和在 ToB_gas_limit 以内；
  • 在给定已宣布的 ToB_marginal_ranking_fee_per_gas 的情况下，每个被及时观察到且不存在 equivocation 的 IL 都在 ABB 中被正确指定。

对于 Attesters 尚未观察到的 ABB 中的 inclusion lists，不会进行审查。节点在观察到这些 ILs 后会请求它们，而 PTC 最终将对它们的及时性进行投票。

Key release

Decryptor 观察随 beacon block n 一起传播的 ABB 中的 ToB_marginal_ranking_fee_per_gas 及其规定的 gas_obligation。它会验证 ToB_marginal_ranking_fee_per_gas 和 decrypt bitfield 确实为其自身的 ST-commitment 产生了指定的 gas_obligation，并且所有 gas_obligation 条目的总和在 ToB_gas_limit 之内。这是释放解密 key(s) 的前提。具体来说，如果 payload 随后被证明无效或不及时，decryptor 的 ST-commitment 始终会落在 ToB_gas_limit 之内。这意味着它们仍然可以在下一个有效 payload 中以 ToB 方式被包含，正如第 4.5 节进一步讨论的那样。

如果负责列出 ST（或 bundle）的 IL 不可用，decryptor 会在此时（如果之前还未这样做）广播完整的 ST 字节（或 bundle body），其 ticket_root/bundle_root 与 ABB 中的 commitment_root 匹配，这样节点就可以在 PTC 截止时间前验证已释放的 key(s)。当 decryptor（或任何人）提供了已承诺 ST 的完整 SealedTransaction 字节时，节点会检查 hash_tree_root(st.ticket) == commitment_root 且 keccak256(st.encrypted_tx) == st.ticket.ciphertext_hash。当 decryptor 确信 beacon block 将成为 canonical（例如在观察到其 attestations 之后）时，它会释放其 key(s)。

在 key release 时，decryptor 会按第 3.1 节所述发布对称 keying material。Key 会通过一条由 decryptor_address 签名的消息释放，该消息通过 committee_index 和 commit_index 标识相关的 ST-commitment，并进一步包含 slot 编号以及携带相关 ABB 的 beacon block 的 beacon_block_root。对于 bundle，key 会被封装在一个长度与 decrypt 位中置为 1 的数量相同的列表中，顺序与承诺的 bundle 中保持一致。

Key 消息会在 P2P 网络中泛洪。节点会转发任何格式良好、目标指向由 (beacon_block_root, slot) 标识的 ABB 中某个 commitment，且签名来自 ST-commitment 中指定的 decryptor_address 的 key 消息。如果 key 能够将已承诺 ciphertext 解密为 RevealedTransaction(plaintext_tx, ToB_fee_per_gas)，并满足 hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) == ticket.reveal_commitment，且解密出的 plaintext_tx 满足要求的固定字段（max_priority_fee_per_gas = 0、max_fee_per_gas = 0、gas_limit = ticket.gas_limit），则该 key 有效。解密后的 plaintext sender 和 nonce 不要求与 ST sender 的 from 和 nonce 相匹配。

针对相同 beacon_block_root、committee_index 和 commit_index 的 key，如果字节不完全相同，则属于 equivocation。发生 equivocation 的 key 的处理方式与 FOCIL 中的 IL equivocation 类似：节点会传播它们观察到的针对同一目标的前两个不同签名 key 消息，以表明存在 equivocation，而 builder 可以自由忽略 decryptor 发生 equivocation 的 STs。若 attesters 在其 attestation 截止时间前观察到了 equivocation 证据，则可以接受这种省略。

PTC vote

PTC 对与 payload 广播和 blob 数据相关的 DA 进行投票。为了满足 payload 的分布式传播要求（第 4 节），PTC vote 还涉及重建已承诺 ExecutionPayload 所需的所有数据的可用性：被引用的 plaintext transaction 字节（tx_reference）、被引用的 ST-commitments，以及这些 commitments 所引用的底层 ST/bundle 字节。

因此，builder 有责任确保其在 ABB 中注册的 ILs 在 PTC 投票时已经到达；但如果 ILs 不可用，decryptors 也可以独立传播相应的 ST 字节。关于这一主题的进一步讨论见第 4.3 节。在借助已存储的 ILs 重建 payload 后，PTC 成员会验证 payload 的 root 是否正确。他们也会通过投票确认 ABB 已被正确指定，这一点可以从 payload 中观察到。

可选地，每个 PTC 成员还会广播一个已签名的 bitfield，用于指示哪些计划在下一 slot 解密的 ST-commitments 在 key 截止时间前已观察到有效的 key 消息。该 bitfield 以调度 ABB 中 decrypt mask 非零的 ST-commitments 为索引，并按 (committee_index, commit_index) 的规范顺序排列（即按 committee_index 递增扫描 IL_data，再按 commit_index 递增扫描 commits[]）。使用 PTC vote 的原因在第 6.3 节中讨论。

builder 和 slot n+1 的 attesters 会根据 PTC vote 对及时性作出判断。为了合并视图，attesters 可以在 slot n+1 开始前冻结他们对 PTC votes 的视图。随后，当某个 key 获得例如 45%-55% 的 vote 时，builder 可能会按其视图来强制执行及时性（低于 45% 时，attesters 强制视为不及时；高于 55% 时，attesters 强制视为及时，前提是他们在投票截止时间前已亲自观察到该 key）。可选地，builder 还可以传播一个单独的结构，附带其观察到的 votes，以便合并视图。

Payment and inclusion

execution payload 的 consensus representation 扩展了 st_tickets 列表和 decrypted_transactions 列表（均在第 4.2 节中描述），用于对 STs 收费。

Charging ST tickets

st_tickets 中的每个 ST ticket 都会从 ticket.from 扣除 ticket.gas_limit * (base_fee_per_gas + ToB_marginal_ranking_fee_per_gas) + ticket.decryptor_fee，其中 ToB_marginal_ranking_fee_per_gas 取自其 ST-commitments 为该 ticket 安排调度的 ABB（即定义 pending set 的 ABB）。在 block n+1 中，不会根据实际 gas_used 退款；如果 ST 未被解密，则只退还 decryptor_fee。如果 st_tickets 中任何 ticket 无法被全额扣费，则该 block 无效。

节点通过将其与排名最高、可被有效包含但被排除在 ToB_gas_limit 之外的 ST 的 ranking_fee_per_gas 进行比较，来验证 ToB_marginal_ranking_fee_per_gas（见第 3.4 节）是否设置正确。由于 ST 是根据公开可见的 gas_limit 而不是实际使用的 gas 来收费，因此 commitment 时的可资助性检查是静态的，不依赖于其他交易的执行。这避免了 UPIL 排名机制中因需要进行保守余额检查而产生的循环依赖问题。

Including and charging decrypted STs

节点会观察 key 的释放，并在本地解密 ST 交易。block n+1 的 builder 会收集它能找到的所有 key，并生成一个 ABB，其中包含一个 bitfield，用于表示其所遵循的有效 key。Attesters 要求 builder 遵循所有及时且有效的 key，而其及时性通过前述的 view-merge 或 PTC vote 来确定。无法使用已释放 key 解密的 ST 会被忽略。

节点会根据生成该交易的具体 ST ticket 来验证每一笔解密后的 ToB 交易，验证时会用到完整的 ST 和相应的 key。只有当 hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) == ticket.reveal_commitment，且解密出的 plaintext_tx 满足要求的固定字段（max_priority_fee_per_gas = 0、max_fee_per_gas = 0、gas_limit = ticket.gas_limit）时，reveal 才是有效的。

处理 decrypted_transactions 的第一步，是向所有未被解密的 ST 退还 ticket.decryptor_fee。发送方通过 ticket_index 中缺失的索引来识别（第 4.2 节）。而 decrypted_transactions 中的 decryptor_fee 则记入相应的 ticket.decryptor_address。协议最后会从 ticket.from 中扣除并销毁 ToB fee ticket.gas_limit * ToB_fee_per_gas。如果 ticket.from 无法支付这笔费用，则该交易不会被包含。

对于提交多个 ST，且其解密后的 plaintext_tx 具有相同 from 并且 nonce 连续的用户，应确保 ToB_fee_per_gas 与 nonce 兼容，因为解密后的交易主要按照 ToB_fee_per_gas 排序，而执行仍然遵循每个发送方的 nonce 顺序。

Unconditional IL version

对于 unconditional IL 版本，需要进行若干修改，下面将详细说明。其思路是推进“Unconditional FOCIL”，遵循 FOCIL 的许多设计原则，但让每个 includer 的列表都是 unconditional。除了作为 LUCID 中加密 mempool 的一种可行路径之外，它在如 EIP-7999 的多维 fee market 下也可能有所帮助。除这里概述的内容外，关于 Unconditional FOCIL 的更多细节和分析将另行给出。

带 overflow 的 UIL

ToB_marginal_ranking_fee_per_gas 从 ABB 中移除。每个 IL 至少允许消耗 ST_gas_min_per_IL 的 ToB gas，该数值计算为 ST_gas_min_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE。IL 实际可以消耗的 ToB gas 取决于其他 IL 消耗了多少。max_bytes_per_inclusion_list 可以设置为使 IL 能够将 calldata 填充到 ST_gas_min_per_IL，或者更低。ST-commitments 的顺序，以及其次 bundle 中 STs 的顺序，定义了 IL 指定的优先级顺序。Builder 会逐步增加某个 IL 可以消耗的最大 gas，直到所有 gas_obligation 条目的总和超过 ToB_gas_limit，然后再降低该最大值以移除最后加入的交易。因此，gas_obligation 条目的（未去重）总和必须在 ToB_gas_limit 之内，和之前一样。

Attesters 会检查：在给定所有 gas_obligation 条目的最大值和已发布的 decrypt bits 时，每个及时观察到的 ST-commitment 是否都正确指定了 gas_obligation。每个 decryptor 也会针对自己的 commitment 验证这一点。他们会为 decrypt = 1 的交易释放 key(s)，使 ST gas limit 的总和等于 gas_obligation。

无 overflow 的 UIL

在无 overflow 的 unconditional IL 版本中，每个 IL 的 ToB gas 都限制为 ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE。由于这个上限对每个 IL 都是固定的，因此 ABB 中可以省略 gas_obligation 字段。由于 includer 仍然可能发生 equivocation，因此在 ABB 中保留 commitment_root 似乎是合理的。

UIL 与 UPIL 结合

另一种可行设计是让 IL 无条件包含 ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE，而额外的交易则按照 UPIL 纳入。此时，overhang 受 max_bytes_per_inclusion_list 限制。

Distributed payload propagation

payload 依赖于对预先 gossip 的交易数据和先前 ST-commitments 的引用，而不是在 payload 广播中重复交易字节。consensus representation 扩展了 st_tickets 和 decrypted_transactions（第 4.2 节），但常规的 transactions 列表仍然像当前的 execution payload 一样，是由完整交易字节组成的列表。通过 P2P 发送的 network representation 则有所不同，它被用作一种临时优化。

Network representation

引入一种轻量级的 payload 广播。除了携带那些不来自 inclusion lists 的交易的完整交易字节外，DistributedExecutionPayloadEnvelope 还包含一个指针列表，指向节点预计已经拥有（或能够从 canonical ILs 中获取）的交易。每个 ILTransactionPointer 还指定了 IL 交易在区块最终 transactions 列表（consensus representation）中的位置。

class ILTransactionPointer(Container):
    committee_index: uint8  # 0..IL_COMMITTEE_SIZE-1
    tx_index: uint16        # 该 committee_index 对应的 canonical IL body 中的索引
    position: uint32         # 最终完整 transactions 列表中的索引

payload 的 network representation 不引用 STs。builder 同时生成的 ABB 足以确定性地重建 ST-tickets 和已解密的 STs。具体而言，调度 ABB 中的 ST-commitments 及其由 builder 指定的 decrypt 位，标识了 payload 包含的 ST-tickets 及其顺序。同样，key_adherence bits 标识了应包含的已解密 STs，其顺序由 ToB fee 决定。关于 recovery 的更多细节见第 4.5 节。

因此，具体来说，DistributedExecutionPayloadEnvelope 会镜像 ExecutionPayload 的 header 字段（即重算 block_hash 所需的一切），但对来自 ILs 的交易依赖指针（ILTransactionPointer），并通过 ABBs 重建 ST-tickets 和已解密 STs。

Consensus representation

执行负载的共识表示扩展了两个额外的列表：st_tickets 和 decrypted_transactions。

st_tickets

st_tickets 是一个由已签名 ST ticket 组成的列表，它们会在区块处理开始时被扣费，并对应于一组待处理的 ST commitments（即尚未被收费的 commitments）。Builder 必须包含其在 ABB 的 ST-commitment 中设置 decrypt=1 的每一个 ST ticket。在 recovery（第 4.5 节）情况下，builder 只能包含与相关祖先 ABB 中待处理的 ST-commitments 相对应的 ST tickets；这些 commitments 具有 decrypt = 1，并且在确定性过滤（dedup、nonce 可行性、可收费性）后仍然保留。

st_tickets 列表具有规范顺序：它通过按递增的 committee_index 扫描调度 ABB 的 IL_data 构造，然后按递增的 commit_index 扫描 commits[]，并且（对于 bundles）按递增的 tx_index 扫描条目，将每个在确定性过滤后仍然保留的条目的 ST ticket 包含进去。

decrypted_transactions

decrypted_transactions 是一个已解密 ToB

Consensus representation 的属性

常规的 transactions 列表仍然与当前的 execution payload 格式一致，是由完整交易字节组成的列表。beacon block 包含一个 SignedExecutionPayloadBid，该 bid 会对完整 payload 作出承诺，尤其是通过其 block_hash，如 EIP-7732 所示。基于指针的 payload 格式仅作为一种临时的网络优化使用：节点在本地重建完整的 ExecutionPayload，计算并验证所得的 block_hash 是否与已承诺的 header 一致，然后 execution layer client 像往常一样执行并存储完整的交易数据。同步针对完整的 block 进行；指针永远不会成为 consensus object 的一部分。

ABB 中的 IL root 承诺，以防止 equivocation

Includer 可能会在区块构建前后传播多个 IL。Builder 可能只在承诺某个 payload 之前观察到其中一个 IL，并决定包含该 IL 中的交易。而网络上的节点可能观察到的是同一 includer 的另一个 IL，从而导致 builder 引用的究竟是哪一个 IL 出现歧义。因此，builder 通过在 ABB 中为每个 includer 包含一个 32 字节的 SSZ IL_root，来定义该 includer 唯一的“canonical” IL。具体来说，如果分布式 payload 通过 ILTransactionPointer(committee_index=i, ...) 引用了 committee member i 的任意交易，那么包含在 beacon block 中的 ABB 就必须为 i 包含一个非空的 IL_root。

如果 builder 没有观察到某个 includer 的 IL，它就会将对应的整个条目留空。如果愿意，它也可以包含那些它已观察到、但不会在区块中引用的 IL 的 root，以便在 reveal 之前混淆 payload 的内容；当然，也可以选择不这样做。

协议会要求节点即使在发生 equivocation 时，也始终转发 canonical IL（同时再附带一个额外的 IL 以表明存在 equivocation）。如果节点已经转发了来自同一 includer 的两个 IL，之后又得知第三个 IL 才是 canonical，那么它们在收到第三个 IL 时也会一并转发。Builder 在 bid 发布之后，如果观察到 equivocation，也会重新设定其 canonical IL。对于 includer 的 equivocation，仍然可以进行惩罚；而在 DPP 下，这样做似乎更为重要，因为 IL 的 DA 变得更加关键。

Payload reconstruction

复杂性封装在 CL client 中。工作流程如下：

  1. IL reception: CL client 通过 P2P 接收 ILs，并将其存储在以 IL_root 为键的本地缓存中。
  2. Payload reception: 它接收 SignedDistributedExecutionPayloadEnvelope，验证 builder 签名，并检查其 (slot, beacon_block_root, builder_index, block_hash) 是否与 beacon block 中承诺的 SignedExecutionPayloadBid 匹配。
  3. Resolution and reconstruction:
    • 客户端通过查找 beacon block 中 ABB 为 committee_index 指定的 canonical IL_root 来解析所有 ILTransactionPointer 条目，从缓存中获取对应的 IL（若缺失则发起请求），并读取 tx_index 处的完整交易。随后，它将这些交易与 envelope 中的完整 transactions 合并，把每笔 IL 交易插入最终列表中的唯一 position。
    • 客户端从调度 ABB（通常是当前 slot 的 ABB；在 recovery 下则是未收费的祖先 ABB）中确定性地构建 st_tickets。它按规范顺序扫描 IL_data → commits[] →（bundle tx_index），应用确定性过滤规则（dedup、nonce 可行性、可收费性），获取相应的 SealedTransaction 字节，并为每个保留下来的条目提取 ST ticket。
    • 客户端根据本 block 中到期应解密的 ST commitments，确定性地构建并排序 decrypted_transactions：正常情况下，这些是父 block 中已调度的 ST commitments；在 recovery 下，这可能包括来自最近的完整祖先和第一个空 block 的 commitments（第 4.5 节）。对于每个具有有效已释放 key 消息且 ABB 遵循该消息的 commitment，客户端会解密得到 RevealedTransaction(plaintext_tx, ToB_fee_per_gas)，识别对应的已收费 ticket t，并验证：hash_tree_root(RevealCommitmentPreimage(t.from, t.nonce, plaintext_tx, ToB_fee_per_gas)) == t.reveal_commitment。随后，它创建一个 decrypted_transactions 条目，其中包含 t 在 st_tickets 中的 ticket_index。最后，它按 ToB_fee_per_gas 递减排序，以 ticket_index 作为并列时的判定依据，并按该顺序应用逐笔可支付性检查（丢弃任何未通过检查的条目）。
  4. Verification: 客户端计算得到的 block_hash，并将其与 beacon block 中的 SignedExecutionPayloadBid 进行校验。
  5. Execution: 客户端将完整构造的 ExecutionPayload 传递给 engine API（engine_newPayload）。
  6. PTC vote: 节点会持续获取缺失的 ILs/ST 字节/keys，并在新数据到达时重试重建。PTC 成员只有在 T_4 时之前已完整重建 payload 并验证 block_hash 的情况下，才投票为“timely”；否则投票为“not timely”。

被拒绝 payload 下的 recovery

只要 beacon block 的 ABB 为其 ST-commitment 指定了正确的 gas_obligation 条目、所有 gas_obligation 条目的总和在 ToB_gas_limit 之内，并且其 ST-commitment 和解密 key(s) 可用，发送方就有权让其已解密交易被包含在下一个 block 中。然而，payload n 可能会在解密 key 已释放后被拒绝，而这并非发送方或 decryptor 的过错。在这种情况下，下一个 payload 必须同时包含原本为 payload n 调度的已解密 STs，以及在 slot n 中已释放 key、原本为 n+1 调度的 STs。

具体而言，一个 block 的已解密 STs 是指那些：

  • ST 字节和 key 均可用，
  • 被列在一个正确指定的 ABB 中，其中该 ABB
    • 不是当前 slot 的 ABB，
    • 其已解密 ST-commitments 尚未被包含上链。

因此，当一个 block 为空（没有 payload）时，下一个 payload 必须包含该空 block 本应包含的已解密 STs，以及该空 block 在 ABB 中承诺的、如今已解密的 STs。此时，recovery payload 不能再承诺新的 STs（如 Potuz 这里所建议），而必须改为通过 key_adherence bit 指示空 block 的 ST commitments 当前是否可用（字节+keys）。这些 bits 也会标记 ST tickets，而这些 tickets 在 recovery 过程中必须与已解密 STs 一起放入同一个 payload 中。如果某个 block 未能包含这些已解密 STs，从而使链完成恢复，那么它也必须被投为空，而再次执行恢复的责任将落到下一个 payload 上。

在 baseline 规范中，已解密 STs 最多分配到 gas limit 的 1/4。这确保了当一个 payload 丢失时，下一个 payload 可以包含两组已解密 STs，而它们最多只会消耗 block gas limit 的 1/2。

LUCID 中的 Reveal optionality

在 sealed transactions 的 commit–reveal 方案下，一个可能的问题是 reveal optionality。一些 STs 会被用来进行“backrun”，例如利用自前一个 block 以来 CEX 价格的变化。只有当 CEX 价格朝有利方向移动，使 PT 在 DEX 上的交易有利可图时，decryptor 才会揭示。然而，即便发送方不行使其 option，也仍然要为其交易支付完整的 gas limit，交易内容永远不会被执行，也不会计入它本应被包含的那个 block 的 gas limit，而且其内容（encrypted_tx）不会成为 chain history（consensus representation）的一部分。因此，寻求 optionality 的发送方几乎不会给协议带来负担。此外，由于 STs 只能通过 ILs 进入协议视野，因此可以对 STs 强制 timing constraints，正如第 5.2-3 节将讨论的那样。

还要注意，LUCID 防止了概率性 sandwich attacks：攻击者可能会尝试根据发送方持有的特定 token 等信息，推测其在交易中会做什么。发送方账户可以在 reveal-time 之前保持隐藏，因为 ST 的 sender 不需要与 PT 的 sender 是同一个账户。本节将回顾 LUCID 中 reveal optionality 的各个方面，包括它在设计上如何防止这种情况，以及可以做出哪些可能的扩展，以进一步缓解任何潜在担忧。

network representation 的有限范围

未执行的 sealed transactions 会支付全额费用，而资源消耗仅限于 network representation。考虑当发送方决定是否行使其 “ST option” 时会发生什么：

  • 如果 CEX 价格朝正确方向移动，decryptor 可以释放 key，使交易得以执行。此时其已支付的 base fee、ranking fee 和 ToB fee 都会被销毁。
  • 如果 CEX 价格没有朝正确方向移动，decryptor 可以扣留 key，使 plaintext_tx 不会被揭示。在这种情况下，ST ticket 在处理 block n 时就已经被收费。该交易不会在 block n+1 中执行，也不会消耗该区块中的 execution gas。ciphertext body（encrypted_tx）也永远不会进入 consensus payload：它只会在链下通过 gossip（经由 ILs 和/或独立的 P2P）传播。在链上，其占用的内容是 ABB 中的 ST-commitment，以及 st_tickets 中已收费的 ticket（不会有 decrypted_transactions 条目）。因此，ST 消耗的资源非常少，却为其未消耗的资源支付了全部费用。这笔支付会被销毁。本质上，LUCID 因此销毁了与通过未执行的 STs 进行套利/backrunning 相关的 MEV；这是一种概率性的 MEV burn。

commitment 时的 builder 优势

即使在 IL observation deadline 之后提交，发送方仍然可以依赖 slot n 的 builder 将其 ST-ticket 插入。因此，相比那些必须遵守截止时间才能保证 inclusion 的发送方，这些发送方具有优势（h/t Julian Ma）。这种时间优势体现在概率性套利上。由于在 slot n 之前或开始时承诺的 PT 只会在 block n+1 中执行，发送方无法对 block n 的 builder 已知的价值进行 backrun/arbitrage，也无法针对已在 block n-1 中承诺并在 block n 中执行的 ST 所对应的价值进行 backrun/arbitrage。相反，发送方可以构造一个期望值稍高的 option，然后可能在一个 slot 之后被行使。还要注意，block n 的 builder 可能会为了稳妥起见，遵守那些它同样是在 observation deadline 之后才首次观察到的 ILs。

Builder 还会带来另一种优势——它在为 block n+1 承诺 STs 时，就已经知道 block n 的内容。它精确知道 payload 中哪些套利机会被执行，以及它认定哪些 key 是 timely 的。由于这种优势同时体现在时间和信息上，我们可能会怀疑，slot n 中一些专注于概率性套利的 STs 会以某种形式通过 builder 进入，从而使这些 STs 成为 block n 的延伸。如果这被认为问题过大，可以考虑两个选项：

  • 可以强制实行统一的截止时间，要么通过 PTC，要么通过其他方式。目前正在与 Julian 一起推进此类设计，并研究相关选项。
  • 可以对未揭示的 ST-commitments 收取费用。第 5.4 节提出了这样一种设计。

key release 时的 builder 优势

view-merge 机制也可能在 key release 时赋予 block n+1 的 builder 一定优势——builder 可以让发送方在 key observation deadline 之后再决定是否行使其 option。因此，如果发送方通过观察其他已解密交易，或通过等到 deadline 之后再释放 key，能够获得收益，那么它们可以在为此类服务向 builder 支付费用后这样做。因此，PTC 可以如第 3.8 节所述，对 key 的及时性进行投票。这会形成一个所有 decryptor 都必须遵守的统一截止时间。

当然，通过观察其他交易获得的某些收益，也可能通过基于交易执行前状态（pre-state）设置条件来获得，例如 pre-swap DEX 的价格和流动性，这些信息可以在链上作为执行的第一步被观察到。主要问题在于，那些试图利用区块之间观测到的 CEX 价格变动获利的套利交易。由于发送方必须预先定义条件逻辑，因此它必须在并不确切知道哪些链上价格变动最适合作为交易条件的情况下这样做。

未揭示失败的潜在 fee

如第 5.2-3 节所述，可以约束 builder，使其不再对 STs 拥有 last-look 优势。第二种选择是通过对未能揭示收取费用，来阻止发送方主动寻求 reveal optionality。最简单的解决方案是在收取 st_ticket 费用时，从发送方额外预留一笔金额。在处理解密后的交易时，将同等金额退还给发送方。

由于 decryptor 和 sender 可以是不同实体，理想情况下应尽量减少双方之间的信任。只有当 ST 因格式错误而无法解密时，才是发送方的错；否则就是 decryptor 的错。如果协议能够判断交易 reveal 失败时究竟是哪一方应负责，就可以正确分配责任。然而，从密码学上让 decryptor 证明自己已经释放了正确的 key 并不简单，这超出了本文范围。一种简单的做法是：只要 decryptor 及时释放了格式正确的 key，就始终假定是发送方的错。另一种类似做法是给发送方一个窗口，在此期间它可以通过揭示自己的临时私钥来证明清白。如果发送方证明了清白，则费用由 decryptor 承担，否则由发送方承担。这将需要对协议进行进一步补充，并且缺点是发送方需要揭示其 plaintext 来证明清白。

要惩罚已注册的 decryptor，它应当有质押，并且只能承诺其 bonded capacity 允许范围内的 gas_obligation。不过，发送方始终必须能够扮演 decryptor 的角色以支持自我解密，因此仍然需要一条单独路径，使发送方像前面讨论的那样被预收费。

设置 reveal failure fee 有两种可行方法：

  1. decryptor 和/或 sender 可以指定它们愿意支付的 fee（按 gas 计），而交易的 ToB 顺序由其承诺的 fee 决定。其好处是，不会让那些只是想防范 sandwich attacks 的 transactors（也许是自我解密者），仅因尝试揭示 key 时可能遇到技术问题而承担支付 fee 的风险，从而给他们增加不必要的负担。
  2. 可以设置一个所有发送方在未能揭示时都必须支付的最低 fee，以抑制概率性套利（如果这符合预期）。可以将 (1) 与 (2) 结合，并保持 (2) 较小。最低 fee 可以设置为：(A) 常数，(B) 与 base fee 成比例，(C) 与 (1) 中发送方/decryptor 指定 fee 的时间平均值成比例，(D) 根据（按 gas 计的）时间平均 reveal failure rate 以及可能的 ToB_gas_limit 使用率自动调整。

在 (1) 中，发送方有动力承诺较高的 fee 以便被排到 ToB。因此，在对交易排序时，将 decryptor 承诺的 fee 和发送方可承诺的 fee（利用已建立的自我解密路径）结合起来是合理的。同样，如果 (2) 中的 decryptor 有能力设置其愿意被分配新 STs 的最高 fee，发送方就会希望有能力通过同一路径提高该 fee（以超过协议最低 fee）。

值得注意的是，一旦可以在 decryptor 和 sender 之间分配责任，也就可以改进 decryptor_fee 的记账。具体来说，如果发送方有错，协议仍然可以在 reveal failure 时向发送方收费并销毁 decryptor_fee。

讨论

模块化与路线图

LUCID 是一次大规模升级，但本文所描述的组件是模块化的。根据优先目标的不同，存在多条可行的采用路径。

总体方向

在本文提出的方案中，唯一的核心依赖是附录 A 中的 staggered inclusion lists 应在 UIL/UPIL 之后采用。否则，builder 会越来越倾向于填满 block，以移除被及时 includer 发现的交易。先采用 encrypted mempool，再让 payload 以分布式方式传播，似乎是合理的做法。注意，该设计仍然不会强制 consensus representation 携带那些解密失败的交易。当 key 未能及时揭示时，builder 只需将这些交易从 payload 中省略即可。因此，第 5 节讨论的保证仍然成立：未加密交易不会成为 chain history 的一部分，发送方仍然支付全额 gas limit，交易内容永远不会被执行，而且其 gas 不计入原本应被包含的那个 block 的 gas limit。

最低可行 EIP

LUCID 的最低可行 EIP 将省略 DPP（当然，对常规交易而言也是如此）、UPIL、SILs，并且可能省略 bundles。

采用无 overflow 的 UIL（第 3.10 节）仍然是可行的，并且可以清晰地区分 STs 和常规交易。由于 ToB_gas_limit 适用于下一个 block，STs 不会竞争相同的 blockspace。因此，每个 IL 都会获得一个 ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE 的配额，并且最多只能包含 MAX_COMMITS_PER_IL 个 ST-commitments，这个数值在初期应保持适中，例如 4。每个 IL 在字节大小方面也像往常一样受到限制。FOCIL 的常规事后检查无需关心 STs，并将按当前规范运行。

即使 block n+1 的 builder 会在 payload 中传播完整的 consensus representation，在 beacon block n 中对 STs 作出承诺后，仍然有必要能够及时且高效地传播这些 STs，以便它们到达下一个 builder。如果要通过 IL path 来传播这些 STs，节点需要在发生 equivocation 时确定 canonical IL。因此，在 ABB 中包含 IL_root 是有意义的。从技术上讲，仅有 ST-commitments 本身也可能已经足够，但加入 IL_root 不会显著增加大小。

虽然 bundles 非常有用，但它们对第一阶段并非关键。设置 MAX_COMMITS_PER_IL=4 时，在 16 个 IL 的情况下，每个 block 将产生 64 个 STs，这已经是相当可观的配额。在不包含 bundles 的设计中，ToB_gas_limit 可以设为一个相对适中的常数，因为 decryptors 将无法通过构建更大的 bundles 来轻易扩展。

因此，在首个 EIP 实现中可以简化设计，同时保留其核心属性。鉴于密码学设计仍是开放的，最初很可能会由简单的无信任自我解密 ux-flow 占据主导地位，而采用其他机制（例如 threshold decryption 或可信解密）的 decryptors 则会在之后逐步建立起来。

通过 DPP 扩展

采用 distributed payloads 后，通过 ILs 包含的交易在 builder reveal 的关键时刻所消耗的“即时带宽”显著少于标准交易。这一区别使一种理论上的“envelope allotment”成为可能，即 DistributedExecutionPayloadEnvelope 的字节大小可以与 gas limit 分开单独设限。这可能会激励通过预先 gossip 的 inclusion list 路径来包含交易，或者在即时传播带宽这一更稀缺的资源上，为非 inclusion-list 交易设定更高的 gas price。

在任何 ePBS 规范下，都存在一个最优的 PTC payload 截止时间，使扩展能力最大化，如 这里给出的 \text{PTC}_P^* 方程所示。这个截止时间必须在 payload 的传播需求和执行需求之间取得平衡。因此，开发 ePBS 的研究者已经考虑使用一种会随 block 中 calldata 数量变化的 payload 时效性截止时间。更大的 payload 会消耗更多 calldata，因此会被允许有更长的传播时间，因为它执行得更快。相反，更小的 payload 必须更早到达，以便下一个 block 的 proposer 有足够的执行时间。

这种可变的 PTC 截止时间也可以用于 DPP 下的扩展。依赖 IL 引用的 payload 更小，因此可以有更早的 PTC 截止时间。相应地，它们拥有更长的执行窗口。因此，可以通过提高 gas limit，使依赖 DPP 且具有更早 PTC 截止时间的 payload 能够消耗比以前更多的 gas。不过需要记住，交易仍然需要传播。区别在于，它们可以在更长的时间段内完成传播。就扩展而言，还可以注意到，节点在查看 key_adherence 字段后，可能就可以开始执行已解密的 ToB 交易，因为它们的排序由 ToB fee（或第 5.4 节中讨论的 fee）以确定性的方式决定。

在主观标准下对 STs 收费

依赖及时 key release 的 encrypted mempool 必然会引入主观的 enforcement surface：即使发送方没有任何过错，交易也可能在未执行的情况下被收费，仅仅因为 attesters 和 builder 合谋忽略了及时释放的 key。这一点值得注意，因为依赖 encrypted mempool 的发送方将不再对其交易拥有更强的有效性保证。

此外，ABB 中承诺的 bundle_root 可能不足以仅凭链上数据客观验证某个被收费的 ticket 是否确实属于所承诺的 bundle，因为 bundle 中的某些条目可能不会成为 consensus representation 的一部分（decrypt=0）。不过，由于及时性本身就是主观的，bundle_root 严格来说只是用于让 decryptor 在观察到 beacon block 后直接释放其 key，而不必等待 payload。Bundle 也可以包含一个 scheduled_root，它针对的是 decrypt=1 的 ticket_root 条目。这可以证明 payload 中包含的 ST tickets 确实是在 ABB 中被调度的。然而，由于及时性检查本身仍然是主观的，发送方本来也需要信任 builder 和 attesters，因此这是否能改进设计并不明确。

附录 A – 错峰 inclusion lists

A.1 概览

LUCID 赋予 includer 对区块内容的实质性控制。因此，为这一角色规定一种补偿模型是明智的。否则就存在一种风险（任何 IL 设计都是如此），即协议参与者会回退到协议外的 inclusion fee，这可能成为中心化的诱因。这里提出的协议内奖励方案是 Staggered inclusion lists（SIL）：每个 IL 都有一个略微错开的 deadline，当多个 IL 提交了相同交易时，deadline 最早的 IL 会获得奖励。这种时间上的分布激励了更广泛的覆盖以及交易的即时纳入。

A.2 先前设计

一种 baseline 方法是 individual distribution，即所有展示某笔交易的 includer 共享该交易支付的奖励。然而，这会导致不必要的网络开销，因为如果一笔交易支付的奖励足够高，includer 往往会展示同一笔交易。关于其他方法的讨论见 这里，例如：

  • collective distribution，即向所有 includer 发放奖励，不论其是否展示了该 ST。该方法的优点是能带来广泛覆盖。然而，鉴于 includer 无论贡献如何都会获得同样奖励，因此它并不特别公平，也不具备激励相容性。
  • waterfall distribution，即通过交易哈希将 includer 分配给某些交易，并根据分配的优先级顺序进行奖励。然而，includer 没有动力提前沟通他们会选择哪些交易，而且与 baseline 方法相同的问题仍会再次出现，只是处于更复杂的情境中。
  • keyed distribution，即发送方将奖励关联到某个 validator ID（或在某个 collective ID 下注册的多个 validator）。这使发送方可以使用协议内奖励，同时有能力将其指向他们希望优先考虑的任何 includer。

A.3 Redirecting the priority fee

当 includer 在 UPIL 或 UIL 中公开一笔交易时，priority fee 的作用就没那么大了。对于 STs，ToB 排序由 ToB_fee 决定，而完整 ToBs 的包含则由 ToB_marginal_ranking_fee_per_gas 决定。常规交易可以由 builder 排序，builder 仍可能更倾向于将支付更高 priority fee 的交易排在前面，以激励发送方支付更高的 fee。然而，priority fee 并不决定交易是否被包含；交易是否被包含由 marginal_ranking_fee_per_gas（UPIL）或 UIL 的规则决定，即交易必须被无条件包含。因此，当 includer 公开一笔交易时，将 priority fee 重定向给 includer，而不是引入新的 includer_fee，似乎也是可行的。不过，这里有一个细微之处：SILs 只允许 includer 提供“inclusion preconfirmations”，而 proposer 在 key 已披露后的短暂窗口期内则可以提供“execution preconfirmations”。以下文字将使用“includer fee”这一说法，至于它究竟是指交易被 IL 公开时重定向的 priority fee，还是专门设立的 includer fee，则暂不作限定。

A.4 错峰 inclusion list 设计

第 4 节中的 DPP 提高了网络效率。然而，它并未解决多个 IL 传播相同交易所带来的低效问题。可以预期它们会这样做，尤其是在所有 includer 都共享交易提供的奖励时。理想情况下，应提出一种协议内解决方案，以减少重叠、实现广泛覆盖，同时奖励 includer 的工作。事实证明，存在一种具体方案能够同时满足这两个目标，并且还提供一种去中心化 pre-confirmations 形式：Staggered inclusion lists（SIL）。

该设计如图 2 所示。Includer 在 slot 期间被分配错开的 deadline。如果两个 IL 都传播了同一笔交易，那么 deadline 更早的 IL 将获得发送方支付的全部 includer fee。因此，随着 slot 推进，includer 会迭代地构建 payload，但没有动力重新包含那些已经被传播的交易。Staggered inclusion lists 可以理解为一种_时间上的_ waterfall distribution scheme——它不是将 includer 分配到不同交易，而是将它们分配到不同 deadline。对 block 分片 proposer 进行错峰的设想在 Ethereum 早期就曾讨论过（1、2、3）。

图 2

图 2. 错峰 inclusion list 设计。PTC 观察 IL 的错峰 deadlines，并最终就它们的及时性进行投票。Includer 快速检测 censorship，并包含 mempool 中新出现的交易。黑色的 ST 在被第四个 IL 收录之前，曾被 censor 三次。

例如，一个 6 秒的 slot 可以分配给 8 个 includer，使每个 includer 之间相隔 0.5 秒。第一个 IL 的 deadline 是 slot 开始后 0.5 秒，最后一个 deadline 是 slot 开始后 4 秒，从而为传播 timeliness votes 留出一些时间。Deadline 顺序以随机方式设置，例如按 committee_index。该设计对发送方似乎很有吸引力——由于错峰 deadlines，他们通常会在 IL 中几乎立即获得无需信任的 inclusion。鉴于本文提出的 UPIL 和 UIL 的强保证，他们因此可以很快相当确定交易会被包含，这是一种无需信任的 inclusion preconfirmation 形式。

一旦最后一个 includer 的 deadline 过去，PTC 成员（或者，如果它独立运行，更准确的名称应为 inclusion list timeliness committee，ILTC）会对已观察到的 incoming ILs 通过传播一个长度为 IL_COMMITTEE_SIZE 的 bitfield 来投票表示及时性。在该 bitfield 中，每个 PTC 成员会依据其本地视图，针对每个 IL 声明该 IL 是否满足其各自的 deadline。下一个 slot 的 builder 必须遵守所有在 attesters 冻结其视图之前到达的 IL，即便它们是在各自的 PTC deadline 之后到达；但奖励则根据 PTC 的投票进行分配。

Builder 收集 PTC votes 并将其包含在 block 中，以在 attesters 的观察下确定 includer 奖励。任何获得超过例如 1/3 及时性支持票的 IL，只要没有 deadline 更早且同样获得超过 1/3 支持票的 IL 也传播了相同交易，就可以从其传播的交易中获得 includer fee。如果某笔交易未被任何达到 1/3 阈值的 IL 认领，则 includer fee 归 builder 所有。

A.5 Timing

值得注意的是，连接良好的 includer 会占据优势；位于更多交易发起地区的 includer 也同样如此。这些 includer 可以在更接近其 deadline 的时间发布 IL，并且平均而言会更早看到交易。另一方面，includer 往往会最早看到从其所在地区传播出来的交易，即便该地区通常发起的交易较少。假设 validator 和 sender 的分布是共变的，那么公共 orderflow 的 inclusion 竞争在那些也发起更多交易的地区往往会更加激烈。这并不能完全抵消某些地理位置的优势，但至少会有所缓和。

无论哪种情况，validator 更靠近 transactor 在整体上都可以说是一种益处。连续 includer 的 deadline 之间的时间 \Delta，将影响地理位置对 validator 之间 includer fee 分配的作用。这里的另一个方面是，ILs 是否有足够的空间来包含某一时刻可用的所有交易。可以将 SILs 与 keyed distribution 结合起来。这对于依赖 private orderflow 的 includer 尤其有价值，因为发送方会直接向特定 includer 提交 STs，并希望在不被稀释的情况下对其进行补偿。这样一来，这些 includer 就不必担心被连接良好的竞争 includer “front-run”。

一个连接不太好的 includer，deadline 为 d+\Delta，可能会在截止时间前以更大的提前量 \delta 发布其 ILs，将 release 设为 d+\Delta - \delta，以便 IL 能在 d+\Delta 之前传播。如果 \delta > \Delta，一个连接良好的、deadline 为 d 的 includer 就可以观察到该 IL，并通过位于 P2P 图中多个关键位置的若干节点传播自己的 IL，以赶在自己更早的 deadline 之前完成发布。如果未纳入 keyed distribution，那么在调整 \Delta 时，合理的做法是将合理的 \delta 一并纳入考虑，以避免这种 back-running。

A.6 Censorship resistance

错峰 inclusion lists 提高了 censorship resistance（CR）。Validator 在做 inclusion 决策时，会知道同一 slot 中更早的 validator 的决定，并将自己的决定传递给更晚的 validator。这提高了所提供的 CR 水平，无论是对于最大化奖励的 includer，还是对于希望通过发现被 censor 的交易来最大化 CR 的 includer：

  • 一个严格专注于最大化奖励的 validator，可以选择 censor 一笔交易，或者获得全部 includer fee。对这种 includer 进行贿赂所需的成本，高于 includer fee 在 includer 之间分摊，或 fee 的分配对象不确定时的情况。当 includer 事先不知道其他 includer 会如何行动时，预期 fee 总会低于标价 fee，因此所需的贿赂也更低。
  • 一个严格专注于发现被 censor 的交易的 validator，可以通过观察其他 includer 忽略 mempool 中某笔交易，获得关于哪些交易被 censor 的信息。当 includer 事先不知道其他 includer 在 slot 结束时会如何行动时，由于随机性，某些交易会被很多 includer 发现，而另一些则根本不会被发现。当 includer 观察到错峰 ILs 时，它可以立即识别出 censorship，从而发现被 censor 的交易。稍微简化一点，这会将那些专注于阻止 censorship 的 validator 的 inclusion 时间，从大约 2-3 个 slots（例如，取决于 slot 时间，为 12s-36s）缩短到 2-3 \Delta（即，取决于 \Delta 的设置，为 0.5s-1.5s）。

附录 B – 紧凑调度的 LUCID

B.1 概览

在 ABB 中包含 batch roots 的一个好处，是为释放解密 key 留出了较长的时间窗口。这对于依赖无信任设计但连接不佳的发送方，或具有通信开销的 threshold decryption scheme，尤其有吸引力。另一种规范则不依赖 ABB。所有 decryptor 直接在 payload 中观察已被包含的 encrypted transactions。

此时，解密 key 必须在 payload 截止时间和 key 截止时间之间更短的时间窗口内释放。该设计的好处是 ABB 更轻量，只包含 IL roots，从而便于 DPP。如果 DPP 也被省略，则 ABB 不是必需的。在 T_3 之后立即发布的早期 payload 允许 decryptor 立刻释放其 key，这不是问题。复杂之处在于如何处理晚到的 payload，尤其是接近 T_4 的 payload。Decryptor 必须能够快速释放 key，但这样做时又会因信息不足而无法判断 payload 是否会成为 canonical。

关键洞见是：payload 可以被视为 STs 的一种特殊 IL，slot n+1 的 builder 必须遵守它，即便 PTC 对其投反对票。这样一来，decryptor 在决定是释放还是扣留 key 时就有了一些余量。可以通过两种方式实现：

  1. Decryptor 依赖释放时间。若 payload 足够早，足以保证在 IL deadline T_5 之前到达 attesters，则无论 payload 是否会在 payload deadline 前到达足够比例的 PTC，它都始终可以释放其解密 key（因为此时 payload 将成为一个无条件 IL）。
  2. PTC 可以尽可能早地对 payload 的及时性进行投票（在对 blob 的及时性投票之前）。Decryptor 可以统计 PTC votes，并在其释放决策中获得一些额外余量，从而使晚到的 votes 不会诱使 decryptor 为一个不会成为 canonical 的 ST 释放 key，或对一个会被有效 block 接受的 ST 扣留 key。

下面将进一步考察这两个选项。

B.2 通过 timing 确定 payload 的 IL status

在观察到 payload 后，decryptor 会确认它与 beacon block 中承诺的哈希匹配且格式正确。它还会观察到 beacon block 已获得足够的 attestations。如果 payload 未能成为 canonical，但在 attesters 于 T_5 冻结视图之前到达它们，则会被视为一种特殊的 IL。payload 中的所有 STs 都必须由 block n+1 的 builder 按 ToB 包含，前提是相应的解密 key 也在 T_5 前到达 attesters。如果某个解密 key 在 attesters 冻结视图之前未到达，则 builder 可以自由忽略相应的 ST。只有当 payload 成为 canonical，而 decryptor 又未在 T_5 前释放 key 时，block n+1 的 builder 才可以忽略那些仍需根据 gas_limit 为已消耗 gas 付费的 STs 的 key。

因此，decryptor 可以对在 T_4 和 T_5 之间到达的 payload 选择释放或扣留 key。Builder 可能会希望谨慎行事，也遵守在 T_5 之后到达的 key，以确保其 block 成为 canonical。这为 decryptor 在 key release timing 上提供了一些额外的概率性余量（但并不保证）。

如果 payload 足够早，能够保证在 T_5 之前到达 attesters，那么无论它是否会在 T_4 前到达足够比例的 PTC，都始终可以释放其解密 key。

B.3 通过统计 PTC 投票确定 payload 的 IL 状态

PTC 会尽可能早地对 payload 的 timeliness 进行投票，然后再对 blob 的 timeliness 进行投票。Decryptor 收集这些投票，以判断 payload 是否会被视为 timely。它在作出决定时有一定的误差空间，在这个范围内，它可以自行决定是否释放 key。理想情况下，应该将这种 optionality 限制为单一结果，使 decryptor 要么在 payload 被视为 timely 时必须释放 key，要么在 payload 被视为 untimely 时必须扣留 key。基于这一设定，如果要求达到 50% 的阈值才将 payload 视为 timely，那么可以给 decryptor 一个例如 30%-50% 或 50%-70% 的 optionality 范围。

在第一种情况下（30%-50% 的 optionality 范围），只要 payload 是 timely，decryptor 就必须释放 key。如果 key 没有被释放，STs 仍然会按照其 gas_limit 被全额收费。如果有 30%-50% 的 PTC 投票支持 payload，则它会作为一种特殊的 IL。若 key 在 attester 冻结截止时间 T_5 时已经可用，其中包含的 STs 必须在下一个 payload 中以解密后的 ToB 形式被包含。

在第二种情况下（50%-70% 的 optionality 范围），只要 payload 是 untimely，decryptor 就必须扣留 key。如果在少于 50% 的 PTC 投票支持 payload 时释放了 key，就可能有人抢跑该解密交易。如果有 50%-70% 的 PTC 投票支持 payload，则缺少 key 的 STs 不会被收费，而已提供 key 的 STs 会像平常一样以 ToB 形式被包含在 block n+1 中。

附录 C – KEM‑DEM hybrid encryption

下面给出一个草稿性的思路（h/t Benedikt Wagner），展示了一种使用 KEM‑DEM hybrid encryption 的加密方案，decryptor 可在 LUCID 中部署该方案。它说明了 decryptor 如何构造第 3.1 节中的 encrypted_tx = header_len || header || ct_dem envelope。

令 KEM 为任意 CCA2 安全的 KEM（例如基于椭圆曲线或格的方案）。令 H 为一个 random oracle。令 SKE 为任意 CCA2 安全的对称加密方案（例如生成 ct_dem = nonce || aead_ciphertext 的 AEAD 风格方案）。为了派生 encrypted_tx，计算：

  • (ct_KEM, kemkey) := KEM.Encaps(pk)
  • k_dem := H(id, kemkey)
  • ct_dem := SKE.Enc(k_dem, m)

这里 id 至少包含 (chain_id, ticket.from, ticket.nonce) 这些字段。设 header = ct_KEM，header_len = len(header)，并将 encrypted_tx 编码为 header_len:u16 || header || ct_dem。

要解密一个与正确签名的 ticket 关联的 encrypted_tx，decryptor 计算 kemkey := Decaps(sk, header)，并公开 k_dem := H(id, kemkey)。

如果不伪造 ticket 签名，就无法修改一个已经签名的 ticket 的 ct_dem（因为 ticket 承诺了 ciphertext_hash = keccak256(encrypted_tx)）。如果将同一个 header 复制到另一个 ticket 中，ticket 的上下文就会变为不同的 id'；根据 KEM 的安全性和 random oracle，已发布的 k' = H(id', kemkey) 不会泄露关于 k = H(id, kemkey) 的任何信息。

  • 原文链接： ethresear.ch/t/lucid-enc...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
微信扫码分享

相关文章

0 条评论

登录后发表评论