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 開發人員，我希望這篇文章能為你節省一些時間。