【论文翻译】Perez 2019 Smart Contract Vulnerabilities:Vulnerable Does Not Imply Exploited

摘要

近年来，我们在智能合约（特别是为以太坊区块链开发的合约）中的漏洞这一话题上看到了大量学术和实际兴趣。虽然大多数工作都集中在对易受攻击的契约进行检测上，但在本文中，我们的重点是找出这些易受攻击的契约中有多少被实际利用了。我们调查了最近六个学术项目所报告的23327个易受攻击的领域，结果发现，尽管这些领域的风险很大，但自部署以来，只有1.98%的领域被开发利用。这最多相当于8487 ETH（约170万美元），或仅占300万ETH（6亿美元）的0.27%。我们通过证明资金非常集中于少数在实践中不可利用的合同来解释这些结果。

1 介绍

当涉及到漏洞研究时，尤其是涉及到软件安全时，通常很难估计实际中发现的漏洞中有多少被利用。然而，公共区块链具有不可更改性、易访问性以及相当于智能合约可重放的执行日志，为此类调查提供了极好的机会。在这项工作中，我们旨在将以太坊[16]区块链上的智能合约中报告的漏洞与这些合约的实际利用情况进行对比。

我们收集了最近六篇论文[24,31,32,35,39,51]的作者与我们分享的数据，这些论文的重点是发现智能合约漏洞。这些学术数据集的规模比我们在野外所能找到的报告要大得多，而且由于受影响合同的绝对数量（23327份）代表了一个优秀的研究课题。

为了使我们的方法更加通用，我们将六个不同的频繁报告的漏洞类表示为数据日志查询，这些查询是通过表示以太坊区块链状态的关系计算的。基于数据日志的漏洞发现方法为我们的过程提供了更大的可伸缩性；此外，虽然其他人使用数据日志进行静态分析，但我们不知道它被用来捕获区块链随时间变化的动态状态。

我们发现，由于一些著名的加密货币漏洞（如dao[45]或Parity wallet[14]漏洞）有时具有耸人听闻的性质，在没有标记的智能合约漏洞数量明显低于可能发生的数量。

贡献。我们的贡献是：

• 数据记录公式。我们提出了一个基于数据日志的模拟，用于对以太坊虚拟机（EVM）执行跟踪执行分析。我们使用这种高度可扩展的方法来分析来自以太坊区块链的总计超过2000万笔交易，以搜索漏洞。我们强调，我们的分析是基于我们提取的事实和定义我们在本文中涉及的漏洞的规则自动运行的。
• 开发的实验评估。我们分析了最近发布的六个研究报告中报告的漏洞，并得出结论，尽管易受攻击的合同数量和风险资金量非常高，但实际利用的资金量要低几个数量级。我们发现，在价值3124433 ETH的23327份易受攻击的合同中，463份合同可能被利用，价值8487 ETH，仅占总风险金额的0.27%。
• 建议的解释。我们假设，造成这些巨大差异的主要原因是，可开采的Ether数量与标记易受攻击的Ether数量相比非常低。事实上，对易受攻击的合同及其包含的Ether的进一步分析表明，大部分Ether仅由少数合同持有，这些合同上报告的漏洞要么是误报，要么是误报实际中不可用。我们还确认，以太坊区块链上的所有合约集与我们的数据集中的财富分布相似。

为了使本文中的许多讨论更加具体，我们在附录A中对高价值合同进行了深入的研究。

2 背景

以太坊[16]平台允许用户在其分布式基础设施上运行“智能合约”。以太坊智能合约（Ethereum smart contracts）是一种定义了一套相关基金管理规则的程序，通常用图灵完整编程语言Solidity编写[19]。Solidity类似于JavaScript，但一些显著的区别在于它是强类型的，并且具有与以太坊平台交互的内置结构。以Solidity编写的程序被编译成低级的非类型化字节码，以太坊虚拟机（EVM）将在以太坊平台上执行[53]。值得注意的是，也可以在不使用可靠度的情况下编写EVM合同。

要执行智能合约，发送方必须向合约发送交易，并支付一笔费用，该费用来自合约的计算成本（以gas为单位）。每一条执行的指令消耗一个商定的气体量[53]。消耗的gas贷记给包含交易的区块的矿工，而未使用的gas则退还给发送者。为了避免从不终止程序导致的系统故障，事务为合同执行指定了gas限制[40]。一旦达到此限制，就会抛出gas不足异常。

智能合约本身有能力调用以太坊区块链上的其他账户。这个函数是重载的，因为它既用来调用另一个契约中的函数，也用来将以太坊中的基础货币ETH（ETH）发送到一个帐户。以太坊的一个特殊之处是，来自合同内部的调用（也称为内部事务）不会创建新的事务，因此不会直接记录在链上。这意味着在不执行事务的情况下查看事务并不能提供足够的信息来跟踪事务流。

2.1 智能合约漏洞

在本小节中，我们简要回顾了一些最常见的漏洞类型，这些漏洞类型是为基于EVM的智能合约而研究和报告的。我们为每个漏洞提供了两个字母的缩写，我们将在本文的其余部分使用。

Re-Entrancy (RE)。当合同“calls”另一个帐户时，它可以选择允许被调用方使用的gas。如果目标账户是一个合同，它将被执行，并可以使用提供的gas预算。如果这样的合同是恶意的，而且汽油预算足够高，它可以尝试在呼叫者中回电——一个重新进入的call。如果调用者的实现不是可重入者，例如，因为它没有更新其包含余额信息的内部状态，则攻击者可以使用此漏洞从易受攻击的契约中耗尽资金[31、35、51]。此漏洞用于DAO漏洞攻击[45]，本质上导致以太坊社区决定使用硬分叉回滚到以前的状态[37]。我们将在第8节中提供有关dao开发的更多详细信息

Unhandled Exceptions (UE).一些稳定的低级操作，如send，用于发送以太，在失败时不会抛出异常，而是通过返回布尔值来报告状态。如果未选中此返回值，则即使支付失败，调用方也会继续执行，这很容易导致不一致[15、31、35、48]。

Locked Ether (LE). 以太坊智能合约可以像以太坊上的任何帐户一样接收以太。然而，有几个原因使收到的资金可能被永久地锁定在合同中。

一个原因是，合同可能依赖于另一个合同，该合同已被使用EVM的自毁指令销毁，即其代码已被删除，其资金已被转移。如果这是这样一个合同发送Ether的唯一方式，它将导致资金被完全锁定。这就是2017年11月发生的Parity Wallet漏洞，锁定了价值数百万美元的以太[14]。我们在第8节中提供了更多的细节

还有一些情况下，合同将总是用尽gas时，试图发送Ether，这可能导致锁定合同资金。有关此类问题的更多详细信息，请参见[24]。

Transaction Order Dependency (TO). 在以太坊，多个事务包含在一个块中，这意味着合同的状态可以在同一块中多次更新。如果调用同一智能合约的两个事务的顺序改变了最终结果，则攻击者可以利用此属性进行攻击。例如，给定一个期望参与者提交exchange中一个谜题的解决方案以获得奖励的合同，恶意合同所有者可以在提交交易时减少奖励金额。

Integer Overflow (IO).整数上溢和下溢在许多编程语言中是一种常见的错误类型，但在以太坊环境中，它可能会产生非常严重的后果。例如，如果一个循环计数器溢出，产生一个无限循环，合同的资金可能会被完全冻结。如果攻击者能够增加循环的迭代次数（例如，通过注册足够的用户来触发溢出），则可以利用此漏洞。

Unrestricted Action (UA). 合约通常通过检查消息的发送者来执行身份验证，以限制用户可以执行的操作类型。通常，只有合同的所有者才可以销毁合同或设置新的所有者。这样的问题不仅发生在开发人员忘记执行关键检查，也会发生在攻击者可以执行任意代码，例如通过控制委派调用的地址[32]。

2.2 分析工具

智能合约通常被设计成操纵和持有以太计价的基金。这使得它们成为非常诱人的攻击目标，因为成功的攻击可能会让攻击者直接从合同中窃取资金。考虑到智能合约中的许多常见漏洞（我们在上一节中描述了其中一些），已经开发了大量工具来自动查找这些漏洞[18、35、51]。这些工具大多分析契约源代码或其编译的EVM字节码，并查找已知的安全问题，如重入性或事务顺序依赖漏洞。我们在图1中总结了这些不同的工作。第二栏和第三栏分别列出了每篇论文中分析的合同和标记为易受攻击的合同的报告数量。“漏洞”列显示每个工具可以检查的漏洞类型。我们将在第2.1节中介绍这些漏洞，并在第8.2节中对这些工具进行更详细的描述。

2.3 定义

本文给出了易受攻击（vulnerable）、可利用（exploitable）和被利用（exploited）三个术语的定义。

vulnerable:如果合约本身已被静态分析工具标记，则它是易受攻击的。正如我们稍后将看到的，这意味着一些合同可能会因为误报而受到攻击。

exploitable:如果契约易受攻击并且该漏洞可能被外部攻击者利用，则该契约是可利用的。例如，如果工具标记的“漏洞”位于需要拥有契约的函数中，则该漏洞是易受攻击的，但不可利用。

exploited:如果合同在以太坊的主网络上接收到触发其漏洞的事务，则会被利用。因此，一个合同可能是易受攻击的，甚至可以在没有被利用的情况下被利用。

3 数据集

本文分析了[35]、[31]、[39]、[51]、[24]和[32]六篇学术论文中的易受攻击的智能合约。为了收集有关分析的地址和发现的漏洞的信息，我们联系了不同论文的作者。

Oyente[35]数据已公开[34]。其他论文的作者很友好地向我们提供了他们的数据集。我们在与作者联系后不到一周内就收到了所有的回复

我们还联系了[48]、[30]和[15]的作者，但无法获得他们的数据集，这就是为什么我们不分析这些论文的原因。

我们的数据集由总共821219个合同组成，其中23327个合同被标记为易受第2节中描述的六个漏洞中的至少一个的攻击。虽然我们直接从作者那里得到了数据，但分析的合同数量通常与论文中报告的数据不匹配，如图1所示。我们认为这方面的两个主要结果是：作者在出版后改进了他们的工具，并且作者在他们提供给我们的数据中没有包含重复的内容。因此，我们将数据集中的数字，以及图2中脆弱合同的风险。风险在于将所有标记为脆弱的合同的余额相加。我们使用每篇论文发表时的平衡，而不是当前的平衡，因为它可以更好地了解可能被利用的Ether的数量。

分类法 Taxonomy.。我们没有按原样重用现有的智能合约漏洞分类法[11]，而是对其进行调整，以适应数据集中工具分析的漏洞。我们不涉及六种工具中至少两种没有分析的漏洞。我们解决了第2节中描述的六种类型的漏洞：重进入（re）、未处理异常（UE）、锁定以太（LE）、事务顺序依赖（TO）、整数溢出（IO）和无限制操作（UA）。由于我们调查的论文对每个漏洞使用了不同的术语和略有不同的定义，因此我们将相关漏洞映射到我们分析的六种漏洞类型之一。我们在图5中展示了如何映射这些漏洞。

重叠漏洞。在本小节中，我们首先检查数据集中合同之间有多少重叠：有多少合约被多个工具分析过，有多少合约被多个工具标记为易受攻击。我们注意到，除[35]外，大多数论文都是在同一时期发表的。我们发现，在821219份合同中，至少有两个工具分析了73627份，但至少有三个工具分析了13751份。在图3a中，我们展示了一个柱状图，显示了有多少不同的工具分析一个合同。在图3b中，我们显示了将单个契约标记为易受任何已分析漏洞攻击的工具的数量。所分析的合约和脆弱合约的重叠相对较小。我们假设其中一个原因是，一些工具处理的是稳定代码[31]，而其他工具处理的是EVM字节码[35，51]，这使得不同工具之间可用的合约数量不同。

在对不同工具的分析中，我们也发现了很多矛盾。我们选择重新进入来说明这一点，因为我们分析的三个工具支持这一点。在图4中，我们展示了支持重入检测的三个工具之间的一致性。“总计”列显示“工具”列中两个工具分析的合同总数，其中至少有一个工具将其标记为易重新进入。Oyente和Securify只同意23%的合同，而Zeus似乎不同意任何其他工具。这反映了构建针对EVM的静态分析工具的困难。虽然我们不试图评估不同工具的性能，但这给了我们另一个动机，即找出所报告的漏洞的影响。

4 方法论

在本节中，我们详细描述了为检查第2节所述漏洞的利用情况而执行的不同分析。

为了检查潜在的漏洞，我们执行字节码级别的事务分析，在执行特定事务时查看契约执行的代码。我们使用这种类型的分析来检测第2节中介绍的六种类型的漏洞。

为了执行我们的分析，我们首先检索数据集中所有合约的事务数据。接下来，为了执行字节码级别的分析，我们提取可能影响感兴趣合同的交易的执行跟踪。我们使用EVM的调试功能，这使我们能够在跟踪执行的指令时重放事务操作。为了加快数据收集过程，我们修补了Go以太坊客户端[10]，而不是依赖默认以太坊客户端提供的远程过程调用（RPC）功能。

提取的跟踪包含已执行指令的列表，以及每条指令的堆栈状态。为了分析跟踪，我们将它们编码为数据日志表示；数据日志是一种实现递归一阶逻辑的语言[29]，允许我们简洁地表示有关执行跟踪的属性。我们使用以下域将有关跟踪的信息编码为数据日志事实，注意V是程序变量集，A是以太坊地址集。在图7中，我们展示了我们收集的事实和用于检查可能的攻击的关系的概述。我们强调，我们的分析自动运行的基础上，我们提取的事实和规则，定义各种违规行为在后面的章节中描述。

4.1 重入

在EVM中，由于事务是独立执行的，因此重新进入问题只能在单个事务中发生。因此，要利用重入性，必须有对外部契约的调用，该调用直接或间接地调用对调用合约的重入回调。因此，我们首先在执行跟踪中查找call指令，同时跟踪当前正在执行的合约。

在执行调用时，可以通过检查堆栈上的值来检索要调用的合约的地址以及要发送的值[53]。使用这些信息，我们可以记录图7a中描述的call（a1，a2，p）事实。我们注意到，合约还可以使用create创建新合约，并使用它执行重入攻击[43]。因此，我们将此指令视为调用。使用这些，我们然后使用图7c所示的查询来检索潜在的恶意重入调用。

分析正确性。我们对重入呼叫的分析是合理的，但并不完整。由于EVM在单个线程中执行每个契约，因此重入调用必须来自递归调用。例如，假设A、B、C和D是函数，则可以使用调用路径（如A→B→C→A）生成重入调用。我们的工具搜索所有相互递归的调用；它通过使用草书数据日志规则支持任意长的调用路径，使分析听起来很合理。但是，我们无法评估重入调用是否恶意，这可能导致误报。

4.2 未处理异常

当Solidity编译契约时，发送Ether的方法（如send）被编译到EVM调用指令中。我们在图6中展示了这样一个调用及其指令的示例。如果传递给CALL的地址是地址，EVM将执行契约的代码，否则它将执行必要的指令将以太网传输到该地址。当EVM执行完毕后，如果调用成功，它会在堆栈上按1，否则按0。

为了检索有关调用结果的信息，我们可以检查调用指令，并在调用执行后使用堆栈上推送的值。通过检查跟踪的深度何时返回到执行调用指令时的值，可以很容易地找到调用执行的结束；我们将此信息保存为call_result(v, n)事实。需要考虑的一个重要边缘情况是对预编译契约的调用，这些契约通常由编译器调用，不需要检查它们的返回值，因为它们是计算结果，其中0可能是有效值，但可能导致误报。由于预编译的合同中有1到10之间的已知地址，我们选择不记录此类调用的call_result事实。

如图6b所示，EVM使用JUMPI指令执行条件跳转。在编写时，这是唯一可用于执行条件控制流的指令。因此，我们将JUMPI中用作条件的所有值标记为in\ U条件。然后，我们可以通过查找调用结果来检查未处理的异常，使用图7c所示的查询，调用结果不会影响条件。

分析正确性。我们为检查未处理的异常而执行的分析是完整的，但不可靠。所有在程序执行过程中失败的调用都会被记录下来，同时我们会积累有关执行的事实。然后，我们使用递归数据日志规则来检查调用结果是否直接或间接地用于条件中。如果调用结果用于某个条件，但该条件不足以阻止攻击，则可能会获得误报。然而，鉴于此漏洞最普遍的模式是根本不使用send的结果[51]，并且当使用结果时，通常在require或assert表达式中执行，我们假设此类误报应该非常罕见。

4.3 locked Ether

尽管合同中的资金被锁定有几个原因，但我们关注的是合约依赖于不再存在的外部合同的情况，因为这是对以太坊财务影响最大的模式[14]。当一个合约使用另一个合约作为库来代表它执行某些操作时，就会出现这种情况。要以这种方式使用协定，将使用DELEGATECALL指令而不是CALL，因为后者不保留调用数据，例如发送方或值。

下一个重要部分是EVM在试图调用一个不再存在的合约时的行为。当一个合约被破坏时，它本身并没有被完全删除，但是它的代码对于调用方来说不再是可访问的。当一个协定试图调用一个已被破坏的协定时，该调用是不可操作的，而不是失败的，这意味着下一条指令将被执行，并且该调用将被标记为成功。为了找到这样的模式，我们收集关于每个DELEGATECALL指令之前和之后程序计数器的所有值的数据日志事实。特别地，我们首先将执行调用的程序计数器值标记为call_entry（i_1∈N，a∈a）。然后，使用与未处理异常相同的方法，跳过调用的内容并标记调用返回的程序计数器值-call_exit（i_2∈N）。

如果被调用的契约不再存在，则i_1+1=i_2必须保持。因此，我们可以使用图7c所示的数据日志查询来检索被破坏的合同地址。

分析正确性。对于我们关注的锁定资金漏洞类别，我们用于检测锁定资金漏洞的方法是合理和完整的。所有易受攻击的合约都必须有DELEGATECALL指令。如果问题存在，并且调用契约确实已被破坏，那么它将始终导致no-op调用。我们的分析记录了所有这些调用，并在执行之前和之后系统地检查程序计数器，从而使分析健全和完整。

4.4 交易顺序依赖

检查事务顺序依赖性利用情况的第一个细节是，同一个块中必须至少包含同一合同的两个事务，这样的策略才能成功。此外，如[35]或[51]所示，利用事务排序依赖漏洞需要操纵契约的存储。

EVM只有一条从存储器SLOAD读取的指令和一条写入存储器SSTORE的指令。在EVM中，用于这两条指令的存储器的位置作为参数传递，称为存储器密钥。在调用指令时，此键在堆栈上可用。我们遍历所有契约的事务，每次遇到其中一条指令时，我们记录tx_ sload（b∈N，i∈N，k∈N）或tx_store（b∈N，i∈N，k∈N），其中b是块号，i是块中事务的索引，k是被访问的存储密钥。

检查事务顺序依赖性问题的规则的本质是寻找至少两个事务包含在同一块中的模式，其中一个事务在存储器中写入一个键，另一个事务读取同一个键。我们在图7c中显示了实际的规则。

分析正确性。我们检查事务顺序依赖关系的方法是合理的，但并不完整。根据我们使用的定义，要使合约具有事务顺序依赖性，它必须在同一块中有两个事务，这会影响存储中的同一密钥。我们检查所有这些情况，因此不可能存在假阴性。但是，如果要确定是否存在事务顺序依赖关系，则需要更多关于如何使用存储的知识，因此我们的方法可能会导致误报。

4.5 整数溢出

EVM是完全非类型化的，用256位字表示所有内容。因此，类型完全在编译级别处理，并且在任何执行跟踪中都没有关于原始类型的显式信息。

为了检查整数溢出，我们在两次传递中累积事实。在第一个过程中，我们尝试恢复堆栈上不同值的符号和大小。为此，我们使用了有关Solidity编译过程的已知不变量。首先，可以将SIGNEXTEND或SDIV等指令的结果中的任何值标记为使用is_signed（v）进行签名。此外，SIGNEXTEND是两个补码的常用符号扩展操作，它同时传递要扩展的值和值的位数。这允许检索有符号值的大小。我们假设任何没有显式标记为有符号的值都是无符号的。为了检索无符号值的大小，我们使用Solidity编译器的另一种行为。

为了解决EVM中缺少类型的问题，Solidity编译器插入AND指令将无符号整数“转换”为正确的值。例如，为了模拟uint8，编译器插入AND value 0xff。在“强制转换”的情况下，第二个操作数m的形式总是m=16^{n−1，n∈n，n=2}p，p∈[1,6]。我们使用这个观察值来标记相应类型的值：uintN，其中N=N×4。大小变量存储为size(v，n)事实。

在第二阶段，我们使用图7b中所示的inferred_signed（v)和inferred_size(v,n)规则来重新检索有关当前变量的信息。当无法推断出有关大小的信息时，我们将其近似为256位，即EVM字的大小。利用这些信息，我们计算所有算术指令（例如ADD、MUL）的期望值，以及EVM计算的实际结果，并将它们存储为数据日志事实。最后，我们使用图7c所示的查询来查找溢出的指令。

分析正确性。我们对整数溢出的分析既不合理也不完整。这些类型是通过使用启发式的编译器属性推断出来的，启发式应该适用于大多数情况，但可能会失败。例如，如果一个合约包含产生 AND value 0xff但值是uint32的代码，那么我们的类型推断算法会错误地推断这个变量是uint8。类型推断过程中的这种错误可能会导致误报和漏报。

但是，只有当开发人员使用与Solidity编译器生成的掩码类似的位操作时，才会出现这种类型的问题。我们发现这样的模式非常罕见，不会扭曲我们的数据，并在第5.5节中给出了可能遵循这种模式的合同数量的估计。

4.6 Unrestricted Action 无限制行动

无限制操作是一类广泛的漏洞，因为它可以包括在不被允许的情况下设置所有者、在不被允许的情况下销毁合同或执行任意代码的能力。由于我们的主要目标之一是检查易受攻击契约的利用情况，因此我们接近于以前的工作[32]给出的定义，并关注使用CALL的无限制以太传输、使用和SSTORE的无限制写入以及使用DELEGATECALL或CALLCODE的代码注入。

首先，我们需要提醒自己，与呼叫数据不同，呼叫方不能伪造。因此，一个主要的见解是，如果一个操作是受限的，取决于调用方是谁，那么受限操作之前应该有一个执行跟踪，根据调用方的不同，该跟踪会有条件地跳转。这对于自毁来说已经足够了，但是对于其他指令来说就不够了，因为它会标记一行，比如balances[msg.sender] = msg.value变得脆弱。为了对此进行建模，我们跟踪消息发送者是影响存储密钥还是要调用的地址。最后，对于代码注入，我们检查传递的数据是否影响DELEGATECALL或CALLCODE调用的地址。

分析正确性。我们对无限制行动的分析既不健全也不完整。在执行敏感指令之前，我们采用一种相对简单的方法来检查消息发送方是否影响某个条件。这可能导致误报，因为检查可能执行得不适当，例如在需要时不还原事务，使分析不可靠。此外，在某些用例中，允许任何发送方写入存储是可以接受的，但是我们的分析会标记为易受攻击，从而导致误报。我们将在第5.6节中进一步讨论这些影响。

5 Analysis of Individual Vulnerabilities

如第3节所述，所有脆弱合同中包含的Ether总量超过300万ETH，价值6亿美元。在本节中，我们逐一介绍每个漏洞的结果；我们的结果是使用第4节中描述的方法获得的；目的是显示这些资金中有多少实际处于风险之中。

方法论。对于每个漏洞，我们分两步进行分析。首先，我们直接或通过内部事务获取10200000块之前影响数据集中契约的所有事务的执行跟踪。然后我们运行我们的工具，自动找到有风险的Ether总量，并报告这个数字。这是我们用于稍后给出所有漏洞的总上限的量。在第二步中，我们手动分析处于风险中的合同，以获得关于漏洞利用的更多见解，并找到有趣的模式。由于手动分析所有合同都是不切实际的，因此对于每个漏洞，我们手动分析风险最高的合同，以便更好地理解这些漏洞背后的原因。然后，我们将有趣的发现作为简短的案例研究。

运行时性能。我们的分析在线性时间和内存中运行，与给定事务执行的指令数有关。指令的数量在不同的事务中差别很大，从几百条到几十万条，平均在100000条左右。我们的工具平均耗时不到10毫秒（stddev。20ms），最大事务的最大时间不超过2秒，这低于我们为单个事务设置的5秒超时时间。

5.1 RE: Re-Entrancy

截至[31,35,51]，共有4337份合同被标记为易再次进入，共有457073笔交易。在对第4节中描述的所有交易进行分析之后，我们发现总共有116个合约包含重入调用。为了寻找有风险的货币金额，我们计算了两个包含重入呼叫的交易合约之间发送的金额之和。利用再进入法开采的以太总量为6076 ETH，由于其价值超过1200000美元，因此可以认为是可开采的。

手动分析。我们根据损失的资金手动分析顶级合约，如图8所示。有趣的是，这三个潜在的开发项目中有一个涉及大量以太：5881 ETH，相当于1180000美元。最近一些关于再进入的研究发现，这个地址很容易受到攻击[43]。看来，作为Maker DAO[9]平台一部分的合同被合同的作者发现易受攻击，他们自己进行了攻击以确认风险[2]。

健全性检查。我们使用两个不同的契约来进行健全性检查。首先，我们来看dao攻击，这是最著名的重入攻击实例。我们的工具检测到以下重入模式：恶意帐户调用dao主帐户，dao主帐户调用奖励帐户，奖励帐户将奖励发送给恶意帐户，允许其执行对dao主帐户的重入调用。

作为另一个合理性检查，我们查看了一个名为SpankChain[6]的契约，该契约最近被重新进入攻击所承诺。我们确认，我们的方法成功地将此契约标记为再次进入攻击的受害者，并正确识别攻击者契约。

最后，我们注意到，我们的工具找到了Sereum[43]提出的所有重新进入模式，包括委托和基于创建的重新进入2。
｜ 2 https://github.com/uni-due-syssec/eth-reentrancy-attack-patterns

5.2 UE: Unhandled Exceptions

共有11427份合同被[31,35,51]标记为易受未处理异常的影响，总交易量超过340万笔，这比我们发现的再进入问题要大一个数量级。

我们发现总共有264个合同没有检查失败的调用，这大约占标记合同的2%。下一个目标是找出由于这些未处理的异常而导致的以太风险量的上限。我们将风险资金的上限定义为发生未处理异常时合同余额的最小值和未能发送的总金额。然后，我们对所有问题的上界求和，得到一个总的上界。这给我们提供了271.89以太未处理异常的风险。

手动分析。我们手动分析顶级合同，并在图9中总结它们的地址和风险金额。其中三份合同都有实体代码。我们确认，在所有情况下，问题都是由于误用了诸如send之类的低级别Solidity函数。

合同0x7011f3edc7fa43c81440f9f43a6458174113b162未能发送总计52.90以太，目前在撰写本报告时仍保留69.3以太余额。经过调查，我们发现该合同是一个废弃的传销[5]。该合同共有21个呼叫失败，都试图发送2.7以太，这似乎是在这个时间点上的传销奖励。不幸的是，这份合同的代码没有提供进一步的检查，但我们的结论是，有一个很高的可能性，一些用户在传销没有正确地获得他们的奖励，因为这个问题。

5.3 LE: Locked Ether

有7285份合同被[51]、[24]、[39]和[31]标记为易受攻击。这些合同总价值超过140万ETH，价值超过2亿美元。我们通过执行上一节中描述的分析来分析可能被锁定的合同的交易。我们的工具显示，实际上没有一个契约受到我们检查的模式的影响，即依赖于已被破坏的契约。我们注意到，我们的工具目前只涵盖了依赖于一个破坏的合同作为一个原因锁定以太和模式，如无界大规模操作尚未涵盖

Parity wallet。受Parity wallet（0x863df6bfa4469f3ead0be8f9f2aae51c91a907b4）错误影响的合约[14]未被我们分析的工具标记，因此不存在于我们的数据集中。由于这是最著名的locked Ether案例之一，因此我们将在受此bug影响的契约上测试我们的工具。为了找到契约，我们只需使用图7c中锁定以太的数据日志查询，并插入奇偶校验钱包地址的值作为参数a。我们对受奇偶校验错误影响的契约的结果确实与其他人在过去发现的结果相匹配[23]，合同地址为0x3bfc20f0b9afcace800d73d2191166ff16540258，已锁定306276以太。

5.4 TO: Transaction Order Dependency

共有1881份合同被[35]和[31]标记为易受交易顺序依赖性影响。我们对他们的3002304笔交易进行了第4节所述的分析，得到了总共54笔可能受交易订单依赖性影响的合同。为了估计风险以太的数量，我们将所有标记的交易期间发送的y以太包括内部交易）的总价值加起来，得出总共297.2以太存在交易订单依赖性风险。

手动分析。对于每个契约，我们都会找到一个块，在这个块中，事务顺序依赖关系可能发生在余额最高的地方，并在图10中用它们在发布时的余额报告top。我们手动调查了列出的合同，它们都有可用的源代码。我们确认，在所有合同中，用户有可能在一个块内读写同一个存储位置。我们进一步检查了0x3da71558a40f63b960196cc0679847ff50fad22b，这是一个名为drawchilddao的合同，发现读取内容非常方便用户检查余额，使得问题变得更为严重。

5.5 IO: Integer Overflow

有2472份合同被标记为易受整数溢出影响，总计超过120万笔交易。我们运行第4节中描述的方法来搜索实际发生的整数溢出。值得注意的是，对于整数溢出分析，我们依赖于Solidity编译器的属性。为了确保我们分析的契约是使用Solidity编译的，我们从Etherscan[7]获取了标记为易受整数溢出攻击的契约的所有可用源代码。在2492份合同中，有945份提供了源代码，而且所有的合同都是以稳定的格式编写的。

Effects of our formulation。如第4.5节所述，某些类型的位操纵可能导致我们的类型推断启发式失败。我们使用我们在这里收集的源代码来验证这可能会影响我们的分析。我们发现，位操作本身在稳固性方面已经相当罕见，在我们收集的2492份合同中，只有244份使用了任何类型的位操作。此外，大多数使用位操作的合约都将其作为位数组来操作变量，并且一次只能检索一个位。这样的模式并不影响我们的分析。我们发现只有33个区域使用0xFF或类似的值，这实际上会影响我们的分析。这约占可获得源代码的合同数量的1.3%。

我们发现总共有62个合约的事务可能发生了整数溢出。为了找出风险中的以太数量，我们分析了导致整数溢出的所有事务。我们通过对包含溢出的事务期间传入和传出的以太总量求和来近似该数量。我们发现总的以太危险是1842以太。这很可能是一个过近似值，但我们使用这个值作为上限

手动分析。我们进一步检查了我们获得的一些结果，以便更好地了解什么样的情况会导致溢出。我们发现溢出的一个常见原因是无符号值的下溢。我们将在下面的调查中重点介绍其中一个案例。

这个合约被我们的工具标记为未处理的异常和整数溢出。经检查，在1364860号地块，业主似乎试图降低费用，但未签字的费用价值溢出，成为一个巨大的数字。因为这个问题，合同当时试图发送大量以太。这会导致失败的调用，而这些调用恰好没有被检查，因此会为未处理的异常设置标志。

5.6 Unrestricted Action

共有5163份合同被[32，39，51]标记为易受无限制行动影响，共有3871770笔交易。我们使用第4.6节中描述的方法，发现总共有42份合同遭受了不受限制的行为，这些行为都是非限制性自毁行为，但在攻击发生时没有一份是有效的。

我们公式的效果。如第4.6节所述，这种分析是不合理的，这意味着我们需要谨慎对待假阳性。合约可以对消息发送方进行检查，检查结果不正确，可以被利用，但不能被标记为不正确。虽然我们假设这是一个边缘的情况，但不能完全排除。然而，为这种检查提供一种自动化方法需要了解程序员的意图，例如通过规范，这超出了本工作的范围。因此，我们决定更详细地检查数据集中的契约，以便更好地了解利用程度。

手动分析。以太的工具标志着可利用的合同，而不是简单的脆弱的合同。因此，期望这些合同更有可能被利用，并关注这些合同进行我们的手动分析。我们获取以太合同的所有历史余额，并检索在任何时间点持有的最大金额，发现这些总数等于4921以太。然而，我们发现4867以太属于48个不同的合同，字节码具有完全相同的字节码，都有相同的交易模式，这是我们在下面的调查中描述的。

它与本合同共享相同的字节码、创建者和交易模式。合同由0x15f889d2469d1de0e0699632d8d448f2178a7创建，从以肯接收以太，交换，发送到0xd1bf1706306c7c667c67fb5c1f76cc76cc7637685bd。我们找不到关于这些地址的进一步信息。我们反编译合同，以了解合同是如何可利用的，并发现在他们持有资金的几个块中，利用合同就像发送一笔交易与转移资金的地址作为论证。这是一个非常危险的情况，但因为以太通常在一分钟内被发送到另一个地址，攻击者需要非常积极主动地使用高级工具来利用合同。这很好地说明了合同如何可以被利用，但在实践中几乎没有机会被利用。

理智性检查。作为理智检查，除了我们的测试套件，我们还使用了一个最著名的不受限制操作的实例之一：地址0x863df6bfa4469f3版0ed8f9f2aae51c91a907b4的破坏奇偶钱包库合同。我们分析了交易，并成功地在交易0x05f71e1b中找到了一个不受限制的存储指令，它被用于控制钱包。

5.7 Summary

我们总结了我们的所有发现，包括最初标记的合同数量、危险的以太数量以及图11中实际开采的数量。Contracts Explosed列表示标记为Explosed的合同数，%Contracts Explosed是该数字相对于标记为vulnerable的合同数的百分比。开采的Ether列显示了可能开采的Ether的最大数量，下一列显示了该数量与风险总量的百分比。总行只记录一次标记有多个漏洞的合同。

总的来说，我们发现被利用的合同数量是不可忽略的，在我们的研究中涉及的6个漏洞中，约有2%到4%的脆弱合同被利用了4个。然而，值得注意的是，开采的Ether百分比要低一个数量级，最多有0.4%的Ether用于再进入。这表明开发的合同通常价值较低。我们将在第7节进一步阐述这个论点。

6 限制

在本节中，我们将介绍我们系统的不同限制，并描述我们如何尝试减轻这些限制。

稳健性vs完整性。对于像这样的大多数工具，我们面临着稳健性和完整性之间的权衡。只要有可能，我们就选择稳健性而不是完整性——我们的分析中有六分之三是稳健性的。当我们不能有一个健全的分析，我们很小心，只遗漏了案件，不太可能产生许多假阴性。换句话说，我们尽可能减少假阴性的数量，即使这意味着增加假阳性的数量。实际上，我们系统的主要目标是为我们提供一个可能被利用的Ether量的上限，这使得假阴性是不受欢迎的。此外，我们手动检查标记为利用的高价值合同，误报不会对最终结果产生重要影响。作为这种权衡的一个例子，对于重新进入，我们标记任何使用重新进入调用调用的合同，以及在此过程中丢失的资金。然而，在某些情况下，这可能是一种预期行为，资金可能已转移到属于同一实体的地址。

数据集。我们只在数据集中包含的契约上运行我们的工具，这意味着我们可能遗漏了一些实际发生的攻击。事实上，我们没有任何合约受到奇偶钱包漏洞的影响，也没有合约受到数据集中DAO黑客攻击的影响。然而，本文的主要目标之一是量化分析工具发现的漏洞在实践中被利用的比例，我们目前的方法允许我们做到这一点。

其他类型的攻击。我们的工具和分析并未涵盖对智能合约的所有现有攻击。例如，有针对ERC-20代币的攻击[42]，还有一些其他类型的DoS攻击，如钱包欺诈[24]。此外，一些检测到的“漏洞”可能是蜜罐[50]的结果，但我们的工具不包括此类情况。所有虽然这将是有趣的，也涵盖这种情况下，我们必须作出决定的范围，该工具。因此，我们将重点放在文献中最常见的漏洞上，我们假设这些漏洞代表了这些漏洞的常见程度。

7 讨论

即使考虑到我们系统的局限性，很明显智能合约的利用率远远低于预期。在本节中，我们将介绍一些影响智能合约实际应用的因素。

我们认为，报告的脆弱合同数量与利用的合同数量之间存在差异的一个主要原因是Ether在合同中的分布。事实上，在我们数据集中的23327份合同中，只有大约2000份含有以太，而且大多数合同的余额低于1Ether。图12a显示了数据集中包含Ether的合同的平衡分布。此外，排名前10位的合约约占总合约的95%。我们在图12b中显示了Ether在含有10个Ether以上的合同中的累积分布。这表明，只要顶级合约无法交割，实际处于风险中的Ether总量就不会接近“脆弱”Ether的上限.

为了确保这一事实推广到整个以太坊区块链，而不仅仅是我们的数据集，我们获取所有现有合约的余额。总共有15459193份合同。其中，只有463538份合同有非零余额，仅占所有合同的3%。余额非零的合同中，前10名、前100名和前1000名分别占Ether总量的54%、92%和99%。这表明，我们的数据集与整个以太坊区块链的趋势相同：只有极少量的合约持有大部分财富。

高价值合同的人工检查。我们决定手动检查前6个合同，在撰写本文时的余额方面，这些合同被数据集中的任何工具标记为易受攻击。我们把重点放在前6位，因为这恰好是目前持有超过10万ETH的合同数量。这些合同总计持有1695240 ETH，占我们数据集中所有合同目前持有的2037521 ETH总数的83%。我们在这里给出了调查结果的概述，在附录a中给出了更深入的版本。

Etherscan上没有此合同的源代码。然而，我们发现它是Ethereum基金会的多重签名钱包（1），它的源代码在GITHUB（3）上是可用的。我们检查代码，发现所有调用都要求消息的发送者是所有者。这本身就足以防止任何重新进入者调用，因为恶意合同必须是所有者，这是没有意义的。此外，尽管本文中使用的Oyente版本报告了重新进入，但该工具的较新版本不再报告此漏洞。因此，我们有把握地得出结论，重新进入问题是一个错误的警报。

我们检查了其他5份合同中的4份。地址为0x07ee55aa48bb72dcc6e9d78256648910de513eca的合同是我们唯一找不到任何信息的合同。名单中的第二、第三和第五个合同也是多签名钱包，利用这些合同将再次要求多数所有者是恶意的。例如，要锁定Ether，所有者必须同意添加足够的额外所有者，以便所有者上的所有环路都会导致气体耗尽异常。地址为0xbf4ed7b27f1d666546e30d74d50d173d20bca754的合同称为撤回合同[4]。我们没有发现任何具体的问题，但它确实使用了一个委托模式来解释宙斯标记的锁定以太漏洞.

我们在附录a中对高价值合同进行了彻底调查。总体而言，我们可以分析的图13中的所有合同似乎都非常安全，标记的漏洞绝对不可利用。尽管我们在第8节中介绍了一些非常罕见的情况，即高Ether余额的合同被盗，但这些仍然是例外。到目前为止，我们提供的事实帮助我们确认以太坊区块链上面临风险的以太数量远没有声称的那么接近[24，31]。

8 相关工作

近年来，在以太坊上发现了一些主要的智能合约漏洞[45]。这些攻击已经被分析和分类[11]，许多工具和技术已经出现，以防止此类攻击[21，26]。最近的文献也显示了对以太坊的攻击是如何随着时间的推移而演变的[55]。在本节中，我们将首先提供有关两个最突出的历史开发的详细信息，然后介绍旨在提高智能合约安全性的现有工作。

8.1 大规模漏洞

The DAO漏洞。DAO漏洞[45]是以太坊区块链上最著名的漏洞之一。攻击者利用了合同的重入漏洞[11]，该漏洞允许耗尽合同资金。攻击者可以在DAO余额减少之前调用函数以重新进入的方式提取资金，从而使资金的自由外流成为可能。共排出350多万Ether。考虑到攻击的严重性，以太坊社区最终同意了硬分叉。

Parity wallet bug。Parity wallet漏洞[14]是以太坊区块链上的另一个突出漏洞，导致价值2.8亿美元的以太坊被冻结在Parity wallet账户上。这是由于一个非常简单的漏洞：Parity wallet使用的库契约没有正确初始化，任何人都可能破坏它。一旦库被毁，任何对平价钱包的调用都将失败，从而有效地锁定了所有资金。

8.2分析和验证智能合约

为了防止此类攻击并使智能合约总体上更加安全，已经做出了很多努力。我们将在这里介绍一些在文献中介绍的工具和技术，并在相关时描述它们与我们的工作的比较。

分析工具大致可以分为两类：静态分析工具和动态分析工具。使用术语“静态”相当宽松，静态分析工具可以定义为不需要部署智能合约就可以捕获bug或漏洞的工具。运行时分析工具试图通过执行部署的契约来检测这些。我们的工具属于第二类。

静态分析工具。静态分析工具一直是研究的重点。这是可以理解的，因为避免已部署契约中的漏洞是多么重要。这些工具大多通过分析字节码或契约的高级代码以及检查已知的易受攻击的模式来工作。

Oyente[35]是最早开发的分析智能合约的工具之一。它使用符号执行结合Z3 SMT解算器[20]来检查以下漏洞：事务排序依赖性、重进入性和未处理的异常。

ZEUS[31]是一个静态分析工具，它在Solidity智能合约上工作，而不是在字节码上工作，这使得它适合于帮助开发工作，而不是分析部署的合约，Solidity代码通常不可用。ZEUS将XACML样式的[46]策略和Solidity契约代码转换为LLVM位代码[33]，并在其上使用约束的Horn子句[13，36]来检查策略是否得到遵守。

Securify[51]是一个静态分析工具，用于检查智能合约的EVM字节码的安全属性。它将安全属性编码为用数据日志（如[52]域特定语言）编写的模式，并检查符合性或违反性。Securify从契约中推断语义事实，并通过查询推断的事实来解释安全模式以检查它们是否违反或符合。这种方法与我们的方法有很多相似之处，使用数据日志来表示漏洞模式。主要区别在于Securify处理字节码，而我们的工具处理执行跟踪。

MadMax[24]与Securify有相似之处，因为它还将智能合约的属性编码到数据日志中，但它关注与gas相关的漏洞。它是检测“无界质量操作”的第一个工具，其中循环受到动态属性（如用户数）的限制，从而导致合同总是在通过一定数量的用户时耗尽天然气。MadMax构建在Vandal[15]实现的反编译器之上，性能足以在10小时内分析以太坊区块链的所有合约。

其他一些静态分析工具也已经开发出来，其中一些工具，如SmartCheck[48]，非常通用，包含了许多类型的漏洞，而另一些工具则更具有领域特定性，如Osiris[49]专注于整数过流，Maian[39]专注于无限制操作，Gasper[17]专注于代价高昂的气体模式。最近，ETHBMC[22]的设计还支持契约间关系、加密哈希函数和memcopy风格的操作。

最后，在正式验证智能合约方面也做出了一些努力。[28]是这方面的第一个尝试，并使用Lem[38]定义了EVM，这允许生成定理证明者（如Coq[12]）的定义。[25]提出了EVM字节码的完整小步语义，并使用F*证明助手对其进行了形式化[47]。在[27]中也做了类似的工作，使用K框架[44]给出了EVM的可执行形式规范。VerX[41]也是最近的一项工作，它允许用户编写智能合约的属性，这些属性将由该工具正式验证。

动态分析工具。虽然动态分析工具的研究比静态分析工具少，但近年来出现了一些工作。

这一行的第一个工作是ContractFuzzer[30]。正如它的名字所示，它使用模糊技术来发现智能合约中的漏洞，并能够检测到各种各样的漏洞，如重入、锁定的以太或未处理的异常。该工具生成合同的输入，并使用检测过的EVM检查是否触发了某些漏洞。这种模糊化方法的一个重要限制是它需要契约的应用程序二进制接口，这通常不适用于部署在以太坊主网络上的契约。

Sereum[43]专注于在运行时通过在修改过的Go-Ethereum客户端中集成检查来检测重入攻击。该工具分析运行时跟踪，并使用污点分析来确保在重入调用中不使用访问契约存储的变量。尽管与我们的工具（也在运行时分析跟踪）有一些相似之处，但Sereum侧重于重入性，而我们的工具更通用，特别是因为漏洞模式可以很容易地用数据日志表示。

teEther[32]也可以在运行时工作，但与之前的工作不同，因为它不试图保护契约，而是主动为契约寻找漏洞。它首先分析契约字节码以寻找关键的执行路径。关键路径是可能导致资金损失的执行路径，例如通过向任意地址汇款或被任何人破坏。为了找到这些路径，它使用了一种接近Oyente[35]的方法，结合符号执行和Z3来解决路径约束。

TXSPECTOR[54]是在本文的第一版之后不久发表的，它使用了一种与我们非常相似的方法来检测再次进入、未经检查的呼叫和自杀合同。它们还利用数据日志方法来检测漏洞，但首先将事务跟踪转换为流图，而不是直接向数据日志数据库添加有关跟踪的事实。虽然这确实增加了表达能力，但它使分析变得更加复杂，导致某些事务的分析超时。因此，我们相信他们的方法可以补充我们的方法，并用于消除我们方法的潜在误报。

总结。静态分析工具通常用于检测易受攻击的契约，而动态分析工具则用于检测可被攻击的契约。唯一的例外是Sereum，它检测使用重入的合同。据我们所知，我们的工作是第一次尝试检测利用各种漏洞的合同。这与其他工作基本上是正交的，可以通过帮助理解野外正在发生的开发类型来支持分析工具的开发工作

9 总结

本文调查了最近6个学术项目所报道的23327份弱势合同。我们提出了一个基于数据日志的公式，用于对EVM执行跟踪执行分析，并使用它来分析这些契约执行的总计超过2000万个事务。我们发现，在23327份合同中，最多有463份受到了侵害，但最多有8487 ETH（170万美元），或者说只有0.27%的300万ETH（6亿美元）的潜在风险被发现。最后，我们发现大部分Ether仅由少数合同持有，并且报告的这些漏洞要么是误报，要么在实践中不可利用，从而为我们的结果提供了合理的解释。

参考文献

[1] Contract with 11,901,464 ether? What does it do?https://www.reddit.com/r/ethereum/comments/3gi0qn/contract_with_11901464_ether_what_does_it_do/, 2015. [Online; accessed 13-October2020].
[2] Critical ether token wrapper vulnerability - eth tokenssalvaged from potential attacks. https://www.reddit.com/r/MakerDAO/comments/4niu10/critical_ether_token_wrapper_vulnerability_eth/, 2016.[Online; accessed 13-October-2020].
[3] Source code of the Ethereum Foundation Multisigwallet. https://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol, 2017. [Online;accessed 13-October-2020].
[4] The DAO Refunds. https://theethereum.wiki/w/index.php/The_DAO_Refunds, 2017. [Online; accessed 13-October-2020].
[5] What’s become of the ethereumpyramid? https://www.reddit.com/r/ethtrader/comments/7eimrs/whats_become_of_the_ethereumpyramid/, 2017.[Online; accessed 13-October-2020].
[6] We Got Spanked: What We Know So Far.https://medium.com/spankchain/we-gotspanked-what-we-know-so-far-d5ed3a0f38fe,2018. [Online; accessed 13-October-2020].
[7] Etherscan — Ethereum (ETH) Blockchain Explorer.https://etherscan.io, 2019. [Online; accessed 13-October-2020].
[8] golem — Computing Power. Shared. https://golem.network/, 2019. [Online; accessed 13-October-2020].
[9] MakerDAO. https://makerdao.com/en/, 2019. [Online; accessed 13-October-2020].
[10] Official Go implementation of the Ethereum protocol. https://github.com/ethereum/go-ethereum,2019. [Online; accessed 13-October-2020].
[11] Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli.A survey of attacks on ethereum smart contracts sok.In Proceedings of the 6th International Conference onPrinciples of Security and Trust - Volume 10204, 2017.
[12] Bruno Barras, Samuel Boutin, Cristina Cornes, JudicaëlCourant, Jean-Christophe Filliatre, Eduardo Gimenez,Hugo Herbelin, Gerard Huet, Cesar Munoz, ChetanMurthy, et al. The Coq proof assistant reference manual:Version 6.1. PhD thesis, Inria, 1997.
[13] Nikolaj Bjørner, Ken Mcmillan, Andrey Rybalchenko,and Technische Universität München. Program verification as satisfiability modulo theories. In In SMT,2012.
[14] Lorenz Breidenbach, Phil Daian, Ari Juels, andEmin Gün Sirer. An In-Depth Look at the Parity Multisig Bug. http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/, 2017. [Online; accessed 13-October-2020].
[15] Lexi Brent, Anton Jurisevic, Michael Kong, Eric Liu,François Gauthier, Vincent Gramoli, Ralph Holz, andBernhard Scholz. Vandal: A scalable security analysisframework for smart contracts. CoRR, abs/1809.03981,2018.
[16] Vitalik Buterin. A next-generation smart contract anddecentralized application platform. Ethereum, (January),2014.
[17] Ting Chen, Xiaoqi Li, Xiapu Luo, and Xiaosong Zhang.Under-optimized smart contracts devour your money.SANER 2017 - 24th IEEE International Conference onSoftware Analysis, Evolution, and Reengineering, 2017.
[18] ConsenSys. Mythril Classic. https://github.com/ConsenSys/mythril-classic, 2019. [Online; accessed 13-October-2020].
[19] Chris Dannen. Introducing Ethereum and Solidity: Foundations of Cryptocurrency and Blockchain Programming for Beginners. Apress, Berkely, CA, USA, 1stedition, 2017.
[20] Leonardo De Moura and Nikolaj Bjørner. Z3: An efficient smt solver. In International conference on Toolsand Algorithms for the Construction and Analysis ofSystems. Springer, 2008.
[21] Ardit Dika. Ethereum Smart Contracts : Security Vulnerabilities and Security Tools. (December), 2017.
[22] Joel Frank, Cornelius Aschermann, and Thorsten Holz.ETHBMC: A bounded model checker for smart contracts. In 29th USENIX Security Symposium, August2020.
[23] Max Galka. Multisig wallets affected by the Parity wallet bug. https://github.com/elementusio/parity-wallet-freeze, 2017. [Online; accessed13-October-2020].
[24] Neville Grech, Michael Kong, Anton Jurisevic, LexiBrent, Bernhard Scholz, and Yannis Smaragdakis. Madmax: Surviving out-of-gas conditions in ethereum smartcontracts. Proceedings of the ACM on ProgrammingLanguages, (OOPSLA), October 2018.
[25] Ilya Grishchenko, Matteo Maffei, and Clara Schneidewind. A semantic framework for the security analysisof ethereum smart contracts. In Principles of Securityand Trust, Cham, 2018.
[26] Dominik Harz and William Knottenbelt. Towards SaferSmart Contracts: A Survey of Languages and Verification Methods. arXiv preprint arXiv:1809.09805, 2018.
[27] E. Hildenbrandt, M. Saxena, N. Rodrigues, X. Zhu,P. Daian, D. Guth, B. Moore, D. Park, Y. Zhang, A. Stefanescu, and G. Rosu. Kevm: A complete formal semantics of the ethereum virtual machine. In 2018 IEEE 31stComputer Security Foundations Symposium, 2018.
[28] Yoichi Hirai. Defining the Ethereum Virtual Machine forInteractive Theorem Provers. In Workshop on TrustedSmart Contracts, 2017.[29] Neil Immerman. Descriptive complexity. Graduate textsin computer science. Springer, 1999.
[30] Bo Jiang, Ye Liu, and W. K. Chan. Contractfuzzer:Fuzzing smart contracts for vulnerability detection. InProceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, 2018.
[31] Sukrit Kalra, Seep Goel, Mohan Dhawan, and SubodhSharma. ZEUS: Analyzing Safety of Smart Contracts.In Proceedings of 25th Annual Network & DistributedSystem Security Symposium, 2018.
[32] Johannes Krupp and Christian Rossow. teether: Gnawing at ethereum to automatically exploit smart contracts.In 27th USENIX Security Symposium, August 2018.
[33] Chris Lattner and Vikram Adve. Llvm: A compilationframework for lifelong program analysis & transformation. In Proceedings of the international symposium on Code generation and optimization: feedbackdirected and runtime optimization. IEEE Computer Society, 2004.
[34] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, and Prateek Saxena. Oyente Benchmarks. https://oyente.tech/benchmarks/, 2016. [Online; accessed 13-October2020].
[35] Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena,and Aquinas Hobor. Making smart contracts smarter. InProceedings of the 2016 ACM SIGSAC Conference onComputer and Communications Security, 2016.
[36] Kenneth L McMillan. Interpolants and symbolic modelchecking. In International Workshop on Verification,Model Checking, and Abstract Interpretation. Springer,2007.
[37] Muhammad Izhar Mehar, Charles Louis Shier, Alana Giambattista, Elgar Gong, Gabrielle Fletcher, Ryan Sanayhie, Henry M Kim, and Marek Laskowski. Understanding a revolutionary and flawed grand experiment inblockchain: The dao attack. Journal of Cases on Information Technology (JCIT), 21(1), 2019.
[38] Dominic P Mulligan, Scott Owens, Kathryn E Gray, TomRidge, and Peter Sewell. Lem: reusable engineeringof real-world semantics. In ACM SIGPLAN Notices,volume 49. ACM, 2014.
[39] Ivica Nikolic, Aashish Kolluri, Ilya Sergey, Prateek Sax- ´ena, and Aquinas Hobor. Finding the greedy, prodigal,and suicidal contracts at scale. In Proceedings of the34th Annual Computer Security Applications Conference, 2018.
[40] Daniel Perez and Benjamin Livshits. Broken metre:Attacking resource metering in EVM. In Proceedingsof 27th Annual Network & Distributed System SecuritySymposium, 2020.
[41] A. Permenev, D. Dimitrov, P. Tsankov, D. DrachslerCohen, and M. Vechev. Verx: Safety verification ofsmart contracts. In 2020 IEEE Symposium on Securityand Privacy, 2020.
[42] R. Rahimian, S. Eskandari, and J. Clark. Resolving themultiple withdrawal attack on erc20 tokens. In 2019IEEE European Symposium on Security and PrivacyWorkshops, June 2019.
[43] Michael Rodler, Wenting Li, Ghassan O. Karame, andLucas Davi. Sereum: Protecting existing smart contractsagainst re-entrancy attacks. In Proceedings of 26th Annual Network & Distributed System Security Symposium,February 2019.
[44] Grigore Ro¸su and Traian Florin ¸Serbanu¸t ˘ a. An overview ˘of the K semantic framework. Journal of Logic andAlgebraic Programming, 79(6), 2010.
[45] Us Securities and Exchange Commission. Report ofInvestigation Pursuant to Section 21(a) of the SecuritiesExchange Act of 1934: The DAO. Technical report,2017.
[46] Remon Sinnema and Erik Wilde. eXtensible Access Control Markup Language (XACML) XML Media Type. https://tools.ietf.org/html/rfc7061,2013. [Online; accessed 13-October-2020].
[47] Nikhil Swamy, Juan Chen, Cédric Fournet, Pierre-YvesStrub, Karthikeyan Bhargavan, and Jean Yang. Securedistributed programming with value-dependent types.SIGPLAN Not., 46(9):266–278, September 2011.
[48] S. Tikhomirov, E. Voskresenskaya, I. Ivanitskiy,R. Takhaviev, E. Marchenko, and Y. Alexandrov.Smartcheck: Static analysis of ethereum smart contracts. In 2018 IEEE/ACM 1st International Workshop on Emerging Trends in Software Engineering forBlockchain, May 2018.
[49] Christof Ferreira Torres, Julian Schütte, and Radu State.Osiris: Hunting for integer bugs in ethereum smart contracts. In Proceedings of the 34th Annual ComputerSecurity Applications Conference, 2018.
[50] Christof Ferreira Torres, Mathis Steichen, and RaduState. The art of the scam: Demystifying honeypotsin ethereum smart contracts. In 28th USENIX SecuritySymposium, August 2019.
[51] Petar Tsankov, Andrei Dan, Dana Drachsler-Cohen,Arthur Gervais, Florian Bünzli, and Martin Vechev. Securify: Practical security analysis of smart contracts. InProceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security, 2018.
[52] Jeffrey D Ullman. Principles of database systems. Galgotia publications, 1984.
[53] Gavin Wood. Ethereum yellow paper. http://gavwood.com/paper.pdf, 2014. [Online; accessed 13-October-2020].
[54] Mengya Zhang, Xiaokuan Zhang, Yinqian Zhang, andZhiqiang Lin. TXSPECTOR: Uncovering attacks inethereum from transactions. In 29th USENIX SecuritySymposium, August 2020.
[55] Shunfan Zhou, Zhemin Yang, Jie Xiang, Yinzhi Cao,Zhemin Yang, and Yuan Zhang. An ever-evolvinggame: Evaluation of real-world attacks and defensesin ethereum ecosystem. In 29th USENIX Security Symposium, August 2020.