LUCID：具有分佈式有效載荷傳播功能的加密內存池

avatar
Ethereum Research
02-05
本文為機器翻譯
展示原文

作者：安德斯·埃洛森

感謝Julian Ma 、 Benedikt Wagner和Justin Florentine的反饋和審閱。還要感謝參加一月初柏林會議的各位成員，他們在會上討論了設計的某些特性： Julian 、 Thomas 、 Justin 、 Vitalik 、 Caspar 、 Marios 、 Ansgar和Francesco 。

1. 概述

本文介紹 LUCID，一種加密內存池設計，它彌合了包含者和提議者之間的鴻溝，同時遵循現有的以太坊機制，例如ePBS 、 BAL和可審計的構建者出價 ( ABB )。該設計用途廣泛，例如可用於發送者無需信任的自解密、受信任方解密或閾值設計。LUCID 是一個首字母縮寫詞，概括了其關鍵特性：

  • IL——該設計依賴於分叉選擇強制執行的包含列表（IL），類似於FOCIL，但經過初步修改，賦予包含者更公平的包含權以及用於MEV保護的加密功能。因此，包含者的行為更類似於提議者。IL可以錯開執行，以提高抗審查性，促進去中心化的包含預確認，並在不造成網絡效率損失的情況下獎勵包含者。
  • U – 考慮兩種 IL 設計方案：統一價格拍賣包含列表 ( UPIL )，根據發送方提供的包含費用對交易進行排名；無條件IL (UIL)，其中包含方決定其自身列表的優先級順序。
  • C – IL 可以攜帶C密文，這些密文以密封交易 (ST) 的形式存在於加密的內存池中，並且可以捆綁在一起。ST 在 ABB 中提交。
  • D – 有效載荷以D分佈式方式傳播，並且僅包含對網絡表示中 IL 交易的引用。共識表示仍然是一個獨立的執行有效載荷，包括用於從 ST 發送者扣款的 ST 票據以及解密的 ST。

本文中描述的許多組件可以單獨使用，也可以組合使用。例如，可以只運行加密方案，而不使用分佈式有效載荷傳播（DPP）；唯一的缺點是廣播效率會降低。LUCID 的時間表如下所示。

第 2 節向讀者介紹所要解決的問題，第 3 節深入探討加密設計。第 4 節介紹 DPP，第 5 節討論設計中如何處理揭示選項。第 6 節最後進行簡要討論，其中 6.1 節詳細說明了如何構建最小可行 EIP。附錄 A 通過提出交錯包含列表 (SIL) 完善了 DPP 的願景，其中包含器在時隙內逐步構建有效載荷。附錄 B 提出了一種更嚴格的設計，其中待解密的 ST 在有效載荷中指定，而不是在 ABB 中指定。附錄 C 最後展示瞭解密器可以部署的一種解密方案。

時間線

圖 1 提供了 LUCID 機制的概述。

圖 1
圖 1 1920×1391 167 KB

圖 1. LUCID 時間線。構建者生成包含密封交易承諾的 ABB。這些 ABB 包含在信標塊中，以便解密者能夠在下一個時隙開始之前及時釋放密鑰。IL 中列出的交易可以通過引用包含在有效載荷中。

  • 在T_1 T 1之前——包含器會傳播 IL，除了明文交易 (PT) 之外，IL 還可以包含 ST。ST 可以單獨包含，也可以捆綁在一起（深藍色背景），並且可以從公共加密內存池中獲取。每個 ST 都包含一個簽名的 ST 票據，用於向發送方收費並綁定到解密器，以及包含在 ST 中的密文encrypted_tx encrypted_tx後會生成一個簽名的 PT，該 PT 的from字段可以與 ST 不同，並且還包含一個ToB_fee_per_gas字段，該字段用於在解密後將 PT 排序到區塊頂部 (ToB)。發送方按照解密器的非協議指令（如果適用，則使用其公鑰）以開放設計加密交易發送給解密器，或者也可以自行解密，無需信任。附錄 A 描述瞭如何交錯部署 IL 以實現更好的覆蓋範圍，附錄 C 給出瞭解密器可以部署的一個加密設計示例。
  • T_1 T 1 – 槽位n的證明者（紫色）凍結其對傳播的 IL 以及前一個塊的解密密鑰的視圖。
  • 在T_1 T 1之後——一旦構建者確信他們已經觀察到所有相關的 IL 和密鑰（大多數驗證者凍結視圖中的那些），他們就會拋出ABB （擴展的ExecutionPayloadBid ），以獲得構建該區塊的權限（藍色矩形）。這些 ABB 包含 IL 中 ST 和 ST 包的哈希值的“ST 承諾”。ABB 還會標記來自前一個槽位的已觀察到的解密密鑰。
  • T_2 T 2 – 在時隙n n開始時，提議者選擇一個獲勝的 ABB，該 ABB 至少與其自身對所需 IL 和密鑰的理解一樣全面。它將該 ABB 包含在信標塊中。
  • T_2之後——在觀測到 ABB 後，節點開始請求任何缺失的 IL 以及 ABB 的 ST 承諾中引用的 ST 字節。發送方和解密方現在也可以獨立地傳播這些字節。
  • T_3 T 3 – 槽位n的驗證者對當前鏈頭進行投票。如果信標區塊缺失，或者由於凍結視圖中缺少 IL 或密鑰，導致包含的 ABB 審核失敗，則他們會指出其視圖中鏈頭所在的前一個區塊。如果 ABB 通過審核，則他們會樂觀地驗證該區塊。
  • T_3 T 3 （有效載荷釋放）之後——構建者釋放有效載荷，其中也包含 ST 票據。第一批交易（白色矩形框）是解密的 ST，之前已在區塊n-1中提交，並按其解密後的每 gas ToB 費用排序。接下來是來自當前時隙的常規 PT（黑色矩形框），由構建者自由排序。構建者通過索引引用 IL 交易，而不是重新傳播它們（在網絡表示中使用單獨的列表）。
  • T_3 T 3 （有效載荷重構）之後——每個客戶端根據其本地緩存的 IL 事務引用以及 ST 承諾來解析 IL 事務引用，並組裝完整的有效載荷。它計算並驗證有效載荷根，然後執行有效載荷。由包含的 ABB 選擇的用於下一時隙解密的 ST 在執行有效載荷中以 ST 票據列表的形式表示，這些票據根據其指定的完整gas_limit進行計費。
  • 在T_3 （密鑰釋放）之後，每個解密器都會觀察信標塊中包含的 ABB 中的 ST 承諾。它會確認 ABB 擁有其自身 ST 承諾的正確數據（例如，與其gas_obligation相關的數據，該 gas_obligation 指定其消耗的 gas 量），所有gas_obligation條目的總和是否在下一個有效載荷的分配份額（ ToB_gas_limit ）之內，以及信標塊是否已被驗證。它會傳播用於揭示下一個區塊中 ST 的簽名密鑰。這些密鑰會在T_5截止時間之前通過 P2P 泛洪傳播，並被下一個區塊的驗證者觀察。然後，就可以使用解密後的 ST 構建有效載荷n + 1的ToB。
  • T_4 T 4 – 有效載荷及時性委員會 (PTC) 對有效載荷的及時性進行投票。鑑於分佈式設計，有效載荷中引用的事務的 IL 或已提交的完整 ST/ST 包必須在此之前也已到達 PTC 成員處，才能通過投票表明有效載荷是及時的。
  • T_4或T_5 –已發佈密鑰的截止日期可以通過 PTC 位域投票來強制執行，以評估其時效性；也可以通過槽位n+ 1的驗證者凍結其對已發佈密鑰的視圖並使用視圖合併來強制執行。驗證者根據 PTC 位域投票或凍結密鑰視圖的執行情況，對下一個 ABB 進行投票。
  • 在T_5之後，該過程遵循與T_1之後（對於前一個時隙）相同的軌跡。時隙 n中解密的ST 被添加到 ToB 中，並按 ToB 費用排序，然後收取該費用。鑑於 ST 在塊n構建之前解密，該設計與 BAL 完全兼容：塊n+ 1的構建器執行並準備 BAL，一切照常。

2. 引言

對於以太坊等去中心化區塊鏈而言，一個令人擔憂的問題是單個提議者對每個區塊中包含的交易擁有壟斷權，這可能導致審查和用戶福利欠佳。因此，人們提出了多併發提議者（MCP）的設計方案（ 1 , 2 , 3 , 4 ）。多年來對包含列表（IL）的研究（例如， 1 , 2 ）最終促成了分叉選擇強制包含列表（ FOCIL ）的設計。FOCIL 通過EIP-7805成為以太坊中實現抗審查（CR）的主要方案，它允許多個包含者傳播待包含在下一個區塊中的交易的包含列表。然而，當區塊已滿時，提議者仍然有權審查交易，即使他們願意支付高於實際包含交易的價格。此外，很大一部分可審查的交易 必須私下傳播以避免 MEV，因此不能依賴 FOCIL 進行 CR。

人們提出了多種限制區塊內容控制權的區塊內協議（IL）設計方案。無條件區塊內協議（UIL）要求所有符合常規包含標準的已列出交易都必須包含在區塊中。EIP -8046引入了統一價格拍賣包含列表（UPIL），確保在區塊已滿的情況下，提議者無法再忽略區塊內協議。交易按其願意支付的費用進行排序，出價最高的交易將被包含，每筆交易支付相同的統一區塊內基礎費用，該費用將被銷燬。這提供了強大的代碼審查能力（CR），有利於對時間敏感的交易和多維費用市場。然而，UIL 和 UPIL 並不能阻止多版本增強（MEV），因為交易仍然需要公開傳播。

為了防止 MEV 攻擊，交易必須在提交之前保持隱藏狀態。針對加密內存池，人們提出了多種設計方案，例如可能利用提議者承諾的閾值加密、類似密封交易中的提交-揭示方案，或二者的混合方案。密封交易在 ePBS 下可以利用ABB 。類似密封交易的基於分叉選擇強制執行的提交-揭示方案，可以進一步促進各種協議外加密方案——一種廣義密封交易。最近，一篇研究論文和EIP也提出了一個朝此方向發展但採用同時隙解密的設計方案。另一種策略是依賴智能賬戶加密內存池，該策略也已作為EIP提出。

哈耶克式的去中心化區塊構建論點是，更廣泛的參與者群體將共同擁有構建一個優質區塊所需的知識。值得注意的是，只有通過屏蔽單個參與者對區塊的貢獻（使其免受MEV的影響）並確保有效交易被納入區塊，我們才能真正使他們能夠以無需信任的方式交流這些知識。

包含列表通常會引入數據冗餘：事務信息先在內存池中傳播，然後通過包含列表 (IL) 傳播，最後在執行有效載荷中再次傳播。通過將包含列表的傳播視為“預填充”步驟，有效載荷可以有效地分佈在整個時隙期間，而不是在末尾突發傳播。這樣就避免了在單個時隙窗口內重複傳輸相同的字節（一次在包含列表傳播中，一次在有效載荷信封中）。減小ExecutionPayloadEnvelope載荷信封的大小可以最大限度地減少傳播延遲，從而允許更短的時隙時間、更大的包含列表或更大的數據塊。該設計與有效載荷分塊 ( 1 , 2 ) 兼容，後者只需在 DPP 下對已經經過一定程度壓縮的有效載荷進行操作即可。

儘管DPP提高了網絡效率，但它並不能解決多個包含器（IL）傳播相同交易的低效問題。因此，理想的解決方案是協議內解決方案，以減少重疊。本文為此提出了交錯包含列表（附錄A），該列表還有助於實現無需信任的預確認。為了限制執行前需要協調的獨立解密密鑰的數量，可以在提交前將密封交易（ST）捆綁在一起。本文提出了LUCID，它實現了通用密封交易（擴展自文獻[1 , 2 ]），同時升級了包含器，使其能夠屏蔽交易免受MEV的影響，並擁有平等的區塊空間權限，從而彌合了包含器和提議器之間的差距。

3. 加密設計

本文首先使用 UPIL 機制描述加密設計，並在 3.10 節中介紹 UIL 機制所需的更改。在通用設計下，也可以使用 Vanilla FOCIL（條件 IL）。需要強調的是，如 6.1 節進一步討論的那樣，3-4 節中概述的幾個特性（例如 DPP、UPIL 和捆綁）對於基本的 LUCID 加密內存池並非至關重要。

3.1 密封交易

密封交易 (ST) 由已簽名的 ST 票據和密文encrypted_tx組成。ST 包含以下字段：

  • from此處簽署ST車票並支付費用，
  • 常規字段nonce 、 gas_limit 、 max_fee_per_gas 、 max_priority_fee_per_gas 、 max_ranking_fee_per_gas 、
  • 負責解密的實體的decryptor_address ，
  • decryptor_fee將在執行解密後的明文交易時支付，前提是from已獲得資金。
  • reveal_commitment ，其中reveal_commitment = hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas))將揭示的明文有效負載綁定到特定的付費票據，
  • ciphertext_hash ，其中ciphertext_hash = keccak256(encrypted_tx)將密文字節綁定在一起，
  • encrypted_tx ，解密後得到RevealedTransaction(plaintext_tx, ToB_fee_per_gas) 。

為了推廣通用解決方案，基本思路是協議僅規定客戶端如何解析和打開encrypted_tx ，而解密者則自行（在協議之外）定義他們使用的密鑰託管/混合加密結構。具體來說， encrypted_tx是一個信封：

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

協議header對協議本身是不透明的，其中可能包含任何解密器特定的元數據，用於恢復 DEM 密鑰（例如，混合公鑰加密 ( HPKE )/KEM 封裝、閾值解密器密鑰下的閾值密文等）。解密器會發布協議外的指令，描述發送方如何填充header以及如何針對給定的票據導出 DEM 密鑰k_dem 。在解密時，解密器僅發佈每個票據的 DEM 密鑰材料 ( k_dem )，以便任何人都可以解密ct_dem並根據reveal_commitment驗證解密結果。

解密器應確保釋放的k_dem與已付費票據上下文相關（例如，通過使用域分隔的(chain_id, ticket.from, ticket.nonce)作為 KDF 輸入（如果使用 HPKE，則使用 HPKE info ）和/或 AEAD 關聯數據來導出）。這使得洩露的密鑰與票據相關，因此即使跨票據複製了header字節，釋放一個票據的解密材料也不會幫助解密附加到其他票據的密文（從頭部恢復的任何長期秘密都絕不能洩露）。附錄 C 給出了此類構造的一個示例（感謝 Benedikt Wagner）。對於無需信任的自解密，發送方可以簡化操作（例如，設置header_len = 0並直接為每個票據選擇一個新的 DEM 密鑰）。

 class RevealedTransaction ( Container ):plaintext_tx: Transaction # Type 2 transaction ToB_fee_per_gas: uint64 class RevealCommitmentPreimage ( Container ):ticket_from: ExecutionAddressticket_nonce: uint64plaintext_tx: TransactionToB_fee_per_gas: uint64 class STTicket ( Container ): from : ExecutionAddressnonce: uint64gas_limit: uint64max_fee_per_gas: uint64max_priority_fee_per_gas: uint64max_ranking_fee_per_gas: uint64decryptor_address: ExecutionAddressdecryptor_fee: uint64reveal_commitment: Bytes32ciphertext_hash: Bytes32signature: Bytes65 # Signature by `from` over the ticket fields class SealedTransaction ( Container ):ticket: STTicketencrypted_tx: ByteList[MAX_ENCRYPTED_TX_BYTES]

gas_limit必須足以支付encrypted_tx字節大小的 calldata 成本，受MAX_TRANSACTION_GAS_LIMIT的限制，並且將全額收費—— RevealedTransaction後觀察到實際 gas 使用量時，不會退款。RevealedTransaction 中的解密plaintext_tx是一個 EIP-1559（類型 2）交易， max_priority_fee_per_gas = 0 ， max_fee_per_gas = 0 （因為解密交易已由 ST 票據預付），並且gas_limit = ticket.gas_limit 。

ST票據的隨機數（nonce）複用以太坊的普通賬戶隨機數，並且無論密文是否最終被揭示都會被消耗，因為ST票據無論執行是否成功都會被收費。ST發送者對ST票據進行簽名。簽名是基於一個域分隔的摘要計算的，該摘要包含chain_id （以及fork/version）和票據字段（不包括signature ）的哈希樹根。

encrypted_tx中的明文有效載荷由明文發送方作為plaintext_tx的一部分單獨簽名。節點通過驗證票據簽名並檢查ciphertext_hash是否與encrypted_tx的哈希值匹配來驗證 ST。

3.2 密封交易捆

密封交易在ABB中進行承諾。如果加密內存池變得流行，大量的獨立承諾和解密密鑰可能會給網絡帶來壓力，尤其是在以太坊擴展的情況下。因此，有必要限制ABB中對密封交易的承諾數量，同時還要保證高吞吐量。所以，可以將密封交易捆綁在一起並共同承諾。

同一交易包中的所有交易必須具有相同的decryptor_address ，並且該交易包必須由控制該decryptor_address的實體簽名。交易包可以攜帶完整的ST，也可以僅包含帶有簽名的哈希值。這樣，完整的ST交易包就需要由包含者自行重建。考慮到這些字節必須在PTC截止時間前可用，要求包含者攜帶完整的ST字節似乎是合理的。如果在信標塊中觀察到引用該交易包的包含者不可用，則必須通過P2P傳播完整的交易包。

包含非捆綁加密內存池交易的功能仍然有諸多益處，原因有三：

  1. 任何ST只要包含在IL中即可執行，從而為公共內存池提供抗垃圾郵件保護。
  2. 諸如閾值解密之類的設計無需預先捆綁交易的序列器即可運行，
  3. 用戶無需傳播他們想要以非信任方式解密的單個 ST 的捆綁包。

3.3 ST承諾

在 ABB 中，密封交易以“ST 承諾”的形式進行承諾，可以單獨承諾，也可以作為來自公共加密內存池的捆綁包的一部分承諾（或者可能通過協議外方式提供，並可能利用類似於 MEV Boost 的設計）。包含列表為 ST 承諾提供了一條重要的包含路徑——構建者必須遵守他們提出的承諾。每個 ST 承諾都指定了四個字段：

 class STCommitment ( Container ):bundle: bool # False if ST, True if ST-bundle commitment_root: Bytes32 # ticket_root if ST, bundle_root if bundle decrypt: Bitfield # indices to release keys to decrypt the tx gas_obligation: uint64 # sum of gas_limit over entries with decrypt=1

ST 承諾通過commitment_root來識別，commitment_root 可以是已簽名票據的 SSZ 哈希樹根ticket_root = hash_tree_root(STTicket)也可以是已簽名捆綁包的 SSZ 哈希樹根bundle_root ，後者涵蓋捆綁包中的所有ticket_root條目。第 6.3 節討論了decrypt=1的ticket_root條目的可能scheduled_root 。請注意，密文字節通過ciphertext_hash = keccak256(encrypted_tx)綁定到票據，該哈希值包含在已簽名票據中。

3.4 配額和 ToB 天然氣限制

每個包含列表 (IL) 都有一定數量的 ST 承諾，初始值可以設置得比較低；例如，每個 IL 最多可以提交MAX_COMMITS_PER_IL = 4 ST 承諾。也可以允許構建者自行提交 ST 承諾，例如也允許其提交MAX_COMMITS_PER_IL個 ST 承諾。但是，為了簡化設計，最簡單的方法可能是直接給構建者分配一個獨立的 IL。每個 IL 都有一個max_bytes_per_inclusion_list分配值，就像 FOCIL 一樣。該值會隨著 gas 限制的變化而變化，這樣當區塊的gas_limit增加時，包含者相對於提議者不會處於劣勢。它可以計算為max_bytes_per_inclusion_list = gas_limit/(IL_COMMITTEE_SIZE * GAS_PER_AGG_IL_BYTES) 。設置GAS_PER_AGG_IL_BYTES = 2**9當使用IL_COMMITTEE_SIZE = 16 （如 FOCIL 中那樣）時，在 gas 限制為 60M 的情況下，IL 字節大小為7.15 KiB承諾仍然計入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中的最大值。

3.5 可審計的建築商投標（ABB）

構建者為獲得構建有效載荷的權利而進行可審計的構建者競價（ABB）。ABB 通過包含ToB_marginal_ranking_fee_per_gas 、ST 承諾以及關於前一個區塊 ST 承諾的密鑰遵守情況的位域來擴展ExecutionPayloadBid ：

 class ILCommitments ( Container ):IL_root: Bytes32commits: List [STCommitment, MAX_COMMITS_PER_IL] class ILKeyAdherence ( Container ):key_adherence: List [Boolean, MAX_COMMITS_PER_IL] class ABB ( Container ):... # existing fields of the ExecutionPayloadBid ToB_marginal_ranking_fee_per_gas: uint64IL_data: List [ILCommitments, IL_COMMITTEE_SIZE]key_adherence: List [ILKeyAdherence, IL_COMMITTEE_SIZE] # one bitfield per previous IL in a list of bitfields

構建器使用(ticket.from, ticket.nonce)對 ST 承諾中的 ST 進行去重。去重後的集合中只能有一個 ST 具有相同的(ticket.from, ticket.nonce) ，該 ST 應包含在有效載荷中，其decrypt位設置為1所有其他具有相同(ticket.from, ticket.nonce) ST 的decrypt位必須設置為0此外，對於ticket.from生成無效 ticket- nonce序列的 ST，或在票據計費開始時不可計費的 ST（參見第 3.9 節），也會以相同的方式移除。應用確定性規則來確定在去重過程中要保留哪個 ST，該規則選擇捆綁包中 ST 數量最多的實例，如果數量相同，則使用 IL 的committee_index進行打破。

如果存在多個指向特定 ST 捆綁包的 IL 承諾，則重複的承諾會將decrypt設置為規範的零編碼0 （單比特 0）以節省空間，並且僅保留committee_index最高的 IL 的 ST 捆綁包。為避免可塑性，當decrypt沒有設置位時，必須將其編碼為精確的0 （單比特 0），並解釋為全零掩碼，而與捆綁包長度無關；其他全零編碼無效。

對於捆綁包內重複的ST，它們共享同一個decryptor_address ，因此去重嚴格來說是解密器的一個記賬操作。此外，構建者不能隨意設置decrypt位。時隙n + 1的驗證者、構建者（以及所有其他節點）將審查decrypt位的設置是否嚴格遵循確定性規則（例如去重），且不會遺漏IL暴露出的有效ST。如果有效載荷未通過審核，則協議將進入無效有效載荷下的恢復過程，如第4.5節所述。

如果去重後的 ST 的ranking_fee_per_gas超過ToB_marginal_ranking_fee_per_gas ，則通過設置decrypt = 1將其包含在內，如果排名相同則使用ticket_root進行判定。確定要包含哪些 ST 後，每個 ST 承諾的gas_obligation被設置為該承諾中所有ToB_marginal_ranking_fee_per_gas decrypt = 1的gas_limit條目的總和。ToB_marginal_ranking_fee_per_gas 還可以用於壓縮decrypt位域，使其僅覆蓋ranking_fee_per_gas足夠的交易的允許範圍。

ABB 中的commitment_root允許解密器在及時觀測到信標塊後識別自身並釋放解密密鑰，甚至在有效載荷釋放之前即可進行。每個IL_root都包含在 ABB 中，用於解決歧義，這將在討論 DPP 的 4.3 節中進一步闡述。

有兩種方法可以避免構建者每次投標都傳播完整的 ABB。構建者可以為每次新投標指定相對於其先前投標的增量，幷包含一個用於引用的哈希值。可以預期，ST 承諾會在投標截止日期前很早就確定，這意味著後續投標的增量只需涵蓋因遲到的 PT 而導致的投標值和有效載荷的變化。另一種方法是採用拉取機制，構建者的投標較為輕量級，提案者在發佈前從中標構建者處拉取 ABB。

3.6 證明

檢驗員將ABB與他們觀察到的IL進行比較。他們核實以下內容：

  • 所有gas_obligation條目的總和在ToB_gas_limit範圍內，
  • ABB 中正確規定了所有及時觀察到的 IL，沒有含糊不清之處，並給出了已公佈的ToB_marginal_ranking_fee_per_gas 。

ABB 中包含但未經驗證者審核的列表將不予審核。節點在 ABB 中觀察到這些列表後會提出請求，PTC 最終將投票決定其是否及時生效。

3.7 關鍵版本

解密器會觀察信標塊n n傳播的 ABB 中的ToB_marginal_ranking_fee_per_gas及其規定的gas_obligation 。它會驗證ToB_marginal_ranking_fee_per_gas和decrypt位域是否確實為其自身的 ST 承諾生成了指定的gas_obligation ，並且所有gas_obligation條目的總和是否在ToB_gas_limit範圍內。這是釋放解密密鑰的必要條件。具體來說，如果有效載荷隨後被證明無效或不及時，解密器的 ST 承諾始終在ToB_gas_limit範圍內。這意味著它們仍然可以包含在下一個有效載荷的 ToB 中，如第 4.5 節進一步討論的那樣。

如果負責列出 ST（或捆綁包）的 IL 不可用，解密器此時（如果之前未執行）將廣播ticket_root / bundle_root與 ABB 中的commitment_root匹配的完整 ST 字節（或捆綁包主體），以便節點可以在 PTC 截止時間前驗證已發佈的密鑰。當解密器（或任何人）提供已提交 ST 的完整SealedTransaction字節時，節點會檢查hash_tree_root(st.ticket) == commitment_root和keccak256(st.encrypted_tx) == st.ticket.ciphertext_hash 。當解密器確信信標塊將成為規範塊（例如，在觀察到其證明之後）時，它將發佈其密鑰。

在密鑰發佈時，解密器會按照第 3.1 節所述發佈對稱密鑰材料。密鑰以消息的形式發佈，該消息由decryptor_address簽名，並通過committee_index和commit_index標識關聯的 ST 提交，此外還包括槽位號以及承載關聯 ABB 的信標塊的beacon_block_root 。對於密鑰包，密鑰會被封裝在一個長度與設置為1 decrypt位數量相同的列表中，其順序與已提交的密鑰包中的順序相同。

密鑰消息通過 P2P 泛洪傳播。節點會轉發任何格式良好的密鑰消息，該消息指向 ABB 中由(beacon_block_root, slot)標識的承諾，並由 ST 承諾中指定的decryptor_address簽名。如果密鑰能夠解密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 ）。解密後的明文發送方和 nonce 無需與 ST 發送方的from和nonce匹配。

指向同一beacon_block_root 、 committee_index和commit_index密鑰，如果字節不完全相同，則構成歧義。歧義密鑰的處理方式與 FOCIL 中的 IL 歧義類似：節點會傳播其觀察到的針對同一目標的前兩個不同的簽名密鑰消息，以表明存在歧義；構建者可以忽略解密者歧義的 ST。如果在驗證截止日期前驗證者觀察到歧義證據，則驗證者接受這種忽略。

3.8 PTC 投票

PTC 對與有效載荷廣播和 blob 數據相關的 DA 進行投票。為了符合有效載荷的分佈式傳播（第 4 節），PTC 投票還涉及重建已提交的ExecutionPayload所需的所有數據的可用性：引用的明文事務字節（ tx_reference ）、引用的 ST 提交以及這些提交引用的底層 ST/捆綁包字節。

因此，構建者有責任確保其在 ABB 中註冊的 IL 在 PTC 投票前到達，但如果 IL 不可用，解密者也可以獨立傳播相應的 ST 字節。關於此主題的更多考慮將在 4.3 節中討論。藉助存儲的 IL 重建有效載荷後，PTC 成員會驗證有效載荷的根是否正確。他們還會通過投票確認 ABB 已正確指定，這可以從有效載荷中看出。

每個 PTC 成員還可以選擇性地廣播一個簽名位域，該位域指示哪些已安排在下一時隙解密的 ST 承諾在密鑰截止時間前已收到有效的密鑰消息。該位域使用非零decrypt掩碼，按規範順序(committee_index, commit_index)對調度 ABB 的 ST 承諾進行索引（即，按committee_index遞增順序掃描IL_data ，並按commit_index遞增順序掃描commits[] ）。使用 PTC 投票的原因將在 6.3 節中討論。

構建者和第 n + 1個槽位的驗證者根據 PTC 投票結果做出關於及時性的決策。為了合併視圖，驗證者可以在第 n+1 個槽位開始之前凍結他們對 PTC 投票的視圖。然後，當某個鍵的得票率達到例如 45% 到 55% 之間時，構建者可以強制執行其關於及時性的視圖（低於 45%，驗證者強制執行不及時；高於 55%，驗證者強制執行及時，前提是他們在投票截止日期前已經觀察到該鍵）。構建者還可以選擇傳播一個包含其觀察到的投票結果的獨立結構，用於合併視圖。

3.9 支付和納入

執行有效載荷的共識表示擴展了st_tickets列表和decrypted_transactions列表（兩者均在第 4.2 節中描述）。這些列表用於對 ST 進行計費。

收取 ST 車票費用

st_tickets中的每個 ST 票據都會從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 承諾的 ABB（即定義待處理集合的 ABB）。根據實際gas_used ，區塊n+1中不會退款；如果 ST 未解密，則僅退還decryptor_fee 。如果st_tickets中的任何票據無法完全收費，則該區塊無效。

節點通過將ToB_marginal_ranking_fee_per_gas （參見 3.4 節）與 ToB 中排除的最高有效排名 ST 的ranking_fee_per_gas進行比較，來驗證 ToB_marginal_ranking_fee_per_gas 設置是否正確。由於 ST 的收費基於其公開可見的gas_limit而非實際使用的 gas，因此承諾時的資金可用性檢查是靜態的，不依賴於其他交易的執行。這避免了 UPIL 排名機制中因循環依賴問題而導致的保守餘額檢查。

包括和對解密的ST進行收費

節點觀察密鑰的發佈，並在本地解密ST交易。區塊n + 1的構建者收集所有能找到的密鑰，並生成一個包含其所遵循的有效密鑰位域的ABB。驗證者要求構建者遵循所有及時有效的密鑰，其中及時性通過視圖合併或PTC投票確定，如前所述。無法使用已發佈密鑰解密的ST將被忽略。

節點會根據生成該交易的特定 ST 票據（通過完整的 ST 和相應的密鑰）驗證每個解密的 ToB 交易。只有當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 ）時，揭示才有效。

處理decrypted_transactions的第一步是退還所有未解密 ST 的ticket.decryptor_fee 。發送方通過ticket_index中缺少索引來識別（參見 4.2 節）。已decrypted_transactions的decryptor_fee將記入關聯的ticket.decryptor_address 。協議最後從ticket.from中扣除並銷燬 ToB 費用ticket.gas_limit * ToB_fee_per_gas 。如果ticket.from不足以支付此費用，則該交易不予處理。

如果用戶提交的多個 ST 的解密plaintext_tx具有相同的from並且 nonce 是連續的，則應確保ToB_fee_per_gas與 nonce 兼容，因為解密的交易主要按ToB_fee_per_gas排序，而執行仍然遵循每個發送者的 nonce 順序。

3.10 無條件 IL 版本

對於無條件 IL 版本，我們進行了一些修改，詳情如下。其理念是實現“無條件 FOCIL”，遵循 FOCIL 的諸多設計原則，但允許每個包含者的列表都是無條件的。除了可以像 LUCID 那樣實現加密內存池之外，它在像 EIP-7999 那樣的多維費用市場中也很有幫助。關於無條件 FOCIL 的更多細節和分析，除本文概述的內容外，將在後續文章中另行介紹。

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實際可以消耗的 ToB gas 量取決於其他 IL max_bytes_per_inclusion_list消耗量。max_bytes_per_inclusion_list 可以設置成允許 IL 填充調用數據，使其不超過ST_gas_min_per_IL或更低。ST 承諾的順序，以及 ST 在捆綁包中的順序，定義了 IL 指定的優先級順序。構建器會不斷增加 IL 可以消耗的最大 gas 量，直到所有gas_obligation條目的總和超過ToB_gas_limit ，然後降低該最大值以移除最後添加的交易。因此， gas_obligation條目的（未去重的）總和必須在ToB_gas_limit範圍內，就像以前一樣。

驗證者會檢查每個及時觀察到的 ST 承諾是否都正確指定了gas_obligation ，其依據是所有gas_obligation條目中的最大值和已發佈的decrypt位。每個解密者也會驗證其自身承諾的這一點。對於decrypt = 1的交易，他們會釋放密鑰，使得 ST gas 限制的總和等於gas_obligation 。

無溢出

在無條件IL版本（無溢出）下，每個IL的上限為ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE以ToB gas為單位）。由於此上限是每個IL固定的，因此可以從ABB中省略gas_obligation字段。考慮到包含者仍然可能產生歧義，因此在ABB中保留commitment_root似乎是合理的。

UIL 與 UPIL 一起

另一種可行的設計是讓 IL 無條件地包含ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE ，並允許根據 UPIL 包含額外的交易。然後，超出限制由max_bytes_per_inclusion_list限制。

4. 分佈式有效載荷傳播

有效載荷依賴於對預先傳播的交易數據和先前 ST 承諾的引用，而不是在廣播的有效載荷中重複交易字節。共識表示擴展了st_tickets和decrypted_transactions （第 4.2 節），但常規transactions列表仍然像當前執行有效載荷一樣，是完整的交易字節列表。通過 P2P 發送的網絡表示有所不同，僅用作臨時優化。

4.1 網絡表示

引入了一種輕量級有效載荷廣播。除了攜帶非包含列表來源的交易的完整交易字節外，分佈式執行有效載荷信封DistributedExecutionPayloadEnvelope還包含一個指向節點預期已擁有（或能夠從規範包含列表獲取）的交易的指針列表。每個ILTransactionPointer還指定了包含列表交易在區塊最終transactions列表（共識表示）中的位置。

 class ILTransactionPointer ( Container ):committee_index: uint8 # 0..IL_COMMITTEE_SIZE-1 tx_index: uint16 # index into the canonical IL body for this committee_index position: uint32 # index in the final full transactions list

有效載荷的網絡表示不涉及ST。構建者生成的ABB足以確定性地重構ST票據和解密後的ST。具體而言，調度ABB中的ST承諾（其decrypt位由構建者指定）標識了有效載荷包含的ST票據及其順序。同樣， key_adherence位標識了應包含的解密後的ST，其順序由ToB費用決定。有關恢復的更多細節將在4.5節中討論。

因此，具體來說， DistributedExecutionPayloadEnvelope鏡像了ExecutionPayload標頭字段（重新計算block_hash所需的一切），但依賴於指針（ ILTransactionPointer ）來獲取來自 IL 的交易，並依賴於 ABB 來重建 ST 票據和解密的 ST。

4.2 共識表示

執行有效載荷的共識表示擴展了兩個附加列表： st_tickets和decrypted_transactions 。

st_tickets

st_tickets是一個已簽名 ST 票據列表，這些票據在區塊處理開始時計費，對應於一組待處理的（即尚未計費的）ST 承諾。構建者必須將每個設置了decrypt=1的 ST 票據包含在其 ABB 的 ST 承諾中。在恢復機制下（第 4.5 節），構建者只需包含在相關祖先 ABB 中經過確定性過濾（去重、nonce 可行性、計費性）後剩餘的、與decrypt = 1 1 的待處理 ST 承諾對應的 ST 票據即可。

st_tickets列表具有規範順序：首先按committee_index遞增掃描調度 ABB 的IL_data ，然後按commit_index遞增掃描commits[] ，最後（對於捆綁包）按tx_index遞增掃描條目，並將確定性過濾後剩餘的每個條目的 ST 票據包含在內。

decrypted_transactions

` decrypted_transactions是一個列表，其中包含當前區塊中已解密的 ToB 交易。每個條目包含(ticket_index, plaintext_tx, ToB_fee_per_gas) ，其中ticket_index是指向調度當前正在解密的交易的區塊（通常是前一個區塊）的ticket_index st_tickets的索引。`ticket_index` 在處理區塊時作為輕量級指針包含在內，如果同一個ticket_index在decrypted_transactions中出現多次，則該區塊無效。當兩組st_tickets （參見 4.5 節）指向同一個decrypted_transactions列表時， ticket_index編號方式為：後出現的st_tickets的索引從len(st_tickets)開始。

僅當hash_tree_root(RevealCommitmentPreimage(t.from, t.nonce, plaintext_tx, ToB_fee_per_gas)) == t.reveal_commitment for t = st_tickets[ticket_index]時，該條目才有效。ToB 的排序必須按照ToB_fee_per_gas遞減的順序進行，如果 ToB_fee_per_gas 仍然為零，則按ticket_index順序打破平局，並跳過因 nonce 順序問題而無法執行的條目。

共識表示的性質

常規transactions列表仍然是完整交易字節的列表，與當前的執行有效載荷格式相同。信標區塊包含一個SignedExecutionPayloadBid ，用於提交完整的有效載荷，特別是通過其block_hash ，如 EIP-7732 中所述。基於指針的有效載荷格式僅用作臨時網絡優化：節點在本地重建完整的ExecutionPayload ，計算/驗證生成的block_hash與已提交的頭部是否匹配，然後執行層客戶端像往常一樣執行並存儲完整的交易數據。同步操作基於完整的區塊；指針永遠不會成為共識對象的一部分。

4.3 IL 在 ABB 中的根本承諾，以防止含糊其辭

包含器可能會在區塊構建前後傳播多個 IL。構建器在提交有效載荷之前可能只會觀察到其中一個 IL，並決定包含來自該 IL 的交易。這存在一個風險，即網絡上的節點觀察到的 IL 與包含器不同，從而導致構建器引用的 IL 出現歧義。因此，構建器通過在 ABB 中包含每個包含器的 32 字節 SSZ IL_root來定義每個包含器的唯一“規範”IL。具體來說，如果分佈式有效載荷通過ILTransactionPointer(committee_index=i, ...)引用了委員會成員i的任何交易，則包含在信標區塊中的 ABB 必須包含一個非空的i的IL_root 。

如果構建器未從包含器中觀察到 IL，則該條目將留空。構建器可以自由地在其代碼塊中包含它不會引用的已觀察到 IL 的根目錄，以便在揭示有效載荷內容之前對其進行混淆，但也可以不這樣做。

節點被指示始終轉發規範的包含請求（即使存在歧義）（同時轉發一條額外的包含請求以指示歧義）。如果節點已經轉發了來自同一包含者的兩個包含請求，並且得知第三個包含請求是規範的，則在收到該包含請求時也會轉發它。如果構建者觀察到歧義，則會在發佈競價後重新播種其規範的包含請求。仍然可以對包含者因歧義而進行懲罰，並且鑑於包含請求的動態屬性（DA）的重要性增加，在動態支付計劃（DPP）下進行懲罰似乎更為合理。

4.4 有效載荷重建

複雜性都封裝在 CL 客戶端中。工作流程如下：

  1. IL 接收： CL 客戶端通過 P2P 接收 IL，並將其存儲在以IL_root為鍵的本地緩存中。
  2. 有效載荷接收：它接收SignedDistributedExecutionPayloadEnvelope ，驗證構建者簽名，並檢查其(slot, beacon_block_root, builder_index, block_hash)是否與信標塊中提交的SignedExecutionPayloadBid匹配。
  3. 分辨率和重建：
    • 客戶端通過以下方式解析所有ILTransactionPointer條目：在信標區塊的 ABB 中查找committee_index對應的規範IL_root ，從其緩存中獲取該 IL（如果緩存中不存在則請求獲取），並讀取tx_index處的完整交易。它通過將每個 IL 交易插入到最終列表中的唯一position ，將這些交易與信封的完整transactions合併。
    • 客戶端根據調度 ABB（通常是當前時隙的 ABB；在恢復模式下，是未計費的祖先 ABB）確定性地構造st_tickets 。它按規範順序掃描IL_data → commits[] ->(bundle tx_index )，應用確定性過濾規則（去重、nonce 可行性、計費性），獲取相應的SealedTransaction字節，併為每個剩餘條目提取 ST 票據。
    • 客戶端根據當前區塊待解密的 ST 承諾確定性地構建並排序decrypted_transactions ：在正常操作中，這些承諾是父區塊的已安排 ST 承諾；在恢復模式下，這可能包括來自最近完整祖先區塊和第一個空區塊的待解密承諾（參見 4.5 節）。對於每個具有有效已發佈密鑰消息且 ABB 遵循該消息的承諾，客戶端進行解密以獲得RevealedTransaction(plaintext_tx, ToB_fee_per_gas) ，識別相應的已收費票據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. 驗證：客戶端計算結果block_hash並將其與信標區塊中的SignedExecutionPayloadBid進行驗證。
  5. 執行：客戶端將完全成型的ExecutionPayload傳遞給引擎 API（ engine_newPayload ）。
  6. PTC 投票：節點持續獲取缺失的 IL/ST 字節/密鑰，並在新數據到達時重試重建。PTC 成員只有在T_4時刻已完全重建有效載荷並驗證了block_hash後，才會投票“及時”；否則，投票“不及時”。

4.5 被拒絕有效載荷下的恢復

如果信標區塊的ABB為其ST承諾指定了正確的gas_obligation條目，所有gas_obligation條目的總和在ToB_gas_limit範圍內，並且發送者的ST承諾和解密密鑰可用，則發送者有權將其解密後的交易包含在下一個區塊中。但是，在解密密鑰發佈後，有效載荷n可能會被拒絕，這並非發送者或解密者的過錯。在這種情況下，下一個有效載荷必須包含已安排在有效載荷n中的解密ST ，以及在時隙n中已發佈密鑰且已安排在n+1中的ST 。

具體來說，一個數據塊的解密序列是指滿足以下條件的序列：

  • 具備ST字節和密鑰，
  • 列於正確指定的ABB中，其中該ABB
    • 不是當前插槽的ABB，
    • 尚未將其解密的 ST 承諾納入鏈上。

因此，當一個區塊為空（沒有有效載荷）時，下一個有效載荷必須包含該空區塊本應包含的已解密存儲轉移（ST），以及該空區塊在ABB中提交的（現已解密的）ST。恢復有效載荷不能提交新的ST（如Potuz在此處建議的那樣），而是必須使用key_adherence位來指示空區塊的ST提交當前是否可用（字節+密鑰）。這些位也標記了ST票據，在恢復過程中，這些票據必須與已解密的ST一起放入同一個有效載荷中。如果該區塊未能包含解密的ST以致鏈無法恢復，則該區塊也必須被投票判定為空，並且恢復的責任將再次落到下一個有效載荷上。

在基準規範中，解密的ST最多分配到1/4的gas限制。這確保了當某個有效載荷丟失時，下一個有效載荷可以包含兩組解密的ST，最多消耗該區塊1/2的gas限制。

5. 揭示 LUCID 中的可選性

在密封交易承諾-披露機制下，一個潛在的問題是披露選擇權。一些密封交易將被用於“回溯”，例如，CEX價格的變化。

相关赛道:
智能合約公鏈
Layer 1
元宇宙
來源
免責聲明：以上內容僅為作者觀點，不代表Followin的任何立場，不構成與Followin相關的任何投資建議。
喜歡
52
收藏
12
評論
相關推薦