📦 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 登錄）流程：
-
用戶發起登錄 → 后端生成隨機 nonce；
-
前端用錢包簽名 nonce，返回簽名；
-
后端用
ethers.utils.verifyMessage()驗證簽名是否匹配； -
簽名成功后，生成 JWT 或 session 令牌，結合角色控制權限。
🔏 權限控制策略：
-
合約中：
-
使用
Ownable/AccessControl控制合約管理權限； -
多簽（Gnosis Safe）或 DAO 治理控制關鍵操作；
-
-
后端中：
-
將鏈上地址與用戶角色映射到數據庫；
-
基于 Role 權限進行 API 限制；
-
支持黑名單 / 白名單邏輯（如禁止 bot 鑄造）。
-
🏛? 8.3 如果你要開發一個 DAO 系統，會怎么設計？
我設計過一個面向社群治理的 DAO 系統原型，結構如下：
🏗? 架構模塊：
-
合約層（Solidity）
-
ERC-20 代幣合約（治理權重）
-
提案合約（Proposal）
-
投票合約（Snapshot 或 OpenZeppelin Governor）
-
時間鎖合約（執行延遲）
-
-
前端 DApp
-
發起提案、瀏覽提案列表、查看投票結果
-
使用 wagmi + viem + Ethers.js 操作合約
-
-
后端服務
-
NestJS 提供提案快照、用戶映射、投票歷史接口
-
PostgreSQL 記錄提案與鏈上同步狀態
-
定期輪詢區塊，獲取事件，更新狀態
-
-
用戶參與
-
基于持倉進行權重投票（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 做事件流分發和延遲消費。
學習筆記)
