九思札记 · 探索区块链 · AI

在前几节中，我们完成了投票合约的编写、Hardhat工程化配置和React前端搭建。本章最后三节将带你把DApp推向可用的完整形态：实现链上事件驱动的实时UI更新、部署到真正的测试网并在区块浏览器上验证，最后对整个项目进行一次全面的复盘。这三步是区别「课程作业」与「可交付DApp」的关键分水岭。

17.7 监听合约事件与实时更新UI

17.7.1 为什么需要链上事件？

智能合约运行在EVM中，由于区块链的封闭性，合约无法主动「推送」消息给前端。Solana的做法是让前端轮询账户状态，而以太坊提供了更优雅的机制——事件（Event）。

事件通过LOG0-LOG4操作码写入交易收据（Receipt）的日志字段。事件的特点是：

不可合约内读取：同一EVM内的其他合约无法消费你发出的事件
链下永久可查：任何人通过节点RPC可以检索历史事件
Gas成本低：写入日志比写入存储（SSTORE）便宜得多

在投票合约中，我们定义了Voted事件：

solidity

event Voted(address indexed voter, uint indexed candidateId, uint timestamp);

这里的indexed关键字至关重要：索引参数（最多3个）会被放入topic[1]-topic[3]中，支持前端按主题过滤。非索引参数（如timestamp）则放在data字段。

17.7.2 ethers.js 事件监听实战

前端使用ethers.js监听Voted事件的核心代码：

jsx

// hooks/useEventListener.js
import { useEffect, useRef } from 'react';
import { ethers } from 'ethers';

export function useEventListener(contract, eventName, callback) {
  const callbackRef = useRef(callback);
  callbackRef.current = callback; // 保证闭包中的callback始终最新

  useEffect(() => {
    if (!contract) return;

    const handler = (...args) => {
      const event = args[args.length - 1]; // 最后一个参数是Event对象
      callbackRef.current(args.slice(0, -1), event);
    };

    contract.on(eventName, handler);

    return () => {
      contract.off(eventName, handler); // 组件卸载时必须清理！
    };
  }, [contract, eventName]);
}

⚠️ 常见陷阱：忘记在useEffect返回值中清理监听会导致内存泄漏。如果组件频繁挂载/卸载而不清理，最终会堆积大量重复监听，造成性能下降甚至事件重复响应。

在投票组件中使用：

jsx

useEventListener(contract, 'Voted', (args, event) => {
  const [voter, candidateId, timestamp] = args;
  setVotes(prev => ({
    ...prev,
    [candidateId.toString()]: (prev[candidateId.toString()] || 0) + 1,
  }));
});

17.7.3 三种状态同步策略对比

策略	延迟	Gas开销	实现复杂度	推荐场景
轮询	高（~12s/次）	无（只读RPC不消耗Gas）	低	对实时性要求低的展示页
事件驱动	低（出块后即时）	无	中	实时DApp交互页
The Graph子图	中（索引延迟数秒）	无	高	复杂历史数据查询

事件驱动是投票DApp的首选方案：用户投票后，事件在同一个区块被发出，前端几乎实时收到通知。但页面刷新后，初始数据仍需通过合约只读调用获取：

jsx

// 页面加载时拉取最新状态
useEffect(() => {
  if (!contract) return;
  const loadCandidates = async () => {
    const count = await contract.getCandidateCount();
    // ... 遍历并拉取每个候选人数据
  };
  loadCandidates();
  // 后续更新由事件驱动
}, [contract]);

17.7.4 结果可视化组件

使用 recharts 库展示投票结果：

jsx

import { BarChart, Bar, XAxis, YAxis, Tooltip } from 'recharts';

function ResultsChart({ candidates }) {
  const data = candidates.map(c => ({
    name: c.name,
    得票数: c.voteCount,
  }));

  return (
    <BarChart width={600} height={300} data={data}>
      <XAxis dataKey="name" />
      <YAxis />
      <Tooltip />
      <Bar dataKey="得票数" fill="#8884d8" />
    </BarChart>
  );
}

当Voted事件触发时，React状态更新会立即反映到柱状图上，实现实时票数增长动画。

17.7.5 Mermaid图表：事件驱动流程

sequenceDiagram
    participant User as 投票者
    participant Frontend as React前端
    participant Contract as 投票合约(EVM)
    participant Event as 链上事件日志

    User->>Frontend: 点击投票按钮
    Frontend->>Frontend: 乐观更新UI(先+1)
    Frontend->>Contract: sendTransaction(vote(1))
    Contract-->>Event: 触发Voted(voter, 1, timestamp)
    Note over Contract,Event: LOG1操作码写入收据
    Event->>Frontend: contract.on('Voted', ...)
    Frontend->>Frontend: 核对与乐观更新一致✓
    Frontend->>User: 实时刷新柱状图
    Note over Frontend: 若交易失败，回滚乐观更新

17.7.6 本节要点

事件是连接链上状态与前端UI的核心桥梁，比轮询更高效
indexed参数支持前端按主题过滤，最多3个索引参数
前端必须管理事件监听的生命周期，防止内存泄漏
乐观更新提升交互体验，但需做好交易回滚时的状态恢复

17.8 部署至测试网与合约验证

17.8.1 测试网选型与环境准备

2025年，以太坊的主要测试网是Sepolia。它取代了已弃用的Goerli和Ropsten，是合约开发的标准测试环境。

准备工作：

获取RPC端点：注册Infura或Alchemy，创建一个Sepolia项目，获取HTTPS端点URL
获取测试ETH：访问 Sepolia Faucet（如Alchemy Faucet），输入你的测试网地址领取测试ETH
管理私钥：创建.env文件，配置环境变量

text

# .env — 禁止提交到Git！
PRIVATE_KEY=0x你的测试网私钥（不含0x前缀）
INFURA_API_KEY=你的Infura项目ID
ETHERSCAN_API_KEY=你的Etherscan API Key

17.8.2 Hardhat网络配置

在hardhat.config.ts中添加Sepolia网络配置：

typescript

import { HardhatUserConfig } from 'hardhat/config';
import '@nomicfoundation/hardhat-toolbox';
import * as dotenv from 'dotenv';

dotenv.config();

const config: HardhatUserConfig = {
  solidity: '0.8.20',
  networks: {
    sepolia: {
      url: `https://sepolia.infura.io/v3/${process.env.INFURA_API_KEY}`,
      accounts: [process.env.PRIVATE_KEY!],
      // EIP-1559: 交易类型2的参数
      maxFeePerGas: 100_000_000_000n,   // 100 gwei
      maxPriorityFeePerGas: 5_000_000_000n, // 5 gwei
    },
  },
  etherscan: {
    apiKey: process.env.ETHERSCAN_API_KEY,
  },
};

export default config;

17.8.3 部署脚本

javascript

// scripts/deploy.js
const hre = require('hardhat');

async function main() {
  const [deployer] = await hre.ethers.getSigners();
  console.log('部署账户:', deployer.address);

  const candidates = ['Alice', 'Bob', 'Charlie'];
  const Election = await hre.ethers.getContractFactory('Election');
  const election = await Election.deploy(candidates);

  await election.waitForDeployment();

  const addr = await election.getAddress();
  console.log('选举合约已部署至:', addr);
  console.log('候选人:', candidates.join(', '));

  // 输出验证命令
  console.log('\n运行验证命令:');
  console.log(`npx hardhat verify --network sepolia  ${addr} "$ {candidates.join('","')}"`);
}

main().catch(console.error);

执行部署：

bash

npx hardhat run scripts/deploy.js --network sepolia

⚠️ 常见错误：如果提示insufficient funds，说明账户中测试ETH不足，需要去Faucet补充。

17.8.4 合约验证

部署完成后，在Etherscan上验证合约源码：

bash

npx hardhat verify --network sepolia <合约地址> "Alice" "Bob" "Charlie"

验证成功后，用户可以在Etherscan上看到：

完整的合约源码（Solidity原文件或扁平化后的版本）
自动生成的Read Contract和Write Contract交互界面
ABI和字节码的公开记录

这对增强DApp透明度和用户信任至关重要。

17.8.5 前端部署到Vercel

前端集成验证后的合约地址，然后部署到Vercel：

将前端代码推送到GitHub仓库
在Vercel控制台导入该仓库
设置构建命令：npm run build
添加环境变量（无需私钥）：

VITE_CONTRACT_ADDRESS：验证后的合约地址
VITE_RPC_URL：Alchemy/Infura的Sepolia RPC端点

部署完成，获得可公开访问的URL

flowchart LR
    A[编写合约] -->|本地测试| B[Hardhat测试通过]
    B --> C[配置Sepolia网络]
    C --> D[获取测试ETH]
    D --> E[部署到Sepolia]
    E --> F[Etherscan验证]
    F --> G[更新前端合约地址]
    G --> H[Vercel部署前端]
    H --> I[全栈DApp上线]

17.8.6 本节要点

Sepolia是当前以太坊主流测试网，替代已弃用的Goerli
.env文件管理私钥和API Key，必须加入.gitignore
合约验证提高透明度和用户信任，是高质量DApp的必要步骤
前端部署只需合约地址和RPC端点，无需私钥

17.9 完整项目复盘

17.9.1 项目目录结构

一个完整的投票DApp项目结构如下：

text

voting-dapp/
├── contracts/                    # Solidity源代码
│   ├── Election.sol              # 核心投票合约
│   └── VoterRegistry.sol         # 选民注册合约
├── test/
│   └── election.test.js          # 合约单元测试
├── scripts/
│   ├── deploy.js                 # 部署脚本
│   └── verify.js                 # 验证脚本
├── frontend/
│   ├── src/
│   │   ├── App.jsx               # 主应用入口
│   │   ├── components/
│   │   │   ├── WalletConnect.jsx  # 钱包连接
│   │   │   ├── ElectionInfo.jsx   # 选举信息展示
│   │   │   ├── CandidateList.jsx  # 候选人列表
│   │   │   ├── VoteButton.jsx     # 投票按钮
│   │   │   └── ResultsChart.jsx   # 结果图表
│   │   ├── hooks/
│   │   │   ├── useContract.js     # 合约交互Hook
│   │   │   └── useEventListener.js# 事件监听Hook
│   │   └── utils/
│   │       └── constants.js       # 合约地址/ABI常量
│   ├── package.json
│   └── vite.config.js
├── hardhat.config.ts
├── .env
└── README.md

17.9.2 关键架构决策回顾

为什么使用工厂模式设计Election合约？

工厂模式允许一次部署创建一个「选举工厂」，后续可以通过工厂合约的方法创建多轮独立的选举。这比在合约中硬编码候选人列表更灵活，也便于扩展。

为什么要分离VoterRegistry合约？

将选民注册逻辑从Election合约中分离出来，使得投票权限管理可以与投票本身解耦。例如，你可以用同一个VoterRegistry管理多轮选举的选民资格，或者在未来将注册逻辑替换为ERC-20余额快照。

为什么选择事件驱动而非轮询？

投票DApp对实时性有一定要求：用户投票后期待立即看到票数变化。轮询每12秒（一个区块时间）拉取一次数据，延迟感明显。事件驱动在区块被挖出的瞬间就将新数据推送到前端，体验更接近Web2应用。

前端状态管理选型思考

对于投票DApp这种中等复杂度的场景，React Context + useState/useReducer完全足够。引入Redux会增加不必要的样板代码。如果未来需要管理更复杂的状态（如多轮选举、用户Session、链上通知），可以考虑Zustand或Jotai这类轻量状态管理库。

页面刷新后的状态恢复

所有状态最终由链上数据驱动。当用户刷新页面时：

前端重新连接钱包（MetaMask自动恢复session）
合约只读方法拉取最新数据（候选人列表、票数）
事件监听重新启动，接收后续更新

这一模式称为「Source of Truth on-chain」——前端只是链上状态的缓存。

17.9.3 开发中的常见陷阱

陷阱	现象	解决方案
MetaMask网络切换	调用交易时网络不匹配	监听`chainChanged`事件，刷新页面或提示切换
ABI版本冲突	前端用旧ABI调用新版合约	部署后从`artifacts/`复制最新ABI
事件监听内存泄漏	多次调用合约方法，UI性能下降	useEffect返回值中调用`contract.off()`
Gas估算失败	交易长时间pending	手动设置`gasLimit`参数
异步错误吞没	交易失败但无提示	使用`.catch()`或在try/catch中捕获并展示
本地与测试网地址混淆	前端连接本地合约地址而非测试网	使用`.env`管理网络相关配置

17.9.4 作业与延伸方向

如果你已完成本节内容，以下是值得继续探索的方向：

添加时间锁

在Election合约中添加votingDeadline变量
投票函数增加时间检查：require(block.timestamp < votingDeadline)
前端显示投票倒计时

加权投票（基于ERC-20余额）

引入ERC-20代币地址作为投票权重依据
投票时读取调用者的代币余额作为票数权重
需注意防止闪电贷操纵快照余额

链上委托投票

实现delegate(address to)函数
将投票权委托给他人，类似Compound的治理模型

DAO风格治理

引入多签国库（Gnosis Safe）
实现提案创建 → 投票 → 执行的三阶段流程

17.9.5 完整项目架构图

flowchart TB
    subgraph 合约层
        EC[Election 合约] --- VR[VoterRegistry 合约]
    end
    subgraph 区块链基础设施
        RPC[RPC节点/Infura] --- ES[Etherscan]
    end
    subgraph 前端层
        WC[WalletConnect 组件]
        EI[ElectionInfo 组件]
        CL[CandidateList 组件]
        VB[VoteButton 组件]
        RC[ResultsChart 组件]
        HL[useEventListener Hook]
    end
    subgraph 用户
        V[投票者]
        AD[管理员]
    end

    V <-->|MetaMask| WC
    AD -->|部署/注册| EC
    EC <-->|合约事件| HL
    HL --> EI
    HL --> RC
    VB -->|sendTransaction| EC
    RC -->|只读调用| EC
    EC -->|已验证| ES
    V --> VB
    AD --> VR

17.9.6 本章关键认知总结

全栈DApp = 合约 + 工具链 + 前端 + 部署：四条腿缺一不可，每条腿都是一套独立的工程知识体系

事件驱动是DApp实时交互的基础：理解EVM日志机制、ethers.js事件API、前端生命周期管理，是区分Web2前端开发者和Web3全栈开发者的标志性能力

测试网部署是将DApp推向真实的必经之路：本地开发环境与测试网环境的差异（RPC限速、出块时间、Gas价格）必须在早期暴露

项目复盘比项目本身更重要：回顾架构决策、总结开发陷阱、规划延伸方向，决定了你是做完一个项目还是真正理解了一个项目

下一章我们将进入代币与NFT实战，掌握ERC-20和ERC-721标准，并学习IPFS元数据管理与多链部署。

本页目录