Arweave 已經有很多完全落地的應用，並且對標的都是 Web2 級別的體驗。

作者：Zeke，YBB Capital  Researcher

封面：Photo by Resource Database on Unsplash

前言

Web3 如今分化出的兩種主流區塊鏈架構設計已經讓人難免有些審美疲勞，不管是泛濫成災的模組化公鏈還是總強調性能卻體現不出性能優勢的新型 L1，其生態可以說都是對乙太坊生態的複刻或者細微改進，同質化極高的體驗早已讓使用者失去新鮮感。 而 Arweave 最新提出的 AO 協定卻令人眼前一亮，在存儲公鏈上實現超高性能運算甚至達成准 Web2 的體驗。 這與我們目前所熟知的擴容方式和架構設計似乎有著巨大的差別，那麼 AO 究竟是什麼？ 支援其性能的邏輯又從何而來？

如何理解 AO

AO 的命名來自於併發運算模型 Actor Model 中一種程式設計範式 Actor Oriented 的縮寫，其整體設計思路源於對 Smart Weave 的延伸，同時也遵循 Actor Model 以消息傳遞為核心的理念。 簡單來說，我們可以將 AO 理解為一台通過模組化架構運行在 Arweave 網路之上的「超併行電腦」。 從實現方案上看，AO 其實並非我們當下常見的模組化執行層，而是一個規範消息傳遞與數據處理的通信協定。 該協定的核心目標旨在通過資訊傳遞實現網路內不同「角色」的協作，從而實現一個性能可無限疊加的計算層，最終使得 Arweave 這塊「巨型硬碟」能夠在去中心化信任環境下擁有中心化雲級別的速度、可伸縮的計算能力及具備可擴充性。

AO 的架構

AO 的理念看起來與 Gavin Wood 在去年 Polkadot Decoded 大會上提出的「Core Time」分割與再組合有些異曲同工之處，兩者都是通過對計算資源的調度與協調，以實現所謂的「高性能世界計算機」。。 但兩者在本質上其實有一些區別，異構調度（Exotic Scheduling）是對中繼鏈區塊空間資源的解構與重組，對於波卡的架構並沒有太大改變，計算的性能雖然突破了插槽模型下單一平行鏈的限制，上限卻依舊受限於波卡的最高閑置核心數。 而 AO 理論上可以通過節點的水準擴展提供近乎無限的計算能力（在實際情況下應該取決於網路激勵水準）和更高的自由度，從架構上來說，AO 規範了數據處理方式和消息的表達，並通過三個網路單元（子網）完成資訊的排序、調度與計算，其規範方式與不同單元的職能，據官方資料分析可概述為以下幾點：

  • 進程（Process）：  行程可被視為 AO 中執行指令的集合，進程在初始化時可定義它所需的計算環境，包括虛擬機、調度程式、記憶體需求和必要的擴展。 這些進程保持一種「全息」狀態（每個進程數據都可獨立存儲狀態至 Arweave 的消息日誌中，下文」可驗證問題「部分中會對全息狀態做出具體解釋），全息狀態意味著進程能夠獨立工作，且執行是動態的，可以由適當的計算單元來執行。 除了從使用者錢包接收消息之外，進程還可通過信使單元轉發來自其它進程的消息;
  • 消息：使用者（或者其它進程）每次與進程的交互都由一條消息來表示，消息必須符合 Arweave 原生的 ANS-104 數據項，從而保持本機結構一致，以便於 Arweave 對資訊的保存。 從更易理解的角度來說消息就有點類似傳統區塊鏈中的交易 ID（TX ID），但兩者並不完全相同;
  • 信使單元（MU）： MU 通過一種稱為『cranking』的過程中繼消息，負責系統中通信的傳遞，以確保無縫交互。 一旦消息被發出，MU 就會將其路由到網路內的適當目的地（SU），協調交互並遞歸地處理任何生成的寄件箱消息。 此過程將持續進行，直到處理完所有消息。 除了消息中繼之外，MU 還提供各種功能，包括管理進程訂閱和處理定時 cron 交互;
  • 調度程式單元（SU）：當收到消息時，SU 會啟動一系列關鍵操作來維護進程的連續性和完整性。 在接收到消息后，SU 會分配一個唯一的增量 nonce，以確保相對於同一進程中其他消息的順序。 這個分配過程通過加密簽名進行形式化，保證真實性和序列完整性。 為了進一步提高進程的可靠性，SU 將簽名分配和消息上傳到 Arweave 數據層中。 這樣可以確保消息的可用性和不變性，並防止數據篡改或丟失;
  • 計算單元（CU）：CU 通過在一個點對點的計算市場內相互競爭，以完成使用者與 SU 解決計算進程狀態的服務。 一旦狀態計算完成，CU 便會返回一個帶有特定消息結果的簽名證明給調用者。 此外，CU 還能生成併發佈其他節點可以載入的簽名狀態證明，當然這也需要支付一定比例的費用。

操作系統 AOS

AOS 可被視為 AO 協定中的作業系統或者說終端工具，可用於下載、運行和管理線程。 它提供了一個環境，使開發者能夠在其中開發、部署和運行應用程式。 在 AOS 上，開發者可以利用 AO 協定進行應用程式的開發和部署，並與 AO 網路進行互動。

運行邏輯

Actor Model 推崇著一種叫「一切皆是演員」的哲學觀點。 該模型內的所有元件和實體都可以被視為「演員」，每個演員都有自己的狀態、行為和郵箱，它們通過異步通信進行消息傳遞與協作，從而使得整個系統能夠以一種分散式和併發的方式來組織和運行。 AO 網路的運行邏輯也是如此，元件乃至使用者都可被抽象為「演員」，並通過消息傳遞層相互通信，使得進程相互連結，一個可並行計算且非共享狀態的分散式工作系統就在交織中被建立起來了。

以下是關於資訊傳遞流程圖步驟的簡述：

  1. 訊息的發起：
    1. 使用者或進程創建消息向其它行程發送請求。
    2. MU（信使單元）接收到該消息，並使用 POST 請求將其發送到其他服務。
  2. 訊息的處理和轉發：
    1. MU 處理 POST 請求並將消息轉發到 SU（調度單元）。
    2. SU 與 Arweave 儲存或資料層進行交互，將消息存儲起來。
  3. 根據消息 ID 檢索結果：
    1. CU（計算）接收到 GET 請求，根據消息 ID 檢索結果，並評估消息在進程上的情況。 它能夠根據單個消息標識碼返回結果。
  4. 檢索資訊：
    1. SU 接收到 GET 請求，根據給定的時間範圍和進程 ID 檢索消息資訊。
  5. 推送寄件匣消息：
    1. 最後一步是推送所有寄件箱消息。
    2. 此步驟涉及檢查結果物件中的消息和生成。
    3. 根據此檢查的結果，可以對每個相關消息或生成重複執行步驟 2、3 和 4。

AO 改變了什麼？「1」

與常見網路的區別：

  1. 並行處理能力：與乙太坊等網路不同，後者的基礎層和每個 Rollup 實際上都作為單一進程運行，AO 支援任意數量的進程並行運行，同時確保計算的可驗證性保持完整。 此外，這些網路在全球同步狀態下運行，而 AO 進程保持自己的獨立狀態。 這種獨立性使得 AO 進程能夠處理更高數量的交互和計算的可擴充性，使其特別適合對高性能和可靠性有需求的應用程式;
  2. 可驗證的可復現性：雖然一些去中心化網路，如 Akash 和點對點系統 Urbit，確實提供了大規模的計算能力，但與 AO 不同，它們不提供交互的可驗證復現性，或者依賴於非永久性存儲解決方案來保存它們的交互日誌。

AO 的節點網路與傳統計算環境的不同之處：

  • 相容性：AO 支援各種形式的線程，無論是基於 WASM 還是 EVM 的，都可以通過一定的技術手段架接到 AO 上。
  • 內容共創類專案： AO 還支援內容共創類的專案，可以在 AO 上發布 atomic NFT，上傳數據結合 UDL 在 AO 上構建 NFT。
  • 數據組合性：AR 和 AO 上的 NFT 可以實現數據組合性，允許一篇文章或內容在多個平臺上共用和顯示，同時保持數據源的一致性和原始屬性。 當內容發生更新時，AO 網路能夠將這些更新狀態廣播給所有相關平臺，確保內容的同步和最新狀態的傳播。
  • 價值回饋和擁有權：內容創作者可以將他們的作品作為 NFT 出售，並通過 AO 網路傳遞擁有權資訊，實現內容的價值回饋。

對項目的支撐：

  1. 基於 Arweave 構建：AO 利用 Arweave 的特性，消除了與中心化供應商相關的脆弱性，如單點故障、數據洩露和審查制度。 AO 上的計算是透明的，可通過去中心化的信任最小化特性和存儲在 Arweave 上的可復現消息日誌來驗證;
  2. 去中心化基礎：AO 的去中心化基礎有助於克服物理基礎設施施加的可擴展性限制。 任何人都可以從他們的終端輕鬆創建一個 AO 進程，無需專門的知識、工具或基礎設施，確保了即使是個人和小規模實體也能擁有全球影響力和參與度。

AO 的可驗證問題

在我們理解了 AO 的框架與邏輯之後，通常會有一個普遍問題。 AO 似乎沒有傳統去中心化協定或者鏈的全域特徵，僅通過上傳一些數據到 Arweave 便可實現可驗證性與去中心化？？其實這正是 AO 設計的奧妙之處。 AO 本身就是鏈下實現，也不解決可驗證性問題，也不更改共識。 AR 團隊的思路是將 AO 與 Arweave 的職能剝離，再模組化銜接，AO 只進行通信與計算，Arweave 只提供存儲與驗證。 兩者的關係更像是映射，AO 只需確保交互日誌存儲在 Arweave 上，其狀態就可以投影到 Arweave，從而創建全息圖，這種全息狀態投影保證了在計算狀態時輸出的一致性、可靠性、確定性。 此外通過 Arweave 上的消息日誌也可反向觸發 AO 進程執行特定的操作（可以根據預設條件和時程表，自行喚醒，並執行相應的動態操作）。

依據 Hill 與 Outprog 的分享，如果把驗證邏輯說的再簡單一點，那麼可以將 AO 想像為一個基於超並行索引器的銘文計算框架。 我們都知道比特幣銘文索引器驗證銘文，需要從銘文中提取 JSON 資訊，並將餘額資訊記錄在鏈下資料庫中，通過一套索引規則完成驗證。 雖然索引器是鏈下驗證，但用戶可以通過更換多個索引器或者自己運行索引來驗證銘文，從而無需擔心索引器作惡。 我們在上文中提到了消息的排序以及進程的全息狀態等數據都上傳至 Arweave，那麼只需要基於 SCP 範式（存儲共識範式，此處可以簡單理解為 SCP 是索引規則在鏈上的索引器，另外值得注意的是 SCP 出現的時間遠比索引器早），任何人都可以通過 Arweave 上的全息數據恢復 AO 或者 AO 上的任何一個線程。 使用者也不需要跑全節點去驗證可信狀態，同更換索引一樣，使用者只需通過 SU 向單個或多個 CU 節點提出查詢請求即可。 而 Arweave 的存儲能力高且費用低廉，所以在這套邏輯下，AO 開發者可以實現遠超比特幣銘文功能的超級計算層。

AO 與 ICP

我們再用一些關鍵詞總結一下 AO 的特性：巨型原生硬碟、無上限並行、無上限計算、模組化的整體架構以及全息狀態的進程。 這一切聽起來都特別美好，但熟知區塊鏈各種公鏈專案的朋友可能會發現 AO 與一個「天亡級」項目特別相似，也就是曾經風靡一時的「互聯網計算機」ICP。

ICP 曾被譽為區塊鏈世界的最後一個天王級專案，深受頂級機構熱捧，在 21 年的瘋狂大牛中也達到過 2000 億美金的 FDV。 但隨著浪潮退去，ICP 的代幣價值也呈直線下降。 直至 23 年熊市 ICP 代幣價值相較於歷史最高位，已經跌了將近 260 倍之多。 但如果不考慮 Token 價格的表現，即便在當前這個時間節點重新審視一遍 ICP，其技術特點依舊有很多獨到之處。 AO 如今令人驚歎的許多優勢特性，ICP 當年同樣具備，那麼 AO 會如同 ICP 一樣失敗嗎？我們先來瞭解一下兩者為什麼會如此相似，ICP 與 AO 都是基於 Actor Model 設計，側重於局部運行的區塊鏈，所以兩者特性才會存在很多共同之處。 ICP 子網區塊鏈由一些獨立擁有和控制的高性能硬體設備（節點機）形成，這些硬體設備運行互聯網計算機協定（ICP）。 互聯網計算機協定由許多軟體元件實現，這些元件作為一個捆綁包是一個副本，因為它們在子網區塊鏈中的所有節點上複製狀態和計算。

ICP 的複製架構從上至下可分為四層：

點對點（P2P）網路層：用於收集和通告來自使用者、其子網區塊鏈中的其他節點以及其他子網區塊鏈的消息。 對等層收到的消息將被複製到子網中的所有節點，以確保安全性、可靠性和彈性;

共識層：選擇並排序從使用者和不同子網收到的消息，以創建區塊鏈區塊，這些區塊可以通過形成不斷發展的區塊鏈的拜占庭容錯共識進行公證和最終確定。 這些最終確定的塊被傳遞到消息路由層;

消息路由層：用於在子網之間路由用戶和系統生成的消息，管理 Dapp 的輸入和輸出佇列，並安排消息執行;

執行環境層：通過處理從消息路由層接收到的消息來計算執行智能合約所涉及的確定性計算。

子網區塊鏈

所謂的子網是交互副本的集合，這些副本運行共識機制的單獨實例，以便創建自己的區塊鏈，在該區塊鏈上可以運行一組「容器」。 每個子網都可以與其他子網通信，並由根子網控制，根子網使用鏈密鑰加密技術將其許可權委託給各個子網。 ICP 使用子網來允許其無限擴展。 傳統區塊鏈（以及各個子網）的問題在於它們受到單個節點機器的計算能力的限制，因為每個節點都必須運行區塊鏈上發生的所有事情才能參與共識演算法。 並行運行多個獨立子網使得 ICP 突破了這一單機障礙。

為什麼失敗

如上文所述，ICP 架構想實現的目的，簡單來說就是去中心化的雲伺服器。 在幾年前這個構想也如同 AO 一樣令人震撼，但為什麼會失敗呢？簡單來說就是高不成低不就，在 Web3 與自己的構想之間並沒有找到一個很好的平衡點，最終導致專案並不 Web3 也不如中心化雲好用的尷尬局面，總結來說問題有三點。 第一，ICP 的程式系統 Canister，也就是上文中的「容器」其實有點類似於 AO 中的 AOS 和進程，但兩者並不一樣。 ICP 的程式是被 Canister 封裝實現的，外界並不可見，需要通過特定介面去訪問數據。 在異步通信下對於 DeFi 協定的合約調用很不友好，所以在 DeFi Summer 中，ICP 並沒有捕獲到相應的金融價值。

第二點是硬體要求極高，導致專案並不去中心化，下圖是當時 ICP 給出的節點最低硬體配置圖，即便放在現在也是非常誇張，遠超 Solana 的配置，甚至存儲要求比存儲公鏈還高。

第三點是生態匱乏，ICP 即便放到現在也是性能極高的公鏈。 如果說沒有 DeFi 應用，那麼其它應用呢？抱歉，ICP 從誕生至今也沒跑出一個殺手級應用，其生態既沒有捕獲到 Web2 的使用者，也沒有捕獲到 Web3 的使用者。 畢竟在去中心化程度如此不足的情況下，為什麼不直接使用內容豐富且成熟的中心化應用呢？但最後不可否認的是 ICP 的技術依舊很頂尖，其反向 Gas、高相容性、無限擴展的優勢還是吸引下一個十億使用者所必備的，而在當前的 AI 浪潮下，ICP 如果能善用自身的架構優勢也許還存在翻身的可能。

那麼回到上文中的問題，AO 會像 ICP 一樣失敗嗎？我個人認為 AO 並不會重蹈覆轍，首先導致 ICP 失敗的後兩點，對於 AO 來說都不是問題，Arweave 已經有很好的生態基礎了，全息狀態投影也解決了中心化問題，相容性上 AO 也更為靈活。 更多的挑戰也許要集中於經濟模型上的設計，對於 DeFi 的支撐，以及一個世紀難題：在非金融與存儲領域，Web3 該以什麼形式展現？

Web3 不應止於敘事

Web3 的世界中出現頻率最高的詞語必然是「敘事」，我們甚至已經習慣用敘事的角度去衡量大部分代幣的價值。 這自然是源於 Web3 大部分項目願景很偉大，用起來卻很尷尬的窘境。 相較之下 Arweave 已經有很多完全落地的應用，並且對標的都是 Web2 級別的體驗。 譬如 Mirror、ArDrive，你如果使用過這些項目應該很難感受到與傳統應用的差別。 但 Arweave 作為存儲公鏈的價值捕獲依然存在很大的局限性，計算也許是必由之路。 尤其在如今的外部世界中，AI 已是大勢所趨，Web3 在現階段的結合中還存在很多天然的壁壘，這點我們在過去的文章也談到過。 現在 Arweave 的 AO 用非乙太坊模組化方案的架構，給了 Web3 x AI 一個很好的新基建。 從亞歷山大的圖書館到超並行計算機，Arweave 在走一條屬於自己的範式。

參考文章

  1. AO 快速入門：超級並行計算機簡介：https://medium.com/@permadao/ao-快速入門-超級並行計算機簡介-088ebe90e12f
  2. X Space 活動實錄|AO 是不是乙太坊殺手，它將怎樣推動區塊鏈的新敘事？：https://medium.com/@permadao/x-space-活動實錄-ao-是不是乙太坊殺手-它將怎樣推動區塊鏈的新敘事-bea5a22d462c
  3. ICP 白皮書：https://internetcomputer.org/docs/current/concepts/subnet-types
  4. AO CookBook：https://cookbook_ao.arweave.dev/concepts/tour.html
  5. AO — — 你無法想像的超並行計算機：https://medium.com/@permadao/ao-你無法想像的超並行計算機-1949f5ef038f
  6. 多角度分析 ICP 沒落的原因：特立獨行的技術與冷清單薄的生態：https://www.chaincatcher.com/article/2098499

免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。

欢迎加入 Web3Caff 官方社群：X(Twitter)账号丨微信读者群丨微信公众号丨Telegram订阅群丨Telegram交流群