Fluence聯合創始人：如何保證分佈式數據庫的安全

個人計算機出現之前，由一些終端提供計算資源。這些終端不需要太多硬件，只要能連接到主機就行，就像是區塊鏈裏的輕客戶端。

當硬件後來足夠便宜，計算資源開始轉移到用戶端上 - 媒體，遊戲，辦公軟件包，科學工具包 - 這些都在臺式機上運行。今天，大部分計算已經轉移到了雲端。通過連接到雲主機，瀏覽器現在扮演着類似於過去終端的角色 ，這種模式可以很好地擴展到數十億用戶。

多個數據中心中的大量計算機組成了雲，與高吞吐量網絡連接，隨時可以提供計算資源和服務請求。這稱爲IaaS - 基礎架構即服務。雲提供商負責監控和修復此基礎架構，以便開發人員可以專注於開發軟件。

雲計算不僅僅是基礎設施。最重要的是，雲提供商部署中間服務：數據庫，消息隊列，lambda函數，數據處理引擎。雖然這些服務不直接與終端用戶交互，但它們構成了軟件架構的重要組成部分，通常稱爲PaaS - 平臺即服務。

通常，雲的中間服務實際上是一個包含在託管服務中的現有開源軟件包。例如，AWS提供RDS作爲流行數據庫MySQL和PostgreSQL 的託管版本，Msk作爲消息隊列Kafka 的託管版本，以及ElastiCache作爲Redis和Memcached的託管版本。

如果有這麼多不同的開源庫和框架，爲什麼開發人員會使用託管雲服務呢？因爲使用它們比執行所有必需的手動DevOps工作容易得多。雲提供商負責配置硬件，安排備份和複製，連接監控和警報系統，以及在出現問題時恢復服務。此外，託管服務可以完美地相互集成，並允許用戶簡單快速構建新的應用。

但是，這種方便的代價是將開發人員牢牢地被雲提供商給鎖住了。開發人員使用的雲服務越多，他們就越容易受到各種雲提供商的影響。

Web 3協議可以減少對中間商的依賴，並不太複雜，開發人員可以獲得與傳統雲提供商一樣的直觀簡單體驗。在這種情況下，託管服務就是獨立的協議了。例如，像AWS S3這樣的對象存儲服務可以由Filecoin，Swarm或Arweave代替，密鑰管理服務AWS KMS由NuCypher代替，媒體流服務AWS Elemental MediaConnect由LivePeer代替。

那麼，分佈式的雲服務可能是什麼樣的呢？

分佈式雲夢想

分散式雲是在無需信任的節點網絡中運行的，其中軟件完全從底層硬件中抽離出來，任何有資源的人都可以運行硬件。Redis，MySQL，Kafka或Spark等開源軟件包可以移植到分佈式雲中，提供的服務就像傳統雲一樣。

沒有必要重新實現之前創建的數百個開源工具和庫 - 它們只能在分散的基礎架構之上運行。由於這些服務將在開放網絡中運行，因此它們將能夠彼此無縫集成。

最後，運行時出現的問題將由更多的社區開發人員監控和修復，而不是私有云部署。開源社區將能夠進行協作，不僅可以編寫代碼，還可以運行代碼。

爲什麼這個想法還沒有成爲現實？要回答這個問題，我們需要考慮在基礎上構成雲的內容。雖然雲可能由大量不同的服務和協議組成，但在其基礎上您只能找到幾個關鍵組件：計算，數據存儲和網絡。

分散數據存儲似乎是一個幾乎已經解決的問題：Filecoin，Swarm和Arweave可以保證數據的可用性和耐用性，並且有可能比傳統的雲存儲更便宜，更強大。

計算的分散化要困難得多，但有幾種不同的方法可用於運行任意的圖靈完備程序：

胖客戶端（也稱爲全節點）：客戶端具有運行程序並在本地執行計算所需的所有數據，這實際上使客戶端成爲全節點。數據本身可以從分散存儲下載，或者從其餘網絡節點找出。

雖然簡單，但這種方法並不總是適用於當前模型，服務器承載大部分工作負載，客戶端和服務器之間的網絡吞吐量有限。

零知識證明：全節點可以在本地執行程序，然後向客戶端提供計算執行正確的證據。理想情況下，客戶端應該花費很少的資源來驗證所提供的證據，並且在整個節點側準備這樣的證據的開銷應該可以忽略不計。

不幸的是，目前，計算零知識證明可能比執行計算本身需要多幾個數量級的資源。因此，很難將這種方法用於大規模計算。

瘦客戶端+ 默克爾證明：對於任何基於指針的數據結構，可以構建默克爾證明以檢索其存儲的部分數據。客戶端可能只從分散的網絡下載它感興趣的數據片段，驗證檢索是否正確，執行計算，並將結果上傳回網絡。這樣，帶寬消耗保持較低，並且仔細使用客戶端資源。

例如，這是OrbitDB使用的一種方法 - 一種無服務器的數據庫，用於在IPFS中存儲數據並使用CRDT，用於不同客戶端之間的同步 OrbitDB允許開發人員使用相當複雜的數據結構：除了鍵值存儲之外，它還支持可變和不可變的日誌，計數器甚至搜索功能。,

但是，對於許多用例，不可能使用此方法。例如，要處理臨時聚合查詢或連接操作，客戶端基本上需要成爲全節點，因爲此類查詢類型通常需要從一個或多個表中讀取大量行，這些都需要傳輸到客戶端。

瘦客戶端+區塊鏈：最後，可以在區塊鏈中運行計算，其中多個節點運行相同的程序並相互驗證。運行相同計算的節點越多，系統的安全性就越高。這是因爲大多數節點作惡的可能性隨着節點數量的增加而下降。

在以太坊裏，節點的數量可以達到數千個，這讓以太坊成爲一個非常安全但與雲相比不太具成本效益的系統。區塊鏈分片可以顯着減少運行相同計算所需的節點數量，但這種減少是否足以滿足雲級成本的效率性？

我們還應該注意，在瘦客戶端+ 默克爾證明方法（以及胖客戶端方法）中，願意使用計算結果的各方需要信任執行此計算的一方。從本質上講，計算結果來自一個oracle：默克爾證明無法阻止已經在一個塊裏下載了5，在另一個塊中下載了3的惡意客戶端，然後將6作爲求和結果上傳回分散存儲。這意味着只有零知識證明和瘦客戶端+區塊鏈方法才能在無需信任的環境中提供足夠的可組合性。

分佈式數據庫的差距

讓我們回到現實，考慮一種特殊但非常有用的雲中間件 - 託管數據庫服務。除了是一個結合了計算和存儲的優秀模型之外，數據庫也是最常用的雲服務之一 - 幾乎每個程序都使用SQL或NoSQL數據庫。

值得注意的是，我們尚未看到AWS RDS的分散版本（提供託管的MySQL和PostgreSQL）或AWS Elasticache的分散版本（提供託管的Redis和Memcached）。

爲什麼會這樣？原因是數據庫不僅僅是存儲; 他們也是關於計算的。除了本文中已經提到的聚合查詢和連接操作之外，數據庫還可以運行存儲過程和用戶腳本，執行批量數據更新以及應用內置和用戶定義的函數。

結合快速處理請求和存儲大量數據的要求，將開源數據庫移植到分散環境變得非常具有挑戰性。分片方法似乎是最實用的，但在我們最終開始走這條路之前，讓我們分析一下雲數據庫通常帶有多少冗餘。

雲環境中的冗餘

首先，雲數據庫通常使用多個副本來實現高可用性，並且在某些情況下，可以增加讀取吞吐量。通常，這些副本中的一個被指定爲主副本並提供所有讀取和寫入請求，而其他副本則用作備用數據庫：如果主副本發生故障，其中一個備用數據庫將替換它。此外，雖然備用數據庫不提供寫請求，但它們仍然可以響應只讀查詢，允許它們並行化某些負載。

通常使用哪些複製因子？它取決於工作負載類型，但對於AWS RDS 2×複製（一個主副本和一個備用副本）通常用於聯機事務處理，並且可能會增加事務處理和分析查詢的混合。Cassandra（一種流行的分佈式NoSQL數據庫）的部署可以爲標準和5倍複製提供關鍵任務數據的3倍複製。通常，似乎2×到5×冗餘是很常見的。

其次，除了數據庫複製之外，還經常使用備份。在這種情況下，會定期獲取數據庫狀態的快照並將其上載到外部存儲服務（如AWS S3）。如果每天拍攝快照，外部存儲可能會保留上週的快照價值。

在這裏我們還應該注意，外部存儲也很可能也有一些冗餘。雖然AWS S3擁有的每個存儲對象的副本數量沒有確切的數字，但基於其99.999999999％的持久性保證，我們可以推測通常至少有三個不同的設備應該保留相同的數據。

如果複製已經到位，爲什麼要備份？其中一個最關鍵的原因是備份允許在某個特定時間點恢復數據庫狀態。這可能很有用，例如，如果有人意外發出DROP TABLE命令，然後在持有此表的所有副本中重複該命令。在單獨的撤銷日誌的幫助下，這樣的命令不能輕易回滾 - 但是使用最新的快照可以恢復至少一些存儲的數據。

總而言之，我們假設的雲數據庫所需的冗餘是主/備用副本的2倍到5倍複製因子加上一些外部存儲3×複製的數據庫快照。我們可以用分片區塊鏈重複這個嗎？爲了簡單起見，讓我們暫時忘記跨分片事務 - 許多Web應用程序只使用一個數據庫實例。

對預算進行分類

假設我們已經爲僅5倍到10倍的冗餘分配了預算。我們可以通過推出一個只有7個基於拜占庭共識驗證者，每個驗證者都帶有一個數據庫副本嗎？不幸的是，它並不是那麼簡單 - 這樣的分片不太安全。

孤立的碎片安全

假設網絡中的一小部分p節點是惡意的。許多拜占庭共識引擎（例如Tendermint）可以容忍由n = 3k + 1個節點組成的分片中的k個惡意節點。反過來說，我們可以認爲，如果分片中的n - k（即2n / 3）或更多節點是惡意的，那麼它們就可以完全接管這個分片並“容忍”誠實的節點。假設分片中的節點是從網絡中隨機抽樣的，則分片接管的概率爲：

對於具有7個節點的模型分片，只需要5個惡意節點來抓住它。我們假設網絡中惡意節點的比例是10％。通過將這些值代入上面的公式，我們得到碎片接管的概率約爲0.017％。即使對於沒有嚴格安全要求的臨時應用程序，這可能太高了。

我們如何防範這種情況？在某些設計中，如果誠實節點在分片中具有⅔多數，則它們可以削減那些簽署了錯誤狀態轉換的節點的存款。但在我們的案例中，惡意節點可以執行他們想要的任何狀態轉換，而無需與誠實的節點交談。

此外，由於惡意節點緊密連接，只有當它們代表碎片中的⅔多數時，它們才能協調和行爲不端- 基本上，當惡意節點沒有任何冒險行爲時。這意味着，如果沒有一些外部監督，瘦客戶端可能永遠不會知道該碎片是不誠實的。

使用共享驗證程序池保護碎片

爲了保護分片，無論它們只有幾個節點還是數百個，通常使用兩種技術：驗證器輪換和漁民節點。從本質上講，這些技術非常相似：網絡中的某個節點驗證了分片只執行了正確的狀態轉換。如果驗證節點發現錯誤的狀態轉換，它可以挑戰這種情況。在這種情況下，如果驗證節點能夠證明狀態更新不正確，則批准錯誤轉換的節點將丟失其存款。

一種選擇是驗證節點替換分片中的另一個節點（在這種情況下，我們說驗證器集已經旋轉）並重放該分片所做的最後幾個事務。爲驗證節點另一種選擇是保持獨立，魚在在被獎勵的希望不同的碎片不正確的狀態轉換。無論使用哪種方法，理念都保持不變：分片不僅由屬於它的節點而且由整個網絡保護。

聽起來不錯，對嗎？但是，如何將分片交易歷史轉移到新加入的驗證者節點或漁民？一個問題是，如果分片中的節點數量很少，則歷史和狀態傳輸可能會對分片施加過多負載，從而阻礙分片實時處理事務的能力。另一個問題是捕獲的分片中的惡意節點可能完全拒絕共享有罪的證據。

分散存儲的救贖

一種解決方案是在外部存儲分片的事務歷史記錄。請考慮以下事項：每當分片處理一個塊時，它就可以將該塊上傳到分散的存儲網絡，並向感興趣的客戶提供該塊確實已上載並正確上載的證據。上傳塊後，分散存儲網絡負責在請求時提供存儲的數據。查看此Swarm文章，瞭解有關協議如何執行此職責的更多信息。

現在，漁民可以從分散存儲下載交易歷史的不同片段，重複計算，並挑戰不正確的狀態轉換。作爲副作用，漁民將計算新狀態，然後他們可以將其作爲快照上傳到分散存儲。然後，可以將此快照用作進一步驗證的起點，或者在整個分片失敗時用作備份。

驗證器輪換可以以類似的方式實現：新的驗證器將從分散存儲下載狀態和事務歷史的所需部分，而不會使分片過載。此外，即使整個分片失敗，也可以使用來自分散存儲的數據作爲備份來恢復它。

請注意，由於此設計中的漁民與碎片斷開連接，因此可以使漁民選擇完全隨機。這樣，當分片正在處理事務時，它不知道它是否會被誠實或惡意的漁民驗證，這會對分片節點施加重大壓力以誠實行事。我們還將在此提出一個暗示（在以下帖子中提到），可以防止漁民知道他們的判決是否會被重新覈實。

驗證遊戲和一致的“共識”

以前，我們提到驗證節點可以證明不正確的狀態轉換。是否有可能以具有成本效益的方式這樣做？答案是“是”：一種方法是使用TrueBit風格的驗證遊戲：如果兩個節點不同意事務應如何更新狀態，則應該可以在不同意的情況下找到單個虛擬機指令的處理。一旦找到這樣的指令，就可以要求外部的，可信賴的法官（例如，以太坊）重複它以找出應該如何處理該指令的正確方法。

請注意，在這種情況下，只有一小部分計算在鏈上進行處理，因此判斷不會過載。此外，可以通過在n-ary搜索的幫助下爭議節點來找到質疑的指令 - 也就是說，沒有太多的計算開銷。

請注意，驗證遊戲機制只需要一個誠實的節點來捕獲惡意行爲。換句話說，碎片節點和漁民必須就如何進行狀態轉換達成一致的“共識”。

讓我們找出完全不被注意的惡意行爲的概率。假設除了由n個節點組成的碎片之外，我們還有m個漁民獨立地驗證這個碎片。只有在碎片被接管並且所有漁民都是惡意的時候纔會檢測到惡意行爲：

如果我們將分片中的4個節點和3個漁民節點之間的計算資源預算分開並保持我們假設網絡中10％的節點是惡意的，則忽略不良行爲的概率變爲0.00037％。這個概率比我們以前的天真模型低兩個數量級！

惡意行爲經濟

如果碎片節點根本無法與漁民節點協調，則這種可能性會進一步下降。想象一下，一些惡意節點能夠接管一個分片。我們還假設這些節點已經在網絡上合併了1,000美元。最後，讓我們假設分片節點是合理的，只有當它們的收益超過損失時纔會執行錯誤的狀態轉換。

如果三個漁民節點稍後驗證了碎片，則惡意節點被捕獲並丟失其利益的概率爲1-0.13 = 99.9％。現在，讓我們計算在他們的行爲變得經濟上有利可圖之前需要獲得多少惡意分片節點。

如果我們假設他們只是在他們的行爲被忽視並且碎片的交易歷史沒有被恢復時才獲利，那麼在1000件中的999件中，他們將失去1,000美元的股份並且什麼都不賺。在1000個案例中的1個案例中，他們將獲得$ x，這應該涵蓋他們失去的所有賭注。解決這個簡單的等式，我們瞭解到惡意分片節點需要至少獲得999,000美元才能實現收支平衡。換句話說，碎片的事務量必須超過一百萬美元才能使攻擊有意義！

這聽起來好得令人難以置信，我們同意：混合系統中惡意行爲的經濟模型要複雜得多。不幸的是，雖然碎片節點事先不知道漁民，因此無法啓動早期對話，但如果他們發現不正確的行爲，一些不那麼誠實的漁民可能會聯繫到碎片節點。然後這些漁民可以要求那些碎片節點收取費用以保持沉默。我們將在進一步的帖子中考慮這個和其他攻擊的經濟細節。

全部放在一起

Fluence Labs正致力於通過將分片式區塊鏈方法與分散式存儲網絡，可信賴的評判和經典的客戶端 - 服務器模型相結合，使分散式雲更接近現實，以部署分散的數據庫網絡，該網絡具有成本效益。傳統的雲。

Fluence是一個混合解決方案，我們在本文前面已經提到了不同方面。Fluence網絡被分成很小的分片，每個分片負責一個獨立的數據庫。這些分片將事務上載到分散存儲，然後共享的漁民池驗證上載的事務歷史記錄。該驗證是與事務處理異步執行的，這允許請求服務延遲保持較低並且用戶體驗是平滑的。

Fluence網絡中的分片組成不會經常更改，這樣可以在新驗證者加入分片時避免過多的數據傳輸。相反，漁民不斷輪換，這提高了整體網絡安全性。如果任何節點不同意如何處理交易，則會啓動對以太坊區塊鏈的爭議，該爭議通過驗證遊戲機制解決。

WebAssembly用作目標虛擬機，結合成本效率，允許將許多編寫良好的開源數據庫移植到Fluence網絡。實際上，我們剛剛移植了Redis，現在期待移植一個生產級SQL數據庫（已經有一個產品  --LlamaDB），比如SQLite。

我們還應該注意到，我們的架構中的延遲驗證允許Fluence進行有效和安全的跨數據庫事務，但這是下一篇文章的主題，以及有關Fluence架構的一些具體細節。

來源：https://medium.com/fluence-network/securing-decentralized-databases-part-i-6736d2a4b2f4

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia