想象一个世界，在线互动由去中心化网络驱动，确保透明度、安全性和用户控制权——这正是由区块链技术支撑的 web3 所承诺的愿景。在本文中，我们将探讨理解以太坊区块链开发所需的基础概念和工具。
为了解释 web2 中客户端-服务器架构的工作原理，人们常用"厨房类比"。在这个类比中，服务器就像一个厨房，客户端（用户）发送请求，类似于点餐。服务器处理请求并返回数据，就像端上一道烹饪好的菜肴。API 则充当服务员，将你的订单传达给厨房并将餐食带回，在客户端和服务器之间充当沟通桥梁，即便双方"语言不通"也能顺畅交流。
我们可以将这个厨房类比延伸到 web3，但有一些关键区别：存在多个完全相同的厨房（节点），其中一个被随机选中，而且你必须在收到餐食之前预先支付烹饪费用。
让我们借助这些类比来理解用户与 dapp 交互时幕后发生的事情。类比并不完美，但它们有助于建立一个思维模型，帮助你开启以太坊开发之旅。
去中心化节点与智能合约——多个厨房
在去中心化的世界中，没有传统意义上的"服务器"。取而代之的是遍布全球的去中心化节点，它们协同工作，共同实现令人瞩目的成果。这些节点共同维护一个共享的、不可篡改的账本，即区块链，确保每笔交易都安全透明。任何节点都可以处理你的交易或执行你的智能合约代码。
区块链中的节点是什么？
区块链节点是指任何运行区块链协议软件并连接到其网络的计算机。这些节点是去中心化网络的支柱，作为维护区块链基础设施的关键参与者。它们充当存储节点，因此每当用户访问区块链上的数据时，实际上是在与某个节点进行交互。节点对网络中的任何人都是透明且可访问的。
由于区块链在没有中央权威机构的情况下运行，控制权分散在节点网络中，这些节点共同承担验证交易和执行治理协议等任务。区块链上的所有代币和智能合约都存在于节点中，使其成为区块链功能不可或缺的组成部分。没有节点，区块链的基础架构将无从存在。
什么是智能合约？
智能合约是运行在区块链上的自执行程序，协议条款直接编码其中。当特定条件满足时，合约会自动执行并强制履行约定条款，无需中间方介入。
然而，在这个去中心化网络中，一个重大挑战是：在缺乏中央权威机构的情况下，如何确保节点诚实行事并正确处理用户请求。这正是"共识"概念发挥作用的地方。
共识机制确保所有交易都经过节点的验证和确认，防止欺诈和双重支付，同时维护区块链的完整性。延伸我们的厨房类比：被选中的厨房准备好你的订单后，会将完成的菜肴和食谱分享给其他厨房。其他厨房按照相同的食谱操作，比对结果，并共同确认订单是否正确完成，从而确保整个网络的一致性和准确性。
智能合约生命周期管理工具
与 web2 不同，web2 需要管理部署服务器的基础设施，而 web3 将大部分后端逻辑转移到区块链上的智能合约中。以下是一些简化智能合约开发整个生命周期的开发环境：
Hardhat： 一个综合性开发环境，包含用于编辑、编译、调试和部署智能合约及应用程序的组件。如果你精通 JavaScript 并需要与 Web 技术进行广泛集成，这是理想之选。
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 请求类似，如下所示：
仔细查看请求体中数据对象的内容：
{"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，即专为与区块链交互而设计的去中心化 Web 或移动应用程序。
那么，dapp 与普通 Web 应用有何不同？从视觉上看，通常没有显著差异。开发者可以在 web3 中使用 web2 中熟悉的 Web 框架，如 React、Next.js 甚至原生 JavaScript，并以大致相同的方式部署 dapp。不过，web3 中常用的去中心化存储解决方案包括 IPFS（星际文件系统）或 SWARM。
大多数 web3 应用的一个显著特征是"连接钱包"功能。当你在 dapp 中点击"连接钱包"时，你是在授权该应用与你的钱包交互，允许其读取你的公开地址并代表你发起交易。交易需要经过身份验证，以确认用户有权执行该操作。这通过签名来实现——签名过程使用你的私钥，这是证明你拥有以太坊账户所有权的唯一标识符，安全存储在你的钱包中。
让我们深入了解钱包：钱包有多种形式，包括浏览器扩展、移动应用程序，甚至实体设备，MetaMask 是其中最受欢迎的之一。就像现实中的餐厅接受多种支付方式一样，你可能需要在 dapp 中支持多种钱包。
为了轻松实现连接钱包功能并支持各种钱包类型，可以考虑使用以下工具：
这些工具可以简化集成过程，确保你的 dapp 与用户钱包之间实现无缝连接。
准备好深入探索 web3 开发了吗？
Web3 开发通过在区块链上使用智能合约改变了应用程序的运作方式，使其永久存在，并将后端任务从中心化服务器中剥离出来。这一转变要求开发者熟悉交易签名、Gas 费处理和 JSON-RPC API 的使用等内容，使其有别于传统的 web2 开发。虽然这可能具有一定挑战性，但同时也开启了令人兴奋的全新可能性。
如需了解更多 web3 开发知识并及时获取最新工具和最佳实践，请访问 MetaMask 博客，获取面向开发者的深度见解和指南。
AI 翻译。可能包含错误。请务必核实信息。
