NodeJS全栈WEB3面试题——P8项目实战类问题（偏全栈）

📦 8.1 请描述你做过的 Web3 项目，具体技术栈和你负责的模块？

我主导开发过一个基于 NFT 的数字纪念平台，用户可以上传照片并生成独特的纪念 NFT，结合 IPFS 和 ERC-721 实现永存上链。

🔧 技术栈：

• 前端：Next.js 13 App Router + TypeScript + wagmi + RainbowKit + Tailwind CSS

• 合约：Solidity 编写的 ERC-721 可铸造合约，支持链上 Metadata URI

• 后端：NestJS + PostgreSQL + Redis（用于缓存 NFT 状态）+ IPFS（Pinata）

• 交互：Ethers.js + Hardhat（部署与测试）+ Alchemy API

• 存储：IPFS（图片 + JSON）+ 数据库存储用户链下行为

🙋‍♂️ 我的职责：

• 负责智能合约开发和部署

• 实现前端钱包连接、签名验证和合约交互

• 搭建后端 API，处理铸造流程与数据库同步

• 集成 Web3 登录、权限控制、前端状态显示优化

---

🧑‍⚖️ 8.2 你如何处理 Web3 项目中的账户管理和权限控制？

在 Web3 项目中，我主张**“链上地址即身份”**的原则，辅以服务端签名认证进行权限控制：

🔐 签名验证（Web3 登录）流程：

1. 用户发起登录 → 后端生成随机 nonce；

2. 前端用钱包签名 nonce，返回签名；

3. 后端用 ethers.utils.verifyMessage() 验证签名是否匹配；

4. 签名成功后，生成 JWT 或 session 令牌，结合角色控制权限。

🔏 权限控制策略：

• 合约中：

  • 使用 Ownable / AccessControl 控制合约管理权限；

  • 多签（Gnosis Safe）或 DAO 治理控制关键操作；

• 后端中：

  • 将链上地址与用户角色映射到数据库；

  • 基于 Role 权限进行 API 限制；

  • 支持黑名单 / 白名单逻辑（如禁止 bot 铸造）。

---

🏛️ 8.3 如果你要开发一个 DAO 系统，会怎么设计？

我设计过一个面向社群治理的 DAO 系统原型，结构如下：

🏗️ 架构模块：

1. 合约层（Solidity）

   • ERC-20 代币合约（治理权重）

   • 提案合约（Proposal）

   • 投票合约（Snapshot 或 OpenZeppelin Governor）

   • 时间锁合约（执行延迟）

2. 前端 DApp

   • 发起提案、浏览提案列表、查看投票结果

   • 使用 wagmi + viem + Ethers.js 操作合约

3. 后端服务

   • NestJS 提供提案快照、用户映射、投票历史接口

   • PostgreSQL 记录提案与链上同步状态

   • 定期轮询区块，获取事件，更新状态

4. 用户参与

   • 基于持仓进行权重投票（Quadratic Voting 支持）

   • 结合 Snapshot 实现免 Gas 签名投票

🚨 安全注意：

• 防范提案注入恶意代码

• 使用多签确认执行

• 支持 Proposal 白名单提交者

---

🧭 8.4 如何解决 Web3 DApp 用户体验不佳的问题？

Web3 用户体验目前最大的问题集中在连接钱包、交易确认与链上延迟。我的改进策略包括：

✅ 交互优化：

• 使用 wagmi + RainbowKit，提高钱包连接稳定性

• 默认连接 MetaMask，但支持 WalletConnect、Coinbase 等扩展钱包

• 加入“连接状态”UI反馈（如连接中、未连接、错误等）

✅ 交易体验优化：

• 对交易发起 → 确认 → 成功全过程添加提示（Toast）

• 使用 waitForTransaction() 等待确认后再跳转或提示

• 显示当前 gas 价格和预估消耗

✅ 网络兼容性处理：

• 检查链 ID，不匹配时自动请求切换网络

• 提供“复制签名内容”功能，解决某些钱包不兼容问题

✅ 兜底方案：

• 提供“离线签名 + 后端广播”的选项

• 引导用户领取测试币或 gas 空投

---

🔁 8.5 如何做合约与数据库之间的数据同步？

链上数据同步是全栈开发的重点，我通常采用事件监听 + 区块轮询机制结合的方式：

📡 方法一：监听合约事件（推荐）

contract.on("Transfer", (from, to, tokenId, event) => {// 保存事件到数据库db.nft.create({ from, to, tokenId, txHash: event.transactionHash });
});

🧩 方法二：后端定时轮询区块

• 使用 getBlockNumber() → getLogs() 查询特定事件日志

• 解决断连 / missed event 的问题

🔐 数据校验：

• 每次监听事件后，进行一次链上状态校验，防止数据库与链上状态不一致；

• 数据库设计成幂等操作，如转移记录不能重复写入。

🧠 工具辅助：

• 使用 Alchemy / Infura 的 webhook + API 提供更稳定的监听服务；

• 若量大可引入 Kafka / Redis Stream 做事件流分发和延迟消费。