由 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毫秒時間戳。
響應正文
構建者必須返回與標準構建者提交相同的 已簽名構建者出價 型別的完整區塊載荷。
