Web3 世界观与前端定位

📚 作者：Henry 🧱 系列：《DApp 前端开发入门与架构实践》 · 第 1 篇 👨‍💻 受众：Web3 前端工程师 / Web3入门者 👉 系列持续更新中，建议收藏专栏或关注作者

什么是 DApp？从 Web2 到 Web3 的范式转变

Web 应用的演进路线

随着互联网的发展，Web 应用经历了从 Web1.0 的信息展示，到 Web2.0 的用户参与，再到 Web3.0 的所有权反转。

DApp，即“Decentralized Application”，是 Web3 时代最具代表性的应用形态，它不再依赖中心化服务器，而是运行在区块链等去中心化网络之上。

DApp 架构三层组成

DApp 的核心由三层组成：

1. 前端（Frontend）

• 通常使用 React、Next.js 等现代前端框架
• 提供用户 UI、钱包连接、签名交互、状态展示等功能

2. 智能合约（Smart Contract）

• 业务逻辑在链上运行，编写语言如 Solidity、Move 等
• 部署在链上后不可更改（或仅可通过代理升级）

3. 区块链网络（Blockchain Network）

• 提供共识、验证、状态记录的基础设施
• 如 Ethereum、Polygon、Optimism 等

Dapp架构图：

Web2 与 Web3 的核心对比

🔍 举例说明：

• Web2 游戏道具 → 只能在游戏中使用，随时可能被删
• Web3 游戏 NFT → 资产上链，可跨游戏/平台自由交易

常见误区

Web3 前端工程师的核心定位

随着 Web3 崛起，越来越多前端工程师希望转型，但常见困惑包括：

• 区块链“太底层”，前端用不上？
• 钱包连接、签名认证不懂怎么用？
• viem / wagmi / ethers.js 一堆库搞不清？

但实际上，Web3 中的前端角色，远比传统 Web2 更关键 —— TA 既是用户入口，也是链上交互的桥梁。

核心角色定位

链接用户与区块链的桥梁

• 提供钱包连接界面（如 MetaMask、WalletConnect）
• 发起交易、构造调用、提示签名
• 监听链上状态变化，驱动 UI 更新

具备合约理解能力

• 理解合约的 ABI、函数结构、状态变量
• 知道什么时候应该调用 read（只读）/ write（交易）
• 熟悉 Gas、交易失败、权限判断等链上风险

参与身份与权限系统设计

• 掌握签名登录（EIP-191 / EIP-712）
• 理解如何构建 Web3 登录态与会话管理
• 明确用户与合约之间的权限界定

技能图谱：从 Web2 到 Web3 的迁移图谱

思维误区

区块链运行原理简析（Ethereum 为主）

作为 Web3 前端开发者，并不需要像节点工程师一样掌握区块链协议细节，但必须了解以下几个关键问题：

• 用户签名后的交易，链上发生了什么？
• 什么是区块、交易池、确认数？
• 为什么调用合约函数要等几秒钟？
• 失败的交易为何还会扣 Gas？
• 状态从链上同步回来，有什么延迟和风险？

这些问题的答案，直接决定你是否能写出一个有“链上认知能力”的 DApp 前端。

Ethereum 区块链的运行机制

Ethereum 是一种状态机驱动的去中心化网络。它的核心运行流程可以总结如下：

1. 交易生命周期（前端触发角度）

构造交易 → 用户签名 → 交易广播 → 节点打包进 mempool → 出块确认 → 状态更新 → UI 同步

2. 每笔交易的五个关键阶段

3. Ethereum 状态模型

• 所有状态存在于全局状态树（Merkle Patricia Trie）中
• 每个账户（EOA / 合约）都是一个状态节点
• 写入合约状态其实是「提交交易 → 触发 EVM 执行 → 修改状态树」

前端相关重点机制

什么是 Gas？为啥交易失败也会扣钱？

• Gas 是执行智能合约操作的计算费用
• 即使失败，节点仍需执行 EVM 验证代码 → 收取实际 Gas used

// Viem 示例：估算调用代价
const gasEstimate = await publicClient.estimateGas({
  account,
  to: contractAddress,
  data: encodedData,
})

什么是确认数？为啥要等几秒才显示“交易成功”？

• 交易被打包进某个区块后，还需等待后续区块的附加确认
• 多数 DApp 默认 确认 1 个区块即可，部分安全场景需等待 3~12 个确认

// Viem 示例：等待交易确认
const txHash = await walletClient.sendTransaction({...})
await publicClient.waitForTransactionReceipt({ hash: txHash }) // 默认确认 1 个块

链上状态是怎么同步到前端的？

• 可通过 JSON-RPC 轮询、合约事件监听或使用 subgraph 等方式同步链上状态
• 建议前端建立状态缓存并标记“链上数据 vs 本地数据”区别

常见误区澄清

账户与签名机制，是 Web3 的根基

在 Web2 中，“账户”通常代表用户名 + 密码 + Session，但在 Web3 中，“账户”即地址，而身份认证、操作权限全部基于签名验证。必须理解：

• 什么是 EOA（Externally Owned Account）？如何签名？
• 合约钱包（如 Gnosis、Safe）是如何验证签名的？
• 前端如何识别当前账户类型，并决定是否允许发起交易？

Ethereum 中的账户类型

签名机制

🔐 EIP-191：最基础的签名格式

用于纯文本或简单结构的签名验证

const sig = await walletClient.signMessage({
  account,
  message: 'Welcome to DApp!',
})

前端多用于“登录签名”，生成签名后发送到后端验证地址

🔐 EIP-712：结构化数据签名（推荐）

结构化数据更安全、明确，尤其适用于合约调用、MetaTx、Permit 等场景。

const sig = await walletClient.signTypedData({
  account,
  domain: {
    name: 'MyDApp',
    version: '1',
    chainId: 1,
    verifyingContract: contractAddress,
  },
  types: {
    Login: [
      { name: 'user', type: 'address' },
      { name: 'nonce', type: 'string' },
    ],
  },
  message: {
    user: address,
    nonce: '123456',
  },
})

EIP-1271: 合约钱包的签名验证

由于合约钱包没有私钥，它不能使用 signMessage，必须通过合约接口验证签名有效性：

// EIP-1271 接口定义
function isValidSignature(bytes32 _hash, bytes memory _signature)
    external
    view
    returns (bytes4 magicValue);

🧠 前端如何判断账户类型？

const isContract = await publicClient.getBytecode({ address })
const accountType = isContract ? 'ContractWallet' : 'EOA'

前端判断为合约钱包后，应使用合约方式验证签名（如调用 isValidSignature()）

交易生命周期与账户角色

✅ EOA 发起交易流程

构造交易 → 钱包签名 → 发送 RPC → 链上确认 → 状态同步

✅ 合约钱包（如 Safe）发起交易

用户发起 → 合约构建多签消息 → 所有者签名 → Relayer 执行 → 状态更新

🔍 合约钱包可能使用 Relayer / Paymaster / Bundler 发起交易（未来 AA 篇将详细讲）

实战代码片段：登录签名验证（191 + 1271）

// EOA 登录签名
const signature = await walletClient.signMessage({
  account,
  message: 'Login to DApp',
})

// 合约钱包判断 + 1271 验证
if (isContract) {
  const isValid = await publicClient.readContract({
    address,
    abi: eip1271ABI,
    functionName: 'isValidSignature',
    args: [hashMessage('Login to DApp'), signature],
  })
}

链上调用流程拆解（EOA）

✅ 标准调用链

构造参数 → 发起签名 → 构造交易 → 发送到 RPC → 节点验证 → 出块 → 状态更新

✅ 合约函数调用分类

核心代码拆解：以铸造 NFT 为例

1. 读取合约状态（不需签名）

const { data: totalSupply } = useReadContract({
  abi,
  address: contractAddress,
  functionName: 'totalSupply',
})

此类调用走 eth_call，不会真正发起交易，适用于 UI 状态显示。

2. 发起交易调用（需签名）

const { writeContractAsync } = useWriteContract()

const txHash = await writeContractAsync({
  abi,
  address: contractAddress,
  functionName: 'mint',
  args: [1],
})

• 用户在钱包中确认签名
• 若失败，返回的是 reject 或 revert 报错
• 成功后需监听 txHash，等待链上确认

3. 等待链上确认 & 状态同步

const receipt = await publicClient.waitForTransactionReceipt({ hash: txHash })

if (receipt.status === 'success') {
  toast.success('Mint success 🎉')
  // 可更新链上数据
}

🚨 注意：交易上链成功 ≠ 合约执行成功，需看 receipt.status 是不是 "success"

状态管理建议：前端如何“感知链上变化”

调用中的常见误区