Lighthouse 客戶端背後的技術堆棧是什麼？
Lighthouse 的主要組件是什麼？它考慮並決定了哪些數據庫？
其架構中是否存在與其他信標鏈客戶端的設計和實現方式特別不同的元素？
Lighthouse 的主要組件是什麼？
從一個非常高的層次來看，我們有三個組件，每個組件都從一個
lighthouse程序啟動：
- 信標節點：連接到 p2p 網路，驗證塊和其他消息，將它們儲存在數據庫中並允許通過 API 訪問。
- 驗證器客戶端：負責控制驗證器密鑰並決定何時生成塊/證明以及它們是否可罰沒。依靠信標節點作為信標鏈的真相來源，並為區塊生產做大量繁重的工作。
- 客戶經理：負責密鑰生成和錢包管理。這是您生成驗證器密鑰並進行自動 eth1 存款送出的地方。
對於低級的東西，我會引導你到@protolambda的基於 Lighthouse 堆棧的簡潔圖表：
https://twitter.com/protolambda/status/1256186181840252929?s=20
它考慮並決定了哪些數據庫？
對於我們
leveldb現在使用的主要客戶端數據庫。它是眾所周知的並且性能相當好。LMDB但是，我們可能會在不久的將來某個時候換成；我們已經在使用它進行原型設計。我們一直專注於優化我們的數據庫模式和訪問方法，而不是預先鎖定數據庫。我們在數據庫優化方面做了很多領先的工作（我們已經在其他客戶中看到了我們的設計），我們希望在鎖定技術之前確定需求。
對於我們正在使用的驗證器削減保護數據庫
SQLite。它很簡單，經過實戰考驗，並且適用於該特定模式。它也有非常令人印象深刻的一致性保證。其架構中是否存在與其他信標鏈客戶端的設計和實現方式特別不同的元素？
從早期開始，我們在優化狀態轉換函式方面做了很多工作。再一次，我們看到我們的設計被多個客戶使用，我們總是很樂意分享我們的見解。高性能對我們來說非常重要，因為我們希望減少驗證器成本成本並在網路攻擊期間保持執行。
此外，我們一直致力於實現“無恐慌”狀態轉換。這意味著檢查所有算術和數組訪問，並避免未定義的行為。我們不斷地在我們的狀態轉換實現中拋出隨機數據（稱為“模糊測試”），以嘗試檢測是否有任何我們遺漏的東西。值得慶幸的是，Rust 對於這類任務來說是一種很棒的語言，它專注於安全性。
最終，我們希望安全快速。這並不是說其他客戶不會那麼好:)