解剖 Solidity：从语言陷阱、编译器缺陷到智能合约安全工具链的实战指南

本文基于 Trail of Bits 安全工程师 Evan Sultanik 的两次公开演讲整理：2018 年 12 月在 Empire Hacking 上的《Anatomy of an Unsafe Smart Contract Programming Language》，以及其更新版《Fantastic Bugs and How to Squash Them; or, the Crimes of Solidity》（2019 年 7 月在 Philadelphia Ethereum Blockchain Meetup 再次宣讲）。完整幻灯片见 2018 版演讲稿.pdf) 与 2019 版演讲稿。读完后，你将理解 Solidity 在语言设计、编译器实现与运行时三个层面的系统性风险，掌握重入、抢跑、随机数操纵等高频漏洞的成因与规避模式，并获得一条可落地的智能合约安全工具链（静态分析、属性模糊测试、符号执行）的接入方法。

一、演讲背景：为什么要"解剖"一门语言

2018 年，以太坊生态中已经出现了多起因智能合约代码缺陷导致巨额资产损失的事件。演讲者开篇用一个直观的模型引入主题：区块链本质上是一个不可变的公开账本（immutable public ledger），任何人都可以把内容写入链上——包括 ASCII 艺术，甚至可执行代码。当这些代码被用于托管真金白银时（演讲中反复强调这些合约被委托管理着数亿美元级别的加密货币），任何设计失误都可能被放大为灾难。

智能合约的典型生命周期是：多方参与者（如买家和卖家）向合约托管资产，合约在满足条件时自动执行转账，整个过程以字节码形式部署在链上，由"自动机"执行。一旦代码存在 Bug，攻击者便可以在数分钟级别的时间窗口内（演讲画面中"分钟"替代"毫秒"的隐喻）将其转化为真金白银的损失。这正是演讲者将 Solidity 称为"unsafe programming language"并逐层剖析的动机：这不是一次调侃，而是一次面向"将信任托付给代码"场景的安全审查。

值得一提的是，该主题与仓库中 Trail of Bits 的长期研究脉络一致：同一时期他们发表了 smart_contract_flaws_fc2020（智能合约缺陷的系统性分析）、构建了 Slither 静态分析框架 与 SlithIR 中间表示，本次演讲正是这套工具链诞生的思想背景——先"解剖"语言的不安全之处，再"对症下药"。

二、语言层诊断：Solidity 为什么"不安全"

演讲用一份经典的"编程语言清单"（Programming Language Checklist）对 Solidity 逐项体检，得出一连串对语言设计者而言相当刺眼的结论。这些结论并非情绪化评价，而是指向了可验证的具体缺陷，构成全文分析的骨架：

体检项	结论	实质含义
语言规范	勾选 "No language spec" 与 "The implementation is the spec"	没有独立于编译器的语言规范，实现即规范
类型系统	勾选 "Your type system is unsound"	类型系统在多种错误场景下并不健全
可解析性	勾选 "Your language cannot be unambiguously parsed"	官方文法存在歧义，无法被无歧义解析
编译器行为	勾选 "Dangerous behavior is only a warning"、"Compiler errors are completely inscrutable"	危险行为仅以警告形式出现，错误信息晦涩
语言血统	勾选 "You have reinvented Javascript but worse"	语法与语义与主流语言（C/Java/JS）表面相似但行为迥异

对开发者而言，最后一条尤为致命：Solidity 的语法刻意接近 C/Java/JavaScript，却在一系列细节上与这些语言行为不同。演讲由此得出第一条核心教训：不要假设 Solidity 表现得像其他主流语言（Don't assume Solidity behaves like most other languages!）。

2.1 运算符优先级陷阱：1 | 0 < 1 到底等于什么

演讲给出了这个看似人畜无害的条件判断：

if(1 | 0 < 1) {
    /* case 1 */
} else {
    /* case 2 */
}

在 C、C++、JavaScript、Java 中，由于 < 的优先级高于 |，表达式等价于 1 | (0 < 1)，即 1 | 1，恒为真，进入 case 1。但在 Solidity 中，运算符优先级的定义与这些语言不一致，同样的表达式可能得到完全不同的结果——演讲用一句经典台词（"LEEROYYY JENKINS!"）调侃这种"看起来像、实则不同"的行为，提醒开发者：任何从其他语言迁移过来的优先级直觉都不可靠，应当用显式括号消除歧义。

2.2 类型推断陷阱：var 的默认类型是什么

第二个例子展示了 var 类型推断的隐蔽性：

for (var i = 0; i < foo.length; ++i) {
    foo[i] = i;
}

演讲者抛出问题："循环结束后，foo[1337] 的值是多少？" 关键在于：var 推断出的 i 的类型取决于 foo.length 的类型。在早期 Solidity 版本中，若 foo 是 uint8[] 之类的短类型数组，i 会被推断为 uint8，于是当 i 增长到 255 后，++i 发生溢出回绕，循环永不终止——数组后续元素被无限写入，内存与存储被逐步耗尽，最终触发回退。这类缺陷不依赖任何"恶意输入"，纯粹由类型推断 + 固定位宽整数溢出的相互作用产生。

由此引出第二条核心教训：始终使用显式类型（Always use explicit types!），避免 var。

2.3 结构体内的函数指针：规范与实现的分裂

演讲展示了一段真实存在歧义的 Solidity 代码：在一个 struct 内部声明一个函数类型成员，然后动态地为其赋值不同的函数并依次调用：

contract C{
    struct myStruct{
        function(uint) my_func;
    }

    function test(){
        myStruct m;

        m.my_func = call_log;
        m.my_func(0);

        m.my_func = call_log2;
        m.my_func(0);
    }

    function call_log(uint a){
        Log(a);
    }

    function call_log2(uint a){
        Log2(a);
    }

    event Log(uint);
    event Log2(uint);
}

这是一个"包含函数指针的结构体"。演讲者指出：Solidity 规范（Spec.）与 Solidity 编译器对这段代码的解释并不一致——规范允许的结构体函数指针写法，编译器实际编译出的行为与文档描述存在偏差。这一案例支撑了演讲的核心论断：Solidity 唯一权威的参考文档，就是其唯一编译器的源代码（The sole, canonical reference for Solidity is the source code of its sole compiler.）。当规范与实现冲突时，真实运行在链上的是编译器的行为。

2.4 文法歧义：逗号既是操作符又是分隔符

在剖析 Solidity 的可解析性时，演讲引用了一段对官方文法的分析（这也是演讲标题"Anatomy"的由来——像解剖标本一样逐层拆开）：

解析 Solidity 时我们发现的另一个有趣挑战是：语言使用同一个符号（逗号）既作为表达式列表的分隔符，又作为表达式自身的操作符。……当解析器在输入中遇到逗号时，它不知道这是当前表达式内部的操作符（匹配 Expression 规则），还是当前表达式与下一个表达式之间的分隔符（匹配 ExpressionList 规则）。对任何解析器来说，由于在遇到逗号时两条规则均可匹配，这种歧义都是一个潜在问题。

这条引文揭示了两个层面的问题：

1. 语言层面：官方文法无法被无歧义解析（unambiguously parsed），给所有第三方解析器实现带来根本困难；
2. 工具链层面：演讲者自述编写 Solidity 解析器的亲身经历——查阅官方文法、尝试用解析器生成器接受它、发现文法不正确、最终发现"现有解析器都是手工 #YOLO 写出来的"。这也是他们最终为智能合约分析自建安全导向中间表示（SlithIR）的直接动因，相关设计可见 SlithIR 演讲说明。

2.5 类型系统的不健全：接口未在编译期校验

演讲对 Solidity 类型系统的诊断同样直白："我们发现 Solidity 的类型系统远非安全，对任何类型的错误都不能幸免——在许多场合，合约接口在编译期根本不会被检查，这导致执行期抛出异常，让用户白白浪费（gas）钱。"

对普通语言来说，类型检查的失败通常只是开发期的尴尬；但在智能合约语境下，编译期检查的缺失意味着错误被推迟到链上执行时才暴露，而每一次失败执行都会消耗调用者支付的 gas——类型缺陷在这里直接转化为经济损失。

三、实现层诊断：编译器与工具链的"犯罪记录"

如果说第二章是语言设计层面的问题，第三章则聚焦于编译器实现与工具链。演讲者的立场很明确："业余爱好者与专业人士的区别在于：你（要）编写自己的编译器。" 言下之意，面对一个"实现即规范"的语言，理解编译器行为本身就是安全工作的必备技能。

3.1 优化器是危险的

演讲给出的第一个重磅警告是：不要开启 solc 编译器优化，除非你真的、真的清楚自己在做什么（Don't turn on solc optimizations unless you really, really know what you are doing）。依据如下：

• 编译器优化仍处于活跃开发阶段，远未成熟；
• 2018 年 11 月的一次独立编译器审计得出结论：优化是危险的；
• 与优化器相关的高危 Bug 数量众多，其中许多甚至没有出现在变更日志中；
• 很可能还存在潜伏未发现的 Bug。

对普通项目而言，开启优化换来的 gas 节省，与引入"改变代码语义"的编译器缺陷风险相比，往往得不偿失。

3.2 幂运算：0**0 == 1 但 0**0x100 == 0

演讲引用了以太坊开发者 Martin Holst Swende 的链上追踪数据来说明编译器代码生成的低效与语义问题。对某 16 个区块的交易追踪显示：

• 共发生 18,538 次 EXP 运算调用；
• 其中超过一半是在计算 160 的 1 次方（160^1）这类本可静态折叠的平凡运算；
• 粗略估算（18538×4 对比 20000×16），这类运算消耗了约 25% 的相关计算时间。

这一数据说明了编译器在基本优化层面的欠缺（演讲在检查清单中勾选了"You don't seem to understand basic optimization techniques"）。更关键的是语义问题——编译器源码中有一句注释：

// We need cleanup for EXP because 0**0 == 1, but 0**0x100 == 0

演讲指出：使用位宽小于 256 位的指数执行 ** 运算，可能得到意外结果。这再次说明"编译器仍然不成熟"（The compiler is still immature）：同样的表达式，仅仅因为指数的类型位宽不同，就可能产生语义不一致的结果。

3.3 变化太快：向后兼容与 solc-select

演讲用一张调侃漫画（改编自 xkcd 1428）表达 Solidity 的版本迭代现状：语言在快速变化，这种变化既是坏事也是好事。坏的一面是，编译器每个版本都可能引入破坏性变更（如 0.4.24 到 0.5.0 之间的大量语法与语义调整，仓库 README 原话是"Solidity is changing quickly, which is both bad and good"）；好的一面是，许多早期缺陷正是通过新版本得到修复。

由此引出的实践建议是：在项目生命周期内，要预期破坏性变更（Expect breaking changes during the course of your project!），并且使用 solc-select 之类的版本管理工具，为每个项目固定并随时切换所需的编译器版本，避免"升级编译器导致既有合约语义漂移"这一类隐蔽风险。

3.4 可升级合约：DELEGATECALL 代理模式的存储布局陷阱

演讲明确将"可升级合约"列为高风险领域。其机制是：用户合约（proxy）通过 DELEGATECALL 将调用委托给逻辑合约（implementation），从而实现"升级逻辑而不迁移存储"。但演讲给出的警告非常具体：

如果你必须使用 DELEGATECALL 代理升级模式，那么你必须始终确保新合约的存储布局与旧合约一致！

原因在于 DELEGATECALL 在调用方的存储上下文中执行被调用方的代码：一旦新版本逻辑合约在存储变量声明顺序、类型或数量上发生变化，旧存储槽位的数据就会被新代码按错误的类型解读，轻则数据错乱，重则直接导致资金损失或权限失控。演讲画面以"新字节码覆盖旧字节码、用户哭泣"的漫画强化了这一后果。

3.5 替代语言：更不成熟的选择

演讲也审视了 Solidity 的替代语言，结论是：它们更加不成熟、缺乏安全工具支持、且具有不同的语义。对于承载资金的场景，"换语言"并不能自动带来安全，反而会引入工具链空白与未知语义的风险。这一判断也与仓库中 Trail of Bits 后来长期深耕 Solidity/Vyper 静态分析（Slither）与形式化验证的路线一致。

四、Bug 解剖室：七类高频智能合约漏洞

《Fantastic Bugs and How to Squash Them》的主体是一份"常见错误动物园"，演讲者将其总结为**常见的错误（common mistakes）与极其隐蔽的怪癖（deeply insidious idiosyncrasies）**两大类。以下七类是其中的核心：

4.1 重入（Reentrancy）

攻击合约在接收转账的回调中（如 fallback 或 receive）再次调用受害合约的同一函数，在受害合约"状态更新"之前反复提取资金。演讲给出的防御模式是业界标准的 "checks, effects, interactions"（先检查条件、再更新自身状态、最后才与外部交互）——把状态更新移到外部调用之前，即可切断重入的获利路径。经典历史案例（如 DAO 攻击）正是对该模式的忽视。

4.2 恶意外部调用

合约调用外部合约时，被调合约可能是攻击者部署的、行为不可控的代码。演讲的教训是：不要信任外部合约（Don't trust external contracts!）。对返回值要显式校验，对调用对象的地址来源要严格限制，对外部调用可能引发的控制流转移要有心理预期。

4.3 零初始化（Zero Initialization）

与大多数语言不同，Solidity 中未初始化的存储键所对应的存储内容会被清零（未初始化键导致未初始化内存，而该内存被置零）。开发者若依赖"未初始化即垃圾值"的 C 语言直觉，就可能把"零值"误认为"有效值"，从而在权限判断或数值运算中埋下漏洞。这是"语言行为与直觉不同"的又一典型。

4.4 数组长度操纵

永远不要手动操作数组的长度（Never manually manipulate the length of an array!）。直接修改 .length 字段而不进行相应的存储整理，可能破坏 Solidity 的存储布局假设，导致越界读写或数据错乱。数组的扩容/收缩应交给语言提供的 push/pop 等内置机制。

4.5 交易抢跑（Frontrunning）

交易在进入区块之前是公开可见的（mempool），而且不保证按提交顺序被打包。这意味着任何人都可以观察待打包交易、并以更高的 gas 价格抢先提交一笔"复制粘贴"的交易，抢先完成对自己有利的状态变更（例如抢在受害者买入前买入、再高价卖出）。演讲的教训：交易是公开的，且不保证按序打包（Transactions are public, and aren't guaranteed to be mined in order）。应对手段包括 commit-reveal、防抢跑定价机制、以及对敏感操作做时间/顺序约束。

4.6 随机数（Randomness）——"区块链上做不了随机"

这是演讲中最具冲击力的一节，结论甚至被编排成一句口号："You can't do random on a blockchain"（你无法在区块链上做随机）。理由有三层：

1. 链上无安全随机源：区块哈希看似随机，但矿工可以操纵它；矿工还能影响时间戳；
2. 链上无秘密：合约中的一切内容公开可见，彩票类合约只有在所有参与者登记后才能生成随机数，而此时的"随机数"对所有人都是可预测的；
3. 链下计算更快：计算机总是比区块链快，合约能生成的任何随机数都可以在链下被更快地预计算出来。

演讲给出的反例代码正是"自作聪明"的典型：

winner = entries[blockHash % entries.length];

用区块哈希取模选幸运者，攻击者只需尝试不同的区块/时机即可操纵结果。演讲的结论：如果你真的需要随机性，请使用可信的链下预言机（oracle），并且不要在数论上自作聪明（Don't try to be clever with number theory）。

4.7 预签名转账与 ecrecover

ecrecover 用于从签名中恢复出签名者地址，是很多"链下签名、链上执行"方案的基石。演讲的教训是：始终检查 ecrecover 的返回值！最好干脆避免使用它（Always check the return value of ecrecover! Better yet, avoid it!）。原因在于：签名无效/格式异常时 ecrecover 可能返回零地址或恢复出一个非预期的地址，若合约代码不对返回值做显式校验，攻击者可以伪造出"零地址授权"等边界状态，绕过权限校验。

4.8 编译器警告：throw 的弃用

在"编译器警告"一节，演讲提醒开发者不要忽略看似无害的弃用警告。典型示例：

Warning: "throw" is deprecated in favour of "revert()", "require()" and "assert()"

throw 的语义（立即消耗全部剩余 gas 并回退）与 revert()/require()/assert() 不同，后者允许更精细的 gas 与错误处理。"危险行为只以警告形式出现"（Dangerous behavior is only a warning）是 Solidity 编译器长期被诟病的特性——警告不是可选项，在智能合约语境下，每条警告都可能是资产损失的前兆。

五、未来已来：YUL 中间表示及其文法问题

演讲以很大篇幅前瞻性地讨论了 Solidity 团队提出的新中间表示 YUL（演讲中称 "They're Proposing a New Intermediate Representation, YUL"），并完整给出了其文法草案：

Block = '{' Statement* '}'
Statement =
    Block |
    FunctionDefinition |
    VariableDeclaration |
    Assignment |
    Expression |
    Switch |
    ForLoop |
    BreakContinue
FunctionDefinition =
    'function' Identifier '(' TypedIdentifierList? ')'
    ( '->' TypedIdentifierList )? Block
VariableDeclaration =
    'let' TypedIdentifierList ( ':=' Expression )?
Assignment =
    IdentifierList ':=' Expression
Expression =
    FunctionCall | Identifier | Literal
If =
    'if' Expression Block
Switch =
    'switch' Expression Case* ( 'default' Block )?
Case =
    'case' Literal Block
ForLoop =
    'for' Block Expression Block Block
BreakContinue =
    'break' | 'continue'
FunctionCall =
    Identifier '(' ( Expression ( ',' Expression )* )? ')'
Identifier = [a-zA-Z_$] [a-zA-Z_0-9]*
IdentifierList = Identifier ( ',' Identifier)*
TypeName = Identifier | BuiltinTypeName
BuiltinTypeName = 'bool' | [us] ( '8' | '32' | '64' | '128' | '256' )
TypedIdentifierList = Identifier ':' TypeName ( ',' Identifier ':' TypeName )*
Literal =
    (NumberLiteral | StringLiteral | HexLiteral | TrueLiteral | FalseLiteral) ':' TypeName
NumberLiteral = HexNumber | DecimalNumber
HexLiteral = 'hex' ('"' ([0-9a-fA-F]{2})* '"' | '\'' ([0-9a-fA-F]{2})* '\'')
StringLiteral = '"' ([^"\\r\\n\\] | '\\' .)* '"'
TrueLiteral = 'true'
FalseLiteral = 'false'
HexNumber = '0x' [0-9a-fA-F]+
DecimalNumber = [0-9]+

演讲者对这份文法草案的审查毫不留情，逐条指出其形式化缺陷：

• "If" 产生式从未被使用——文法中定义了 If 规则，但 Statement 的展开项里根本没有引用它，属于冗余/死规则；
• 默认 switch 分支（default）后面没有跟随冒号——与其他 case 分支的写法不一致；
• "switch foo" 是这份文法中的合法产生式——按文法推导，switch 后面可以没有 case/default 分支，这显然不是设计意图；
• StringLiteral 不经过强制转换就无法表示——字符串字面量需要与类型绑定，文法本身无法直接表达这一约束。

演讲者的总结是："这一切以前都发生过……还会再次发生"（All of this has happened before … and will happen again.），并预告了 Trail of Bits 自己的对策——SlithIR（安全导向的中间表示）与 EVM::SSA 方案。这与仓库中 SlithIR 演讲 的内容互为印证：SlithIR 通过把 Solidity 转换为精简的 SSA 中间表示，为污点追踪等经典程序分析技术提供坚实基础，从而回避了在"不健全语法树"上直接分析的困境。

六、对策与工具链：如何让智能合约开发更安全

演讲的收尾部分给出了一条完整的、可直接落地的安全实践路径：把免费开源的自动化工具集成进你的 CI 流水线。以下工具按分析类型分为三类，覆盖"静态检查 → 属性测试 → 符号验证"三个层级。

6.1 Slither：静态分析（秒级、低误报）

• 输入：Solidity 代码；输出：可检测的错误清单（内置大量漏洞检测器）、不良编码实践警告、继承图与合约摘要；
• 特性：支持 Solidity 与 Vyper、误报率低、易于集成进 CI、速度极快（毫秒级）、支持高级值与污点追踪、提供 Python 检测器 API 便于自定义规则。

安装与使用（演讲原文，即插即用）：

pip3 install slither-analyzer

然后：

slither contract.sol

或对 Truffle 项目整体扫描：

truffle compile; slither .

演讲者评价："Slither 超级简单快速！没有理由不把它集成进你的 CI 流水线。"（仓库中关于其架构与 SlithIR 设计原理的说明见 Slither 演讲 README。）

6.2 Echidna：属性模糊测试（发现全新 Bug 类别）

• 输入：Solidity 代码与测试；输出：Echidna 能违反的不变量列表、触发违规的最小调用序列；
• 特性：生成并执行大量合约输入、基于语法的智能输入生成、无缝融入开发者工作流、每秒可运行数千个生成输入、自动生成最小化测试用例、通过 Haskell API 高度可扩展。

适用场景：当你想检测"从未见过的新类别 Bug"（演讲中借"测试新 Bug"的例子说明：在大量路径与条件下，某个特定参数值 a == 65 才会触发的深埋缺陷，靠手写测试几乎不可能命中）时，Echidna 这类属性测试器比静态规则更合适。演讲者的评价是：Echidna 没有 Slither 快，但在 CI 中依然足够快；与 Slither 不同，它有能力发现全新的 Bug 类别。

6.3 Manticore：符号执行验证

• 输入：Solidity 代码（可选）或原始 EVM 字节码；输出：检测到的缺陷清单、被验证的属性、发现路径的执行轨迹；
• 特性：对 EVM 进行符号执行、跨多笔交易与多个合约深入探索可能状态、直接从字节码发现函数、检测整数溢出与未初始化内存/存储使用等缺陷、验证自定义程序断言、通过 Python API 高度可脚本化。

演讲给出了一个可复现的示例。对如下合约：

contract Simple {
    function f(uint a){
        // .. lot of paths and conditions
        if (a == 65) {
            revert();
        }
    }
}

运行：

manticore simple.sol

典型输出：

2018-02-28 17:06:21,650: [25981] m.main:INFO: Beginning analysis
2018-02-28 17:06:21,803: [25981] m.ethereum:INFO: Starting symbolic transaction: 1
2018-02-28 17:06:22,098: [25981] m.ethereum:INFO: Generated testcase No. 0 - REVERT
2018-02-28 17:06:23,185: [25981] m.ethereum:INFO: Generated testcase No. 1 - REVERT
2018-02-28 17:06:24,206: [25981] m.ethereum:INFO: Finished symbolic transaction: 1 | Code Coverage: 100% | Terminated States: 3 | Alive States: 1
2018-02-28 17:06:24,213: [32058] m.ethereum:INFO: Generated testcase No. 2 - STOP
2018-02-28 17:06:25,269: [25981] m.ethereum:INFO: Results in /examples/mcore_zua0Yl

注意输出中的 Code Coverage: 100%：符号执行自动发现了导致 revert 的具体输入（测试用例 No. 0 与 No. 1），并覆盖了 a == 65 这条深埋路径。演讲同时提醒：Manticore 能验证合约满足其不变量，但运行时间可能很长，适合作为关键合约的深度验证手段而非日常快速扫描。

6.4 周边生态资源

除三大工具外，演讲还推荐了若干配套资源：

• (Not So) Smart Contracts：教育型工具，包含真实世界漏洞的可运行示例合约，用于学习 EVM 与 Solidity 漏洞，审计代码时是很好的参考资料；
• Awesome Ethereum Security：社区维护的开源参考列表，汇集安全开发资源、CTF 与靶场、以及可视化/静态检查/Bug 发现/验证/逆向等各类安全工具索引；
• Blockchain Security Contacts：区块链应用安全联系人清单，为资产规模较大的项目提供漏洞披露实践与联系渠道模板。

七、结论：一份面向实践的"安全宣言"

演讲的最终结论是一份浓缩的行动清单，同时也是对全文的收束：

1. Solidity 并非一门好语言，但（在当时）我们还得用它——正确态度是认清其缺陷并主动防御；
2. 不要假设 Solidity 表现得像一门"正常"语言——运算符优先级、类型推断、未初始化语义等处处不同；
3. 不要信任 Solidity 文档，唯一的编译器实现才是规范——以真实编译行为为准；
4. 不要启用 Solidity 编译器优化——优化器风险高于收益；
5. 避免 DELEGATECALL 代理升级模式——如无法避免，必须保证新旧版本存储布局一致；
6. 不要信任外部合约调用；
7. 记住区块链上的一切都是公开的——没有秘密、没有安全随机源；
8. 不要假设交易会按序（甚至会被）打包——抢跑是常态威胁；
9. 阅读 (Not So) Smart Contracts，从真实漏洞中学习；
10. 把 Slither 与 Echidna 接入 CI 流水线，用 Manticore 验证关键合约的正确性。

对照仓库中的后续成果，这条路线已经被验证为可持续的工程实践：Trail of Bits 围绕智能合约安全持续产出了 Slither 静态分析框架、SlithIR 中间表示、智能合约缺陷论文，以及在 reviews 目录下的大量真实合约安全审计报告。本演讲的价值在于：它以"解剖语言"的方式，把安全从业者与开发者共同面对的风险讲得透彻而具体——理解一门语言如何不安全，是让依赖它的代码变得安全的第一步。