Software Crypto Web3

软件加密与 Web3 工程 (Software Crypto/Web3)

使用此技能来设计、实施和审查安全的区块链系统，包括：智能合约、链上/链下集成、托管与签名、测试、审计及生产运营。

默认原则：安全优先开发、明确的威胁模型、全方位的测试（单元测试+集成测试+分叉测试+模糊测试/不变量测试）、高价值场景下的形式化方法、可升级的安全性（时间锁、治理、回滚计划）以及密钥托管与签名的深度防御。

快速参考表

适用范围

当您需要进行以下工作时，请使用此技能：

• 智能合约开发 (Solidity, Rust, CosmWasm)
• DeFi 协议实施 (AMM, 借贷, 质押, 流动性挖矿)
• NFT 与令牌标准 (ERC-20, ERC-721, ERC-1155, SPL Token)
• DAO 治理系统开发
• 跨链桥接与互操作性方案
• Gas 优化与存储模式设计
• 智能合约安全审计
• 测试策略制定 (Foundry, Hardhat, Anchor)
• 预言机 (Oracle) 集成 (Chainlink, Pyth)
• 可升级合约模式 (Proxy, Diamond)
• Web3 前端集成 (ethers.js, web3.js, @solana/web3.js)
• 区块链数据索引 (The Graph, Subgraphs)
• MEV 保护与闪电贷机器人开发
• L2 扩容方案 (Base, Arbitrum, Optimism, zkSync)
• 账户抽象 (ERC-4337, EIP-7702, 智能钱包)
• 后端加密集成 (.NET/C#, 多提供商架构, CQRS)
• Webhook 处理与签名验证 (Fireblocks, 托管服务商)
• 基于 Kafka 的加密支付事件驱动架构
• 交易生命周期管理与监控
• 钱包管理 (托管与非托管)

决策树：区块链平台选择

项目需求: [使用场景]
  - 是否需要兼容 EVM 的智能合约？
    - 复杂的测试需求 -> Foundry (支持模糊测试、不变量、Gas 快照)
    - TypeScript 生态偏好 -> Hardhat (丰富插件、TS 支持、Ethers.js/Viem)
    - 企业级功能 -> NestJS + Hardhat

  - 追求高吞吐量 / 低费用？
    - 基于 Rust 生态 -> Solana (Anchor)
    - EVM L2 方案 -> Arbitrum/Optimism/Base (共享以太坊安全性，极低 Gas)
    - 结合 Telegram 分发 -> TON (Tact/FunC)

  - 追求跨链互操作性？
    - Cosmos 生态 -> CosmWasm (IBC 协议)
    - 多链应用 -> LayerZero 或 Wormhole (需验证其信任假设)
    - 自研桥接 -> 风险极高；需建立严密的威胁模型

  - 代币标准实施？
    - 同质化代币 -> ERC20 (OpenZeppelin), SPL Token (Solana)
    - NFT -> ERC721/ERC1155 (OpenZeppelin), Metaplex (Solana)
    - 半同质化代币 -> ERC1155 (适用于游戏、碎片化 NFT)

  - DeFi 协议开发？
    - AMM/DEX -> Uniswap V3 分叉或自定义 (集中流动性)
    - 借贷协议 -> Compound/Aave 分叉 (抵押借贷)
    - 质押/收益 -> 自定义奖励分配合约

  - 需要合约可升级？
    - 透明代理 (Transparent) -> OpenZeppelin (实现管理员/用户权限分离)
    - UUPS 代理 -> 升级逻辑集成在实现合约中
    - 钻石模式 (Diamond) -> 模块化功能扩展 (EIP-2535)

  - 后端集成方案？
    - .NET/C# -> 采用多提供商架构 (参见后端集成参考)
    - Node.js -> Ethers.js/Viem + 持久化队列
    - Python -> Web3.py + FastAPI

各链特定注意事项：

• 以太坊/EVM：安全第一、Gas 成本较高、生态系统最庞大。
• Solana：性能优先、需使用 Rust 语言、费用极低。
• Cosmos：互操作性优先、原生支持 IBC、生态持续增长。
• TON：Telegram 生态优先、异步合约调用、架构独特。

请参阅 references/ 目录以获取各链的最佳实践。

安全优先模式 (2026 年 1 月更新)

安全基线：假设处于对抗性环境。将合约和签名基础设施视为完全公开、随时可能受攻击的 API。

托管、密钥与签名 (核心)

密钥管理是生产级加密系统中最主要的风险来源。请参考真实的密钥管理标准（如 NIST SP 800-57）。

最佳实践：

• 建立相互独立的“热/温/冷”签名路径，并设置限额和审批流。
• 高额转账必须经过双重控制（策略引擎验证 + 人工审批）。
• 为每一次签名请求保留不可篡改的审计追踪（谁、什么时间、操作内容、原因）。

禁忌做法：

• 严禁在数据库或应用配置文件中明文存储私钥。
• 严禁跨环境（开发/预发/生产）重复使用签名密钥。
• 严禁在没有速率限制和“熔断机制”的情况下运行热钱包自动化。

“检查-效果-交互” (CEI) 模式

所有状态修改函数必须遵循此模式。

// 正确做法: CEI 模式
function withdraw(uint256 amount) external {
    // 1. 检查 (Checks): 验证所有前提条件
    require(balances[msg.sender] >= amount, "余额不足");

    // 2. 效果 (Effects): 在进行外部调用之前更新内部状态
    balances[msg.sender] -= amount;

    // 3. 交互 (Interactions): 将外部调用放在最后执行
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "转账失败");
}

// 错误做法: 在更新状态前进行外部调用（极易导致重入攻击）
function withdrawUnsafe(uint256 amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount; // 更新太晚了！
}

安全工具箱 (2026 年 1 月更新)

// Certora CVL 验证规则示例
rule balanceNeverNegative(address user) {
    env e;
    require balances[user] >= 0;
    deposit(e);
    assert balances[user] >= 0;
}

注意：使用 AI 工具应仅用于审计前的预检和辅助覆盖，不能替代最终的安全决策。应将其输出视为不可信，必须通过确定性工具、测试和人工复核来验证结果。

MEV (最大可提取价值) 保护

// “提交-揭示” (Commit-Reveal) 模式示例
mapping(address => bytes32) public commitments;

function commit(bytes32 hash) external {
    commitments[msg.sender] = hash;
}

function reveal(uint256 value, bytes32 salt) external {
    require(
        keccak256(abi.encodePacked(value, salt)) == commitments[msg.sender],
        "揭示验证失败"
    );
    // 逻辑处理揭示后的真实数值
}

账户抽象 (AA) (2026 年 1 月更新)

注意：账户抽象的采用率和协议升级计划变化极快。在提出具体方案前，请务必使用 WebSearch 验证 ERC-4337 生态系统的当前状态以及 EIP-7702 的激活细节。

ERC-4337 与 EIP-7702 对比

ERC-4337 运作架构：

用户 -> UserOperation (用户操作) -> Bundler (打包器) -> EntryPoint (入口合约) -> 智能账户 -> 目标合约
                                    |
                                    v
                                Paymaster (Gas 赞助商)

EIP-7702 (Pectra 升级相关)：

• 普通 EOA 账户可以临时委派给智能合约。
• 支持批量交易，并能为现有地址提供赞助 Gas。
• 与 ERC-4337 互补（共用 Bundler/Paymaster 基础设施）。
• 已获得 Ambire, Trust Wallet 等越来越多钱包的支持。

核心能力：

• 免 Gas 交易：通过 Paymasters 使用 ERC-20 代币或法币代付 Gas 费。
• 批量操作：在单个事务中完成多个操作。
• 社交恢复：支持多重签名或基于受托人的密钥恢复机制。
• 会话密钥 (Session keys)：为 dApp 分配有限权限，无需完全授权钱包。

L2 (第二层网络) 开发 (2026 年 1 月更新)

注意：L2 的市场份额和风险评估处于快速变动中。在对 L2 进行排名、统计 TVL 或风险分类前，请参考最新数据（如 L2Beat）。

L2 选择建议

企业级 Rollup 趋势 (2025-2026)

越来越多的大型机构基于 OP Stack 推出自己的 L2 网络：

• Kraken INK - 交易平台原生 L2。
• Uniswap UniChain - 针对 DeFi 深度优化。
• Sony Soneium - 专注于游戏与媒体内容。
• Robinhood - 集成 Arbitrum 网络。

EIP-4844 (Blob 数据优化)

自 2024 年 3 月起，Rollup 开始使用基于 Blob 的数据发布方式：

• 之前：通过 calldata 发布 -> 成本极高。
• 之后：通过 blob 发布 -> 数据可用性 (DA) 成本大幅降低。

常见漏洞与错误 (2025-2026)

警示：合约漏洞通常会造成惨重损失。权限控制、签名/托管逻辑以及集成环节的错误依然是事故频发的主要原因。

禁忌的开发模式

严禁使用：

• 使用 tx.origin 进行身份验证（存在钓鱼风险）。
• 在链上存储任何敏感私密信息（所有链上数据皆为公开可见）。
• 利用 block.timestamp 生成伪随机数（易受矿工/验证者操控）。
• 忽略 transfer/send 的执行返回值。
• 使用已停止维护的工具（如 Truffle, Ganache, Brownie）。

最佳实践建议：

• 每次代码变更后都运行静态分析（如 Slither 和 Aderyn）。
• 在任何审计启动前，必须完成模糊测试和不变量测试。
• 高价值 DeFi 项目必须采用形式化验证（如 Certora 和符号执行测试）。

LLM 在智能合约开发中的局限性

严禁完全依赖 LLM 进行：

• 涉及到安全性关键逻辑的验证。
• 复杂的 Gas 消耗优化计算。
• 严密的数学逻辑证明。

推荐利用 LLM 进行：

• 样板代码生成（如测试脚本、基础文档）。
• 代码逻辑解释和审计前的初步梳理。
• 提出初始漏洞假设（但必须经过人工和工具验证）。

导航与参考

核心参考资料

• references/blockchain-best-practices.md - 通用区块链设计模式与安全性。
• references/backend-integration-best-practices.md - 后端加密集成模式 (.NET/C#, CQRS, Kafka)。
• references/solidity-best-practices.md - Solidity/EVM 特定开发指南。
• references/rust-solana-best-practices.md - Solana 与 Anchor 开发模式。
• references/cosmwasm-best-practices.md - Cosmos/CosmWasm 最佳实践。
• references/ton-best-practices.md - TON 合约 (Tact/FunC) 开发与部署。
• references/defi-protocol-patterns.md - 深度解析 DeFi 各类协议（AMM、借贷、预言机等）。
• references/nft-token-standards.md - NFT 相关标准与元数据处理。
• references/cross-chain-bridges.md - 跨链桥架构与安全性分析。
• data/sources.json - 精选的各链外部参考资源。

代码模板

• 以太坊/EVM: assets/ethereum/template-solidity-hardhat.md, assets/ethereum/template-solidity-foundry.md
• Solana: assets/solana/template-rust-anchor.md
• Cosmos: assets/cosmos/template-cosmwasm.md
• TON: assets/ton/template-tact-blueprint.md, assets/ton/template-func-blueprint.md
• 比特币: assets/bitcoin/template-bitcoin-core.md

趋势感知协议 (Trend Awareness Protocol)

重要事项：当涉及 Web3/加密货币的技术选型或趋势询问时，您必须在回答前先执行 WebSearch 以获取最新动态。

触发关键词

• “最适合 [用例] 的区块链是哪个？”
• “开发 [智能合约/DeFi/NFT] 推荐使用什么工具？”
• “Web3 开发目前的最新进展是什么？”
• “2026 年关于 [Solidity/审计/Gas 优化] 的最佳实践？”
• “[以太坊] vs [Solana] vs [其它网络] 选哪个？”

必须执行的搜索

1. “2026年Web3开发最佳实践”
2. “[Ethereum/Solana/Base] 2026年开发动态更新”
3. “智能合约安全审计 2026”
4. “[Hardhat/Foundry] 2026年对比分析”

结果汇报要求

搜索后，您的回复应包含：

• 当前现状：目前主流的链、工具及框架。
• 新兴趋势：正在获得关注的新协议或设计模式。
• 过时警示：已失去热度或不再推荐的技术方案。
• 专家建议：基于最新数据和生态活跃度给出的针对性建议。

操作手册

• references/operational-playbook.md - 包含智能合约架构、安全优先工作流以及各平台特定的操作模式。

事实核查要求

• 在给出最终答复前，务必验证当前的外部事实、版本号、定价、法规动态及平台行为。
• 优先选择一手信息源。
• 如果无法进行网络搜索，请在答复中明确说明局限性，并将指南标记为“未经验证”。