Web 3.0應(yīng)用程序(或“DApps”)的體系結(jié)構(gòu)與Web 2.0應(yīng)用程序完全不同。
以Medium為例，這是一個(gè)簡(jiǎn)單的博客網(wǎng)站，允許用戶發(fā)布自己的內(nèi)容，并與他人的內(nèi)容進(jìn)行交互。
作為一個(gè)web 2.0應(yīng)用程序，它聽起來可能很簡(jiǎn)單，但Medium的架構(gòu)中有很多東西使這一切成為可能:
首先，必須有一個(gè)地方存儲(chǔ)必要的數(shù)據(jù)，如用戶、帖子、標(biāo)簽、評(píng)論、喜歡等等。這需要不斷更新數(shù)據(jù)庫(kù)。
其次，后端代碼(用像Node.js、Java或Python這樣的語言編寫)必須定義Medium的業(yè)務(wù)邏輯。例如，當(dāng)一個(gè)新用戶注冊(cè)、發(fā)布一個(gè)新博客或在其他人的博客上發(fā)表評(píng)論時(shí)，會(huì)發(fā)生什么?
第三，前端代碼(通常用JavaScript、HTML和CSS編寫)必須定義Medium的UI邏輯。例如，站點(diǎn)是什么樣子的，當(dāng)用戶與頁面上的每個(gè)元素交互時(shí)會(huì)發(fā)生什么?
當(dāng)您在Medium上寫一篇博客文章時(shí)，您將與它的前端交互，前端與后端交互，后端與數(shù)據(jù)庫(kù)交互。所有這些代碼都駐留在中心化的服務(wù)器上，并通過瀏覽器呈現(xiàn)給用戶。這是對(duì)當(dāng)今大多數(shù)Web 2.0應(yīng)用程序如何工作的一個(gè)很好的高級(jí)總結(jié)。
但這一切都在改變。
區(qū)塊鏈技術(shù)為Web 3.0應(yīng)用程序開辟了一個(gè)令人興奮的新方向。在本文中，我們將重點(diǎn)討論以太坊區(qū)塊鏈帶來了什么。
是什么讓W(xué)eb 3.0與眾不同?
與像Medium這樣的Web 2.0應(yīng)用程序不同，Web 3.0消除了中間人。沒有存儲(chǔ)應(yīng)用程序狀態(tài)的集中式數(shù)據(jù)庫(kù)，也沒有后端邏輯駐留的集中式web服務(wù)器。
相反，您可以利用區(qū)塊鏈在分布式的狀態(tài)機(jī)上構(gòu)建應(yīng)用程序，該狀態(tài)機(jī)由互聯(lián)網(wǎng)上的匿名節(jié)點(diǎn)維護(hù)。
通過“狀態(tài)機(jī)”，我指的是維護(hù)某些給定程序狀態(tài)和該機(jī)器上允許的未來狀態(tài)的機(jī)器。區(qū)塊鏈?zhǔn)且环N狀態(tài)機(jī)，用一些初始狀態(tài)實(shí)例化，并且有非常嚴(yán)格的規(guī)則(即共識(shí))來定義該狀態(tài)如何轉(zhuǎn)換。
更好的是，沒有一個(gè)實(shí)體控制這個(gè)分布式的狀態(tài)機(jī)——它是由網(wǎng)絡(luò)中的每個(gè)人共同維護(hù)的。
那么后端服務(wù)器呢? 在Web 3.0中，您可以編寫智能合約來定義應(yīng)用程序的邏輯，并將它們部署到去中心化的狀態(tài)機(jī)上，而不是如何控制Medium的后端。這意味著每個(gè)想要構(gòu)建區(qū)塊鏈應(yīng)用程序的人都會(huì)在這個(gè)共享狀態(tài)機(jī)上部署他們的代碼。
前端呢?它幾乎保持不變，除了一些例外，我們將在后面討論。
這個(gè)架構(gòu)是這樣的:
更進(jìn)一步
現(xiàn)在，讓我們更深入地研究一下是什么讓這成為可能。
1)區(qū)塊鏈
以太坊區(qū)塊鏈經(jīng)常被吹捧為“世界計(jì)算機(jī)”。這是因?yàn)樗且粋€(gè)全局可訪問的、由點(diǎn)對(duì)點(diǎn)節(jié)點(diǎn)網(wǎng)絡(luò)維護(hù)的確定性狀態(tài)機(jī)。此狀態(tài)機(jī)上的狀態(tài)更改由網(wǎng)絡(luò)中的對(duì)等點(diǎn)遵循的共識(shí)規(guī)則進(jìn)行管理。
換句話說，它被設(shè)計(jì)成世界上任何人都可以訪問和寫入的狀態(tài)機(jī)。因此，這臺(tái)機(jī)器不屬于任何單一實(shí)體，而是由網(wǎng)絡(luò)中的每個(gè)人共同擁有。
還有一件事需要知道:數(shù)據(jù)只能寫入以太坊區(qū)塊鏈—您永遠(yuǎn)不能更新已經(jīng)存在的數(shù)據(jù)。
2)智能合約
智能合約是一個(gè)運(yùn)行在以太坊區(qū)塊鏈上的程序，它定義了發(fā)生在區(qū)塊鏈上的狀態(tài)變化背后的邏輯。智能合約是用高級(jí)語言編寫的，比如Solidity或Vyper。
由于智能合約代碼存儲(chǔ)在以太坊區(qū)塊鏈上，任何人都可以檢查網(wǎng)絡(luò)上所有智能合約的應(yīng)用邏輯。
3)以太坊虛擬機(jī)(EVM)
接下來，您將擁有以太坊虛擬機(jī)，它執(zhí)行智能合約中定義的邏輯，并處理在這個(gè)全局可訪問狀態(tài)機(jī)上發(fā)生的狀態(tài)更改。
EVM不理解Solidity和Vyper等用于編寫智能合約的高級(jí)語言。相反，您必須將高級(jí)語言編譯為字節(jié)碼，然后由EVM執(zhí)行。
4)前端
最后是前端。正如我們前面提到的，它定義了UI邏輯，但前端也與智能合約中定義的應(yīng)用程序邏輯進(jìn)行通信。
前端和智能合約之間的通信比上圖中顯示的要復(fù)雜一些。讓我們接下來仔細(xì)看看這個(gè)問題。
前端代碼如何與以太坊上的智能合約通信?
我們希望我們的前端與我們的智能合約通信，這樣它們就可以調(diào)用功能，但請(qǐng)記住，以太坊是一個(gè)去中心化的網(wǎng)絡(luò)。以太坊網(wǎng)絡(luò)中的每個(gè)節(jié)點(diǎn)都在以太坊狀態(tài)機(jī)上保存所有狀態(tài)的副本，包括與每個(gè)智能合約相關(guān)的代碼和數(shù)據(jù)。
當(dāng)我們希望與區(qū)塊鏈上的數(shù)據(jù)和代碼交互時(shí)，我們需要與這些節(jié)點(diǎn)中的一個(gè)進(jìn)行交互。這是因?yàn)槿魏喂?jié)點(diǎn)都可以廣播要在EVM上執(zhí)行的交易請(qǐng)求。然后，礦工將執(zhí)行交易，并將結(jié)果狀態(tài)更改廣播到網(wǎng)絡(luò)的其他部分。
有兩種方式來廣播一個(gè)新的交易:
- 啟動(dòng)自己的運(yùn)行以太坊區(qū)塊鏈軟件的節(jié)點(diǎn)。
- 使用第三方服務(wù)提供的節(jié)點(diǎn)，如Infura, Alchemy和Quicknode。
如果您使用第三方服務(wù)，就不必自己處理運(yùn)行完整節(jié)點(diǎn)的所有麻煩。畢竟，在您自己的服務(wù)器上設(shè)置一個(gè)新的以太坊節(jié)點(diǎn)可能需要幾天時(shí)間。(有很多數(shù)據(jù)需要同步——它甚至可以占用比普通筆記本電腦更多的帶寬和存儲(chǔ)空間。)
此外，存儲(chǔ)完整以太坊區(qū)塊鏈的成本隨著DApp的擴(kuò)展而增加，您需要添加更多的節(jié)點(diǎn)來擴(kuò)展您的基礎(chǔ)設(shè)施。這就是為什么當(dāng)你的基礎(chǔ)架構(gòu)變得更加復(fù)雜時(shí)，你需要全職的DevOps工程師。它們將幫助您維護(hù)基礎(chǔ)設(shè)施，以確?？煽康恼＿\(yùn)行時(shí)間和快速的響應(yīng)時(shí)間。
也就是說，為了避免這些麻煩，許多DApps選擇使用像Infura或Alchemy這樣的服務(wù)來管理它們的節(jié)點(diǎn)基礎(chǔ)設(shè)施。當(dāng)然，這是有代價(jià)的，因?yàn)檫@會(huì)創(chuàng)建一個(gè)集中的阻塞點(diǎn)。
接下來，讓我們談?wù)勌峁┱摺．?dāng)您需要與區(qū)塊鏈交互時(shí)所連接的節(jié)點(diǎn)(無論您自己設(shè)置它們還是使用來自第三方服務(wù)的現(xiàn)有節(jié)點(diǎn))通常被稱為“提供者”。
每個(gè)以太坊客戶端(即提供者)都實(shí)現(xiàn)了一個(gè)JSON-RPC規(guī)范。這確保了當(dāng)前端應(yīng)用程序想要與區(qū)塊鏈交互時(shí)，有一組統(tǒng)一的方法。如果您需要了解JSON-RPC的基礎(chǔ)知識(shí)，它是一種無狀態(tài)的輕量級(jí)遠(yuǎn)程過程調(diào)用(RPC)協(xié)議，它定義了幾種數(shù)據(jù)結(jié)構(gòu)及其處理規(guī)則。它與傳輸無關(guān)，因此可以在同一個(gè)進(jìn)程中、在套接字上、在HTTP上或在許多不同的消息傳遞環(huán)境中使用這些概念。它使用JSON (RFC 4627)作為數(shù)據(jù)格式。
一旦通過提供程序連接到區(qū)塊鏈，就可以讀取存儲(chǔ)在區(qū)塊鏈上的狀態(tài)。但是，如果您想寫入狀態(tài)，在將交易提交給區(qū)塊鏈之前，還需要做一件事—使用您的私鑰對(duì)交易進(jìn)行“簽名”。
例如，假設(shè)我們有一個(gè)DApp，它允許用戶向區(qū)塊鏈讀取或發(fā)布博客文章。在前端可能有一個(gè)按鈕，允許任何人查詢特定用戶撰寫的博客文章。(回想一下，從區(qū)塊鏈讀取并不需要用戶對(duì)交易進(jìn)行簽名。)
然而，當(dāng)用戶想要在鏈上發(fā)布一個(gè)新的帖子時(shí)，我們的DApp會(huì)要求用戶使用他們的私鑰“簽名”該交易——只有這樣，DApp才會(huì)將該交易轉(zhuǎn)發(fā)給區(qū)塊鏈。否則，節(jié)點(diǎn)將不會(huì)接受交易。
這種交易的“簽名”是Metamask通常使用的地方。
Metamask是一個(gè)工具，它使應(yīng)用程序可以輕松地處理密鑰管理和交易簽名。這非常簡(jiǎn)單:Metamask將用戶的私鑰存儲(chǔ)在瀏覽器中，每當(dāng)前端需要用戶簽署交易時(shí)，它就會(huì)調(diào)用Metamask。
Metamask還提供了一個(gè)到區(qū)塊鏈的連接(作為一個(gè)“提供者”)，因?yàn)樗呀?jīng)有一個(gè)到Infura提供的節(jié)點(diǎn)的連接，又因?yàn)樾枰鼇砗炇鸾灰住Ｍㄟ^這種方式，Metamask既是提供者又是簽名者。
區(qū)塊鏈上的存儲(chǔ)
當(dāng)然，如果您正在構(gòu)建一個(gè)應(yīng)用程序，其中所有的智能合約和數(shù)據(jù)都完全存在于以太坊區(qū)塊鏈上，那么這種架構(gòu)是有意義的。但任何在以太坊上構(gòu)建應(yīng)用程序的人都知道，在區(qū)塊鏈上存儲(chǔ)所有東西會(huì)很快變得非常昂貴。
請(qǐng)記住，在以太坊中，用戶每次向區(qū)塊鏈添加新數(shù)據(jù)時(shí)都要付費(fèi)。這是因?yàn)橄蚍植际綘顟B(tài)機(jī)添加一個(gè)狀態(tài)會(huì)增加節(jié)點(diǎn)維護(hù)該狀態(tài)機(jī)的成本。
每次交易需要添加新狀態(tài)時(shí)，要求用戶為使用DApp支付額外費(fèi)用并不是最好的用戶體驗(yàn)。解決這個(gè)問題的一種方法是使用去中心化的鏈下存儲(chǔ)解決方案，如IPFS或Swarm。
IPFS是一種用于存儲(chǔ)和訪問數(shù)據(jù)的分布式文件系統(tǒng)。因此，IPFS系統(tǒng)不是將數(shù)據(jù)存儲(chǔ)在中心化的數(shù)據(jù)庫(kù)中，而是將數(shù)據(jù)分布和存儲(chǔ)在對(duì)等網(wǎng)絡(luò)中。這使您可以在需要時(shí)輕松地獲取它。
IPFS還有一個(gè)激勵(lì)層，稱為“Filecoin”。這一層激勵(lì)世界各地的節(jié)點(diǎn)存儲(chǔ)和檢索這些數(shù)據(jù)。您可以使用像Infura(它為您提供了一個(gè)IPFS節(jié)點(diǎn))或Pinata(它提供了一個(gè)易于使用的服務(wù)，您可以將您的文件“固定”到IPFS，并獲取IPFS hash并將其存儲(chǔ)在區(qū)塊鏈上)這樣的提供商。
Swarm的相似之處在于它是一個(gè)去中心化的存儲(chǔ)網(wǎng)絡(luò)，但有一個(gè)顯著的區(qū)別。雖然Filecoin是一個(gè)單獨(dú)的系統(tǒng)，但Swarm的激勵(lì)系統(tǒng)是內(nèi)置的，并通過以太坊區(qū)塊鏈上的智能合約來執(zhí)行，用于存儲(chǔ)和檢索數(shù)據(jù)。
所以現(xiàn)在，有了IPFS或Swarm，我們的應(yīng)用架構(gòu)看起來是這樣的:
精明的讀者可能還注意到在下面的圖中，前端代碼沒有存儲(chǔ)在區(qū)塊鏈上。我們可以在AWS上托管這些代碼，就像我們通常在Web 2.0中所做的那樣，但這為您的DApp創(chuàng)建了一個(gè)集中化的阻塞點(diǎn)。如果AWS癱瘓了怎么辦?如果它審查你的應(yīng)用呢?
這就是為什么，如果你想構(gòu)建一個(gè)真正去中心化的應(yīng)用程序，你可能會(huì)選擇在一個(gè)去中心化的存儲(chǔ)解決方案上托管你的前端，如IPFS或Swarm。
所以現(xiàn)在你的應(yīng)用程序架構(gòu)看起來更像這樣:
查詢區(qū)塊鏈上的數(shù)據(jù)
到目前為止，我們已經(jīng)討論了如何通過簽署交易并將它們發(fā)送到區(qū)塊鏈來寫入?yún)^(qū)塊鏈。但是從區(qū)塊鏈上的智能合約讀取數(shù)據(jù)呢?有兩種主要的方法:
1)智能合約事件
你可以使用Web3.js庫(kù)來查詢和監(jiān)聽智能合約事件。您可以監(jiān)聽特定的事件，并在每次事件觸發(fā)時(shí)指定回調(diào)。例如，如果你有一個(gè)智能合約，它在每個(gè)區(qū)塊中發(fā)送一個(gè)從A到人B的連續(xù)支付流，那么你可以在每次向B進(jìn)行新的支付時(shí)發(fā)出一個(gè)事件。你的前端代碼可以偵聽由智能合約觸發(fā)的事件，并基于它執(zhí)行特定的操作。
2)圖
上述方法是可行的，但它有一些局限性。例如，如果您部署了一個(gè)智能合約，但后來發(fā)現(xiàn)需要觸發(fā)一個(gè)最初沒有包含的事件，該怎么辦?不幸的是，您必須使用該事件和數(shù)據(jù)重新部署一個(gè)新的智能合約。此外，使用回調(diào)來處理各種UI邏輯很快就會(huì)變得非常復(fù)雜。
這就是“圖”發(fā)揮作用的地方。
圖(Graph)是一個(gè)鏈下索引解決方案，使其更容易查詢以太坊區(qū)塊鏈上的數(shù)據(jù)。圖允許您定義要索引哪些智能合約，要偵聽哪些事件和函數(shù)調(diào)用，以及如何將傳入的事件轉(zhuǎn)換為前端邏輯(或使用API的任何東西)可以使用的實(shí)體。它使用GraphQL作為查詢語言，許多前端工程師喜歡這種語言，因?yàn)榕c傳統(tǒng)REST api相比，它的表達(dá)能力很強(qiáng)。
通過索引區(qū)塊鏈數(shù)據(jù)，Graph允許我們以低延遲查詢應(yīng)用程序邏輯中的鏈上數(shù)據(jù)。
現(xiàn)在，你的DApp架構(gòu)看起來像這樣:
擴(kuò)展你的DApp
正如您可能已經(jīng)聽說的，以太坊無法擴(kuò)展——至少現(xiàn)在還不行。
很明顯，我們有麻煩了。在以太坊上構(gòu)建DApp需要支付高額的gas費(fèi)用以及完整的區(qū)塊會(huì)導(dǎo)致非常糟糕的用戶體驗(yàn)。值得慶幸的是，有一些解決方案正在開發(fā)中。
一個(gè)流行的擴(kuò)展解決方案是Polygon，一個(gè)L2擴(kuò)展解決方案。Polygon使用“側(cè)鏈”來處理和執(zhí)行交易，而不是在主區(qū)塊鏈上執(zhí)行交易。側(cè)鏈?zhǔn)桥c主鏈交互的二級(jí)區(qū)塊鏈。每隔一段時(shí)間，側(cè)鏈就會(huì)向主鏈提交最近區(qū)塊的聚合。
L2解決方案的其他例子是Optimistic Rollups and zkRollups.
。這里的想法是類似的:我們使用“rollup”智能合約來批量處理鏈下的事務(wù)，然后定期將這些事務(wù)提交到主鏈。
最重要的想法是:L2解決方案在鏈下執(zhí)行交易(即慢的部分)，只有交易數(shù)據(jù)存儲(chǔ)在鏈上。這使我們能夠擴(kuò)展區(qū)塊鏈，因?yàn)槲覀儾槐貓?zhí)行鏈上的每個(gè)交易。這也使得交易更快、更便宜，并且在必要時(shí)他們?nèi)匀豢梢耘c主以太坊區(qū)塊鏈通信。
拼湊在一起
如果所有這些都讓你頭暈?zāi)垦?，你不是一個(gè)人。拼湊所有這些工具是復(fù)雜的，可能會(huì)導(dǎo)致痛苦的開發(fā)人員體驗(yàn)。但是別擔(dān)心——我們已經(jīng)開始看到新的開發(fā)人員框架，它們確實(shí)改善了開發(fā)人員的體驗(yàn)。
例如，Hardhat是一個(gè)開發(fā)者框架，它使以太坊開發(fā)者更容易構(gòu)建、部署和測(cè)試他們的智能合約。Hardhat提供了“Hardhat Network”，開發(fā)人員可以使用它將智能合約部署到本地網(wǎng)絡(luò)上，而不需要處理實(shí)時(shí)環(huán)境。更好的是，它提供了一個(gè)很棒的插件生態(tài)系統(tǒng)，讓開發(fā)者的生活更加輕松。為了調(diào)試目的，Hardhat還提供了類似于javascript的console.log()功能。
翻譯自：
https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application
