software-crypto-web3

name	software-crypto-web3
description	针对 EVM、Solana、Cosmos 和 TON 的安全区块链开发。在构建智能合约、审计或集成链上后端时使用。

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

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

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

---

快速参考表

任务	工具/框架	常用命令	使用场景
Solidity 开发	Hardhat/Foundry	npx hardhat init 或 forge init	以太坊/EVM 智能合约
Solana 开发	Anchor	anchor init	Solana 区块链开发
Cosmos 合约	CosmWasm	cargo generate --git cosmwasm-template	Cosmos 生态系统合约
TON 合约	Tact/FunC + Blueprint	npm create ton@latest	TON 区块链开发
可靠性测试	Foundry/Hardhat	forge test 或 npx hardhat test	单元、分叉、不变量测试
安全审计	Slither/Aderyn/Echidna	slither . 或 aderyn .	静态分析、模糊测试
AI 辅助审查	AI 扫描器 (可选)	N/A	预审计准备（需人工验证结果）
模糊测试	Echidna/Medusa	echidna 或 medusa fuzz	基于属性的模糊测试
Gas 优化	Foundry Gas 快照	forge snapshot	基准测试与优化 Gas 消耗
部署任务	Hardhat Deploy/Forge Script	npx hardhat deploy	主网/测试网部署
合约验证	Etherscan API	npx hardhat verify	源代码验证
可升级合约	OpenZeppelin Upgrades	@openzeppelin/hardhat-upgrades	基于代理 (Proxy) 的升级
智能钱包	ERC-4337, EIP-7702	账户抽象 (AA) SDK	智能账户与赞助 Gas (需验证网络支持)

适用范围

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

• 智能合约开发 (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）。

模式	密钥持有者	典型用途	主要风险	默认控制措施
非托管	最终用户钱包	消费者应用、自我托管	钓鱼、授权错误、用户操作失误	硬件钱包支持、清晰的签名 UI、交互白名单
托管	您的服务 (HSM/MPC)	交易平台、支付、B2B	密钥失窃、内部威胁、操作失误	使用 HSM/MPC、职责分离、限额/审批、审计日志
混合	责任共担	企业级应用	复杂的故障模式	明确的恢复/覆盖路径、完善的操作手册

最佳实践：

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

禁忌做法：

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

“检查-效果-交互” (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 月更新)

类别	工具名称	核心用途	使用建议
静态分析	Slither	漏洞检测，内置 92+ 种检测器	每个合约必用
静态分析	Aderyn	基于 Rust，处理大型代码库速度极快	大型项目推荐
模糊测试	Echidna	基于属性的模糊测试	处理复杂状态时必用
模糊测试	Medusa	并行化的 Go 语言模糊测试工具	集成到 CI/CD 流水线
形式化验证	SMTChecker	Solidity 内置的逻辑检查器	每个合约推荐使用
形式化验证	Certora	基于属性的证明 (CVL)	DeFi 及高价值合约必用
形式化验证	Halmos	符号执行测试	验证复杂的不变量
AI 辅助	Sherlock AI	机器学习驱动的漏洞检测	审计前预检
AI 辅助	Olympia	集成到 DevSecOps	CI/CD 环节安全加固
AI 辅助	Auditless	423+ 检测器，由 LLM 驱动	审查业务逻辑漏洞
突变测试	Sumi	评估测试套件的覆盖质量	验证测试的有效性

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

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

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

保护策略	具体实施方式
私有内存池	使用 Flashbots Protect、MEV Blocker
“提交-揭示”模式	使用哈希承诺，在截止日期后揭晓内容
批量拍卖	使用 CoW Protocol、Gnosis Protocol
加密内存池	使用 Shutter Network

// “提交-揭示” (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	智能合约钱包	无需修改以太坊协议的完整 AA 方案	新用户钱包、DeFi 深度集成、游戏
EIP-7702	EOA 账户增强	让普通 EOA 账户能执行合约代码	现有钱包升级、批量交易处理
ERC-6900	模块化账户	AA 钱包的插件化管理标准	可扩展、可定制的钱包功能

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 选择建议

网络	类型	最适合场景	核心优势
Base	Optimistic	消费级应用、主流普及	与 Coinbase 深度集成，费用极低
Arbitrum	Optimistic	DeFi 协议、成熟的生态	TVL 最高、活跃的 DAO 资助
Optimism	Optimistic	公共物品、超级链 (Superchain) 生态	完善的 OP Stack 与资助计划
zkSync Era	ZK-Rollup	快速确认、原生支持 AA	zkEVM 兼容，提现无需等待
Starknet	ZK-Rollup	Cairo 语言开发、原生 ZK 支持	STARK 证明技术，定制化 VM

企业级 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)

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

错误类型	潜在影响	预防措施
权限控制缺失	未授权的管理员操作	使用 OpenZeppelin 的 Ownable2Step 或 AccessControl
重入攻击 (Reentrancy)	资金被循环提取至空	严格执行 CEI 模式，使用 ReentrancyGuard
未检查外部调用返回值	操作静默失败	始终检查 call 返回值，使用 SafeERC20 库
整数溢出 (0.8 以前版本)	数值被恶意操纵	升级至 Solidity 0.8.x+ (内置溢出检查)
抢跑交易 (Front-running)	MEV 被提取、三明治攻击	使用 Commit-reveal、Flashbots Protect 或私有内存池
预言机操纵	价格喂价遭受攻击	采用 TWAP (时间加权平均价)、多预言机校验、设置波动阈值
初始化不当	代理合约被非法接管	使用 initializer 修饰符，调用 _disableInitializers()
存储冲突 (代理模式下)	合约数据损坏	遵循 EIP-1967 标准插槽，使用 OpenZeppelin Upgrades 插件

禁忌的开发模式

严禁使用：

• 使用 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 - 包含智能合约架构、安全优先工作流以及各平台特定的操作模式。

事实核查要求

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