Arweave 重要中間件：詳解去中心化協議 KYVE 及其工作原理

3 年前觀點

作為 Arweave 的重要中間件，KYVE 解決了什麼問題？

內容目錄

基礎概念

1. 什麼是 Arweave？

Arweave 是去中心化數據存儲的協議/網絡
Arweave 實現了數據的永久儲存
Arweave 實現了一次付費永久儲存的經濟模式
Arweave 不是傳統意義的鍊式結構，而是使用了類似圖狀的 Weave 數據結構，新節點無需同步所有舊數據
Arweave 使用 SPoRA ( （Succinct Proofs of Random Access，隨機訪問的簡潔證明） ) 共識，該共識鼓勵存儲更多的數據，儲存更少節點儲存的數據。通過儲存內容+ 算力的方式來競爭出塊，更多共識細節可以參考這裡

2. 什麼是中間件？

中間件是一類介於系統層與應用層中，掩蓋系統層開發細節，直接提供應用層業務所需功能的工具
區塊鏈領域的中間件可以理解為，避免了直接與底層鏈端交互開發，輔助上層應用進行開發的一系列工具，例如 Chainlink/The Graph/Infura 等都屬於中間件

3. 什麼是 KYVE?

KYVE 是一組提供數據流標準化存儲與驗證的去中心化協議
KYVE 協議構建在一條基於 CosmosSDK 的公鏈 Korellia 上
KYVE 是 Arweave 生態最重要的應用之一，作為存儲中間件雙雄 KYVE + Bundlr 之一

4. KYVE 解決了 Arweave 什麼問題？

4.1 擴容問題

鏈上儲存擴容
- 傳統區塊鏈類似 Ethereum 全節點大小已經達到 700G , 日益增長的鏈數據會造成節點的儲存壓力, 也就是我們常說的狀態爆炸問題，不斷提高著新節點加入的門檻。KYVE 最主要的一項業務便是歸檔其它區塊鏈的數據並儲存至 Arweave。區塊鏈數據在歸檔到 Arweave 後可以壓縮裁剪掉可以通過計算還原的歷史中間狀態數據，僅保留較近一段時間的中間狀態數據和最新狀態數據用作節點驗證，大幅縮小儲存壓力。
- KYVE 使用了一種被稱為 Bundle 的批處理技術，將多個數據進行捆綁處理，大大加快存儲與驗證的效率, 也降低了存儲開銷。某種程度上 KYVE 也可以看作 Arweave 的 Rollup。
- KYVE 使用不同的 Runtime 模塊來匹配不同類型的區塊鏈數據類型，抓取區塊數據存儲後，也可以非常方便查找，提供了一定程度的檢索功能
鏈下計算擴容
- 傳統區塊鏈例如 Ethereum 的節點需要同時負責執行/結算/共識/DA 的工作。執行的意思就是每次智能合約的調用，幾乎所有節點都需要去執行一遍計算。這樣做安全性非常高但是也有顯而易見的問題- 效率很低，導致的問題大家也都清楚- 網絡堵塞，費用高昂。這個時候就出現了計算擴容的需求
- 針對傳統區塊鏈的擴容有很多方向, 側鏈/rollup/新共識/鏈下擴容等。鏈下擴容的基礎思路是將執行部分放到用戶本地或者單獨的鏈下節點進行計算。好處是顯而易見的，這裡執行計算的機器只有一台或者少數的幾台，節約了大量計算資源。而且鏈下機器可以針對特定計算類型進行優化，達到計算效率的最優化
- Arweave 的永久儲存特性可以保證鏈上儲存的數據不可更改性 (數據可用性)，這個在鏈下擴容看來就像圖靈機的紙帶，所有的合約代碼與合約運行狀態都可以持續的記錄到 Arweave 上，用戶在使用時將合約代碼與合約的所有運行狀態同步到本地，進行一遍狀態計算確保最新狀態的有效性後，就可以開始執行自己的操作，最後將最新的合約狀態再上傳至 Arweave 完成鏈下計算的功能
- 上面說的 Arweave 提供的這種鏈下計算方法叫做 SmartWeave , 是 Arweave 團隊開發的智能合約執行環境。通過上面流程的描述可以發現一個問題，為了獲得最新狀態數據的有效性保證，用戶在本地執行鏈下計算需要先下載所有歷史狀態數據並進行一遍驗證計算。顯然如果歷史狀態過多或者計算量巨大，用戶每次實際使用前都浪費大量時間和算力在同步歷史數據與驗證最新狀態上。KYVE 通過整個網絡的共識可以保證最新狀態的有效性，那麼借助 KYVE 的最新狀態數據，用戶便可以直接開始自己的鏈下計算工作了，計算完成後通過 KYVE 再將狀態更新回 Arweave。KYVE 解決了上傳下載過程中數據有效性這個對於鏈下計算擴容來說至關重要的問題

4.2 數據跨鏈問題

已有數據跨鏈方案的問題
- 如今最常用的數據跨鏈方案大都遵循監控- 中繼模型, 在源鏈上會有一組合約監控具體的數據狀態並生成證明文件，證明文件通過中繼網絡發送到目標鏈上。這裡可以看到兩個問題，源鏈上的監控者需要持續的監控狀態變更，還需要持續生成證明文件，開銷是一個問題。更重要的問題是數據信息的中繼需要完全信賴中繼網絡，這也是整個系統最薄弱的地方。
- 中繼或者見證人的存在本質上是為了解決 DA 信息相互獨立隔絕的問題。假如多條鏈的 DA 存放在同一個 DA 層上，那所有信息中繼都只是 DA 層內的信息傳遞，安全性等同於 DA 層的安全性，那就只需監控者就可以完成跨鏈。
KYVE + Arweave = DA 層？
- 最近很火的專注於 DA 的區塊鏈 Celestia 最重要的一個 Feature 就是解決了數據跨鏈互操作的問題。因為所有其上的區塊鏈都將 DA 數據存放其中，所以數據跨鏈本質上就只需要監控這一個角色了，所有中繼都是鏈內的信息傳遞，這個安全性等同於區塊鏈的安全性。之前我們討論過 KYVE 保證了數據的有效性，Arweave 保證了數據的可用性，那本質上 KYVE+Arweave 完全可以作為 DA 層，達到和 Celestia 一樣的數據跨鍊和互操作性效果
- KYVE 相較於 Celestia 的優勢在於獲取數據的主動性。KYVE 是中間件，網絡內可以通過治理提案很容易的創建新的數據池來抓取特定區塊鏈的數據。Celestia 是被動獲取構建於其上的執行層的數據，選擇一定程度上是受限的。
- 還有一點我們不能忘記，KYVE 的底層網絡 Korellia 是基於 CosmosSDK 的獨立 POS 鏈。所以 IBC 是完全適用於 KYVE 的，我想像不出還有哪個網絡比 KYVE 更適合作為 Arweave 與 Cosmos 生態的 IBC 接口。

KYVE 架構

5.1 網絡設計

協議層
- 協議層架構於鏈層之上，負責現有 KYVE 業務 (Pools/Fund/Stake/Delegate)
- 創建和維護各種數據池
- 數據池內 Protocol 節點負責上傳和驗證數據
- 數據池內 Protocol 節點負責達成數據有效性共識
- 數據池內節點發送自身狀態到 Chain 節點
鏈層
- Tendermint 共識, 保存 Protocol 節點的狀態
- 負責保證 Protocol 的狀態有效性 (目前只有 KYVE 協議)

5.2 網絡角色

游泳池
- 數據池可以被看做是完成收集及驗數據工作的最小單位
- 數據池內包含 Funder/Protocol Staker/Protocol Delegator 角色
- 數據池的運行規則依賴 runtime 模塊
- 針對不同的虛擬機環境需要不同的 runtime，但是相同的虛擬機環境可以復用 runtime
  - @kyve/evm 可以用在 Ethereum 上，也可以用在 EVM 兼容鏈上 (Moonbeam/Aurora)
  - 對於 Solana 則要使用 @kyve/solana

資助者
- Funder 是每個數據池的資金來源，數據池內所有其它角色的盈利來自於 Funder
- Funder 是需要使用該數據池數據的項目方或者用戶，如果數據池內的 funding 被耗盡則該數據池會停止工作
- 目前每個數據池只有 100 個 Funder 卡槽，目前 Funder 沒有激勵，但是不排除之後針對數據池給與 Funder 的特權與激勵

協議質押者
- Protocol Staker 是數據池內運行節點的角色，真正負責數據池內的上傳驗證等工作
- 成為 Protocol Staker 需要質押 kyve 代幣，如果出現不良行為 (離線/上傳錯誤數據/驗證數據失誤等) 會造成節點內質押代幣的 slash
- Protocol Staker 會按工作量獲得 kyve 代幣獎勵，獎勵和節點代幣質押量相關

協議委託人
- 如果你不想自己運行 Protocol 節點, 可以選擇作為 Delegator, 將 kyve 代幣質押給自己支持的 Staker 來分享節點的工作收益
- Protocol Staker 的不良行為也會造成在其上質押的 kyve 的 Delegator 被 slash
- Protocol Delegator 可以幫助篩選出優質節點，共享網絡收益

鏈樁
- Chain Staker 需要在 Korellia 網絡上運行 Chain 節點，負責 Korellia 網絡的有效與安全
- Chain Staker 在運行 Chain 節點時也需要質押 kyve 代幣，類似於其它 Cosmos 生態鏈

鏈委託人
- Chain Delegator 質押代幣給支持的 Chain Staker 來分享節點工作收益，和其它 cosmos 生態的鏈的 Stake 機制相同

5.3 經濟設計

金庫
- Protocol 節點每次完成 bundle proposal 都會從 Funder 處獲取獎勵，其中 1% 作為網絡費用會被直接扣除到金庫
- Slash 的資金也會進入金庫
- 金庫資金用於網絡的發展與治理
削減
- 無效上傳行為，會造成當事節點 20% 質押代幣的罰沒
- 無效驗證行為，會造成當事節點 10% 質押代幣的罰沒
- 超時離線行為，會造成當事節點 1% 質押代幣的罰沒

KYVE 工作原理

6.1 數據包

為了加快 KYVE 中數據驗證的效率，所有數據在被上傳前都被打包成 bundle，這樣在一個驗證輪內可以同時處理多個數據，數據流也可以被拆分至多個驗證輪中執行。

6.2 捆綁生命週期

1. 選擇一個 Uploader
- 每一個驗證輪由選舉此輪的 Uploader 開始
- Uploader 的選擇與節點 staker 的質押量以及 Delegation 數量相關
2. 創建 Bundle Proposal
- 上面選擇出來的 Uploader 按照設定的 upload_interval 去收集數據
- 一旦收集到足夠數據，數據就被發到 buffer 進行 gzip 壓縮
- 最後創建一個 bundle proposal 之後供其它 validator 進行驗證
3. 上傳 Bundle 到 Arweave, 將上傳信息同步到 Kyve 網絡
- Uploader 將上面打包完成的 bundle 上傳至 Arweave
- 將 Arweave 返回的上傳記錄以及其它上傳信息同步至網絡中
4. Validator 驗證 Bundle 的有效性
- 當 Uploader 將上傳記錄和其它 bundle 信息同步到網絡後，validator 便開始對數據有效性進行驗證
- validator 會從 Arweave 下載原始 bundle 數據，解壓縮，然後把數據解析到原始 json 格式，然後和源數據進行一次哈希比對
- 最後 validators 通過對 proposal 的投票來達成數據有效性的共識
5. 達成網絡狀態的最終性
- 如果超過一半的 validator 確認數據的有效性，則達成網絡狀態的最終性，此 Bundle Id 也可以被提供給外部使用
- 網絡內獎勵的分配