先來回顧下 Web2.0 應用程序架構，一圖勝千言：
圖示是對大多數 Web 2.0 應用程序如何工作的一個很好的抽象總結。以一個博客平臺為例：
首先，必須有一個地方來存儲基本數據，也就是數據庫；
其次，要有后端代碼（用 Node.js、JAVA 或 Python/ target=_blank class=infotextkey>Python 等語言編寫），用于定義業務邏輯；
第三，還要有前端代碼（通常用 JavaScript、html 和 css 編寫），用于實現 UI 和交互；
這些代碼都托管在集中式服務器上。
視角來到 Web3.0 ，消除了中心化，沒有集中式的數據庫，沒有存放后端代碼的集中式 Web 服務器。采用了區塊鏈技術，在互聯網上的匿名節點維護的分布式 狀態機 上構建應用程序。
“狀態機”是指一臺機器，它維護一些給定的程序狀態、以及該機器上允許的未來狀態，它具有非常嚴格的規則（即共識）來定義狀態如何轉換。
沒有一個實體可以控制這個分布式的狀態機 —— 它由網絡中的每個人共同維護。
后端邏輯代碼化身成狀態機上的“智能合約”，這是開源的。
前端部分呢？暫按下不表，先看此時數據庫、后端代碼演變后的架構圖：
再進一步看看這些新穎的概念：
??-
ethereum blockchain，以太坊區塊鏈，被認為是“世界計算器”，一個可全局訪問的狀態機，對等節點網絡維護，狀態的更改遵循共識規則的約束；只要是寫入了數據，就會被記錄，數據不能再更新回去；
-
智能合約：以太坊上運行的程序，由高級編程語言編寫，例如 Solidity 或 Vyper；
任何人都能檢查智能合約是否合理；
-
EVM 虛擬機，用于執行合約的環境，相當于執行引擎；
OK，視野來到了前端代碼部分。按道理將，前端代碼應該也是用智能合約的方式實現，實際上，它也確實如此，不過要更為復雜一點。
當我們想要與區塊鏈上的數據和代碼進行交互時，我們需要與這些節點中的一個進行交互。任何節點都可以廣播在 EVM 上執行交易的請求，然后礦工將執行交易并將結果狀態更改傳播到網絡的其余部分。
廣播新交易有兩種方式：
-
設置自己運行以太坊區塊鏈軟件的節點；
-
使用Infura、 Alchemy和Quicknode等第三方服務提供的節點；
借助第三方節點可能會更輕松一點，它的邏輯是這樣的：
每個以太坊客戶端（即提供者）都實現了 JSON-RPC 規范。這確保了當前端應用程序想要與區塊鏈交互時，有一組統一的方法。JSON-RPC 是一種無狀態、輕量級的遠程過程調用 (RPC) 協議，定義了多個數據結構及其處理規則。它與傳輸無關，可以通過多種方式傳輸，比如 HTTP、套接字、其它傳輸環境，JSON (RFC 4627) 作為一種數據格式。
還有一個很重要的東西，進行身份驗證，鑒權。通常借助 Metamask 實現；
Metamask 將用戶的私鑰存儲在瀏覽器中，每當前端需要用戶簽署交易時，它就會調用 Metamask。
將所有內容都存儲在區塊鏈上是很昂貴的，更新數據都需要收費，所以還有一個 去中心化的鏈下存儲解決方案 —— IPFS/Swarm
架構圖如下：
IPFS/Swarm 是用于存儲和訪問數據的分布式文件系統，你可以輕松去檢驗它。
到目前為止，我們已經討論了如何寫入，那如何讀取數據呢？
答案是借助 The Graph，The Graph 是一種鏈下索引解決方案，可以更輕松地查詢以太坊區塊鏈上的數據。前端工程師可以直接調用，這比傳統的 REST API 更具有吸引力。
現在，DApp 架構如下：
截至目前，架構圖已初成雛形。
引申補充，完整的實現上圖這一架構，成本有點高昂。所以，有一種流行的擴展方案 —— L2 scaling 解決方案
在側鏈操作，然后提交到主鏈。
這樣既節約成本，又能達到目的，真是大聰明。
把這個側鏈執行，理解為代碼的預編譯吧，編譯后再放到瀏覽器引擎上做真正的編譯執行。
我們團隊從2016年做區塊鏈技術開發以來一直從事前言技術探索和產品開發，2020年gamefi 爆發以來持續關注gamefi的最新動態并為大大小小的企業團隊設計開發幾十款鏈游產品，并且打造自己的元宇宙生態，如果有興趣的團隊個人可以和我們合作一起研發打造最新最有價值的區塊鏈產品。
