從架構維度看Web2.0與Web3.0應用之別（轉載）
原文標題：《The Architecture of a Web 3.0 application》
原文編譯：律動研究院
應用架構中的每一個元件都決定著應用的底層屬性
大家對於區塊鏈、智慧合約、IPFS、錢包、節點等這些名詞都不陌生，也大概明白他們都是做什麼的，然而他們是如何聯動起來服務於 Web3.0 去中心化應用的搭建的呢？
展現在我們眼前的僅僅是應用的前端，我們很難窺探到應用背後究竟是如何實現的。應用架構中的每一個元件都決定著應用的底層屬性，若想真的理解 Web2.0 與 Web3.0 應用之間的本質差異，我們需要從應用的架構入手。
本文作者 Preethi Kasireddy 曾在 2013 至 2015 年擔任 a16z 合夥人，隨後在 2016 年入職 Coinbase 擔任軟體工程師並在同期以智慧合約工程師身份活躍在以太坊網路中。本文從應用框架維度對 Web3.0 應用進行了深度解析。律動 BlockBeats 對全文進行了翻譯：
Web 3.0 的應用架構
Web 3.0 應用程式（或"DApps"）的架構與 Web 2.0 應用程式完全不同。
以 Medium，一個簡單的部落格網站為例子。Medium 允許使用者釋出自己的內容並與其他人的內容進行互動。
Medium 是一個 web 2.0 應用程式，架構聽起來很簡單。但實際上在 Medium 的架構中，需要大量工作使這一切成為可能。
首先，Medium 需要一個地方來儲存像使用者，帖子，標籤，評論，贊之類的基礎資料。這些工作需要不斷地更新資料庫。
其次，像 Node.js, Java, or Python 後端程式碼語言決定了 medium 的商業邏輯。例如，當新使用者註冊、釋出新部落格或在他人部落格上發表評論時會發生什麼情況？
還有，像 JavaScript, HTML, and CSS 之類的前端程式碼語言決定了 Medium 的 UI 邏輯。例如，網站是什麼樣子的，當用戶與頁面上的每個元素互動時會發生什麼？
當你在 Medium 上寫部落格時，這些所有的東西會整合起來聯動。你與它的前端互動，前端和後端互動，後端再與它的資料庫互動。所有這些程式碼都託管在中心化伺服器上，並通過網際網路瀏覽器傳送給使用者。這是對當今大多數 Web 2.0 應用程式的工作原理的一個高度總結。
現在這些全變了。
區塊鏈技術為 Web 3.0 應用開啟了令人興奮的新方向。在本文中，我們將重點討論以太坊帶來的改變。
是什麼讓 Web 3.0 如此不同？
與 Medium 這類 web2.0 程式不同是，Web3.0 去除了中間層。這中間沒有儲存應用程式狀態的中心化資料庫，也沒有中心化網站伺服器用於儲存後端邏輯。
你可以利用區塊鏈構建程式在去中心化的狀態機構建應用程式，這一系統是由網際網路上的匿名節點在維護。
狀態機是指一種可維持程式狀態並允許新的狀態寫入的「機器」。區塊鏈就是一種虛擬機器，其以創世狀態作為示例，隨後狀態根據具體規則進行轉換。
更重要的是，沒有單一實體控制這個去中心化的狀態機，它由網路中的每個人共同維護。
在 Web 3.0 中，你可以編寫智慧合約來定義應用程式的邏輯並將它們部署到去中心化的狀態機上。這意味著每個想要構建區塊鏈應用程式的人都在這個共享狀態機上部署他們的程式碼。這與 Medium 的後端十分不同。
Web3.0 的前端和 Web2.0 的前端基本相同，有一些特例我們將在後文中講解。
下圖是 Web3.0 的架構
深度解析
那麼，讓我們更深入地瞭解是什麼讓這一切成為可能
1）區塊鏈
以太坊是全球都可以參與維護的，點對點具有確定性的狀態機，這讓以太坊經常被吹捧為「世界電腦」。狀態機上的狀態更改由網路中的遵循共識規則的節點控制。
換句話說，它實際上被設計為世界上任何人都可以訪問和寫入的狀態機。因此，這臺機器不屬於任何單一實體，而是由網路中的每個人共同擁有。
還有一件事要知道：資料只能寫入以太坊區塊鏈，你永遠無法更新現有資料。
2）智慧合約
智慧合約是執行在以太坊區塊鏈上的程式，用於定義區塊鏈上發生的狀態變化背後的邏輯。智慧合約通常都用 Solidity 或者 Vyper 這類的高階語言編寫。
由於智慧合約程式碼儲存在以太坊區塊鏈上，任何人都可以檢查網路上所有智慧合約的應用邏輯。
3）以太坊虛擬機器（EVM）
虛擬機器是用來執行智慧合約中定義的邏輯並處理狀態機上發生的狀態變化。
以太坊虛擬機器不理解像 Solidity 或 Vyper 的這種高階語言。你需要將這些高階語言編譯成以太坊虛擬機器可以執行的位元組碼。
4）前端
正如我們之前提到的，前端定義了 UI 邏輯，但前端也與智慧合約中定義的應用程式邏輯進行互動。
前端和智慧合約之間的互動比上圖中顯示的要複雜一些。接下來讓我們詳細說明一下這部分。
以太坊上前端程式碼如何與智慧合約進行互動
我們想讓前端和智慧合約互動時能夠觸發程式的特定功能，但不要忘記，以太坊是一個去中心化的網路。所有每一個以太坊的節點都需要儲存一份以太坊狀態機上所有狀態的副本。這個副本包括所有與智慧合約相關的程式碼和資料。
當我們想和區塊鏈上的資料和程式碼進行互動的時候，我們要和區塊鏈中的某一節點進行通訊。因為任何節點都可以廣播在以太坊虛擬機器上進行交易的請求。在這之後礦工將執行交易並將結果狀態更改廣播到網路的其他節點上。
有兩種方式廣播新的交易：
1． 自己設立一個執行以太坊程式的節點
使用第三方節點，能讓你免去自己執行全節點所帶來的麻煩。因為有大量資料需要同步的關係，設立一個以太坊的節點通常需要好幾天的時間。並且同步所需的頻寬和儲存容量超過了一般膝上型電腦的處理能力，所以你同時需要一臺效能強勁的裝置。
此外，儲存完整以太坊區塊鏈的成本隨著 DApp 的擴容而增加，你需要新增更多節點來擴張你的基礎設施。當你的基礎設施變得複雜到一定程度後，你將需要一個全職 DevOps 工程師（可程式設計運維工程師）。他們將幫助你維護基礎設施，以確保你的基礎設施有著可靠的正常執行時間和快速的響應時間。
綜上所述，為了避免這些麻煩，許多 DApp 選擇使用 Infura 或 Alchemy 之類的服務商來管理他們的節點。但凡事有利有弊，這也造成了一箇中心化的阻塞點。但我們先不談這個問題。
不管是你自己設定還是使用來自第三方服務的節點，這些節點通常被稱為「提供商」（Providers）。我們接下來好好說說這些「提供商」。
每個以太坊客戶端（提供者）實行 JSON-RPC 規範。這確保了前端應用程式想要與區塊鏈互動時有一組統一的方法。JSON-RPC 是一種無狀態、輕量級的遠端應用程式呼叫 (RPC) 協議，它定義了多個數據結構及其處理規則。因為它具有傳輸不可知性（transport-agnostic），因此這些概念可在同一程序中被使用、穿梭在 sockets、 HTTP 或許多不同的訊息傳遞環境中。它使用 JSON (RFC 4627) 作為資料格式。
當你通過提供商連線到區塊鏈後，你就可以讀取儲存在區塊鏈上的狀態。但是，如果你想寫入狀態，你需要在將交易提交到區塊鏈之前，使用你的私鑰對交易進行「簽名」。
舉個例子，假設我們運行了一個 DApp，它可以讓使用者閱讀或釋出部落格文章到區塊鏈。你在前端設定了一個按鈕，允許任何人查詢特定使用者撰寫的部落格文章。但要記得，閱讀區塊鏈中的文章並不需要使用者對交易進行簽名。
但是，當用戶想要在區塊鏈上釋出新的文章時，DApp 會要求使用者使用他們的私鑰「簽署」交易，只有這樣 DApp 才會將交易傳播到區塊鏈上。否則節點不會接受這筆交易。
簽署交易這個環節通常是需要使用Metamask（小狐狸）的時候。
Metamask 是一種工具，可讓應用程式輕鬆處理金鑰管理和交易簽名。它原理非常簡單，Metamask 將使用者的私鑰儲存在瀏覽器中，每當前端需要使用者簽署交易時，它都會呼叫 Metamask。
Metamask 也會作為提供商與區塊鏈進行連結。因為 Metamask 需要簽署交易，所以它與 Infura 提供的節點建立了連線。在某種程度上說，Metamask 既是提供者又是簽名者。
在區塊鏈上儲存
當然，如果你所搭建的應用中所有智慧合約和資料都儲存在以太坊上的話，那麼這種架構還算合理。然而，在以太坊上搭建過應用程式的人都知道，在區塊鏈上儲存雖然快捷，但價格也不菲。
我們要明白，使用者每次在以太坊上新增新資料都要付費。這是因為去中心化的狀態機是由節點來維護的，而在狀態機上每新增一個狀態，都會增加節點的成本。
如果你的 DApp 每次在使用者交易需要新增新狀態時，都要求他們支付額外費用的話，那麼使用者體驗是很差的。不過，使用去中心化鏈下儲存方案，如 IPFS 或 Swarm，便可以解決這一問題。
IPFS 是一個用於儲存與訪問資料的分散式檔案系統。也就是說，IPFS 系統並不是將資料儲存在一箇中心化的資料庫中，而是將資料分散式儲存在 P2P 網路中，讓你隨時可以對資料進行檢索。
「Filecoin」是 IPFS 的激勵層，其作用是激勵世界各地的節點來儲存和檢索這些資料。你可以使用像 Infura 或 Pinata 這樣的提供商，因為 Infura 可以為你提供 IPFS 節點，而 Pinata 則可以讓你將檔案在 IPFS 中「定位」，繼而得到 IPFS 的雜湊值並將其儲存在區塊鏈上，且整個操作過程相當簡單。
Swarm 是一個去中心化的儲存網路，和 IPFS 有很多相似之處，但二者也有一個明顯區別。那就是，Filecoin 系統相對獨立，Swarm 的激勵系統是內建的，由以太坊上的智慧合約來執行，用於資料的儲存與檢索。
所以現在，有了 IPFS 或 Swarm，我們的應用架構會是這樣的：
在下圖當中，機智的你可能會注意到，前端程式碼並沒有儲存在區塊鏈上。其實我們完全可以和我們在 Web 2.0 中所做的一樣，將程式碼儲存在 AWS 上面，但這樣做也意味著你的 DApp 會受到來自中心化的制約。比方說，如果 AWS 癱瘓了怎麼辦？如果它對你的應用程式進行審查又該怎麼辦？
這也就是為什麼，如果你想搭建一個真正的去中心化應用程式，你會選擇像 IPFS 或 Swarm 這樣的去中心化儲存方案來儲存前端了。
所以現在你的應用架構會變成這樣：
在區塊鏈上進行查詢
到目前為止，我們已經探討了如何通過簽署交易並將它們傳送到區塊鏈上來完成交易的寫入。但從區塊鏈上的智慧合約中讀取資料又該如何操作呢？主要有以下兩種方式：
1）智慧合約事件
你可以利用 Web3.js 庫來查詢和監聽智慧合約事件。你也可以使用 Web3.js 監聽特定事件，並指定一個回撥函式在每次事件觸發時進行呼叫。比如說，現在假設有一個智慧合約可以在每個區塊中的傳送者與接收者之間傳送連續支付流，那麼每次向接收者支付款項時，你都可以發出一個智慧合約事件。前端程式碼可以監聽由智慧合約所觸發的事件，並據此採取相應行動。
2）The Graph
上述方法的確可行，但它同時也有一定的不足。比如說，你可能在智慧合約部署完成後才發現，自己要傳送的事件並沒有包含在合約當中，這該如何是好？不幸的是，你只能重新部署一個新的智慧合約，並將該事件與相關資料放入新的合約當中。不僅如此，回撥函式也很難處理不同的 UI 邏輯。
這時就該讓「The Graph」上場了。
The Graph 是一個鏈下資料索引方案，可以方便人們在以太坊上查詢資料。在 The Graph 中，你既可以定義哪些智慧合約需要索引、哪些事件與函式呼叫需要監聽，也可以規定如何將傳入的事件轉化為前端邏輯（或任何正使用 API 的程式）可處理的實體。它使用 GraphQL 作為查詢語言，這種語言深受前端工程師的喜愛，因為與傳統的 REST API 相比，它能傳達更多資訊。
通過索引區塊鏈資料，The Graph 可以讓我們在應用邏輯中查詢鏈上資料，並且幾乎不會出現延遲的情況。
現在，你的 DApp 架構大概是這樣：
現在只剩下最後一個重要問題：擴容。
DApp 的擴容
你可能已經聽說了，以太坊不具備可擴充套件性，至少目前還沒有。
以太坊 Gas 平均價格
平均交易費用
平均區塊規模
顯然，問題在於，以太坊上 Gas 費用高昂且區塊幾近飽和，在它上面搭建 DApp 會給使用者帶來非常不好的體驗。不過值得慶幸的是，一些相關方案正在開發當中。
Polygon 便是一個很受歡迎的 L2 擴容方案。在 Polygon 中，交易的處理與執行是由「側鏈」而非主鏈來完成的。這些側鏈是與主鏈相連的二級區塊鏈。每隔一段時間，側鏈就會將其最近的區塊聚合起來提交給主鏈。
同樣，Optimistic Rollup 和 zkRollup 也屬於 L2 方案，工作原理也都類似：他們用「Rollup」智慧合約在鏈下將大量交易進行捆綁，然後定期將這些交易提交給主鏈。
我們需要知道的是：L2 方案是將交易的執行（即速度較慢的部分）放在鏈下進行，而在鏈上只儲存交易資料。這樣一來，區塊鏈就能得以擴容，因為我們不用再在鏈上執行每筆交易了。同時，這也讓交易程序加快、成本降低，而且在必要時，L2 方案還可以與以太坊主鏈進行通訊。
全貌
如果到此你感覺頭暈目眩、迷惑不解，也屬於正常現象，因為將所有這些工具整合在一起本來就十分複雜，容易讓開發者感到焦頭爛額。但是不用擔心，開發框架的不斷問世將會切實提升開發者的工作體驗。
比如說，Hardhat 就是一個能方便以太坊開發者搭建、部署並測試智慧合約的開發框架。Hardhat 內建了「Hardhat 網路」，開發者可以用此網路將智慧合約部署到本地網路上，而無需處理實時環境。不僅如此，它還搭載了一個強大的外掛生態系統，可以為開發者提供更大的便利。同時，Hardhat 還具備 console.log() 功能，和 javascript 一樣可以用於除錯。
當然，這僅僅只是開始，我希望開發者工具在未來能有更好的發展。
總結
很多人花了幾個月的時間才搞清楚工具型區塊鏈是什麼，所以如果你是一個入門級的 DApp 開發者，那麼我希望這篇文章能為你省去部分時間。既然如此，那就開始 DApp 的搭建吧！ 如果你對搭建 Web 3.0 應用程式感興趣，那麼就請報名參加我們下一期的以太坊開發訓練營（Ethereum bootcamp），在那裡你將學習如何在以太坊上搭建並部署你的首個 DApp。
像往常一樣，如果你有任何問題或在這篇文章中發現任何錯誤，歡迎在評論區中和我交流!