钱包与签名安全（Web3）

• 签名钓鱼的原理（恶意站点诱导用户签名）
• 域名校验、消息可读化、危险签名拦截
• 前端如何降低钓鱼风险

钱包签名钓鱼（Phishing）指攻击者伪造网站或通过恶意 DApp，诱导用户对不透明或恶意的内容进行签名，从而窃取资产或授权。前端工程防御策略包括：严格校验 window.ethereum 来源与域名（避免被 iframe 恶意注入）、对签名消息进行可读化解析（如 EIP-712 结构化展示）、在签名前向用户清晰展示将要签名的内容与风险、对 eth_sign 等危险方法实施拦截或白名单、使用域名锁与通道校验（如 EIP-1193 的 app metadata）、引入 2FA 与风控、以及监听钱包反钓鱼名单（如 MetaMask 的 phishing detect）。此外，前端应使用 https 并设置 CSP、防 clickjacking 头，避免页面被嵌入恶意 iframe。

签名钓鱼的根源是"用户在没有理解内容的情况下签名"。前端的关键职责是让签名内容透明、可读、可预期，并阻断危险路径，把"签名即授权"的单向操作变成可感知的安全流程。

• AA 账户与 EOA 的区别
• 用户操作（UserOperation）与 Bundler/EntryPoint
• 前端接入智能账户的工程价值

ERC-4337 通过引入 UserOperation、Bundler 与 EntryPoint 合约，把"签名 + 交易"逻辑从 EOA 外置为可编程的智能账户，实现账户抽象（Account Abstraction）。前端应用时，用户以智能账户地址交互，可享受：无助记词体验（社交恢复、托管签名）、批量交易、代付 gas（paymaster）、会话密钥、权限粒度控制等。前端通常借助 SDK（如 viem + aa 相关库、zerodev、Privy 等）把 UserOperation 组装、签名、提交给 Bundler，并监听交易状态。这极大改善了 Web3 的用户体验与安全性。

智能账户把账户从"私钥单点"升级为"可编程逻辑"，前端可借此实现更友好的交互。工程上需处理 UserOperation 的签名、nonce、gas 估算与 bundler 提交，并处理确认与重试的异步状态。

• Gas 概念与影响手续费的因素
• L2 的扩容原理（Optimistic vs ZK）
• 前端针对 L2 的实践

Gas 是执行链上交易所需的计算费用，主链（L1）拥堵时 gas 高。Layer 2 通过在 L1 之上做批处理与争议/证明机制，显著降低交易成本、提升吞吐。Optimistic Rollup（Optimism、Arbitrum、Base）依赖欺诈证明，ZK Rollup（zkSync）依赖零知识证明。前端实践中，应根据主链与 L2 分别支持 EIP-1193 的 chainId 切换，为不同链提供 gas 估算与费用提示，并在 DApp 中默认引导用户使用低成本的 L2，同时在 UI 上区分 chain 与 network。

对前端而言，L2 的差异主要体现在 chainId、gas 估算接口与网络切换。理解 L2 类型有助于设置正确的默认链与费用预期，并为用户提供更便宜的交互路径。

• eth_sign 对任意数据签名（hex）不安全
• personal_sign 对带前缀的消息签名（可读）
• 两者在安全与兼容性上的取舍

eth_sign 对任意数据（raw hex）进行签名，钱包只显示一串不可读的十六进制，用户无法判断内容，极易被滥用用于授权或任意交易，因此被主流钱包（如 MetaMask）限制或禁用。personal_sign 在消息前追加 "\x19Ethereum Signed Message:\n" 前缀，使签名内容可读、可预期，且与交易签名在语义上区分，安全性更高。前端应优先使用 personal_sign 或 eth_signTypedData，避免 eth_sign。personal_sign 返回的签名与 eth_sign 不同，后端校验时需用对应前缀。

差异核心在于"可读性与用途隔离"。eth_sign 因不可读而危险，personal_sign 通过前缀与可读消息提升安全性。工程上把 eth_sign 视为反面模式，默认用 personal_sign。

• chainId 的读取与校验
• wallet_switchEthereumChain 切换网络
• 错误网络提示与链感知 UI

多链 DApp 必须读取并校验当前 chainId，确保与业务链一致。通过 EIP-1193 的 wallet_switchEthereumChain 可请求钱包切换网络，若不支持还可调用 wallet_addEthereumChain 添加自定义链。工程上，当 chainId 不匹配时应阻断关键操作并给出"错误网络"提示，引导用户切换；同时实现链感知 UI——根据当前网络展示不同的资产、合约地址与 gas 信息。这样可避免用户在错误链上发送资产或调用错误合约。

chainId 管理是多链 DApp 正确性的基础。链感知 UI 与错误提示把"链状态"显式化，避免用户误操作，是前端钱包交互的重要工程实践。

• EIP-1193 标准化的 provider 接口
• eth_requestAccounts 连接钱包
• events（accountsChanged、chainChanged）订阅

EIP-1193 定义了钱包 provider 的标准接口，request({ method: 'eth_requestAccounts' }) 用于请求用户授权账户并返回地址列表，是连接钱包的统一入口。事件订阅（accountsChanged、chainChanged、disconnect）让前端能响应账户切换、网络切换与断连，从而动态更新 UI 与重新获取数据。这一标准的工程价值在于：前端无需关心具体钱包实现，只用统一接口即可对接任意符合 EIP-1193 的钱包，并保持状态同步。

EIP-1193 把"连接钱包"抽象为统一请求 + 事件流，极大降低了集成的耦合度。前端应在上层封装这些方法，并在账户/链变化时清理旧数据、重新查询，避免状态错乱。

• wagmi 提供 hooks（useAccount、useConnect、useReadContract 等）
• viem 提供类型安全、细粒度的底层 API
• 两者分工与协作

wagmi 是 React 生态的 Web3 数据层，提供 useAccount、useConnect、useReadContract、useWriteContract、useSignMessage 等声明式 Hooks，封装了连接、网络、合约读写与签名等状态管理。viem 是底层类型安全库，提供 createPublicClient、createWalletClient、decodeEventLog、parseAbi 等细粒度 API。wagmi 内部基于 viem 构建，开发者既可用 wagmi 快速开发，也可用 viem 做底层定制。二者协作让前端代码类型安全、可维护，且支持 tree-shaking 与多链。

wagmi 解决"状态与数据获取"的抽象，viem 解决"类型安全与底层操作"，二者分层清晰。工程上通常用 wagmi 组 hooks，用 viem 处理自定义 RPC 与解析等复杂场景。

• personal_sign 的简单可读签名
• eth_signTypedData_v4 的结构化签名（EIP-712）
• 钱包兼容性与链差异

personal_sign 适合对简单字符串消息签名（如登录、验证身份），实现简单、兼容性好；eth_signTypedData_v4 基于 EIP-712，对结构化数据（含 domain、types、message）签名，可在钱包中展示可读的字段结构，防止被"盲签"，适合需要强语义的授权（如交易、授权、Permit）。取舍上，若需要展示复杂字段并防范钓鱼，用 v4；若只是简单登录，用 personal_sign。不同钱包对方法命名与支持度有差异（如 eth_signTypedData、eth_signTypedData_v3/v4），前端需做能力探测与降级。

选择取决于签名内容的复杂度与安全需求。typed data 因可读、结构化、防重放（含 domain）而更安全，但实现与兼容成本更高；personal_sign 简单但语义弱。工程上应结合业务与钱包支持选择。

• EIP-712 的三层结构（domain、types、message）
• 钱包可读展示与防盲签
• 防重放（domain 分隔）

EIP-712 允许对结构化数据签名，包含 domain（域名、chainId、合约地址、版本）、types（数据结构定义）与 message（实际数据）。钱包会根据结构中文字段在签名界面展示可读内容，用户能看清"我在签什么"，从而防盲签与钓鱼。domain 中的 chainId 与合约地址将签名"绑定"到特定链与合约，防止跨链重放攻击。前端用 eth_signTypedData_v4 发送，并用 verifyTypedData 校验签名；结构化签名还支持 Permit 等无 gas 授权。

EIP-712 把"签名"从不可读的哈希变成可读、可验证、可防重放的结构化协议，是防钓鱼与安全授权的关键。工程价值在于签名可读、可校验、可复用（Permit）。

• eth_sign 盲签风险与滥用
• personal_sign 的前缀可读性
• 安全实践与后端校验

eth_sign 对任意 hex 数据签名，钱包无法展示可读内容，攻击者可诱导用户对恶意交易或授权签名，是高风险反面模式，主流钱包默认禁用或强烈警告。personal_sign 在消息前加 "\x19Ethereum Signed Message:\n" 前缀，使消息可读、与交易签名区分，安全性更高。安全实践包括：默认使用 personal_sign 或 EIP-712 typed data；在 UI 展示签名内容让用户确认；签名消息加入 nonce、时间戳与域名防止重放；后端用 verifyMessage 校验并遵守前缀规则。

eth_sign 的隐患在于"签名不可读、用途不明"，personal_sign 通过前缀与可读性缓解。工程上应把 eth_sign 列入黑名单，并在签名流程中加入防重放与内容确认。

• EIP-6963 的 event 广播发现钱包
• window.ethereum 单钱包独占问题
• 多钱包共存与用户选择

传统上 DApp 通过检测 window.ethereum 发现钱包，但浏览器只能有一个全局 provider，存在"钱包独占"与"注入顺序"问题，用户无法选择第二个钱包，也易被恶意扩展伪造。EIP-6963 引入标准化的 eip6963:announceProvider / eip6963:requestProvider 事件，让多个钱包通过 CustomEvent 广播自身信息（如 uuid、name、icon、rdns），前端可收集并展示所有已安装钱包让用户选择。因此 window.ethereum 检测被视为反面模式，应改用 EIP-6963 事件发现。

EIP-6963 解决了多钱包共存与用户选择问题，提升安全性与用户体验。工程上应通过事件监听收集钱包列表，并避免依赖全局单例 provider。

• WalletConnect v2 的协议与配对
• Reown 的跨平台连接
• 在移动端与桌面端的连接体验

WalletConnect v2 通过中继（relay）与配对（pairing）机制，用二维码或 URI 把 DApp 与钱包连接起来，支持多链、多账户，且不依赖 window.ethereum 注入，适用于移动端与桌面端跨设备连接。Reown（原 WalletConnect 品牌）是这一协议与 SDK 的提供方，提供 @reown/appkit 等库，让前端轻松集成扫码连接、多链管理与 UI。工程价值在于：统一了"浏览器插件 vs 移动 App"的连接体验，支持多链 DApp 与更广的钱包生态。

WalletConnect 解决了"无注入钱包"的移动端连接问题，扩展了 DApp 的可用钱包范围。工程上用其 SDK 封装二维码配对、会话管理与多链切换，体验更佳。

• Ethers.js 的成熟与全量
• viem 的类型安全与 tree-shaking
• wagmi 的 React hooks 封装

Ethers.js 是历史最久、功能全面的库，API 稳定、生态成熟，适合无需强类型的中小型项目与快速开发。viem 是模块化、类型安全的现代库，基于 TypeScript 提供精确的 ABI 类型推导、tree-shaking、体积小，适合需要类型安全与细粒度控制的项目。wagmi 是构建在 viem 之上的 React 数据层，提供声明式 hooks，适合 React 应用快速接入 Web3 状态。选型建议：新项目、React 团队倾向 wagmi + viem；需要类型安全与后端互操作选 viem；追求简单全量可选 ethers.js，同时注意生态迁移趋势。

三者是"底层库 / 框架"分层关系。选型取决于团队技术栈、类型需求与项目规模，现代新项目多倾向 viem（类型安全）配合 wagmi（React 抽象）。

• 重放攻击的定义（旧签名被重复使用）
• nonce 防止重复使用
• domain（chainId、合约地址）防止跨链跨合约重放

签名重放攻击是指攻击者把某个已生成的合法签名在不同的链、合约或上下文里重复提交，从而绕过校验。防护手段包括：在签名消息中嵌入 nonce（每次递增的唯一值），后端记录已使用 nonce 并拒绝重复；嵌入 domain（chainId、合约地址、版本），使签名绑定到特定链与合约，防止跨链/跨合约重放；还可加入时间戳设置有效期。EIP-712 的 domain 分隔正是为此设计。前端在生成签名时需填充 nonce 与 domain，后端校验时必须校验两者。

重放源于"签名缺少上下文绑定"。nonce 防同上下文重复，domain 防跨上下文重放，二者结合是签名安全的标准做法。前端需在签名消息中正确带上这些字段。

• 助记词（BIP-39）生成私钥
• 热钱包（软件）vs 冷钱包（硬件）
• 前端对私钥管理的边界

私钥是 Web3 资产的核心凭据，管理方式分热钱包（软件钱包，如 MetaMask）与冷钱包（硬件钱包，如 Ledger/Trezor）。助记词（BIP-39）是私钥的人类可读备份，丢失助记词即丢失资产。硬件钱包把私钥保存在安全芯片中，签名在硬件内完成，不暴露私钥，抗钓鱼与恶意软件能力更强，适合大额资产；软件钱包便捷但私钥可被恶意扩展或恶意页面窃取。前端工程上，不应把私钥长期保存在页面内存或 localStorage，应依赖钱包提供签名，或使用非托管/合约钱包降低私钥风险。

私钥的安全边界在于"私钥只在与钱包交互时使用，绝不落盘到业务代码"。前端应引导用户使用硬件钱包或安全的托管方案，并强调助记词离线备份。

• approve 的无限授权风险
• 授权目标合约校验
• 前端如何降低授权风险

在 DApp 调用 approve 授权代币时，常见风险是无限授权（approve 一个超大额度），一旦被授权合约存在漏洞或恶意，可转走用户全部代币。前端的工程安全实践包括：仅在用户明确同意时发起授权；默认使用有限额度（如按需授权或授权后立即 increaseAllowance/permit 回收）；使用 eth_call 与 eth_estimateGas 模拟交易、展示授权对象地址与额度；校验授权目标合约地址与源代码；优先使用 EIP-2612 Permit 实现无 gas 授权并可撤销。前端 UI 应清晰展示"授权给谁、多少额度"。

approve 的安全核心是"额度可控、目标可信、可撤销"。前端应避免无限授权、明确展示授权信息，并借助模拟交易确认授权结果，降低资金损失风险。

• eth_call 只读模拟执行
• eth_estimateGas 估算 gas 并检测失败
• 预先发现失败、授权风险与钓鱼

eth_call 可在不真正上链的情况下模拟执行交易，返回结果或错误，用于预览调用结果；eth_estimateGas 估算消耗的 gas，若交易会失败通常会报错，从而在提交前发现回滚。前端可在提交前用 eth_call 模拟 approve 授权结果、用 eth_estimateGas 检测合约调用是否会失败，并展示 gas 与模拟结果，避免用户盲签确认。这些"交易模拟"还能用于风控：识别异常授权额度、畸形参数或可疑目标，辅助防钓鱼。现代框架（如 viem 的 simulateContract）在此基础上封装。

模拟交易把"先上链再发现失败"变成"先模拟再提交"，提升用户体验与安全性。对授权类操作尤为重要，可在提交前确认授权对象与额度，避免资金损失。