合约缺陷的字典：EIP-1470 与 SWC 编号的现状

给缺陷起名字为什么重要

安全行业的一个共识是：没有统一的缺陷命名，就没有可靠的统计与分工。Web 世界有 CWE 和 OWASP 榜单，人们才谈得上”这类漏洞在行业里占多大比例”。2018 年 9 月 18 日提交的 EIP-1470 想把同样的方法带到智能合约：建立一套合约专用的弱点分类体系（SWC），在 CWE 的术语骨架上叠加合约特有的变体，目标包括给弱点分类、定位漏洞根因、为架构设计代码提供共同语言、以及训练分析工具。提案状态是 Stagnant（停滞，且类型为 Informational 信息类），但它孵化出的注册表一度成为审计报告的标准引用格式。

注册表与编号长什么样

实现这套方案的是 Smart Contract Security 团队的 SWC Registry。每个条目有 SWC 编号、弱点名、适用范围、状态，并像 CWE 那样标注与其他条目的关系——例如整数溢出变体挂在”计算错误”这个 CWE 父类之下。审计工具的发现项从此可以写成”SWC-101 整数溢出""SWC-107 未检查的调用返回值”这样的引用，让不同审计公司的报告能横向对比。用户读到 SWC 编号时，它的价值正在于此：顺着编号查定义、查触发条件、查历史利用方式，把一段吓人的发现摘要还原成具体的、可判断的问题。

现状：停止新增与后继标准

需要如实交代的是注册表自身的情况。其 README 开头声明该仓库不再活跃维护，2020 年后未新增条目；所有已描述的弱点被并入 2022 年 8 月发布的 EEA EthTrust 安全等级规范第一版，该规范 2023 年 12 月出了第二版且持续维护；另一条延续线是长期更新的智能合约安全验证标准 SCSVS。范围说明还专门提醒：SWC 只覆盖 Solidity 合约代码内的弱点，“合约相邻代码”不在册——文中举的例子恰恰是钱包代码里的 gas siphoning 攻击，明确说这类问题应当”在钱包代码中防住”却不会以 SWC 编号出现。读 SWC 而不读范围声明，会误以为它涵盖了所有风险面。

钱包用户为什么要碰这个词

你大概率永远不给合约写一行代码，但你会读产品披露的审计报告或漏洞赏金摘要。这时 SWC 编号是效率工具：看到”已缓解 SWC-107”，你知道它说的是低级但致命的返回值检查；看到一堆”信息级”条目，也不必恐慌。但更重要的是理解这套字典的结构性盲区：它管的是”合约写得对不对”，管不到”合约做的事对你是否有利”。权限设计、经济模型、预言机依赖的恶意操纵面，很多并不表现为某个编号的弱点。把”零 SWC 高危”理解为”资金安全”，是把字典当成了世界。

把字典接回自己的操作

一个健康的阅读顺序是这样的：先确认审计对象——报告标题里的合约地址、版本、提交日期，对照你在用的产品版本，过期的审计报告要打折；再看发现项与处置状态，用编号查清每个弱点在你使用的场景下是否可达；最后落到钱包侧的防御动作：验证过源码的合约优先、额度授权按需给、大额操作前小额试路。涉及多签、桥、质押合约这类多方系统时，审计报告通常只覆盖合约代码，钱包与后端的运行环境风险要另行评估。这套组合拳不依赖任何单一分类体系的完备性。

编号之外的风险账

SWC 的故事到头来是一堂元课：分类法有维护周期，标准会换代（EthTrust 接棒就是明证），而漏洞的产生不会等标准。把安全感建立在”报告里有哪些编号”上，等于把判断外包给字典。可靠的习惯始终是具体而重复的：查过合约地址，读过授权对象，确认了提现路径，再点确认。任何涉及资产、收益或交易操作的决策，都不应以一份分类清单替代你对产品结构的理解；本文内容只用于理解风险，不构成任何投资建议。