Web 3.0 應用程序（或“DApps”）的架構與 Web 2.0 應用程序完全不同。
以博客園爲例，這是一個簡潔的博客網站，用戶可以發佈自己的內容並可以評論他人的內容進行互動。
作爲一個 web 2.0 應用程序，可能聽起來很簡單，但是博客園的架構中包含了很多東西可以才讓這一切成爲可能：
-
首先，必須有一個地方來存儲基本數據，例如用戶、文章、標籤、評論、推薦、反對等。這需要一個即時更新的數據庫。
-
其次，後端代碼（用 Go、Java、PHP 或 Python 等語言編寫）必須定義博客園的業務邏輯。例如，當新用戶註冊、發佈新博客或在其他人的博客上發表評論時會發生什麼？
-
第三，前端代碼（通常用 JavaScript、HTML 和 CSS 編寫）必須定義博客園的 UI 邏輯。例如，網站是什麼樣的，當用戶與頁面上的每個元素交互時會發生什麼？
綜上所述，當你在博客園上寫一篇博客文章時，你會與它的前端交互，前端與後端通信，後端與它的數據庫通信。所有這些代碼都託管在集中式服務器上，並通過互聯網瀏覽器發送給用戶。這是對當今大多數 Web 2.0 應用程序如何工作的一個概括性總結。
但這一切都在改變。
區塊鏈技術爲 Web 3.0 應用開啓了一個激動人心的新方向。在本文中，我們將重點關注以太坊區塊鏈帶來的好處。
是什麼讓Web3.0與衆不同？
與博客園等 Web 2.0 應用程序不同，Web 3.0 消除了中間人。沒有存儲應用程序狀態的集中式數據庫，也沒有後端邏輯所在的集中式 Web 服務器。
相反，您可以利用區塊鏈在由互聯網上的匿名節點維護的分散狀態機上構建應用程序。
“狀態機”(state machine)是指一臺機器，它維護一些給定的程序狀態和該機器上允許的未來狀態。區塊鏈是用一些初始狀態實例化的狀態機，並且具有非常嚴格的規則（即共識）來定義該狀態如何轉換。
更好的是，沒有任何一個實體可以控制這個分散的狀態機 —— 它由網絡中的每個人共同維護。
那麼後端服務器呢？在 Web 3.0 中，您可以編寫定義應用程序邏輯並將它們部署到去中心化狀態機上的智能合約，而不是如何控制博客園的後端。這意味着每個想要構建區塊鏈應用程序的人都將他們的代碼部署在這個共享狀態機上。
前端呢？它幾乎保持不變，除了一些例外，我們將在後面介紹。
這是架構的樣子：
透過現象看本質
現在，讓我們更深入地瞭解是什麼使這成爲可能。
區塊鏈(blockchain)
以太坊區塊鏈經常被吹捧爲“世界計算機”。 這是因爲它是一個全局可訪問的確定性狀態機，由對等節點網絡維護。 此狀態機上的狀態更改受網絡中對等方遵循的共識規則的約束。
因此，換句話說，它實際上被設計爲世界上任何人都可以訪問和寫入的狀態機。 因此，這臺機器不屬於任何單一實體，而是由網絡中的每個人共同擁有。
還有一件事要知道：數據只能寫入以太坊區塊鏈——你永遠無法更新現有數據。
智能合約(smart contracts)
智能合約是在以太坊區塊鏈上運行的程序，它定義了區塊鏈上發生的狀態變化背後的邏輯。智能合約是用高級語言編寫的，例如 Solidity 或 Vyper。
由於智能合約代碼存儲在以太坊區塊鏈上，任何人都可以檢查網絡上所有智能合約的應用邏輯。
以太坊虛擬機(Ethereum Virtual Machine,EVM)
接下來，你有以太坊虛擬機，它執行智能合約中定義的邏輯並處理在這個全局可訪問的狀態機上發生的狀態變化。
EVM 不理解用於編寫智能合約的高級語言，如 Solidity 和 Vyper。相反，您必須將高級語言編譯成字節碼，然後 EVM 可以執行該字節碼。
前端(front-end)
最後，我們有前端。正如我們之前提到的，它定義了 UI 邏輯，但前端也與智能合約中定義的應用程序邏輯進行通信。
前端和智能合約之間的通信比上圖中顯示的要複雜一些。接下來讓我們仔細看看這個。
前端代碼如何與以太坊上的智能合約通信？
我們希望我們的前端與我們的智能合約進行通信，以便它們可以調用函數，但請記住，以太坊是一個去中心化的網絡。 以太坊網絡中的每個節點都會在以太坊狀態機上保存一份所有狀態的副本，包括與每個智能合約相關的代碼和數據。
當我們想要與區塊鏈上的數據和代碼進行交互時，我們需要與這些節點之一進行交互。 這是因爲任何節點都可以廣播在 EVM 上執行交易的請求。 然後礦工將執行交易並將結果狀態更改傳播到網絡的其餘部分。
廣播新交易有兩種方式：
- 設置您自己的運行以太坊區塊鏈軟件的節點
- 使用 Infura、Alchemy 和 Quicknode 等第三方服務提供的節點
如果您使用第三方服務，則不必自己處理運行全節點的所有麻煩事。畢竟，在你自己的服務器上設置一個新的以太坊節點可能需要幾天時間。（有很多數據需要同步——它甚至會佔用比典型筆記本電腦所能處理的更多的帶寬和存儲空間。）
此外，存儲完整的以太坊區塊鏈的成本會隨着 DApp 的擴展而增加，您需要添加更多節點來擴展您的基礎設施。這就是爲什麼隨着您的基礎架構變得越來越複雜，您將需要全職的 DevOps 工程師。他們將幫助您維護基礎設施，以確保可靠的正常運行時間和快速的響應時間。
總而言之，避免這些令人頭疼的問題就是爲什麼許多 DApp 選擇使用 Infura 或 Alchemy 等服務來爲他們管理節點基礎設施。當然，有一個權衡，因爲這會創建一個集中的阻塞點，但讓我們把那個兔子洞留到另一天。
繼續，讓我們談談供應商。當您需要與區塊鏈交互時連接的節點（無論是您自己設置還是使用來自第三方服務的現有節點）通常稱爲“提供者(providers)”。
每個以太坊客戶端（即提供者）都實現了 JSON-RPC 規範。這確保了當前端應用程序想要與區塊鏈交互時有一套統一的方法。如果您需要 JSON-RPC 入門，它是一種無狀態、輕量級的遠程過程調用 (RPC) 協議，它定義了多種數據結構及其處理規則。它與傳輸無關，因此這些概念可以在同一進程、套接字、HTTP 或許多不同的消息傳遞環境中使用。它使用 JSON (RFC 4627) 作爲數據格式。
通過提供者連接到區塊鏈後，您可以讀取存儲在區塊鏈上的狀態。但是，如果你想寫入狀態，在將交易提交到區塊鏈之前，你還需要做一件事——使用你的私鑰“簽署”交易。
例如，假設我們有一個 DApp 可以讓用戶閱讀或發佈博客文章到區塊鏈。您可能在前端有一個按鈕，允許任何人查詢特定用戶撰寫的博客文章。（回想一下，從區塊鏈讀取數據不需要用戶簽署交易。）
但是，當用戶想要在鏈上發佈新帖子時，我們的 DApp 會要求用戶使用他們的私鑰“簽署”交易——只有這樣 DApp 纔會將交易中繼到區塊鏈。否則，節點不會接受交易。
這種交易的“簽名”是 Metamask 通常出現的地方。
Metamask 是一種工具，可以讓應用程序輕鬆處理密鑰管理和事務簽名。這很簡單：Metamask 將用戶的私鑰存儲在瀏覽器中，每當前端需要用戶簽署交易時，它就會調用 Metamask。
Metamask 還提供了與區塊鏈的連接（作爲“提供者”），因爲它已經與 Infura 提供的節點建立了連接，因爲它需要它來簽署交易。這樣，Metamask 既是提供者又是簽名者。 🤯
區塊鏈上的存儲
當然，如果您正在構建一個所有智能合約和數據都完全位於以太坊區塊鏈上的應用程序，那麼這種架構是有意義的。但是任何在以太坊上構建應用程序的人都知道，將所有內容存儲在區塊鏈上會變得非常昂貴、非常快。
請記住，對於以太坊，用戶每次向區塊鏈添加新數據時都需要付費。這是因爲向去中心化狀態機添加狀態會增加維護該狀態機的節點的成本。
每次交易需要添加新狀態時，要求用戶爲使用你的 DApp 支付額外費用並不是最好的用戶體驗。解決此問題的一種方法是使用去中心化的鏈下存儲解決方案，例如 IPFS 或 Swarm。
IPFS 是用於存儲和訪問數據的分佈式文件系統。因此，IPFS 系統不是將數據存儲在集中式數據庫中，而是將數據分發和存儲在對等網絡中。這使您可以在需要時輕鬆檢索它。
IPFS 還有一個稱爲“Filecoin”的激勵層。這一層激勵世界各地的節點存儲和檢索這些數據。您可以使用 Infura（爲您提供 IPFS 節點）或 Pinata（提供易於使用的服務，您可以將文件“固定”到 IPFS 並獲取 IPFS 哈希並將其存儲在區塊鏈上）之類的提供商.
Swarm 的相似之處在於它是一個去中心化的存儲網絡，但有一個顯着的區別。雖然 Filecoin 是一個單獨的系統，但 Swarm 的激勵系統是內置的，並通過以太坊區塊鏈上的智能合約執行，用於存儲和檢索數據。
所以現在，使用 IPFS 或 Swarm，我們的應用程序架構如下所示：
精明的讀者可能還注意到，在下圖中，前端代碼並未存儲在區塊鏈上。 我們可以像通常在 Web 2.0 中那樣在 AWS 上託管此代碼，但這會爲您的 DApp 創建一個集中化的阻塞點。如果 AWS 出現故障怎麼辦？ 如果它審查你的應用程序怎麼辦？
這就是爲什麼，如果你想構建一個真正去中心化的應用程序，你可能會選擇將你的前端託管在一個去中心化的存儲解決方案上，比如 IPFS 或 Swarm。
所以現在你的應用程序架構看起來更像這樣：
查詢區塊鏈
到目前爲止，我們已經討論瞭如何通過簽署交易然後將它們發送到區塊鏈來寫入區塊鏈。但是從區塊鏈上的智能合約中讀取數據呢？有兩種主要方法可以做到這一點：
(1)智能合約事件(Smart Contract Events)
您可以使用 Web3.js 庫來查詢和監聽智能合約事件。您可以監聽特定事件並在每次觸發事件時指定回調。 例如，如果您有一個智能合約在每個區塊中從 A 人向 B 人發送連續付款流，那麼您可以在每次向 B 人進行新付款時發出一個事件。您的前端代碼可以監聽被觸發的事件 通過智能合約並基於它執行特定的操作。
(2)The Graph
上述方法有效，但有一些侷限性。例如，如果你部署了一個智能合約，後來意識到你需要一個你最初沒有包含的事件，該怎麼辦？不幸的是，您必須使用該事件和數據重新部署新的智能合約。此外，使用回調來處理各種 UI 邏輯會很快變得非常複雜。
這就是“The Graph”的用武之地。
The Graph 是一種鏈下索引解決方案，可以更輕鬆地查詢以太坊區塊鏈上的數據。 圖表允許您定義要索引的智能合約、要偵聽的事件和函數調用，以及如何將傳入事件轉換爲前端邏輯（或任何使用 API）可以使用的實體。 它使用 GraphQL 作爲一種查詢語言，許多前端工程師都喜歡這種語言，因爲它與傳統的 REST API 相比更具表現力。
通過索引區塊鏈數據，The Graph 讓我們能夠以低延遲查詢應用程序邏輯中的鏈上數據。
現在，您的 DApp 架構如下所示：
我們幾乎完成了，但我們還剩下一個主要話題：擴展。
擴展你的 DApp
你可能聽說過，以太坊無法擴展 —— 至少目前還沒有。
顯然，我們這裏有問題。在以太坊上以高昂的gas費和完整的區塊構建 DApp 會導致非常糟糕的用戶體驗。值得慶幸的是，有一些解決方案正在開發中。
一種流行的擴展解決方案是多邊形，一種 L2 擴展解決方案。 Polygon 沒有在主區塊鏈上執行交易，而是擁有處理和執行交易的“側鏈”。 側鏈是與主鏈交互的二級區塊鏈。每隔一段時間，側鏈就會將其最近區塊的聚合提交回主鏈。
L2 解決方案的其他示例是 Optimistic Rollups 和 zkRollups。這裏的想法是相似的：我們使用“彙總”智能合約在鏈下批量交易，然後定期將這些交易提交到主鏈。
帶回家的想法是這樣的：L2 解決方案在鏈下進行交易執行（即慢速部分），只有交易數據存儲在鏈上。這讓我們可以擴展區塊鏈，因爲我們不必在鏈上執行每一筆交易。這也使交易更快、更便宜 —— 並且在必要時它們仍然可以與主要的以太坊區塊鏈進行通信。
拼湊起來
如果所有這些都讓您頭暈目眩，那麼您並不孤單。將所有這些工具拼湊在一起很複雜，並且可能會導致痛苦的開發人員體驗。但別擔心——我們開始看到新的開發者框架真正改善了開發者的體驗。
例如，Hardhat 是一個開發者框架，它使以太坊開發者更容易構建、部署和測試他們的智能合約。Hardhat 提供了“Hardhat Network”，開發人員可以使用它來將他們的智能合約部署到本地網絡上——而無需處理實時環境。更好的是，它提供了一個很棒的插件生態系統，讓開發人員的生活變得更加輕鬆。Hardhat 還提供了類似於 javascript 的 console.log() 功能，用於調試目的。
當然，這僅僅是開始。我希望我們在未來繼續看到更好的開發者工具。
結論
大多數人花費數月時間來弄清楚工具鏈是如何工作的，所以如果你是一個新的 DApp 開發人員，我希望這篇文章能爲你節省一些時間。