探討面向大規模應用的技術路線：基于存儲共識的鏈下計算范式_SUB

前言

一款大眾意義上成功的Web2.0ToC應用，至少應該在百萬月活量級。我們熟知的頂級的Web2.0應用Twitter,Google,Facebook,WeChat,Tiktok等，月活都在10億量級以上。也就是說，面向C端的應用，必需搞定高并發及大數據量存儲和檢索，以及其它一些東西。而我們來看看目前基于區塊鏈的明星應用，截止目前：Audius，目前月活400萬用戶，號稱建立在以太坊和Solana之上，具體其使用鏈的方式，對區塊鏈的依賴有多大，信息并不透明AxieInfinity，有170萬游戲用戶，運行在其以太坊獨立鏈Ronin上，不過這個Ronin的信息同樣公開得較少以太坊上的頭部24個DeFi應用，用戶地址數加起來有300萬總體來說，區塊鏈上的用戶量量級處于一個較低狀態。造成這種現狀，除了用戶本身關注度較少之外，還有兩個重要的基礎層面的原因：現有的大部分Dapp的UX體驗，普通互聯網用戶難以理解和操作現有區塊鏈的計算性能太低、數據存儲成本太高，使得使用成本太高也就是說，現在這些區塊鏈的基礎設計，其實承載不了互聯網級別的用戶量，這里面有結構性機制性的問題。我們本篇嘗試討論如何才能讓區塊鏈適用于大規模應用場景。月活百萬用戶應用的基本要求

我們這里僅對Web2.0月活百萬用戶入門級應用稍作分析。1.用戶UX要好用WebApp和手機App的UX體驗要平滑，流程要順暢，前置要求不能過多，用戶上來就能用。并且賬號不一定需要自己的重新注冊，能方便地使用現有的第三方登錄是最好的。2.能支撐高并發，請求延遲要低能支撐大量用戶的同時訪問，不能出現卡殼的情況，延遲也不能過高。這些都會體現在產品的UX用戶體驗上面。面對大量的請求，不能出現服務崩潰，中斷的情況。3.計算低成本計算成本與計算性能這個指標是相關的，服務端系統的計算性能不能太低，不然無法承載高并發的請求。計算成本不能太高，不然云服務器的成本會急劇攀升。4.存儲低成本用戶在使用App的過程中會產生大量的數據。這些數據不僅包含用戶直接創造的UGC數據，還有很多服務中間狀態數據，各個層級的日志數據。這些數據最后都會存儲下來，存放在SQL數據庫或、NoSQL數據庫、對象存儲服務、或者文件存儲服務等等。一些索引服務如ElasticSearch也需要單獨存儲被索引的數據。這些存儲要占用大量的存儲空間。考慮到數據的可靠性，還需要做冗余處理。做冗余處理，相當于數據占用的空間要大幾倍。這些都要求存儲成本要保持比較低的水平，不然會導致服務整體的成本過高，App難以運維下去。Web3.0的要求

其實，Web3.0的目標只有一個：開放性。開放性是Web3.0的唯一核心目標。那么，開放性這個詞有哪些內涵呢？1.數據的開放性2.對數據的操作的開放性3.組織形式的開放性本文在這里不打算展開論述，詳細討論可參見拙作：《對Web3.0概念的梳理》和《為什么Web3.0需要區塊鏈》。目前區塊鏈計算方式的瓶頸

我們這里討論一下主流區塊鏈以太坊Ethereum的技術方案存在主要問題。1.合約虛擬機，分時復用，計算能力有限全世界所有以太坊的節點都在evm中以單線程的形式運行一個合約序列。從合約程序的角度來看，每個對合約函數的調用按排隊執行，一個執行完再執行另一個，相當于分時復用同一個CPU。這種計算模型，決定了節點的計算能力受限于節點單個CPU的計算能力，其性能限制非常大。目前以太坊的處理能力TPS為13左右。2.存儲成本高昂據計算，目前在以太坊上每存儲1k字節數據的費用超過：$100。而傳統云存儲服務存儲1G數據的成本大概是：$0.02每月。如果按10年來算，以太坊上的存儲費用比云存儲高41,666,666倍。為了防止過度占用計算資源和存儲資源，以太坊設計了Gas費機制。擴容之路

由于以太坊的計算能力和存儲能力都非常有限，其它的公鏈項目便有了出頭的機會。不同的公鏈在不同的方向上做出了一定程度的創新。SolanaSolana思路是把Layer1性能做到最好，號稱目前TPS最高的公鏈。其PoH共識輔助機制，使得一些共識子流程可以使用GPU來做并行驗證。目前Solana的TPS大概在2000左右。Solana一定程度上放棄了部分去中心化特性，并且其節點配置要求特別高。這些都是追求高TPS的代價。Ethereum2.0，NEAR,Polkadot這仨都是走的分片之路。分片非常難，可能是最難的擴容方案了。以太坊2.0節奏緩慢，遙遙無期。NEAR據說2021年底發布6個分片的網絡，目前還不清楚分片后的網絡實際效果如何，帶來多大優勢，交易成本會不會增加。Polkadot的平行鏈現在在穩步推進，其先行網已經上了幾個平行鏈了，但還沒經過真正應用的驗證。分片的難，難在原理上，詳見NEAR的《夜影協議白皮書》。現在尚無一個真正的穩定運行的分片網絡，分片網絡后面會不會遇到什么新的問題，是否具有實用性，這些都需要時間來驗證。L2群雄：Polygon,Arbitrum,OptimisticRollup,ZKRollupL2對以太坊的擴容是目前的主流擴容方向。詳見：《以太坊的Layer2擴容之路》。Cosmos,Octopus這倆兄弟項目走的是多鏈跨鏈之路。基本出發點是認為支撐應用的最小單位是應用鏈，而不是合約。每個應用一條鏈，然后所有應用鏈都可以通過IBC協議直接互聯互通。上述提到的這些項目，到目前為止，都已產生可觀的影響。擴容之路不是那么容易，最后只能靠時間來檢驗，誰才能夠走到最后。面向Web3.0應用的計算范式

Patrick Hansen：歐洲央行正在邀請技術專家參加技術會談，探討CBDC的設計方案:金色財經報道，Presight Capital的加密風險投資顧問Patrick Hansen在社交媒體上表示，歐洲央行正在邀請技術專家參加技術會談，探討CBDC的設計方案，會談的重點是增強隱私的技術在零售支付結算中的應用。申請截止到7月20日。[2022/7/11 2:05:00]

前面提到，Web3.0的核心在于開放性，而不是以下名詞中的任何一個：安全性區塊鏈去中心化密碼學安全性是延伸屬性，密碼學和區塊鏈是工具，去中心化是手段，開放性才是目的。而對區塊鏈來講，我們前面提到的所有主流的區塊鏈，其實都是面向資產而設計，而非應用。回顧歷史，如果從2008年比特幣誕生開始算起，這十多年，所有主流區塊鏈項目其實只做了一件事情：處理資產。12年的一個成果，剛剛好就是2020年之夏的DeFi熱潮。即便只是資產這么一個東西，要處理好也是一件了不起的事情。也就是說，即使只處理資產、金融相關的業務，以太坊已經不夠用了，還要出現那么多的L2、側鏈、新型公鏈等項目來分擔處理。這么多選手一起上也還差得遠，離解決好金融業務這個目標還有太遠的距離。也就是說，到目前為止，在區塊鏈上做的那些努力，連基本盤金融領域都尚未處理得過來，更遑論面向Web3.0進行應用這一層次的創新了。鏈上邏輯只適合處理資產業務

在拙作《為什么區塊鏈需要Web3.0》中提出：合約型公鏈僅適合于處理DeFi相關業務。而在本篇中，我們將進一步提出：所有鏈上邏輯都只適合處理DeFi相關業務。既然本篇我們討論的是大規模的應用，那出發點就是大規模應用的標準，而不是做Demo，演示其可能性。對于合約型公鏈來說，可以把所有合約應用，組合起來看作一個大的應用，皆為鏈上邏輯。這是由基礎的賬戶模型決定的。而對于由Substrate這種框架開發的應用鏈Appchain來說，其鏈上邏輯仍然只適合處理資產相關業務。區塊鏈的鏈上邏輯，無法用于處理通用型大規模的應用。理由如下：1.鏈上邏輯的計算量受限于節點性能和出塊間隔的限制2.鏈上邏輯必須在虛擬機體系內完成，不能有任何副作用3.鏈上狀態的存儲使用MPT實現，具有一系列優異的特性，但是也增大了中間存儲量和計算量4.鏈上數據結構受限于存儲特性和Gas費等，種類比較少，形式比較初級，要注意的細節點很多，在處理業務時很受限5.由于區塊鏈的安全性要求，鏈上無法內置一個SQL這種Web2.0中最基礎而又強大的檢索引擎，這讓寫業務代碼的時候，需要人為手動在數據插入的時候建立更新索引對象，非常別扭由于以上的這些問題，我們認為傳統的區塊鏈鏈上計算范式無法承載Web3.0應用的大規模實踐。面向Web3.0應用，我們需要尋找另外的計算和存儲范式。基于Arweave的存儲共識范式

存儲共識范式：通過Arweave永久存儲和鏈下計算達到共識。存儲共識范式是everFinance提出的下一代區塊鏈應用開發范式。在Ethereum模型中，計算會被區塊鏈網絡中的所有節點執行，所有節點都會生成和存儲全局狀態以供查詢。不同于Ethereum模型，存儲共識范式分離了計算和存儲，區塊鏈僅進行數據存儲不進行任何計算，所有計算由鏈下的客戶端/服務器執行，生成的狀態也由鏈下客戶端/服務器進行保存。存儲共識范式使用了鏈下智能合約，智能合約可以是任何語言編寫的程序，這些程序的所有輸入參數都來自存儲型區塊鏈。在范式中，區塊鏈更像是計算機的硬盤，鏈下智能合約可以在任何具備計算能力的機器上進行。使用區塊鏈作為硬盤，所存儲的數據具備了不可篡改和可追溯的特性，區塊鏈為數據賦予了可信的特性。鏈下智能合約對可信數據進行計算，能保證狀態的最終一致性。存儲共識范式開發的應用程序，具備區塊鏈的透明和可信特性，同時又具備傳統互聯網應用的高性能和可用性。存儲共識范式具備以下優勢：1.可組合性：傳統金融服務間進行業務對接，需要會計對賬，對賬過程繁復且容易出錯。采用存儲共識范式，將金融交易記錄完全上鏈，把傳統金融服務轉化成區塊鏈應用，實現自動化對賬，達到應用間的快速協同，高效組合。2.開發門檻低：使用Ethereum虛擬機編寫智能合約需要使用Solidity語言，鏈下計算則可以用任何的語言進行開發，開發者可以將傳統的應用轉化成區塊鏈應用。3.無性能限制：鏈下計算，其性能跟傳統應用一樣，鏈下服務器可以承載大量的交易。TPS取決于提供服務的機器性能和構建應用的技術架構。4.共識成本極低：100萬筆交易僅需要1美金。參考資料：Storage-basedConsensusParadigm。Substrate框架的OffChain特性

安永將于1月26日出庭探討QuadrigaCX加密資產估值方式:加拿大加密交易所QuadrigaCX破產案的受托人安永公司將于1月26日出庭，討論QuadrigaCX加密資產的估值方式。安永認為，應考慮從2019年4月15日（該交易所破產之日）起對加密資產進行估值。而受QuadrigaCX破產事件影響的加密初創公司BlockCAT則認為，應從2019年2月5日起進行估值。估值日期的起始點將影響加密貨幣的估值方式，從而影響剩余資產池中債權人的收益。（CoinDesk）[2021/1/20 16:36:43]

OffChain特性是Substrate中提供的一套相當強大的基礎設施。畢竟對區塊鏈來說，鏈上的邏輯操作空間非常有限，有些事情必須通過鏈下來完成。在沒有OffChainWorker(OCW)之前，這一類事情，通常是由預言機Oracle來完成。預言機是外部服務，通過區塊鏈節點RPC接口向區塊鏈提交交易從而把外界的信息傳到鏈上去。這種方式雖然是可行的，但它在安全性、集成性、可擴展性和基礎設施效率問題上面，仍然不夠好。為了讓鏈下數據的集成更安全和有效，Substrate提供了offchain相關的特性。其架構圖如下：

Off-chainWorker架構圖Offchain特性包含三大組件：OffChainWorkerOffChainStorageOffChainIndexingOffChainWorker用于實現鏈下邏輯。其代碼與Runtime代碼寫在一起，并被編譯到同一個wasm字節碼字符串中，在同一個交易中被傳播到全網絡。但是在執行的時候，OffChainWorker的代碼是在獨立的VM中執行的，即與Runtime邏輯的執行完全隔離開。具體來說，OffChainWorker能夠實現如下功能：將計算的結果以交易形式提交到鏈上包含一個全功能的HTTP客戶端，能夠訪問外部服務的數據可以訪問本地node的keystore，這樣便可以驗證和簽名交易可以訪問本地的KV數據庫，且在所有offchainworker中共享這個數據庫本地的安全的熵源，用來產生隨機數可以訪問本節點的本地時間可以sleep和resume工作OffChainStorage是鏈下邏輯獨立的存儲空間，與鏈上的Storage是完全隔離開的。它具有如下特性：能被OffChainWorker讀取和寫入存儲在node本地，不會傳遞到網絡中其它節點去，不會參與網絡共識被所有同時運行的OffChainWorkers共享訪問。因此，可以利用其在不同的Workers之間通信能被Runtime代碼寫入，但是不能讀。因此，可基于其實現一定的鏈上鏈下交互功能可被wasm環境外的node中的代碼讀取，因此能被RPC讀取OffChainIndexing提供了在Runtime環境中，向OffChainStorage寫入數據的能力。但是不能讀取OffChainStorage中的數據。這為一些新的編程范式提供了可能性。其它還有一些，比如，完善的OCW集成測試框架等等。Substrate的OffChain特性非常強大，令人印象深刻。基于Substrate實現鏈基于存儲共識的鏈下計算范式

從Arweave存儲共識范式獲得靈感，我們來看看在Substrate中如何實現類似基于存儲共識的鏈下計算范式。整個Substrate框架其實分成三大塊可編程邏輯：1.Runtime2.OffchainWorker3.Node容器和兩大塊存儲：1.RuntimeStorage鏈上狀態存儲2.OffchainStorage鏈下存儲詳情見下圖：

Substrate應用開發架構前面我們說過，Substrate中的Runtime只適合處理資產類邏輯，RuntimeStorage只適合存儲資產類數據，它們不適合處理和存儲其它大規模應用的邏輯和數據。在《為什么Web3.0需要區塊鏈》中，有一幅Web3.0應用的通用架構圖：

聲音 | 日本財務大臣：將在G20會議上探討數字貨幣:日本財務大臣麻生太郎表示，將在G20會議上探討全球經濟和數字貨幣。[2020/2/21]

Web3.0App架構可以看到，在Web3.0應用中，鏈下計算和鏈下存儲占據非常重要的位置。在本節，可以將這幅圖針對Substrate做一細化，設計一套嶄新的計算模式。我們理解：區塊是應用的操作和輸入數據的歷史分段打包。其與數據庫的SQL日志是類似的，區別在于：1.分段打包，離散化，郵戳化2.每一個分段都由多個節點參與共識確認，形成一個全網的共識，并在各自節點中敲定。敲定的過程，也是對每個節點中的交易池中的交易定序的過程每個塊頭包含三個Hash：1.前面一個塊的Hash，以明確當前塊是鏈到哪個塊上的2.當前塊中包含的交易序列的總Hash,merkle_root。用于驗證，防止在網絡傳輸途中被篡改交易3.當前節點中，全局鏈上狀態空間的state_root。用于不同節點間全局狀態空間的同步，每一個塊都校驗state_root，能讓所有參與節點內部保持一個嚴格的同步的一致的鏈上全局狀態。基于這些認識，我們可以基于前面的Substrate應用架構圖，做出如下設計：將邏輯從Runtime中剝離。Runtime邏輯的作用僅在于：1.作為代理函數，將外部交易的調用的方法的名稱和輸入數據按一定規范寫入OffchainStorage2.校驗輸入參數3.用于升級整個wasm代碼。這個機制內建在substrateruntime中，不需要單獨開發而鏈上存儲不再需要了。真正的邏輯在OffchainWorker中執行。這部分代碼是wasm字節碼，由鏈上發交易統一管理升級，保證所有節點的一致性。OffchainWorker代碼在塊導入時執行。執行邏輯如下：1.Offchainworker入口函數執行2.檢查offchainstorage中是否有符合某些鍵值對規范的存儲內容，這個內容應該包括：方法名稱，參數表。如果有，取出方法名稱和參數表3.在Offchainworker中，按方法名稱進行路由，并把反序列化后的參數表傳到對應的路由handler中去。這些路由handler代碼可以寫在不同的文件中，在runtime主文件中引進來4.Handler可以使用offchainstorage中的數據，充分完成計算、聚合、重整化等工作5.Handler執行完成后，可以通過以下方式通知網關要返回的結果：a.通過offchainworker中的http請求能力，主動將結果發送給gateway，gateway監聽到結果后，根據結果中的uri對應地將數據返回給前端b.將結果緩存在offchainstorage中。gateway定時輪詢或監聽substratenode的rpc接口，通過rpc接口從offchainstorage中取得相應結果，并返回給前端6.主流程結束。以上就是使用Substrate實現基于存儲共識的鏈下計算范式的主要流程。這里需要解釋一下為什么這種方式就是基于存儲共識的鏈下計算：1.執行邏輯offchainworker中的代碼，是通過substrate交易提交到鏈上，通過p2p網絡，在各個節點通過驗證后，更新到各個節點上的。這保證了執行代碼的一致性2.Substrateoffchainindexing的一大特性就是：一致性。Substrate.dev中有一段話：”UnlikeOCWs,whicharenotexecutedduringinitialblockchainsynchronization,off-chainindexingispopulatingthestorageeverytimeablockisprocessed,sothedataisalwaysconsistentandwillbeexactlythesameforeverynodewithindexingenabled.”。有這個特性保證，就可以保證存儲在offchainstorage中的對方法的調用和傳入的參數在所有節點上是一致的。也即是保證了輸入數據的一致性3.一旦Offchainworker開始執行，其是在鏈下執行的，與鏈上邏輯和存儲完全分開。這也就對應了Arweave存儲共識范式中的鏈下執行部分4.計算后的結果，并不會重新上鏈，這是非常重要的一點。在這方面，與Arweave存儲共識范式也是相同的。好了，我們說了這么多，到底使用Substrate實現基于存儲共識的鏈下計算范式有什么優勢值得我們關注呢？下面一節，我們重點與目前已有的典型計算方案做一下對比。與目前典型計算方案的對比

NULS與智云鏈Nebula AI在技術層面進行深度探討:據NULS與Nebula AI 官方Twitter消息，在昨天結束的紐約Consensus2018會議上，NULS團隊與Nebula AI團隊在技術層面進行了深度交流，雙方將在跨鏈和模塊化賬本開發方面開展進一步的技術探討。NULS是一個可定制的區塊鏈基礎設施，智云鏈(Nebula AI)是可承載人工智能程序的去中心化共享算力區塊鏈。[2018/5/17]

與傳統區塊鏈計算范式的對比

這里，我們說傳統區塊鏈計算范式，指的就是鏈上計算范式。Substrate基于存儲共識的鏈下計算范式的優勢：1.Offchainworker計算不再受限于出塊間隔的要求，可以實現長時間的計算或等待2.Offchainworker是獨立的輕量級線程，同時可并發執行多個輕量級線程，以充分利用節點的計算能力3.Offchainworker具有訪問外部服務的能力，也具有對外部產生副作用的能力，這點在實際的業務中，非常重要4.OffchainStorage，不再受鏈上設計制約，可以充分利用已有的數據庫領域的歷史積累和前沿創新，為大規模數據存儲鋪平道路5.OffchainStorage中的存儲內容，可以分為三個部分。只有方法名調用和輸入數據這塊需要保持強一致性。邏輯運算結果需要訪問一致性。在第三部分可以靈活地存取/緩存本地節點數據，以實現更靈活地編程6.用于Substrate鏈下計算的節點可以是整個區塊鏈大網絡節點中的一部分，這樣可有效控制計算成本和存儲成本，使得內容的處理和存儲量級可以大規模的擴張Substrate基于存儲共識的鏈下計算范式的劣勢：1.SubstrateStorage目前是簡單的kv數據庫，失去了MPT結構天生的一些特性2.鏈上存儲狀態在每一個區塊中都有state_root做同步，而Substrate鏈下計算范式則失去了這個特性。這樣對存儲狀態的同步缺少強制性3.Substrate鏈下計算范式對計算結果的存儲和中間狀態的存儲需要有一套自定義的規范，這些規范只是定義在offchainworker代碼中，而沒有其它節點強制驗證的過程4.在Substrateworker中仍然要注意，諸如隨機數和外部請求這些副作用，不能對需要一致性的存儲區造成影響。因此在編寫代碼的時候，需要人為注意，需要有約定或者最佳實踐與基于Arweave的存儲共識范式的對比

Substrate鏈下計算范式的優勢：1.鏈的集成度更高。Substrate節點本身組成一條區塊鏈，不再單獨需要一條鏈作為服務2.Substrate鏈的交易的驗證過程比Arweave數據上傳請求驗證過程更細致。SubstrateRuntime中可以寫交易的自定義驗證代碼，這是在鏈上執行的，而Arweave只是鏈上存儲服務，做不到這一點3.Substrateoffchainindexing是從鏈上主動往鏈下寫內容，而Arweave需要鏈下的計算客戶端主動從Arweave網絡上去拉對應的數據。這個過程顯得不那么自動化，至少輪詢的次數會多。另外，從Arweave上拉數據存在網絡訪問，可能存在網絡訪問失敗的問題，如果數據量較大，那么下載完成也需要可觀的時間。而Substrateoffchainindexing完全運行在一個節點內部，性能更好，集成度也更高，對開發者來說，掌控力更好4.基于Substrate節點，鏈上邏輯和鏈下邏輯是統一運維的，集成度更好，運維的可靠性更好5.Substrate鏈下邏輯強制使用wasm字節碼來運行。在這點上，Arweave并沒有要求。Webassembly是一套得到國際廣泛支持的字節碼標準，在其上有非常多的創新，生態在快速發展。從運行效率和未來生態來說，采用wasm來部署應用是一個優勢簡單來說，Substrate基于存儲共識的鏈下計算范式，相當于實現了Arweave的一部分功能，但是沒有提供Arweave永存的特性。這點上，如果將Substrate鏈的塊歷史上傳到Arweave上存儲，那么就充分地利用了Arweave的永存優勢。Substrate鏈下計算范式的劣勢：1.語言中不立。Substrate目前只能使用Rust語言進行開發，這意味著要使用Substrate實現Web3.0應用開發，必須學習使用Rust語言。而Arweave存儲共識范式是語言中立的，可以用任何語言開發2.Substrate鏈下計算范式對編程方式有新要求，而基于Arweave存儲共識范式的編程開發就與Web2.0開發類似，只需要調用Arweave相關的第三方服務即可3.Arweave實現的永存，對需要一致性共識的內容具有歷史可靠性更好的優勢。即使區塊鏈項目倒閉了，它的那些內容還可以從Arweave上查到4.Arweave作為一個存儲計算服務，類似于XaaS，在某些場景下會很方便我們前面描述過，Substrate鏈下計算范式需要人為做一些約定，在這點上，Arweave存儲共識范式一樣會遇到。這點上兩者一致。與TheGraph/SubQuery的對比

印度央行成立專門小組 探討研究自己的數字貨幣:據livemint報道，印度央行(Reserve Bank of India)已采取措施遏制加密貨幣與盧比之間的交易，并成立了一個專門小組，以探索擁有自己的數字貨幣。[2018/5/8]

Substrate是工具套件，TheGraph/SubQuery是服務。TheGraph/SubQuery是外部索引服務，主要用于對鏈上拋出的事件進行索引，并通過寫Mapping方法實現事件信息提取，生成schema結構化數據存入數據庫中。它們提供GraphQL接口，其內部本身也還是傳統的SQL或NoSQL數據庫。Substrate基于存儲共識的鏈下計算范式的優勢：1.集成度更高，TheGraph/SubQuery需要一個第三方外部服務才能獲取數據2.Substrate的模式能提供的接口形式更靈活。在網關上配置RPC，Restful,GraphQL都可以3.Substrate更可控，更去中心化。TheGraph/SubQuery是一個服務，大家都用這個服務，對這個服務的依賴性也就更強，對其運行的穩定性也就有擔憂。而Substrate這套工具，只需要對自己的鏈負責，別人出的問題不會影響到自己，自己出的問題不會影響別人。大家部署自己獨立的服務，其實是更好的執行去中心化的過程Substrate基于存儲共識的鏈下計算范式的劣勢：1.目前將OffchainStorage替換/升級成支持SQL引擎的存儲還沒實現，索引還得自己來維護2.TheGraph能夠對合約公鏈進行索引，而Substrate鏈下計算范式只適用于Substrate框架實現的Appchain3.TheGraph/SubQuery是對鏈上拋出的信息進行索引，鏈上寫代碼的方式該怎樣就怎樣，不受影響，也即沒有侵入式。而Substrate鏈下計算范式對使用Substrate框架開發代碼的方式有要求，要按照新的范式來寫代碼，所以是侵入式的對比可見，兩者各有其適用的場景。TheGraph/SubQuery更適用于傳統的基于合約的Dapp開發，Substrate基于存儲共識的鏈下計算范式更適用于面向具體場景的Web3.0App的開發。與傳統中心化應用的對比

由于鏈下計算的特性，傳統中心化應用的那些成熟的基礎設施，理論上來說都能被Substrate基于存儲共識的鏈下計算范式應用所利用。Substrate基于存儲共識的鏈下計算范式的優勢：1.相對于傳統中心化應用來說，Substrate的鏈下計算范式應用是去中心化應用，業務邏輯在各個節點上運行，并且通過區塊鏈的強制特性保持了業務和運行結果的一致性。去中心化應用的一切優勢，Substrate鏈下計算范式的應用都自動具有2.保障了開放性。前文提到的三個層次的開放性，在這個計算范式下，都能得到有效保證，這正是我們Web3.0追求的目標。任何一個感興趣的人都可以運行Substrate節點，同步所有歷史區塊，跑出所有數據來。獲取數據的人不一定要參與鏈的共識。而傳統的中心化應用，在這三個層次上，都是封閉的Substrate基于存儲共識的鏈下計算范式的劣勢：1.同樣的邏輯，需要在各個鏈下計算節點重復計算，并在每個節點都做存儲。這在計算成本和能耗上，確實不是優勢。但是由于參與鏈下計算的節點數量可以控制，這塊的冗余性與傳統中心化應用需要做的數據冗余和邏輯冗余，其實是類似的2.在基礎設施層面，中心化應用能用到充分成熟的支撐大規模應用的基礎設施，而Substrate鏈下計算范式的基礎設施還不成熟目前SubstrateOffchain基礎設施的不足

OffchainStorage目前只是最基礎的kv數據庫實現。要支撐真正面向實際的應用，基礎設施還需要完善，有幾個方向可以參考：1.Redis：Redis作為內存KV數據庫，其內建豐富的數據結構的支持，使得其得到了各種領域大規模的應用2.Mongodb：Mongodb作為對象型數據庫，特別適合某些領域3.Tikv+Tidb：作為新一代分布式數據庫的代表，tikv在rocksdb之上做了分布式協議層，而tidb進一步在tikv之上做了SQL引擎層。這是非常有效合理的層次劃分，這種理念也特別適合用在SubstrateOffchainStorage未來的改進上面。如果能夠嫁接tikv/tidb到Substrate中來，那么tikv/tidb上面的很多生態設施都可以一并用到Substrate的鏈下計算上來，非常美好的局面另外就是代碼編寫的思維有些變化：OffchainWorker是定時器思維，或流編程思維。與傳統的服務器的on_request/response思維有不同。這塊兒如何最佳實踐，還需要更多研究。對Web3.0App的定義

基于本篇前面章節的討論，我們可以將區塊鏈進一步做如下區分：用于處理鏈上資產的鏈，我們叫它資產鏈。用于處理Web3.0應用數據的使用鏈下計算范式的鏈，我們叫它數據鏈。基于這種區分，我們可以做出如下示意圖：

這個圖定義了：Web3.0App=DatasetChain+AssetChain的一部分+一部分Web2.0已有的基礎設施數據鏈是Web3.0App的核心載體。基于存儲共識的鏈下計算范式實現的Web3.0App，其位置處于區塊鏈大生態的邊界，一邊連接資產區塊鏈，一邊連接已有的Web2.0基礎設施。工具or服務？

在本文快要結束的時候，我們來簡單做一下關于工具還是服務的思辨。這里的服務，指的是ToB基礎設施層面的服務，而不是ToC業務型的服務。通常，你要完成一件事情，有兩個選擇：1.使用一個工具，在自己的電腦上運行計算，完成2.使用一個服務，在服務所在的服務器上運行計算，然后將結果返回給你這就是工具與服務的區別：計算，是在你自己的地盤內完成，還是在第三方的地盤上完成。云服務IaaS取得巨大的成功。從以前的自己買服務器托管至機房的模式，到云服務IaaS，開啟了云時代，進而到現在的k8s，這條路目前還看不到盡頭。而相對于IaaS，更上層的PaaS似乎并不成功。反而SaaS取得了一定的成功。服務的產生總是滯后的，開始總是先用一些工具進行實踐。我們不要忘了，開啟了Web2.0時代的是什么？是LAMP。而到目前為止，全世界仍然有30%的網站由Wordpress搭建。而JavaSpring框架、RubyonRails以及Nodejs等技術棧框架，在整個互聯網的發展過程中，起到了相當重要的作用。這些框架給了你：1.在本地開發調試部署一個完整應用的流程和能力2.對你自己的代碼邏輯有100%的掌控力3.在自己申請的云服務器上運行，自己對應用數據有100%的掌控力4.對互聯網服務的運行成本可以有比較準確的預估5.其它等等這些框架沒給你：1.隨著業務的擴展，需要自己維護服務器集群2.需要自己維護服務器安全3.其它等等而第三方服務給了你：1.現成的功能組件，低成本的開箱即用2.完全無需關注運維的問題，需要的所有擴容都是自動完成的3.快速的試驗環境4.其它等等第三方服務沒給你：1.透明的實現2.準確的計算成本3.深入自定義優化的空間4.其它等等對于創業團隊來講，有些場景下力求短平快的服務啟動，會傾向于直接使用第三方服務實現。而當業務規模擴張到一定階段的時候，力求對各個組件的運行實現全面掌控，這時就傾向于用開發框架的配套組件自己來搭建服務了。當然實際情況是往往混搭起來使用。如果考慮文化、地域、國家政策等更多因素，具有自主搭建的能力的需求就更加強烈。最關鍵的一點是，各方能夠自己比較容易地搭建相對完整的的服務，對于“去中心化”的實現，是一個非常重要的措施。如果所有人都在用同一個服務，這個服務是不是另一種層面的中心化？除非特別專業性的服務，一般來說，服務是可選項，開發框架才是根本立足點。不應忽視對開發框架的投資。結語

本文我們嘗試為Web3.0App設計了一種面向大規模應用的技術路線：基于存儲共識的鏈下計算范式。本文使用Substrate框架作為示例來講解。理論上來說，任何框架都可以實現此計算范式——只有集成度、成熟度的區別。大家可以嘗試將此計算范式引入到自己的框架中實踐。本文由MikeTang和Outprog合作完成。我們的郵箱為：mike@oct.network，outprog@ever.finance，歡迎與我們聯系。參考資料

:https://cryptobriefing.com/ethereum-defi-ecosystem-has-hit-3m-users/:https://mp.weixin.qq.com/s/vJM6TIZT2f-tnQ49cpMnrw:https://mp.weixin.qq.com/s/h76lTnFWlvpXs72aBVs3FA:https://near.org/papers/nightshade/:https://www.theblockbeats.com/news/24443:https://mp.weixin.qq.com/s/zXqJ0BGdEbvZypAwLWKmtQ:https://mirror.xyz/0xDc19464589c1cfdD10AEdcC1d09336622b282652/KCYNKCIhFvTZ1DmD7IpXr3p8di31ecC283HgMDqasmU:https://substrate.dev/docs/en/knowledgebase/learn-substrate/off-chain-features#off-chain-indexing:https://techjury.net/blog/percentage-of-wordpress-websites/#gref本文來自Web3Explorer

Tags：SUBUBSBSTTRATSubscriptions超零幣UBS可靠嗎BSTKTratin

TUSD