Web 3.0 應用程序（或“DApps”）的架構與 Web 2.0 應用程序完全不同。
以 Medium 為例，這是一個簡單的博客網站，用戶可以發布自己的內容并與其他人的內容進行交互。
作為一個 web 2.0 應用程序，它可能聽起來很簡單，但 Medium 的架構中有很多東西使這一切成為可能：
首先，必須有一個地方來存儲基本數據，例如用戶、帖子、標簽、評論、喜歡，等等。這需要一個不斷更新的數據庫。
其次，后端代碼（用 Node.js、JAVA 或 Python/ target=_blank class=infotextkey>Python 等語言編寫）必須定義 Medium 的業務邏輯。例如，當新用戶注冊、發布新博客或在其他人的博客上發表評論時會發生什么？
第三，前端代碼（通常用 JavaScript、html 和 css 編寫）必須定義 Medium 的 UI 邏輯。例如，網站是什么樣的，當用戶與頁面上的每個元素交互時會發生什么？
綜上所述，當你在 Medium 上寫一篇博客文章時，你會與它的前端交互，它與它的后端對話，它與它的數據庫對話。所有這些代碼都托管在集中式服務器上，并通過互聯網瀏覽器發送給用戶。這是對當今大多數 Web 2.0 應用程序如何工作的一個很好的高級總結。
但所有這一切都在改變。
區塊鏈技術為 Web 3.0 應用開啟了一個激動人心的新方向。在本文中，我們將重點關注以太坊區塊鏈帶來的好處。
是什么讓 Web 3.0 與眾不同？
與 Medium 等 Web 2.0 應用程序不同，Web 3.0 消除了中間人。沒有存儲應用程序狀態的集中式數據庫，也沒有后端邏輯所在的集中式 Web 服務器。
相反，您可以利用區塊鏈在由互聯網上的匿名節點維護的分散狀態機上構建應用程序。
“狀態機”是指一臺機器，它維護一些給定的程序狀態和該機器上允許的未來狀態。區塊鏈是用一些創世狀態實例化的狀態機，并且具有非常嚴格的規則（即共識）來定義該狀態如何轉換。
更好的是，沒有一個實體可以控制這個分散的狀態機——它由網絡中的每個人共同維護。
那么后端服務器呢？在 Web 3.0 中，您可以編寫定義應用程序邏輯并將它們部署到去中心化狀態機上的智能合約，而不是如何控制 Medium 的后端。這意味著每個想要構建區塊鏈應用程序的人都將他們的代碼部署在這個共享狀態機上。
前端呢？它幾乎保持不變，除了一些例外，我們將在后面介紹。
這是架構的樣子：
仔細觀察
現在，讓我們更深入地了解是什么使這成為可能。
1) 區塊鏈
以太坊區塊鏈經常被吹捧為“世界計算機”。這是因為它是一個全局可訪問的確定性狀態機，由對等節點網絡維護。此狀態機上的狀態更改受網絡中對等方遵循的共識規則的約束。
因此，換句話說，它實際上被設計為世界上任何人都可以訪問和寫入的狀態機。因此，這臺機器不屬于任何單一實體，而是由網絡中的每個人共同擁有。
還有一件事要知道：數據只能寫入以太坊區塊鏈——你永遠無法更新現有數據。
2) 智能合約
智能合約是在以太坊區塊鏈上運行的程序，它定義了區塊鏈上發生的狀態變化背后的邏輯。智能合約是用高級語言編寫的，例如 Solidity 或 Vyper。
由于智能合約代碼存儲在以太坊區塊鏈上，任何人都可以檢查網絡上所有智能合約的應用邏輯。
3）以太坊虛擬機（EVM）
接下來，你有以太坊虛擬機，它執行智能合約中定義的邏輯并處理在這個全局可訪問的狀態機上發生的狀態變化。
EVM 不理解用于編寫智能合約的高級語言，如 Solidity 和 Vyper。相反，您必須將高級語言編譯成字節碼，然后 EVM 可以執行該字節碼。
4) 前端
最后，我們有前端。正如我們之前提到的，它定義了 UI 邏輯，但前端也與智能合約中定義的應用程序邏輯進行通信。
前端和智能合約之間的通信比上圖中顯示的要復雜一些。接下來讓我們仔細看看這個。
前端代碼如何與以太坊上的智能合約通信？
我們希望我們的前端與我們的智能合約進行通信，以便它們可以調用函數，但請記住，以太坊是一個去中心化的網絡。以太坊網絡中的每個節點都會在以太坊狀態機上保存一份所有狀態的副本，包括與每個智能合約相關的代碼和數據。
當我們想要與區塊鏈上的數據和代碼進行交互時，我們需要與這些節點之一進行交互。這是因為任何節點都可以廣播在 EVM 上執行交易的請求。然后礦工將執行交易并將結果狀態更改傳播到網絡的其余部分。
廣播新交易有兩種方式：
- 1.設置您自己的運行以太坊區塊鏈軟件的節點
- 2. 使用Infura[1]、Alchemy[2]和QUIcknode[3]等第三方服務提供的節點
如果您使用第三方服務，您不必自己處理運行全節點的所有麻煩事。畢竟，在你自己的服務器上設置一個新的以太坊節點可能需要幾天時間。（有很多數據需要同步——它甚至會占用比典型筆記本電腦所能處理的更多的帶寬和存儲空間。）
此外，隨著 DApp 的擴展，存儲完整的以太坊區塊鏈的成本也會上升，你需要添加更多的節點擴展您的基礎設施。這就是為什么隨著您的基礎架構變得越來越復雜，您將需要全職的 DevOps 工程師。他們將幫助您維護基礎架構，以確保可靠的正常運行時間和快速的響應時間。
總而言之，避免這些令人頭疼的問題就是為什么許多 DApp 選擇使用 Infura 或 Alchemy 等服務來為他們管理節點基礎設施。當然，有一個權衡，因為這會創建一個集中的阻塞點，但讓我們把那個兔子洞留到另一天。;)
繼續，讓我們談談供應商。當您需要與區塊鏈交互時連接的節點（無論是您自己設置還是使用來自第三方服務的現有節點）通常稱為“提供者”。
每個以太坊客戶端（即提供者）都實現了 JSON-RPC 規范。這確保了當前端應用程序想要與區塊鏈交互時有一組統一的方法。如果您需要 JSON-RPC 入門，它是一種無狀態、輕量級的遠程過程調用 (RPC) 協議，它定義了多個數據結構及其處理規則。它與傳輸無關，因此這些概念可以在同一進程中、通過套接字、通過 HTTP 或在許多不同的消息傳遞環境中使用。它使用 JSON (RFC 4627) 作為數據格式。
通過提供者連接到區塊鏈后，您可以讀取存儲在區塊鏈上的狀態。但是，如果您想寫入狀態，在您將交易提交到區塊鏈之前，您還需要做一件事——使用您的私鑰“簽署”交易。
例如，假設我們有一個 DApp 可以讓用戶閱讀或發布博客文章到區塊鏈。您可能在前端有一個按鈕，允許任何人查詢特定用戶撰寫的博客文章。（回想一下，從區塊鏈讀取數據不需要用戶簽署交易。）
但是，當用戶想要在鏈上發布新帖子時，我們的 DApp 會要求用戶使用他們的私鑰“簽署”交易——只有這樣 DApp 才會將交易中繼到區塊鏈。否則，節點不會接受交易。
這種交易的“簽名”是Metamask[4]通常出現的地方。
Metamask 是一種工具，可以讓應用程序輕松處理密鑰管理和事務簽名。這很簡單：Metamask 將用戶的私鑰存儲在瀏覽器中，每當前端需要用戶簽署交易時，它就會調用 Metamask。
Metamask 還提供了與區塊鏈的連接（作為“提供者”），因為它已經與 Infura 提供的節點建立了連接，因為它需要它來簽署交易。這樣，Metamask 既是提供者又是簽名者。
區塊鏈上的存儲
當然，如果您正在構建一個所有智能合約和數據都完全位于以太坊區塊鏈上的應用程序，那么這種架構是有意義的。但是任何在以太坊上構建應用程序的人都知道，將所有內容存儲在區塊鏈上會變得非常昂貴、非常快。
請記住，對于以太坊，用戶每次向區塊鏈添加新數據時都需要付費。這是因為向去中心化狀態機添加狀態會增加維護該狀態機的節點的成本。
每次交易需要添加新狀態時，要求用戶為使用你的 DApp 支付額外費用并不是最好的用戶體驗。解決這個問題的一種方法是使用去中心化的鏈下存儲解決方案，如IPFS[5]或Swarm[6]。
IPFS 是用于存儲和訪問數據的分布式文件系統。因此，IPFS 系統不是將數據存儲在集中式數據庫中，而是將數據分發和存儲在對等網絡中。這使您可以在需要時輕松檢索它。
IPFS 還有一個稱為“Filecoin”的激勵層。這一層激勵世界各地的節點存儲和檢索這些數據。您可以使用 Infura（為您提供 IPFS 節點）或 Pinata（提供易于使用的服務，您可以將文件“固定”到 IPFS 并獲取 IPFS 哈希并將其存儲在區塊鏈上）之類的提供商.
Swarm 的相似之處在于它是一個去中心化的存儲網絡，但有一個顯著的區別。雖然 Filecoin 是一個單獨的系統，但 Swarm 的激勵系統是內置的，并通過以太坊區塊鏈上的智能合約執行，用于存儲和檢索數據。
所以現在，使用 IPFS 或 Swarm，我們的應用程序架構如下所示：
精明的讀者可能還注意到，在下圖中，前端代碼并未存儲在區塊鏈上。我們可以像通常在 Web 2.0 中那樣在 AWS 上托管此代碼，但這會為您的 DApp 創建一個集中化的阻塞點。如果 AWS 出現故障怎么辦？如果它審查你的應用程序怎么辦？
這就是為什么如果你想構建一個真正去中心化的應用程序，你可能會選擇將你的前端托管在一個去中心化的存儲解決方案上，比如 IPFS 或 Swarm。
所以現在你的應用程序架構看起來更像這樣：
查詢區塊鏈
到目前為止，我們已經討論了如何通過簽署交易然后將它們發送到區塊鏈來寫入區塊鏈。但是從區塊鏈上的智能合約中讀取數據呢？有兩種主要方法可以做到這一點：
1) 智能合約事件您可以使用 Web3.js 庫來查詢和監聽智能合約事件。您可以監聽特定事件并在每次觸發事件時指定回調。例如，如果您有一個智能合約在每個區塊中從 A 人向 B 人發送連續付款流，那么您可以在每次向 B 人進行新付款時發出一個事件。您的前端代碼可以監聽被觸發的事件通過智能合約并基于它執行特定的操作。
2) 圖表上述方法有效，但有一些局限性。例如，如果您部署了一個智能合約，后來意識到您需要一個您最初沒有包含的事件，該怎么辦？不幸的是，您必須使用該事件和數據重新部署新的智能合約。此外，使用回調來處理各種 UI 邏輯會很快變得非常復雜。
這就是“ The Graph[7] ”的用武之地。
The Graph 是一種鏈下索引解決方案，可以更輕松地查詢以太坊區塊鏈上的數據。圖表允許您定義要索引的智能合約、要偵聽的事件和函數調用，以及如何將傳入事件轉換為前端邏輯（或任何使用 API）可以使用的實體。它使用 GraphQL 作為一種查詢語言，許多前端工程師都喜歡這種語言，因為它與傳統的 REST API 相比更具表現力。
通過索引區塊鏈數據，The Graph 讓我們能夠以低延遲查詢應用程序邏輯中的鏈上數據。
現在，您的 DApp 架構如下所示：
我們幾乎完成了，但我們還有一個主要話題：縮放。
擴展你的 DApp
您可能聽說過，以太坊無法擴展——至少目前還沒有。
以太坊平均gas價格
平均交易費用
平均塊大小
顯然，我們這里有問題。在以太坊上以高昂的汽油費和完整的區塊構建 DApp 會導致非常糟糕的用戶體驗。值得慶幸的是，有一些解決方案正在開發中。
一種流行的縮放解決方案是Polygon[8]，一種 L2 縮放解決方案。Polygon 沒有在主區塊鏈上執行交易，而是擁有處理和執行交易的“側鏈”。側鏈是與主鏈交互的二級區塊鏈。每隔一段時間，側鏈就會將其最近區塊的聚合提交回主鏈。
L2 解決方案的其他示例是Optimistic Rollups 和 zkRollups[9]。這里的想法是相似的：我們使用“匯總”智能合約在鏈下批量交易，然后定期將這些交易提交到主鏈。
帶回家的想法是這樣的：L2 解決方案在鏈下進行交易執行（即慢速部分），僅將交易數據存儲在鏈上。這讓我們可以擴展區塊鏈，因為我們不必在鏈上執行每一筆交易。這也使交易更快、更便宜——并且在必要時它們仍然可以與主要的以太坊區塊鏈進行通信。
拼湊起來
如果所有這些都讓您頭暈目眩，那么您并不孤單。將所有這些工具拼湊在一起很復雜，并且可能會導致痛苦的開發人員體驗。但別擔心——我們開始看到新的開發者框架真正改善了開發者的體驗。
例如，Hardhat[10]是一個開發者框架，它使以太坊開發者更容易構建、部署和測試他們的智能合約。Hardhat 提供了“Hardhat.NETwork”，開發人員可以使用它來將他們的智能合約部署到本地網絡上——而無需處理實時環境。更好的是，它提供了一個很棒的插件生態系統[11]，讓開發人員的生活變得更加輕松。Hardhat 還提供了類似于 javascript 的 console.log() 功能，用于調試目的。
當然，這僅僅是開始。我希望我們在未來繼續看到更好的開發者工具。
結論
大多數人會花費幾個月的時間來弄清楚工具鏈是如何工作的，所以如果你是一個新的 DApp 開發人員，我希望這篇文章能為你節省一些時間。是時候開始建設了！
如果您對構建 Web 3.0 應用程序感興趣，請注冊我們的下一個DappCamp[12]隊列，在那里您將學習如何在以太坊上構建和部署您的第一個 Dapp。
引用鏈接
[1] 使用Infura: https://infura.io/
[2] Alchemy: https://www.alchemy.com/
[3] Quicknode: https://www.quicknode.com/
[4] Metamask: https://metamask.io/
[5] IPFS: https://ipfs.io/
[6] Swarm: https://www.ethswarm.org/
[7] The Graph: https://thegraph.com/
[8] Polygon: https://polygon.technology/
[9] Optimistic Rollups 和 zkRollups: https://ethereum.org/en/developers/docs/scaling/layer-2-rollups
[10] Hardhat: https://hardhat.org/
[11] 插件生態系統: https://hardhat.org/plugins/
[12] DappCamp: https://www.dappcamp.xyz/
