原文作者：付少慶，SatoshiLab ，Bihelix ，萬物島BTC 工作室
閱讀註釋：
（1）本文稍顯晦澀，因為涉及了一些系統的底層原理，且作者本人在分散式系統方面的理論與實務經驗有限。一般讀者可以直接閱讀結論，即3.3 節web3.0 大規模應用的架構。
（2）二層建設的分類，參考文章《一文梳理比特幣二層（Layer 2）建設的基礎知識體系》。根據參考文章中的系統結構分類，將比特幣Layer 2 的二層分為三種：區塊鍊式結構， 分散式系統結構，中心化系統結構。
（3）從狀態機的角度觀察比特幣的二層建設會發現狀態機的原理在三種系統結構（區塊鏈系統、分散式系統、中心化系統）中都適用，只是實現的方式受限於系統的結構。
（4）三種觀察角度：分散式帳本，狀態機，區塊+鏈結構
前言多層次與多角度
多層次與多角度觀察事物屬於綜合分析方法論。它的優勢體現在幾個方面：全面性、深度理解、綜合性、精準性、利於執行。綜合分析方法論的優勢使得它在複雜和多變的問題中具有更強的應用價值，可以提供更全面、深入和準確的分析結果，為解決問題和推動發展提供有力支持。
（1）多層次
多層次一般可以採用宏觀、中觀、微觀，也可以從時間的周期上，採用短期、中期、長期三個層次觀察。在比特幣生態的發展中，我們從短期、中期、長期三個層面觀察，可以獲得比特幣生態更全面、深入、準確的認識與理解。
這裡借用大山老師的總結：「 比特幣生態分成短期、中期、長期的三個機會： 比特幣生態短期機會是BRC-20 為代表的銘文賽道；中期機會是比特幣Layer 2 賽道和Nostr 加閃電網絡賽道；長期機會是RGB 協定和BitVM 為代表的鏈下解決賽道。這其中包含的四個賽道，銘文賽道；Layer 2 賽道；Nostr 加閃電網絡賽道；鏈下賽道（以RGB 和BitVM 為代表）。”
本文在3.4 節中將Layer 中基於鏈的二層建設的前期階段也劃入到短期機會，原因在3.4 節中介紹。
（2）多角度
同時對於比特幣生態，我們從多個角度觀察，可以帶來全面、客觀、深入、靈活和創新的優勢。這種多角度的觀察有助於我們更好地認識和理解事物，並利於創新。
這個多角度，我們從業務角度－分散式帳本（利於理解業務），抽象運算角度－狀態機（利於理解區塊鏈+分散式系統的實現），技術實現角度－ 區塊+鏈的結構（利於理解生態中的區塊鏈部分）。
1. 三個觀察角度
在以太坊的文檔《Ethereum EVM illustrated》中，介紹了對於以太坊的區塊結構，有三個觀察角度（分散式帳本、狀態機、區塊鏈）。這種觀察結果同樣適用於比特幣，而且更適合觀察比特幣的生態架構。在以下的介紹中，我們從這三個角度來理解，會有不同的收穫。
從狀態機的角度理解，不僅容易理解區塊鏈上的狀態和狀態處理，我們會更容易理解在分散式系統中狀態，狀態通道，狀態轉換，同時結合分散式系統的結構，會容易理解路由的問題，理解狀態轉換的有向無環圖要求。狀態機是基於圖論的底層抽象計算原理，基於這些原理與具體的實現結構（區塊鏈、分佈式、中心化），會理解需要解決的具體問題與解決方案的想法。
其次是業務的角度，我們會很容易理解區塊鏈為什麼可以處理信任數據，為什麼區塊鏈上面的數據可以作為數字貨幣，這使得區塊鏈系統更像一個帳本。會理解，為什麼分散式系統不是帳本，需要與帳本合作。同時會理解在與帳本的合作中，分散式系統如何處理帳本上的資料與流轉。
從技術實現的角度，我們會理解Blockchain 這種系統是區塊鏈結構，這種技術結構的優點和缺點也很容易歸納和總結。
對於比特幣生態的結構，從帳本和狀態機的角度我們可以更好的理解每種結構的優缺點，以及如何使用三種可選擇的結構來構建比特幣的二層，甚至是如果構建Web3. 0 應用的整個架構。
在閱讀以太坊的文檔《Ethereum EVM illustrated》時，我有一種感受。三種不同的角度觀察以太坊可以類比的事物，為我們解決以太坊提供了一些思考想法和處理經驗參考。例如， 當以太坊看成基於狀態的自動機時，電腦領域關於狀態機的理論和算法就可以透過改造用於以太坊。當把以太坊看成基於帳本的資料庫時，資料庫裡面的一些理論就可以用在以太坊裡──如數據庫裡面的分片思想。這種感觸在比特幣的生態中同樣適用，而且會混合在三種大型的系統結構中使用，靈活性會更強。
1.1. 業務角度—分散式帳本
從帳本的角度來看，區塊鍊是一組組的交易，就像寫在帳本上面的一頁頁的資料。
從帳本的角度來看，我們容易理解其業務能力，也就更容易理解其貨幣與金融的作用。這也是在Web3.0 應用的整體架構中，一定要有帳本這種角色。
從帳本的角度我們也容易理解鏈的二層建設，不同業務的帳目可以記錄到不同的帳本上， 這些子帳本匯總到總帳就可以。
從帳本+分散式的角度，我們可以理解，給參與者一筆數字貨幣，具體怎麼處理，怎麼分賬，參與方去自己協商處理，最後再記錄會賬本就可以。
1.2. 抽象計算角度—狀態機
在這裡我們重點介紹一下狀態機，因為這個角度可以很好的理解區塊鏈系統與分散式系統。並且可以理解資料（或狀態）在區塊鏈系統中處理過程與在分散式系統中處理的差異。
從狀態的角度來看，區塊鍊是一個基於交易的狀態機。一個交易是觸發條件，使得一個原始狀態σt ，在交易的作用下，轉換到下一個狀態σt+ 1 。
一組交易打包到一個區塊鏈中，是一個資料包，使得與這組資料相關聯的狀態都改變。
於是從這個角度來看，區塊鍊是一個狀態鏈（在分散式系統中，就是一個狀態通道）。從狀態的角度，區塊鏈系統可以看做是一個基於狀態的自動機。
從狀態的角度，我們觀察區塊鏈+分散式系統，會更容易理解狀態在兩個系統中的傳遞與變化規則，而兩個系統其實都是基於狀態的自動機。
當把區塊鏈看成基於狀態的自動機時，電腦領域圖論中關於狀態機的理論和演算法就可以作用於區塊鏈。同樣，如果實現的技術結構不是區塊鏈結構，而是一種分散式結構，我們也可以用狀態機的理論。像是有限無環圖DAG（避免產生雙花），狀態通道，一次性密封都是在分散式系統中處理狀態需要使用的技術。
1.3. 技術實現角度—區塊+鏈的結構
從技術實現的角度來看，比特幣和以太坊等系統就是一個區塊鏈。由數據塊和里面的哈希指針將分散的數據聯繫在一起。
這只是為了運作區塊鏈這樣的系統，保持的一種技術實現結構。區塊鏈上面的數據和計算都是採用全局的方式，只有這種結構能夠完成帳本的功能。在與外部系統連接時，需要考慮這種結構的實現細節和適用性。
這種塊+鏈的技術實現結構，我們很容易理解其特點，也可以計算性能指標。例如，比特幣網絡的區塊是1 M（支援隔離見證後理論最大是4 M） ，其支援的交易數量就完全可以計算出來。
計算公式為：（區塊大小/交易的平均尺寸）/ 區塊平均時間間隔。一般情況下，比特幣每個區塊大約可以容納2000-3000 筆交易，即3-7 TPS。
1.4. 區塊鏈的基礎特性與三種Layer 2 建設結構的特點
參考比特幣二層建設的三種分類：區塊鍊式結構，分散式系統結構，中心化系統結構。比較比特幣一層和二層建設的一些基礎特性，可以清楚的看到他們之間的差異。如下表所示。稍後對照3.2 節的應用需求，以便我們從這些基礎系統架構中選取一個適當的架構建構組合。
通過上表，我們能夠大致總結出區塊鏈結構、分散式系統結構、中心化結構的特性。
（1）區塊鏈結構
區塊鏈結構的最大好處是解決信任相關問題，可以記錄資料的變化過程（狀態轉換）, 於是資料和計算規則都變成了可信資料與可信任計算。這些可信數據，一種是基礎的原始數據（表現為貨幣），一種是處理數據的指令集（表現為代碼與智慧合約）。
區塊鏈結構最大的問題是效能差，這有兩個原因，一是區塊鏈結構在於無法去除部分計算的場景，都是以全量計算的方式處理所有請求。如，部分計算與全局計算，局部數據與全局數據，臨時數據與永久數據。二是區塊鏈結構有明顯的效能上限。如果是透過鏈的方式進行二層擴展，支援的事務數量也很有限。簡單計算如下：
區塊鏈系統的上限是單一區塊容量所能容納的最大交易數，多層區塊鏈的上限是每一層區塊容量交易數量的乘積。例如，一層比特幣每秒7 TPS ，一個二層鏈的處理能力是100 TPS ， 那麼這兩種結構組合在一起就是700 TPS。
為了擴大包含區塊鏈結構的效能，需要多層建設，並且需要與異質的系統結合使用。對於必須在區塊鏈系統完成的工作，只需要記錄需要全局保存和計算的數據，其他的非全局數據都可以分配到其他層來處理，盡可能使得處理的數據與代碼只與相關方有聯繫。
透過上表，只有區塊鏈結構才能實現去信任帳本功能，所以一個系統中要想實現去信任帳本功能，必須包含區塊鏈系統。但大規模應用對效能的要求，使得區塊鏈系統一定需要結合其他系統才能滿足需求。
（2）分散式系統
在上表中，我們可以看到分散式系統的明顯優點：去中心化、效能、可擴展性都是極佳， 只有在功能實現上有較複雜的特性。此外，分散式系統不具備去信任帳本的能力。
於是如果能夠基於比特幣的一層帳本功能，在二層建設中使用分散式系統，理論上可以在維持區塊鏈基礎特性的同時，還能實現無限的效能擴展。這方面的案例以比特幣+ 閃電網絡為代表，這樣組合的性能就是比特幣的7 TPS * ∞。
在分散式系統中實現圖靈完備的原因是：在區塊鏈系統中記錄和運行智慧合約的代價是很高的，因為是全域資料與全域代碼。所以智慧合約也適合分層理論，將智慧合約的程式碼儲存與執行局限在參與者之間。這也是分散式系統中的客戶驗證所產生的場景，只需要相關者之間的可信資料（狀態，一次性密封）參與計算，只在局部進行圖靈完備的計算。這就是常說的分散式系統中的全網共識與參與人共識用分散式系統結構建造二層的最大困難是，技術實現上的複雜大比較大。像閃電網絡這樣單純解決支付問題的網絡都發展緩慢，有較多不完美。如果在分散式系統上實現圖靈完備的計算，就更有挑戰。 RGB 發展的緩慢和版本更新慢，就是一個參考案例。
解決複雜性的最大代價是容易出現安全問題與開發的門檻較高。在分散式系統上實現圖靈完備的智慧合約功能，不僅底層平台的開發週期長，開發難度大，而且經常會出現合約代碼漏洞和持續的駭客攻擊。
（3）中心化系統
在上表中，我們可以看到中心化系統的好處是工程實現相對簡單，這是由於內部的邏輯控制簡單，計算簡單。同樣，中心化系統也不具有去信任帳本的能力。中心化系統的優勢不突出，如果是處理規模不大的數據，或處理臨時數據與臨時計算會相對比較適合。
中心化系統的二層建設可以作為其他兩種方式的補充或過渡性方案。
（4）綜合分析
在價值時代，透過上面的內容，我們可以看到單靠一個系統很難到達滿足需求的效果。這也是比特幣生態發展二層的實際需求。但這個三種系統怎麼組合需要很多的探索，我們先從理論上分析，面對不同的需求，會有不同的組合結構。
首先，從協議分層的設計想法來看，比特幣網絡確實不需要圖靈完備，它是一個全球的信任機器，只需要保存這些需要全域信任的資料和資料變化的軌跡。根據這個最基本要求，比特幣的指令集可以減少到最低。其他功能，則交給上層的擴充來完成。除了滿足本層功能需求，還需要比特幣一層和上層網絡的連接技術進一步發展和完善，而且這種連接技術，在滿足功能的前提下，對比特幣的數據空間佔用越少越好。
一般的小型應用，只需要在單一的區塊鏈上就可以完成。稍大的系統適合在區塊鏈+ 區塊鏈的二層建設上完成。但對於大規模的應用，優選的方案是使用區塊鏈系統+分散式系統。從效能角度，分散式系統上限在理論上是無限的，那麼這樣的組合就是比特幣的7 TPS * ∞。工程實踐中，也會受到一些具體因素的限制，通常這樣的系統的上限是受限於分散式系統的路由能力，狀態變化的有向無環圖的處理能力等具體技術實現環節。後面在Web3.0 的典型應用架構中，還可以看到多種系統的組合圖示。
透過多種系統結構的組合，可以突破單一系統基礎理論的限制。例如，區塊鏈系統受限於DSS 不可能三角形的限制，但如果使用區塊鏈系統+分散式系統，就可以解決去中心化D、安全性S、可擴展性S 的不可能三角形。其他組合，區塊鏈+ 中心化系統，也可以一定程度上解決擴展性的問題。分散式系統+ 中心化系統，可以解決分散式系統中CAP 三角形的限制。
在以往的技術發展歷史中，也存在一些組合使用的案例。例如，中心化的資料庫在能力受限時，採用主從結構，到分庫分錶，到分散式資料庫，就是使用中心化系統與分散式系統的案例。
這種組合也體現了一個哲學思想：一個問題的解決方法不能在產生問題的層次上得到答案，但可以在更高的層次上解決這個問題。這句話理解清楚不是特別容易，我想到《禪與摩托車維修藝術》有一個比喻特別好：我們不能揪著自己的頭髮把自己提起來。這是告訴我們不能依賴系統本身解決自身的問題，一定需要藉由外部系統來解決。
2. 從狀態機的角度再看比特幣二樓的設計與發展
狀態與狀態機，在三種二層建設中都存在，只是名稱上有些不同，使得多數人不關注這個觀察角度。
如果我們從狀態與狀態機的角度來看，三種二層結構都是處理狀態的狀態機，只是原理稍有不同。這三種系統組合使用的時候，需要確保「狀態」概念在三個系統中一致，並且每個系統的狀態機能夠處理狀態變化，但不能破壞狀態的一致性。
比特幣生態或Web3.0 的應用架構，我們從狀態機的角度來看，就是藉助這幾種系統組合， 完成狀態變換的處理，從而完成業務邏輯的處理。
用狀態機的這種思想，我們再看比特幣的二層網絡建設，可以看到架構的每一層有適合其特徵的分工。
2.1. 圖論中狀態與狀態機的基礎知識
在圖論中，狀態與狀態機的基礎知識包括以下內容：
狀態（State）：狀態是指圖論中的節點或頂點。在有向圖中，狀態可以表示為一個節點；在無向圖中，狀態可以表示為一個頂點。
狀態轉移（State Transition）：狀態轉移是指從一個狀態到另一個狀態的過程。在有向圖中，狀態轉移可以表示為一條有向邊；在無向圖中，狀態轉移可以表示為一條無向邊。
狀態機（State Machine）：狀態機是一個抽象的計算模型，用來描述一系列狀態和狀態之間的轉移規則。狀態機由狀態集合、初始狀態、轉移函數和終止狀態組成。
有向圖（Directed Graph）：有向圖是由頂點和有向邊組成的圖結構，其中有向邊從一個頂點指向另一個頂點，表示狀態之間的轉移關係。
無向圖（Undirected Graph）：無向圖是由頂點和無向邊組成的圖結構，其中無向邊連接兩個頂點，表示狀態之間的關聯關係。
拓撲排序（Topological Sorting）：拓撲排序是指對有向無環圖（DAG）的頂點進行線性排序，使得對任兩個頂點u 和v ，如果存在邊(u, v) ，則u 在排序中出現在v 之前。
有向無環圖（DAG）：有向無環圖是一個有向圖，其中不存在從某個頂點出發經過若干條邊後能回到該頂點的環。
最短路徑（Shortest Path）：最短路徑是指在圖中找到連接兩個頂點的路徑中，邊的權重總和最小的路徑。
最小生成樹（Minimum Spanning Tree）：最小生成樹是指在連通圖中，找出一個包含所有頂點的樹，使得樹的邊的權重總和最小。
這些基礎知識是圖論中的核心概念，用於描述和分析狀態之間的關係和轉移規則。相關的知識和圖形在專業的書籍中可以深入學習。
雖然看起來這些知識有些抽象和枯燥，如果我們把這些知識轉換成經常遇到的一些區塊鏈概念就很容易理解。例如，一些場景要求是有向無環圖就是避免雙花的問題；一次性封裝就是將區塊鏈中的狀態轉變成分佈式系統中的狀態；路由算法是在分散式系統中尋找最短路徑的計算；閃電網絡中支付成本最小的路由就是最小生成樹問題；客戶端驗證也可以看成一種形式的狀態機。
2.2. 狀態機與分散式系統
這裡我們用幾種分散式網絡來介紹：
（1）閃電網絡中
在閃電網絡中，能夠體現狀態、狀態機相關的知識點有：
閃電網絡是基於狀態通道技術的比特幣二層解決方案，閃電網絡中的支付通道是一種雙向的狀態通道，參與者可以在通道內進行多次交易，並通過更新通道狀態來實現快速、低成本的支付。
閃電網絡中的交易（即狀態）是透過基於Hash 時間鎖定合約（HTLC）來實現的，參與者可以透過這種合約來鎖定資金（實現狀態在比特幣與閃電網絡兩個系統中傳遞） ，並在通道內進行安全的交易（簡單的狀態處理）。
閃電網路中的路由：為了實現跨通道的支付，閃電網路使用了一個名為路由的機制，參與者可以透過找到一條可信賴的路徑來進行支付。
閃電網路中的中繼節點：中繼節點是指那些能夠轉發支付請求的節點，他們可以幫助實現跨通道的支付。
閃電網絡的雙向支付：閃電網絡允許參與者在支付通道中雙向支付，即不僅可以向對方支付，還可以接受對方的支付。
閃電網路的支付隱私性：由於閃電網路的交易是在通道內進行的，不需要將所有交易都寫入區塊鏈，因此可以提高支付的隱私性。
閃電網絡的限制（大都是狀態與狀態機實現技術的限制）：閃電網絡還存在一些限制， 如通道的存活性、資金鎖定時間等，需要綜合考慮這些限制來設計合適的支付通道。
（2）在RGB 中，與狀態，狀態機，狀態通道相關的知識點有：
RGB 是基於LNP 和BP 協定。有關於RGB 是二層還是三層的討論，如果是基於BP 直接進行RGB 的運算，則是直接擴展了比特幣的圖靈完備功能，屬於第二層，這種方式對性能的擴展有限。如果是基於LNP 進行RGB 運算，則屬於第三層（因為LNP 是比特幣的第二層）， 這種方式既能擴展性能又能擴展圖靈完備的計算能力，只是技術實現上有一定的複雜度。通常用組合的方式，既能擴展運算能力，又能擴展效能，還能降低實現的複雜度。
RGB 是基於比特幣或閃電網絡中的狀態通道技術。 RGB 中的狀態通道是指建立在LNP 和BP 之上的雙方或多方之間的通訊通道，可以在通道內進行多次交易和狀態更新，減少了區區塊鏈上的交易數量和費用。
RGB 中的狀態通道使用了基於比特幣的多重簽名腳本來鎖定資金，並使用了特殊的交易類型來更新通道的狀態。
RGB 中的狀態通道可應用於各種場景，如支付管道、去中心化交易所、資產發行等， 提高了交易效率和使用者體驗。
RGB 中的狀態通道透過更新通道狀態來實現支付和資產轉移，通道內的交易不需要寫入區塊鏈，只有最終的狀態會被寫入區塊鏈。
RGB 中的狀態通道還可以實現更複雜的功能，如原子交換、支付路由等，透過智慧合約和多重簽署腳本來實現。
RGB 中的狀態通道可與其他技術和協定結合使用，如閃電網絡、LNURL 等，提供更豐富的功能和更好的使用者體驗。
RGB 中的狀態通道的設計和實施需要考慮安全性、隱私性、擴充性等因素，以確保系統的可靠性和可用性。
（3）在Nostr 中，與狀態，狀態機，和狀態通道相關的概念。
在Nostr 中因為傳遞的是訊息，還沒有體現狀態（可信數據，數字貨幣）和狀態機的概念。但相信Nostr 這種分散式結構稍加改造，增加對狀態的處理，會形成像閃電網絡相似的系統，這樣的系統既可以傳遞訊息，又可以專遞價值。在3.3 節Web3.0 的應用架構圖中也描述了這種基於資訊的分散式系統逐漸轉換為包含價值處理的分散式系統的可能性。
目前Nostr 的簡單介紹：Nostr 中有兩個主要元件，客戶端和中繼。每個用戶運行一個客戶端，通過中繼和其他人聯繫。每個用戶都由公鑰來標識。用戶發布的每個貼文都有簽名。每個客戶端都會驗證這些簽名。客戶端從他們選擇的中繼獲取資料並將資料發佈到他們選擇的中繼。中繼之間不相互通信，僅直接與使用者通訊。
（4）在分散式系統中，與狀態機相關的知識點有：
狀態機模型：狀態機是一種數學模型，用來描述系統在不同狀態之間的轉換和行為。在分散式系統中，狀態機模型常用於描述系統的行為和狀態變化。
有限狀態機（FSM）：有限狀態機是一種最基本的狀態機模型，它包含一組有限的狀態和一組狀態之間的轉換規則。在分散式系統中，有限狀態機可以描述系統的各種狀態和狀態之間的轉換。
狀態轉換：狀態轉換是指系統從一個狀態轉移到另一個狀態的過程。在分散式系統中， 狀態轉換可能由各種事件或條件觸發，例如接收到訊息、超時等。
狀態機的行為：狀態機在不同的狀態下可以定義不同的行為。在分散式系統中，狀態機的行為可以包括處理訊息、執行操作、傳送訊息等。
狀態一致性：在分散式系統中，多個節點可能具有不同的狀態。狀態一致性是指在系統中保持各節點的狀態相互協調且一致。
分散式狀態機（DSM）：分散式狀態機是指將狀態機模型應用於分散式系統中的一種技術。它可以將系統的狀態和狀態轉換分佈在多個節點上，並確保節點之間的狀態一致性。
原子狀態機（ASM）：原子狀態機是指在狀態轉換過程中保持原子性的狀態機。在分散式系統中，原子狀態機可以確保系統在狀態轉換過程中的一致性和可靠性。
一致性協定：一致性協定是一種用於保證分散式系統中狀態一致性的協定。常見的一致性協定有Paxos、Raft、ZAB 等。
容錯性：分散式狀態機需要具備容錯性，也就是在節點故障或訊息遺失的情況下，系統仍能保持正確的狀態和行為。
可擴充性：分散式狀態機需要具備可擴充性，即在系統規模擴大時能夠仍保持高效率的狀態轉換和一致性。
2.3. 狀態機與區塊鏈系統
透過以太坊的文檔《Ethereum EVM illustrated》，每個區塊都是一組觸發狀態，整個以太坊系統都是一個狀態處理機。在1.2 中，我們介紹了區塊鏈系統中的狀態機內容。在以太坊的白皮書中也有很多狀態機的描述。
狀態機雖然有很強的處理能力，但上限是區塊鏈結構的這個天花板。
對於基於UTXO 模型和基於帳號模型（類EVM）的區塊鏈互聯組合應用時，狀態與狀態機的實作方式有較大的差異。基於UTXO 模型的區塊鏈比較容易與分散式系統結合，是因為中兩種系統中的狀態都是基於UTXO ，不存在轉換或只需要簡單轉換，比較容易實現。基於帳號模型的鏈，因為其狀態與外部分散式系統之間的狀態需要進一步的封裝與轉換，實現有復雜度，這也是以太坊上雷電網絡發展不順利的部分原因。
2.4. 狀態機與中心化系統
使用區塊鏈+ 中心化系統的案例有類似Ordinals ，中心化交易所CEX。
這樣的系統相對簡單，有些根本不存在狀態傳遞，類似Ordinals ，僅使用中心化索引完成統計工作。
像中心化交易所，其中的狀態傳遞，完全依賴中心化系統設定的規則，裡面的狀態機也是由中心化系統程式構成的狀態處理機，沒有復雜的概念。
在未來Web3.0 的應用中，應該會出現較多使用區塊鏈+ 中心化系統的案例。
3. Web3 應用的結構應該是什麼樣子
透過文章前面的內容，我們知道了透過三種比特幣二層架構的組合可以完成更複雜的結構設計，從而得到所需的特性需求。而且從業務角度，如果應用的底層邏輯可以分解成狀態與狀態機，便可以使用三種系統的組合來完成上層的整個業務邏輯。
那麼這些常見的組合會有哪些呢？哪些因素會決定組合的結構？我們從常見的應用分類和應用需求來推測滿足Web3.0 的大規模應用的結構。
3.1. 常見應用的分類
我們以第48 次《中國互聯網機發展狀況統計報告》的應用統計為參考， 以下簡稱統計報告。因為Web2.0 已經發展成熟，不影響應用分類與使用者規模的結果分析，我們使用的應用參考資料是2020 年與2021 年的舊資料。需要注意的一點是，這只是中國互聯網的統計數據，在Web3.0 階段，許多應用都是在全球範圍，用戶的規模和效能要求更高。
在統計報告中，可以看到Web2.0 中的應用程式已經非常豐富，並且擁有龐大的使用者群體。這些應用包括：即時通訊、網路影片、短影片、網路支付、網路購物、搜尋引擎、網路新聞、 網絡音樂、網路直播、網路遊戲、網路外送、網路文學、網約車、線上辦公室、線上旅遊預定, 線上教育、線上醫療、… … ，幾乎涵蓋了人們生活的整個領域。除了這些消費互聯網的內容， 在產業互聯網中也有很多的應用。
如果Web2.0 全部應用程式都移到Web3.0 ，絕大多數對效能的要求是很高的。以Visa 支付為例，高峰期的性能需求為： 65000 TPS，這樣的性能指標只有分散式系統才能支持，例如， 當前閃電網絡每秒4000 萬筆的性能，而且閃電網絡的性能在理論上還沒有上限。
此外，我們以常見的遊戲為例，目前區塊鏈上最高TPS 的全鏈遊戲可實現高峰在數千TPS 左右，與數十萬級TPS 的傳統Web2 3A 遊戲存在巨大差距。如果要將所有的遊戲遷移到Web3.0 ，需要的基礎架構效能會是一個很大的挑戰。
何況遊戲在常見的應用分類中只是一種應用，其他的應用還有更多的效能與特定需求。
3.2. Web3.0 應用的需求
了解應用的需求，使用收入結構這個指標會更直接。我們參考《Token Terminal, curated by FutureMoney Research 2022 Q2》報告，這個報告雖然稍早，但像支付和其他應用都在初級階段，不影響主要的分析結果。所以作者在這個地方偷懶了，使用了我寫作Web3.0 圖書時候的數據，如果有2023 年Q4 的數據會更準確一些。
（1）透過收入報告的需求分析
報告裡面的收入分類比較好的代表了目前Web3.0 的核心產品組成。如圖所示。
1) Layer 1 （區塊鏈中的基礎主鏈）的收入48% ， 佔比接近總收入的一半，其商業模式可以理解為「 出售區塊空間」；
2) NFT 交易平台收入佔比為22% ，其商業模式可以理解為版稅抽傭或營銷活動變現；
3) DeFi 中的Dex 收入佔比為15% ，其商業模式為交易手續費和流動性做市收入；
4) DeFi 中的Staking 類收入佔比為8% ，其商業模式為資產管理的提成或利差；
5) Gamefi 佔比是5% ，其商業模式是版稅抽傭，轉帳手續費，銷售NFT 等；
6) DeFi 中的Lending 收入佔比約為1% ，其商業模式為利差；
7) Tooling 的營收佔比約為1% ，其商業模式為服務費，未來還會包含流量變現費用；
其他和Web3.0 相關的產業，不是Web3.0 的應用，不算Web3.0 的核心產業，不記入。例如：Web3.0 的媒體、研究組織、培訓組織等。
從收入結構可以看到目前BTC 生態的應用需求基本上可以靠區塊鍊和它的二層系統來解決，還不需要複雜的系統架構。但Gamefi 和SocialFi 發展比較快，我們使用參考文獻中的遊戲例子，可以看到大型的遊戲已經對系統結構有了更高的明確需求。
從收入結構可以看到當前BTC 生態的應用需求，值得把在以太坊等生態的產品都重做一遍。稍加改造以太坊生態上基於鏈的二層建設技術，在比特幣上建立新二層，能夠比較好的完成這些初級需求，只是在去中心化程度、安全性、隱私性、抗審查性做了一定的妥協。在《一文梳理比特幣二層（Layer 2）建設的基礎知識體系》那些新的基於EVM 類型的二層建設都是這種情況的案例。
（2）高效能需求的應用使用遊戲案例的分析
在文章《不可能變成可能：讓全鏈遊戲開發在閃電網絡上的成為現實》，對功能與效能都提出了較大的需求。 Web3.0 應用的真正架構也逐漸浮現。
文章中的問題描述：全鏈遊戲在確保安全性、隱私性和去中心化的基礎上，可擴充性始終沒有找到最佳解決方案。例如最熱門的全鏈遊戲引擎Mud 和Dojo ，致力於幫助全鏈遊戲實現更高的TPS ，但玩家每次操作仍需要2 秒以上的緩衝。事實上，目前區塊鏈上最高TPS 的全鏈遊戲可實現高峰在數千TPS 左右，與數十萬級TPS 的傳統Web2 3A 遊戲存在巨大差距。在追求不損失區塊鏈優勢的前提下，全鏈遊戲以克服的可擴展性。
在後面技術討論的解決方案中，使用閃電網絡和RGB 擴充效能，同時也提出了臨時鍊和專用鏈的概念。
Ephemeral chain（臨時鏈）
臨時區塊鏈可以定義為不會永遠存在的區塊鏈，一旦區塊鏈的目的實現（例如記錄交易），或者一旦其狀態永久儲存在其他地方，它們就會被銷毀。臨時鏈儲存的終止狀態只是有關臨時鏈相關終止事實的數據，因此將所有內容壓縮了相當大的數量級。臨時鏈主要受區塊鏈上交易延遲和吞吐量限制。
臨時鏈VS 狀態通道
就臨時鏈而言，由於公共鏈上有狀態，我們最終將擁有大量用戶。需要插入公鏈的狀態會透過剪枝/壓縮/差異提取來減少大小，然後定期而不是不定期地保存在公鏈上。 RGB 狀態通道的設定有可能繞過臨時鏈的效能約束，實現和臨時鏈相同的功能。
App-specific blockchains（特定應用程式區塊鏈）
特定於應用程式的區塊鍊是為運行單一去中心化應用程式（dapp）而創建的區塊鏈。開發人員不是在現有區塊鏈上構建，而是使用自定義虛擬機(VM) 從頭開始建立新的區塊鏈， 該虛擬機執行用戶與應用程式互動的交易。開發人員還可以客製化區塊鍊網絡堆棧的不同元素— —共識、網絡和執行— —以滿足特定的設計要求。提升智慧合約執行速度，解決運算資源限制可以幫助特定應用區塊鏈落地。允許開發人員為不同的用例定制基礎設施，使開發變得更容易。同時讓web3 開發人員建立強大的價值模型並擴展其dapp 以滿足指數級成長的需求，激發更多創新。
透過這個遊戲的案例，加上我們前面幾種架構的分析，我們可以大致判斷未來大規模應用的架構。
3.3. 滿足Web3.0 大規模應用的架構應該是什麼樣子
前面內容我們了解了Web2.0 中的常見應用分類，這些應用程式都升級到Web3.0 ，才是全面進入Web3.0 時代的標誌。什麼的架構才能滿足上面的眾多應用呢？
（1）簡單的Web2.0 與Web3.0 的架構區別
這裡參考了區塊鏈女神Preethi Kasireddy 寫的文章《 The Architecture of a Web 3.0 application》 內容。這裡對於Web3.0 應用的結構描述是一種很簡單的，只依賴區塊鏈系統就成完成的結構。但這種結構過於簡單，還沒有體現二層建設，在大規模應用上無法勝任。
將傳統中心化產品技術實現與Web3.0 產品的技術實現案例，進行差異對比，會更容易理解技術實現上兩者的差異。結合Gavin Wood 對Web3.0 的技術堆疊願景描述，我們可以看到Web3.0 的技術實現最大差異在後台，使用者的體驗層差異比較小。
（2）Web3.0 時代大規模應用的系統架構
在沒有區塊鏈的時代，應用是建立在中心化系統和分散式系統之上的。例如，建立在中心化系統上的商城、IM、影片等應用，建立在分散式系統上的迅雷下載。
有了區塊鏈系統後，我們進入Web3.0 時代，這個時期的應用是建立在區塊鏈系統、分散式系統、中心化系統之上的複雜架構。其中區塊鏈系統與其二層擴展完成價值的傳遞與處理，分散式系統與中心化系統完成訊息的傳遞與處理。
如下圖所示，
具體內容說明如下：
（1） 比特幣主網與二層建設是所有價值的中心，大部分的價值都建立在這個網絡之上。在比特幣二層建設中，基於鏈的二層完成價值的效能擴展與處理，處理的都是全量帳本資料。在比特幣二層建設中，基於分散式系統的二層建設完成效能的擴展，處理的都是局部相關數據，使用相關者共識，但最終計算結果需要落地到區塊鏈系統。比特幣二層建設中，基於中心化系統的二層建設，直接為上層應用服務。
（2）類RGB 系統也會需要一些臨時鍊或中間鏈，完成帳本的結算功能，如圖中的藍線所示。在參考文獻1 的遊戲案例中就有這種場景的描述。還沒有大規模出現是因為類RGB 系統建置複雜，還沒到成熟期。
（3）除了比特幣生態，還有其他區塊鏈系統的生態，完成不同業務場景的需求。如我們在二層基礎架構的文章中所描述，基於鏈的二層會存在眾多項目，對於非比特幣生態的鏈也同樣適用。其他區塊鏈系統和二層同樣可以進入閃電網絡與RGB，隨著技術成熟度上升這種情況就會逐漸出現。
（4）在Web3.0 生態中，中心化系統也會有一席之地，只是不再像Web2.0 中的比例那麼大。中心化系統有不少的優勢。
（5）在實際應用中，上圖內部的連線會加複雜，有些不需要使用二層，而直接對一層網絡操作，如RGB 在使用BP 協定時。其他區塊鏈也可能使用分散式系統，如以太坊上的雷電網絡，雖然不成熟，如果有需求場景，透過改造一些基礎特性也會有使用場景。上圖是對Web3.0 應用架構的簡化描述。
3.4. 可行的建設路徑
從收入結構可以看到目前BTC 生態的應用需求，從常用應用的分類，我們可以看到未來完全進入Web3.0 的需求。這會是一條漫長的路。所以對於這種建設週期比較長的事物， 都需要分階段來處理。
這裡的三個階段和大山老師所說的短期、中期、長期都非常相似。只是把基於鏈的二層建設的簡單階段也歸納到了第一階段建設中。
（1）第一階段是基於銘文和基於鏈的二層建設的前期
基於銘文和基於鏈的二層建設，因為相對容易，當前出現了眾多的應用。不管是brc 20 ， src 20 ，arc 20 ，銘文等應用，還是那些基於鏈的二層建設項目方，都很豐富。
這個階段建設相對簡單，多數是金融應用，有改造與模仿以太坊二層的經驗加持，很容易更快。雖然相對簡單，但這個過程必不可少，而且很重要，他們幫助繁榮了生態，引來了流量和資金，測試了跨鏈連接技術，測試了穩定幣，測試了各種可能性。這一階段主要是完成功能可行性的各種驗證。
（2）第二階段是基於鏈的二層建設的中後期與基於分散式系統的二層建設
在這個階段，基於鏈的二層建設也參與其中，是基於鏈的建設的高級階段，此外，第二階段重點是測試和完善多種分佈式的二層建設。閃電網絡會更加成熟，RGB 功能和穩定性得到較大的改善，應用場景都會更豐富。類RGB 的競爭者也會逐漸出現與成熟，如BitVM 。同時像Nostr 這樣的分散式系統也會融入價值功能。這一階段主要是完成功能和性能可行性的各種驗證。
（3）基於比特幣生態的大規模建設
最後一個階段是成熟階段，這個階段Web3.0 開始大量建設，逐漸成熟。在3.1 中描述的常見應用都開始進入Web3.0 時代。
也許這個階段要較長時間才能到來，也許遇到一個拐點事件，能夠推動大批的Web2.0 應用者進入，時間也許會不那麼長久。
不管如何，真正的Web3.0 時代來臨的時候，一定會有很大的不同，功能與產值比當前的PC 互聯網+移動互聯網的總體還要大，還要輝煌。也許就像AI 領域Sora 的出現，非常驚艷，讓人震驚，只是過程沒有那麼突然。
參考文獻說明
（1）參考了大山老師對於比特幣生態短期、中期、長期的相關文章與課程內容。
（2）《不可能變成可能：讓全鏈遊戲開發在閃電網絡上的成為現實》https://m.jinse.cn/news/blockchain/3667669.html（受這篇文章的啟發與驗證作用更大）
（3）三種觀察角度主要參考《Ethereum EVM illustrated》，Takenobu T. ， 2018.3
（4）應用分類相關內容，主要參考作者2022 年寫作的《Web3.0 ：建構元宇宙的數字未來》。
（5）參考了大學數字邏輯中的圖論知識。
（6）參考了一些分散式系統的文章內容。
