存儲賽道的終極解法?數據雲存儲賽道的前生今世

作者:Ray 來源:X,@RayAC1397

摘要:從雲存儲賽道的前身,分析整個賽道和歷史的變化,接着分析Filcoin和Arweave的問題,最後分析irys的商業模式並預測Irys TGE之後的估值。Irys FDV 3億以下爲低估,至於長期來看是否能夠坐穩雲賽道龍頭老大位置,需要關注業務與tokenomics的契合度以及核心用例是否能夠順利跑通。

關鍵詞:雲存儲賽道分析、Filcoin商業模式分析、Arweave商業模式分析、Irys項目介紹、估值預測、Irys戰略分析

正文:

Chapter 1:從石壁到雲端的演進

在遙遠的美索不達米亞文明,人類第一次有了將信息存儲下來的想法:我們的祖先們聰明地把信息刻在“經久不衰”的石板上;在工業革命時期,音樂作爲一種信息,被存儲在了唱片上;而在計算機時代,人們又發明了磁帶、硬盤、光盤等一系列信息存儲硬件……

數據的存儲方式,從來都是時代進步的剪影。

1956 年,IBM 推出 Model 350,這是一臺足有兩臺冰箱並排那麼大的機器,重量接近一噸,卻只能保存 5MB 的數據,人們需要用吊車將它吊入機房。盡管笨重至極,但它第一次讓“電子存儲”成爲企業能夠付費使用的資源。這種突破改變了信息的命運:它不再完全依附於難以維系生命的紙張上,而可以存在於能夠長期留存的電磁材料上。隨後的幾十年裏,硬盤廠商展開了一場看不見硝煙的戰爭。Seagate、Western Digital、日立等公司不斷提高磁盤的存儲密度,讓每平方英寸磁盤片上能排列的磁性顆粒越來越多。每一次技術迭代,都意味着容量翻倍、價格下降。到了上世紀九十年代,個人電腦的普及和互聯網的興起,讓這些硬盤廠商成爲整個產業的基石。在那個年代,存儲就是“原材料”,市場的核心標準只有一個:誰的存儲解決方案效率高,即又便宜又好。然而,當數據存儲規模開始指數級增長之後,企業的首要需求變爲“如何保證數據的穩定與安全”。銀行、航空公司、制造類企業的運營都依賴數據,對他們來說,細小的失誤都可能造成巨大損失。於是 EMC、NetApp 這樣的企業級存儲廠商崛起,他們賣的是一整套存儲陣列與配套軟件。此時,雲儲存賽道的商業邏輯由一次性服務變爲長期合作,企業客戶與服務廠商簽署的是長期的服務和保障合同。存儲在這裏第一次被歸類爲“業務資產”。

時間來到21 世紀初,互聯網和移動浪潮讓數據開始跨越國界流動。傳統企業級存儲方案在全球化的需求面前顯得笨重而昂貴。2006 年,亞馬遜推出 S3 服務,把存儲抽象成一個簡單的 API:開發者無需再採購機房和磁盤,只需幾行代碼就能隨時把文件寫入雲端。這種“隨用隨取”的模式徹底改變了開發者的習慣,也讓初創公司第一次獲得了和大公司一樣的基礎設施。雲存儲的價值不在於便宜,而在於彈性和生態。它讓存儲從設備,變成了一種“隨時在線的服務”。很快,Dropbox 和 Google Drive 把這種體驗帶到了消費者端。用戶不需要關心文件放在哪臺電腦,只要有網路,就能隨時在手機、平板、筆記本之間無縫切換。存儲的概念再次被改變:數據不再被存儲在物理設備上,而是屬於人類自己的“賽博空間”。從 IBM 的磁鼓,到 EMC 的存儲陣列,再到 AWS S3 的對象存儲,數據存儲的演進反復印證一個規律:每一次新龍頭的加冕,都是因爲它創造,或者說滿足了一個新的數據使用需求。第一代硬盤解決了容量的問題,企業存儲解決方案滿足了“穩定與安全”的需求,雲存儲則瞄準的是“靈活與可擴展”的痛點。然而,在這些歷史背後,有一個特徵始終沒有被改變:數據所有權過度集中在雲廠商手中。在數據被資產化的今天,這顯然是不可接受的。

至此,Web3開始入局。

Chapter 2:FIL 礦工邏輯 與 Arweave 的理想主義

在 Web2 體系下,數據所有權與控制權高度集中。無論是 Facebook 的社交關係,還是亞馬遜的交易數據,本質上都由公司掌握。用戶雖然在“使用”,但從未真正“擁有”。企業肆無忌憚地利用數據賺錢,但用戶卻只能當一個無力的小羊羔:當個人帳號被封禁時,他的數據也隨之消失;當企業出於合規或政治壓力而下架內容時,這些信息就會馬上從公共空間裏消失。

於是,去中心化存儲的呼聲出現了。2015 年,FIL 項目提出了一種新的思路:用“內容哈希”去尋找文件。意思就是,任何節點只要保存了這份文件,就能響應請求,這解決了“單點存儲風險”的問題。但很快人們發現,光有技術是不夠的,沒有經濟激勵,節點不會願意長期保存數據。於是 FIL 應運而生,它在 FIL 的基礎上加上了Tokenomics:礦工提供存儲空間,以獲得$FIL,FIL協議用復雜的時空證明算法驗證數據是否有被真實的保存下來。從設計上看,它的基本命題是“把存儲做成一個開放市場”,這在供給側確實奏效:只要有token獎勵,一定能組織起大量的礦工參與生態活動。但他們沒考慮到的點是,市場不僅有供給,還有需求。此時,一大堆搭便車者出現。FIL 的激勵主要落在“提供容量並按時出證明”上,礦工天然更關心經濟利益,而不是如何爲用戶服務。於是,一大堆搭便車者出現了。你會看到一個結構性剪刀差:供給端極其活躍,需求端卻沒有同步增長。這個剪刀差很快傳導到產品層。一個需要穩定讀寫的團隊,評估 FIL 時會先問三個問題:寫入之前要準備什麼、檢索延遲的不確定性在哪個區間、出了問題找誰負責。另一方面,在寫入這邊,真實業務數據往往伴隨不斷更新,而 FIL 的語義天然偏向“定長、定期、續約”的冷儲存,開發者要額外搭建索引、版本映射與續期策略。而到檢索時,問題又來了:如果決定自己做 CDN 與緩存,使用 FIL 的邊際收益就會被無限拉低;如果依賴第三方網關或服務商,服務關係又變成“半中心化”,負責人會質疑爲何不直接上雲。最後一環是責任邊界:鏈上證明無法直接爲產品體驗負責。對企業客戶來說,哪怕只是 1% 的不確定性,也足夠把FIL排除在關鍵鏈路之外。激勵設計帶來的路徑依賴還體現在付費者身上。在一個理想的開放市場裏,付費者應當是使用者。但當早期真實需求不足時,生態就不得不用激勵去拉動需求(例如給予某些數據集更優惠的上鏈條件)。這可以短期拉動交易筆數,卻很難證明“自發的、願意持續付費”的需求真的成立。久而久之,供給端的財務模型圍繞“區塊補貼、抵押與罰沒”運轉,需求端的付費意願則圍繞“是否有補貼與額度”波動,兩個系統沒有真正耦合起來。這也是爲什麼你在很多成功案例裏,會看到“大數據上鏈”的新聞,卻很少看到“高頻檢索、持續復用、上層產品盈利”的閉環敘事。

幾乎同時,Arweave 提出了另一種解決方案:用戶一次性支付存儲費用,網路則承諾長期保存。創始人 Sam Williams 的靈感來自於史學與社會學:如果過去能被抹去,那麼社會記憶就將不再可靠。這條路的價值不言自明:某些價值一旦被刪改,社會的信任就會被侵蝕。

Arweave 把“未來的存儲”通過一次性付費的方式折現,網路在很長時間裏持續復制、保存,這是它打動人心的地方。但當你把它放進產品與商業的語境裏,另一組問題會冒出來。第一是“永久”與“迭代”的張力。絕大多數應用並不是一次寫入、永不更新,而是不斷修訂、回滾、A/B。Arweave 的正確用法是把每次變更當作新內容寫入、通過索引指向最新版本。技術上能做,工程上也不復雜,但應用層的設計卻始終是個問題:用戶只想看最新版本,而不是花時間理解一條不可變的時間鏈。第二是永久儲存帶來的倫理問題。開放網路必然會承載灰色與違法內容,Arweave協議不能刪除,只能依賴網關、前端與索引層的“自律”與過濾,這使得開發者在面對“責任歸屬”時左右爲難:一旦你主動負責過濾工作,那麼你就變成了責任主體;而若你不承擔,就會失去客戶。第三是經濟系統的理想化。Arweave 的承諾依賴兩個樸素的長期假設:存儲單位成本持續下降以及網路在足夠長的時間裏維持復制強度。它們在宏觀上成立的概率很高,但對於單一產品經理而言,眼前的現金流壓力是很難解決的,畢竟這意味着要一次性付出的大額寫入費,光算利息都會讓人望而卻步。久而久之,Arweave的業務就被限制在一個非常小的細分市場裏,估值一直無法實現突破。

Chapter 3:AI與雲存儲,數據在跳舞

在FIL 與 Arweave 打開Web3雲存儲的大門後,很長一段時間雲存儲賽道都無人問津。而就在這個空窗期嗎,Irys 出現了。它提出的核心問題是:爲什麼數據不能自己動起來? 既然寫入存儲的那一刻,本質上就是一個“事件”,那麼爲什麼這個事件不能立刻觸發邏輯?如果網路本身能承擔執行環境,那麼數據就不再只是沉睡的檔案,而是能驅動應用的單元。Irys 的設計基點正是如此。它不再圍繞着 FIL 的“挖礦邏輯”和 Arweave 的“永久存儲”裏做更新,而是把存儲與計算結合在一起,提出“可編程數據鏈”的概念。寫入數據即觸發,數據攜帶邏輯進入網路,由 Irys 的執行環境(IrysVM)直接運行。對開發者來說,這意味着從“兩段式”操作,變成了“一段式”——寫入即調用。

前文提到過,在過去半個世紀,存儲的每一次演進,都是因爲它創造了新的需求。因此我認爲,Irys的前瞻性在 AI 時代顯得尤爲重要。AI 模型需要大量數據,而且需要可信的來源與可驗證的執行。傳統存儲把數據鎖在冷倉庫裏,再交給鏈下邏輯處理,不僅繁瑣,還在可信度上留有空白。而 Irys 設想的數據形態是數據自驅:它們能自動“喂模型”,自帶計費與權限規則,能在無需托管第三方的情況下,跨組織協作。

另一方面,Irys 厲害的地方,是把存儲、執行和驗證整合到同一底層協議裏。這意味着,不同協議寫入的數據,可以被彼此直接讀取和復用,甚至驅動更復雜的應用邏輯。那麼隨着節點越來越多,網路的整體價值就會自然增長,因爲數據的可發現性和可組合性不斷增強。要理解這一點,可以想想以太坊。當年它引入智能合約時,很多人不明白這和普通鏈上轉帳有何不同,直到 Uniswap、Aave、Compound 等金融應用相繼誕生,人們才意識到智能合約就是無限敘事的種子。Irys 其實在做一件類似的事情,只不過對象從“金融”變成了“數據”。雖然數據過於抽象不如金錢直觀,可一旦生態積累起來,開發者就會發現:我可以直接在別人的數據輸出上繼續搭建,而不必再依賴外部預言機或重復採集。這樣的敘事,其實與 AWS 當年的路徑也很像。AWS 並不是單靠“便宜存儲”取勝,而是通過一整套 SDK、控制臺、API,把開發者徹底鎖定在它的生態裏。你用了 AWS 中的一兩個服務,很快就會被整個AWS 體系的便利性所吸引。Irys 如果正確執行合作,比如“高質量數據”只在寫入 Irys 時才能訪問,它也會形成類似的價值鎖定。屆時,Irys 上的數據就不僅僅是某個協議的資產,而是整個生態的燃料,而這種正向循環最終會反哺到數據網路本身和代幣價值之中。

Chapter 4:Irys的估值與市場

要知道,理想雖好,但現實往往是殘酷的。擁有前瞻性的項目不等於必然成功。Irys 面臨的第一個難題是冷啓動。如果沒有真實需求,即足夠的應用願意消費這些“可編程數據”,它就會退化爲另一個便宜的存儲方案。第二個難題是兼容性。開發者已經深度依賴 EVM、FIL、AWS 等接口,任何新範式都會提高學習成本。Irys 想要打開局面,必須在“零門檻使用”上做得足夠順滑。第三個難題是治理。數據一旦能觸發邏輯,就會帶來新的攻擊面:虛假數據騙保、惡意觸發消耗資源、版權和隱私糾紛。中心化雲靠法律與權限解決,而去中心化協議必須在機制與治理上給出答案,否則難以獲得機構級採用。因此,Irys是神是鬼,要在主網上線後才能判斷。讓我們期待一下,它能否像 AWS 當年那樣,把抽象做得足夠優雅,把樣板場景跑得足夠漂亮,讓開發者願意用它替換掉原有的拼裝方案。從歷史的角度來看,這是所有基礎設施能否幹掉老大,成爲“下一代龍頭”的關鍵點。

如果是筆者,會關注以下三條路徑:

1、第一個應用場景。歷史上的所有基礎設施,都有標志性的應用場景來證明其價值。S3 靠 Flickr、Dropbox;Snowflake 靠金融和零售的實時分析場景。

同樣,Irys 必須跑出一兩個殺手級場景,比如健康數據的實時激勵系統或是 DePIN 設備的自動結算機制。

2、降低遷移門檻。開發者習慣是最難改變的。EVM 爲什麼能成爲事實標準?因爲它讓人們在新的環境裏復用舊的工具和語言。Irys 要避免“重新教育市場”,而是要在接口、SDK、開發體驗上最大化兼容現有習慣。

3、設立治理工具或生態規則。數據一旦能觸發邏輯,就一定會帶來攻擊與糾紛:虛假數據騙取獎勵、惡意觸發消耗資源、版權歸屬的灰色地帶。如果 Irys 能夠在機制層提供“驗證數據來源”“限制惡意觸發”“嵌入版權與隱私邏輯”的工具,它就能在 ToB 和 ToG 的場景裏贏得信任。雲賽道戰爭的激烈程度不容低估。雲廠商依然是龐然大物,拼裝方案依舊靈活便宜,鏈下證明模式更是成本低廉。但歷史一次又一次證明,真正的突破並不是從舊格局裏拼殺出來的,而是當某個新習慣被創造出來、變成標準之後,格局才被重塑。Irys要解決這個核心問題,才能當上龍頭老大。

在估值方面,截止至本人寫文時間,$FIL的流通市值20億,FDV達到47億;$AR的流通市值4億,幾乎全流通。同期上線BN的ZK rolldown基礎設施Succinct的$Prove流通市值爲2億,FDV11億。考慮到Irys擁有AI+雲存儲兩個大概念,雖然市場AI概念正盛,但由於宏觀方面帶有巨大的不確定性,市場很難給予溢價。

我認爲IrysTGE後的估值如下:

1、低開:3 億 – 5 億 FDV;

2、正常:8 億 – 12 億 FDV

鑑於作者本人風險偏好較低:

1、如若業務進展順利,並且能與Tokenomics形成飛輪閉環,且估值水平低於3億FDV,我將直接買入。若FDV到達5億附近,我將小倉位買入;高於5億保持觀望。

2、如若業務進展不順利,或者tokenomics不能與業務協同,我將保持觀望,並把判斷走勢的權重指標從基本面移至技術面上。

FIL-0.4%
查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)