信標鍊和執行層的交易是否重複?
信標鏈上區塊的具體內容是什麼?部分回答了這個問題,但對我來說仍然不完整。
我知道,由於合併,執行層資訊在信標鏈中。
- 那麼執行層是否仍然對應於另一個“鏈”,或者交易是否只寫在信標鏈中?
- 這是否意味著自合併以來信標鏈塊的大小增加了(因為它們帶有 eth1 資訊)
- 當我們使用 geth+prysm 安裝節點時,兩者都在同步。但是如果 prysm 正在下載關於共識和執行層的數據,那麼 geth 下載是什麼?
我已經閱讀了文件等等,但我無法理解執行層資訊(在執行層和信標鏈之間)的儲存位置。
提前感謝您的寶貴時間,您已經很棒了 <3
合併是 Bellatrix 共識(層)規範、巴黎執行(層)規範和引擎 API 的實現。
貝拉特里克斯:https ://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix
巴黎:https ://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md
- 巴黎主要由EIP-3675組成。
共識層和執行層的互動由 Engine API 指定:https ://github.com/ethereum/execution-apis/blob/main/src/engine/specification.md
第一季度
執行層自創世以來一直有塊;信標塊才開始在 Bellatrix 中進行交易。所以每一層都可以認為是一條“鏈”。
關於自合併以來重複交易的問題,僅從規範來看,EIP-3675 並未指定在執行層對交易進行任何刪除或優化。正如 EIP-3675 的基本原理所述:“該 EIP 旨在最大限度地降低熱交換乙太坊網路實時共識的複雜性。同時考慮了操作的安全性和生產時間。” 所以 Q1 的答案是它取決於執行客戶端的實現。在實踐中,交易可能是重複的。
第二季度
是的,Bellatrix 規範說明了擴展和添加。
BeaconBlockBody
和分別用和BeaconState
擴展。ExecutionPayload``ExecutionPayloadHeader
第三季度
共識層 (CL) 和執行層 (EL) 在很大程度上與合併之前一樣執行。例如,EL 管理記憶體池並為一個塊收集交易,並與創世同步。
基於引擎 API 討論的Merge 引擎 API 測試向量有助於了解層如何互動。CL 呼叫
engine_forkchoiceUpdatedV1
以便 EL 準備有效負載。CL 呼叫engine_getPayloadV1
以獲取有效負載。然後 CL 告訴 EL 通過呼叫engine_newPayloadV1
. 假設有效負載是有效的,CL 然後通過呼叫告訴 EL 有效負載是鏈的頭部engine_forkchoiceUpdatedV1
。