原文作者：parithosh

一級標題

概要

概要

總結

總結

總結

合併測試網Kintsugi 在前幾週的運行中遇到了一系列問題，暴露了多個客戶端的幾個漏洞。問題主要是由開發者Marius 開發的fuzzer 引發的，這個fuzzer 旨在創建有意思的區塊並在網絡裡對區塊進行廣播。blockHash一個這樣的區塊的parentHash（區塊哈希）被替換為它的engine_executePayload(父塊哈希)。blockHash具備了所有構建一個區塊和構建該區塊的blockHash所需的所有參數。 EL （執行層) 客戶端應該根據這些參數來構建區塊，並根據通過的

進行驗證。這個特定區塊正確無誤地沒有通過Geth 的檢查，但通過了Nethermind 和Besu 的驗證。該區塊之所以在Nethermind 被錯誤地通過驗證是因為緩存問題，而Besu 則完全沒有這項檢查。由此，該區塊被一個Lighthouse-Besu 節點提議，並導致區塊鏈分叉為兩部分，在執行層與Nethermind 或Besu 連接的驗證者在一個分叉上，而月Geth 連接的驗證者則在另一個分叉上。blockHash請注意，檢查當前區塊的

是合併新增的要求，因此在某些客戶端上會存在缺少或不准確的驗證。INVALIDGeth 的一個問題是當執行錯誤的負載時，它返回的是一個JSON-RPC 錯誤而不是

在找到和部署了Nethermind 和Besu 節點的修復程序後，我們就能夠讓它們重新連上正確的鏈。 Teku-Geth 節點的更新導致了另一個與無效內存訪問相關的問題，它由Geth 上與區塊排序驗證相關的問題引起。這個具體的漏洞也是由Marius 的fuzzer 觸發的，這個fuzzer 產出了一個parentRoot是有效且block_number=1和parentHash和parentHash和blockNumber和parentHash。由於Teku 是同時執行所有分叉裡的所有負載，緩存就不再包含blockNumber。因此，Geth 試圖在它的database 里通過parentHash和

一級標題

一級標題

FAQ

一級標題

A:Q: 這個測試網死了嗎？

沒有。在我們部署修復程序並重新同步一些停滯的節點後，鏈最終又開始做最終敲定了。當鏈恢復最終敲定，它就可以如常運行。目前，Kintsugi 的參與率是大約99%，這表明所有客戶端的漏洞已經得到修補，且網絡也運行良好。交易和智能合約交互繼續如常運作。

A:Q: 為什麼這條鏈這麼長時間不做最終敲定？

雖然我們很早就找到了根本原因，我們想要讓鏈保持非最終敲定狀態，讓客戶端團隊調試他們的代碼。此外，我們想要收集非最終敲定期間的客戶端表現數據。

A:Q: 在分叉鏈上的驗證者會被罰沒嗎？

不會。每個驗證者都包含一個slashing protection(罰沒保護) database，確保驗證者不會對可罰沒的信息簽名。在“錯誤”分叉的驗證者只會被視為在“正確”分叉上處於inactive狀態。一旦它們重組到“正確”分叉上，罰沒database 會阻止它們對可罰沒信息簽名。

A:Q: 這會如何影響主網發布？會有新的延遲嗎？

我們認為這件事不會影響主網發布計劃。在規範本身上沒有發現嚴重的問題。測試網的目的是發現漏洞，我們認為Kintsugi 在發現客戶端實現的邊緣情況方面表現很好。這事件是對多個客戶端組合的一次很好的壓力測試。我們有一個公開的清單，它將指引我們何時準備好在主網實現合併。

A:Q: 這會如何影響測試計劃？

我們將研究創建幾個強制處於非最終敲定狀態的測試網。對這些非最終敲定的測試網進行持續測試使我們可以觸發更多邊緣情況，和改進工具。在這次事故中發現的漏洞將被添加為靜態測試用例，以確保我們會通過回歸測試。

對驗證者、基礎設施提供商和工具開發者的重要啟示:

• 測試網上的非最終敲定時期加強了最糟糕情況硬件要求的一些假設。在非最終敲定期，驗證者應該預期：

• 由於需要對多個分叉選擇規則進行評估，CPU 負載會增加(有時達到100%)

• 在非最終敲定期由於不會有修剪，硬盤使用量會增加

RAM 使用量會有邊際增長

這意味著，在同一台機器上運行的任何額外工具或監測都會遇到資源爭用問題。 Kintsugi 測試網的工具(區塊瀏覽器、水龍頭、RPC) 在具有3 個節點的Kubernetes 集群上運行。這個集群還運行多個工具使用的信標節點。由於信標節點使用的資源比預置的要多得多，因此我們的工具經常由於資源不足而以降級的方式運行。對於基礎設施提供商來說，謹慎的做法是在不同的機器上運行它們的共識層和執行層，或有嚴格的資源使用定義。

合併意味著每個共識層客戶端都需要運行自己的執行層客戶端。 (主網上的) 執行層客戶端現在需要很大的磁盤容量。在非最終敲定期間，CL 的磁盤使用量也會激增，這會由於磁盤空間不足而導致崩潰。所有驗證者應該確保他們有足夠大的緩衝磁盤空間來應對這種問題。optimistic依賴於最終確定性的工具開發者應該為非最終敲定時期多做考慮。一種可能的方式是顯示