以太坊2.0開發更新＃35 – Prysmatic Labs
我們每周兩次更新由整個Prysmatic Labs團隊撰寫的關於以太坊寧靜路線圖的更新。
互操作性事件回顧：成功
Interop取得了成功參加這次靜修的每個人都很棒，特別感謝Consensys負責物流。通過libp2p傳遞信息，團隊能夠將7種不同的實現互相配合。僅此一項就是一項巨大的成就，更不用說客戶正在同步塊，證明和最終確定鏈條。我們在超越的時候超級充滿了興奮的未來
為Devcon V做準備
發布互操作，有更多預期的工作，團隊的首要任務是關注同步彈性，這意味著節點可以斷開幾個插槽，重新上線並趕上其同行。另一個優先順序是增強我們的同步策略，從請求來自單個對等體的塊到以循環方式從多個對等體請求塊。第二層優先順序是SSZ彈性，測試覆蓋率改進和UX改進。
合併代碼，請求和問題
與最新的網路規範一致
我們已經完成了Prysm repo與以太坊Serenity最新最好的官方網路規範的協調。擁有標準的，可升級的網路規範是客戶無縫通信的關鍵，並確保我們有一個很好的方式來處理p2p級別的Eth2的重要功能。最新的網路規範使我們能夠更好地處理節點之間的初始握手，以及在節點之間發送帶有大量數據的流，以加快通信速度。由於塊響應現在被分塊而不是作為整體響應發送，這允許節點終止來自早期發送壞數據的對等體的流。您可以在此處查看此跟蹤問題的全套更改。
通過Attestations改進性能
原型是以太坊2.0中最常見的網路對象。節點可能每秒處理數十個證明，因此這些代碼路徑是明確的優化候選者。自上周的互操作事件以來，我們一直在分析並仔細審查任何優化機會的代碼，例如儘可能並行處理不同的證明。當我們將測試網路帶入完整的主網規模時，這些優化將變得越來越重要。
客戶端互操作性實用程序內置於Prysm
為了準備互操作，我們需要與如何快速啟動Prysm客戶端以確保其他人使用的標準保持一致。其中一個重要特性是能夠從創世狀態文件啟動信標節點，然後可以在客戶端之間使用它來測試各種功能。
另一個重要的部分是能夠快速簡單地進行「冷啟動」，這意味著您只需指定驗證器的數量和創建時間，系統即可快速旋轉，無需任何其他需要。自上次更新以來，我們將這兩個功能包括在內，並證明它們對於互操作中的簡單原型設計至關重要，甚至可以讓我們每天進行本地開發。如果您想了解更多有關此功能以及如何設置Prysm這種方式，頭部到我們的互操作性文檔在這裡。
即將開始的工作
BLS密碼學前進
這是因為我們的BLS簽名驗證庫，https://github.com/phoreproject/bls，是THE在Prysm最大的瓶頸和阻礙我們擴展到驗證數量龐大的真正重要的東西。看看我們隊友Ivan的火焰圖，看看我們處理一個塊及其底層數據時BLS需要多長時間。
是的，BLS大約佔我們運行時間的99.9％……
當我們進入生產準備階段時，我們確實需要一個替代方案，我們一直關注https://github.com/herumi/bls作為替代方案，但由於局限性而無法整合到Prysm中cgo及其傳遞依賴性。BLS正迅速成為我們的首要任務，我們將在未來幾個月繼續探索各種選擇。
更大的測試覆蓋率，模糊測試，負載測試
為生產做好準備的一部分意味著不僅要測試以太坊信標鏈運行時的「快樂路徑」，還要考慮意外情況，不良數據，垃圾數據和惡意活動。許多官方的以太坊Serenity規範測試確保每個客戶端在計算狀態轉換等方面具有相同的行為，但規範測試肯定不是模糊測試，這是我們迫切需要的。
模糊測試
簡而言之，模糊測試意味著將隨機數據輸入系統以確保它不會爆炸。例如，具有奇怪格式化信息的塊，RPC端點接收隨機形成的請求等。模糊測試廣泛用於諸如序列化庫或其他通用工具之類的實用程序，這些工具應該處理某些形狀的「通用」數據。或形式。我們現在正在探索廣泛的模糊測試功能來測試Prysm並確定其邊緣情況。
準備生產的另一個重要方面是對信標節點進行負載測試。關鍵問題是，是否有一些人發送垃圾郵件節點的開放端點會殺死節點？是否有內置的DoS保護？我們能用這種方式識別微妙的攻擊向量嗎？通常，可公開訪問的Web伺服器在投入生產之前會進行負載測試，並且釋放Ethereum Serenity也不例外。在這方面期待我們的更多工作以及一些有趣的結果。
檔案信標節點功能
Eth1節點可以選擇以` – archive`模式運行，該模式存儲以太坊區塊鏈的整個狀態，包括除了達成共識所需的所有賬戶和合約數據。通常，塊瀏覽器或其他數據密集型應用程序需要此功能，這些應用程序用於跟蹤以太坊網路的歷史信息。我們相信它也是Eth2的一個重要特性，這就是為什麼我們設計了我們的信標鏈RPC端點來查詢舊數據（如果請求）。對於這一點，我們把一個設計歸檔數據存儲在這裡，並通過我們的設計DB API為此開始了工作在這裡。
大多數所需的歸檔信息不是存儲每個信標狀態，而是相當於驗證器集的變化，例如驗證器激活，削減，自願退出等。我們決定存儲以下數據結構：
消息ArchivedActiveSetChanges { 重複uint64 activated = 1; 重複uint64退出= 2; 重複uint64彈出= 3; 重複uint64 proposers_slashed = 4; 重複uint64 attesters_slashed = 5; 重複VoluntaryExit voluntary_exits = 6; 重複ProposerSlashing proposer_slashings = 7; 重複AttesterSlashing attester_slashings = 8; }
每個紀元以及有效驗證器索引及其餘額。我們現在正致力於確保我們的整個後端支持存檔，使我們的RPC API對第三方用例更有用。
循環網路同步
照片來源：preact.co.uk
為了提高效率並減輕同伴的個人負擔，Prysm正在利用循環同步策略來檢索塊。該機制將均勻地在對等體之間劃分批量塊請求。與多個對等體同步減少了服務分叉鏈或有目的無效塊的單個對等體的攻擊機會。此外，它減少了單個對等體的負載，因為它們只服務於整個請求的子集。我們希望此策略在加入網路時提供更快，更安全的初始塊同步。
使用指數退避進行狀態生成
對於具有弱主觀性的系統（如ETH2.0）而言非常重要的一個客戶端功能是狀態生成。ETH2客戶端必須設計為重新生成過去的狀態，直到至少最近的最終狀態。這是為了重新組織我們的鏈以與fork對齊。我們還可以為RPC調用或依賴於我們具有某種過去狀態的任何其他事件重新生成先前狀態。
我們將使用一種稱為e xponential backoff的策略來生成狀態，這意味著我們只保存從當前狀態到2的冪的狀態，直到最近的最終狀態。例如，如果自上次最終確定狀態以來我們有2個完整的紀元（128個插槽），我們會將狀態保存在128,64,32,16,8,4和2個插槽中。由於我們從最終點保存所有塊，我們可以使用它們從保存的點向前重新生成狀態。這比為每個槽保存狀態要輕得多，因為reorgs最常發生在最近的狀態中。
對貢獻感興趣？
我們一直在尋找有興趣幫助我們的開發者。如果你知道Go或Solidity，並希望為以太坊的研究做出貢獻，請給我們留言，我們非常樂意幫助你。:)
查看我們的貢獻指南以及我們在Github上的開放項目。每個任務和問題都分為0階段里程碑及其所屬的特定項目。
與往常一樣，在Twitter上關注我們或加入我們的Discord伺服器，讓我們知道您想要提供哪些幫助。
官方，Prysmatic Labs以太坊捐贈地址