想像一個世界，線上互動由去中心化網路驅動，確保透明度、安全性與使用者掌控權——這正是由區塊鏈技術支撐的 web3 所承諾的願景。在本文中，我們將探討在以太坊區塊鏈上進行開發所需了解的基礎概念與工具。
為了說明 web2 中客戶端—伺服器架構的運作方式，人們常使用「廚房比喻」。在這個比喻中，伺服器就像一間廚房，客戶端（使用者）發送請求，就像點餐一樣。伺服器處理這個請求並回傳資料，就像端上一道烹調好的餐點。API 則扮演服務生的角色，將你的點單送進廚房，再把餐點帶回來，負責協調客戶端與伺服器之間的溝通，即使雙方「語言不通」也沒問題。
我們可以延伸這個廚房比喻來說明 web3，但有幾個關鍵差異：存在多間一模一樣的廚房（節點），其中一間會被隨機選中，而且你必須在收到餐點之前預先支付烹飪費用。
讓我們透過這些比喻，來了解使用者與 dapp 互動時幕後發生了什麼事。雖然比喻並不完美，但它們有助於建立心智模型，讓你開啟在以太坊上的開發之旅。
去中心化節點與智能合約——多間廚房
在去中心化的世界裡，沒有傳統意義上的「伺服器」。取而代之的是分散於全球各地的去中心化節點，共同協作以實現令人驚嘆的成果。這些節點共同維護一個共享且不可篡改的帳本，稱為區塊鏈，確保每一筆交易都安全且透明。任何節點都可以處理你的交易或執行你的智能合約程式碼。
什麼是區塊鏈中的節點？
區塊鏈節點是任何執行區塊鏈協議軟體並連接至其網路的電腦。這些節點是去中心化網路的骨幹，作為關鍵的利益相關者，負責維護區塊鏈的基礎設施。它們充當儲存節點，因此每當使用者存取區塊鏈上的資料時，都是在與某個節點互動。節點對網路中的任何人都是透明且可存取的。
由於區塊鏈在沒有中央機構的情況下運作，控制權分散於節點網路之中，這些節點共同處理驗證交易、執行治理協議等任務。區塊鏈上所有的代幣與智能合約都存在於節點之中，使其成為區塊鏈功能不可或缺的一部分。沒有節點，區塊鏈的基礎架構便無從存在。
什麼是智能合約？
智能合約是一種在區塊鏈上運行的自動執行程式，協議條款直接編碼於其中。當特定條件被滿足時，合約會自動執行並落實雙方同意的條款，無需任何中間人介入。
然而，在這個去中心化網路中，一個重大挑戰在於：在缺乏中央機構的情況下，如何確保節點誠實行事並正確處理使用者請求。這正是「共識」概念登場的時刻。
共識機制確保所有交易都經過節點的驗證與確認，防止詐欺與雙重支付，同時維護區塊鏈的完整性。延伸我們的廚房比喻：被選中的廚房完成你的訂單後，會將完成的菜餚與食譜分享給其他廚房。這些廚房接著按照相同的食譜操作，比對結果，並共同確認訂單是否正確完成，確保整個網路的一致性與準確性。
智能合約生命週期管理工具
與 web2 不同，web2 需要管理部署伺服器的基礎設施，而 web3 將大部分後端邏輯轉移至區塊鏈上的智能合約。以下是一些能簡化智能合約開發完整生命週期的開發環境：
Hardhat： 一個全面的開發環境，包含編輯、編譯、除錯及部署智能合約與應用程式的各項元件。如果你熟悉 JavaScript 並需要與網頁技術進行廣泛整合，這是理想的選擇。
Foundry： 一個快速、高效的選項，將一切保持在 Solidity 生態系統內，透過其速度與對 Solidity 的原生支援來提升生產力。
如需 Hardhat 與 Foundry 的詳細比較，請參閱我們的指南：選擇正確的以太坊開發工具。
Remix： 一個預載基本操作外掛的線上 IDE，非常適合快速測試程式碼，無需在本機安裝任何東西。
開發者可以使用各種高階程式語言來撰寫智能合約，這些合約隨後會被編譯成低階位元組碼。兩種最受歡迎的語言是：
其他語言包括 Yul、Cairo 和 Rust，可根據你的開發需求提供額外選擇。
JSON-RPC API——服務生
你的點單如何從餐桌傳到廚房，完成的餐點又如何回到你的桌上？當然是透過服務生！
在 web2 中，REST API 扮演「服務生」的角色，負責協調你的應用程式與存放業務邏輯的後端伺服器之間的溝通。要與這個後端互動，你需要一個 URL 以及針對各種操作的特定端點。
在 web3 中，與區塊鏈節點的互動是透過 JSON-RPC API 進行的。這個 API 讓多個 dapp 能夠透過在 JSON-RPC 呼叫主體中指定包含業務邏輯的合約，與同一個 URL 互動。雖然你可能對 JSON-RPC API 較不熟悉，但它們的運作方式與一般的 HTTP 請求類似，如下所示：
仔細看看請求主體中 data 物件的內容：
{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}它包含 JSON-RPC 版本、所需操作的方法（例如，取得最新區塊號碼）、可選參數，以及用於追蹤請求的 ID。這種格式標準化了與以太坊節點的溝通，無論是用於資料擷取還是執行區塊鏈操作。
請求中的 URL 指向 Infura，這是一個節點提供商，讓我們免於自行建立和維護以太坊節點的複雜性與資源需求。這個 URL 作為通往區塊鏈的閘道。
還記得之前提到的預先支付烹飪費用嗎？在 web3 中，執行交易會產生一種稱為「Gas 費用」的成本，其金額取決於交易的複雜程度以及當時的網路擁塞狀況。不過，從區塊鏈讀取資料是免費的。
為了確保你的交易能被正確理解並執行，需要一種標準化的方式來描述它。這就是 ABI（應用程式二進位介面）的用途——它就像一份菜單，定義了如何與智能合約的函式互動、指定所需的參數，以及函式應如何執行。
那麼，你的 dapp 如何與已部署的智能合約溝通？如我們所討論的，這需要使用 JSON-RPC API，但為了簡化這個過程，有幾個函式庫可以提供協助。在 JavaScript 中，選項包括 Ethers.js 或 Viem；對於基於 React 的前端，wagmi——一個用於以太坊的 React Hooks 函式庫——特別實用。這些函式庫封裝了你的 JSON-RPC 呼叫，讓與區塊鏈及已部署合約的互動更易於管理。
Viem，以及延伸而來的 Wagmi（底層使用 viem），提供強型別 API，透過自動補全、型別推斷和靜態驗證來提升開發者體驗。透過提供 ABI，viem 能提供自動補全功能，並在型別錯誤影響使用者之前就加以捕捉。
不確定要選擇 ethers.js 還是 viem？查看這份 Web3 開發者詳細比較指南。
Web3 dapp 前端開發——用餐體驗
與智能合約互動有多種方式，但讓我們來探索最受歡迎的方法：透過 dapp，也就是一種專為與區塊鏈互動而設計的去中心化網頁或行動應用程式。
那麼，dapp 與一般網頁應用程式有何不同？在視覺上，通常沒有顯著差異。開發者可以在 web3 中使用來自 web2 的熟悉網頁框架，例如 React、Next.js 或甚至原生 JavaScript，並以大致相同的方式部署 dapp。不過，web3 中也常使用去中心化儲存解決方案，例如 IPFS（星際檔案系統）或 SWARM。
大多數 web3 應用程式的一個顯著特色是「連接錢包」功能。當你在 dapp 中點擊「連接錢包」時，你正在授權該應用程式與你的錢包互動，允許它讀取你的公開地址並代表你請求交易。交易需要經過身份驗證，以確認使用者有資格執行該操作。這是透過簽名來實現的，這個過程使用你的私鑰——一個證明你擁有以太坊帳戶的唯一識別符，安全地儲存在你的錢包中。
讓我們深入了解錢包：錢包有多種形式，包括瀏覽器擴充功能、行動應用程式，甚至實體裝置，其中 MetaMask 是最受歡迎的之一。就像現實世界中的餐廳接受多種付款方式一樣，你可能需要在你的 dapp 中支援多種錢包。
為了輕鬆實現連接錢包功能並支援各種錢包類型，可以考慮使用以下工具：
這些工具可以簡化整合流程，確保你的 dapp 與使用者錢包之間的無縫連接。
準備好深入探索 web3 開發了嗎？
Web3 開發透過在區塊鏈上使用智能合約，改變了應用程式的運作方式，使其具有永久性，並將後端任務從中心化伺服器中移出。這種轉變要求開發者熟悉交易簽名、處理 Gas 費用以及使用 JSON-RPC API 等事項，使其有別於傳統的 web2 開發。雖然這可能具有一定挑戰性，但也開啟了全新且令人興奮的可能性。
如需進一步了解 web3 開發並掌握最新工具與最佳實踐，請造訪 MetaMask 部落格，獲取專為開發者打造的深度見解與指南。
AI 翻譯。可能包含錯誤。請務必核實資訊。
