【论文翻译】2019 Bug Searching in Blockchain Systems

摘要：

随着以太坊平台上智能合约的疯狂发展，其市场价值也随之攀升。2016年，DAO重入攻击导致加密货币损失近5000万美元，人们对此感到震惊。由于智能合约中存在着大量的资金流动，其安全性受到了研究者的广泛关注。在本文中，我们调查了几种常见的智能合约漏洞，并分析了它们可能出现的情况以及如何利用这些漏洞。此外，本文还综述了近年来针对以太坊平台的智能合约漏洞检测工具。我们发现这些工具在软件漏洞检测技术上有相似的原型。此外，针对以太坊等公共分发系统的特点，我们提出了这些软件漏洞检测技术面临的新挑战。

关键词：
区块链、智能合约、以太坊、形式验证、模糊测试、符号执行
Blockchain, Smart Contract, Ethereum, FormalVerification, Fuzzing, Symbolic Execution

1 介绍

分散加密货币在学术界和工业界都获得了巨大的关注。源自这些系统的新兴新技术是区块链，一种按顺序排列的账本系统。系统具有分布性、不可逆性、不可伪造性和可追踪性。以太坊[1]作为最易访问的区块链平台，通过称为EVM的底层在线虚拟机支持不同情景中的分布式应用程序，EVM是完成智能合约执行的基础层。智能合约[2][3]是区块链系统上执行的代码和数据（也称为状态）的集合。图灵完备允许我们编写预定义的规则。智能合约非常适合需要可靠安全性、不可逆持久性和高度信任的场景，如数字资产、在线投票、赌博游戏、保险、财产管理和金融应用。

然而，智能合约存在许多漏洞[4][5][6][7][8][9][10]，高财务状况带来更高的互动风险。与传统的分布式应用平台不同，以太坊等智能合约平台允许任何人加入。这种高度的开放性使得EVM环境非常脆弱。此外，一些漏洞只能在以太坊的一些独特的新功能（如时间戳设计、gas设置和回退功能）中被利用。例如，DAO[11]利用了各种有充分记录的重入攻击，导致价值超过5000万美元的以太网被盗。因此，以太坊智能合约的安全问题备受关注。

在漏洞检测领域，研究人员开发了许多工具来发现程序中的漏洞。我们关注三种工具，包括模糊测试[12]、形式验证和符号执行，它们已经发现了许多漏洞。然而，对于这些工具在智能合约中的应用，目前还处于研究的起步阶段。模糊化的本质是为程序生成输入，并试图根据执行程序的结果发现漏洞[12]。模糊化最大的挑战来自于这样一个事实：它以随机行为测试程序。形式验证是一种基于逻辑推理的方法，它试图证明或反驳程序的正确性。研究人员必须严格证明他们的结论，这样目标程序才能被完全信任或放弃。我们介绍的最后一个工具是符号执行，它将程序中的变量视为符号值。它将程序中的每个条件视为一个约束，并试图找到一个可能的解决方案以及执行路径。符号执行的主要挑战是循环或数组导致的路径爆炸。当这些工具被应用到智能合约中时，研究者必须找出具体的方法来将这些工具应用到智能合约中。细节将在下面讨论。

在本文中，我们调查了一些常见的漏洞对EVM及其触发机制。本文还介绍了在这个新平台上开发的一些软件漏洞检测工具及其工作流程和特点。此外，针对EVM平台的一些新特性，我们也对这些软件漏洞检测工具提出了一些新的挑战。

2 EVM概述

A. EVM Model

以太坊虚拟机（EVM）为在分布式以太坊平台上执行智能合约提供了一个实用的环境。它是指部署、编译和执行的一整套逻辑过程[1]。用户通过基于事务的状态转换，可以根据预定义的规则自动执行合同[2]。为了实现状态机的转换，智能合约可以看作是一种共享状态。全局共享状态由称为account的小单元组成，它们可以通过消息传递相互作用。每个帐户都关联一个状态和一个20字节的地址作为标识符。有两种不同类型的账户：

• 外部拥有的帐户，由没有任何关联代码的私钥控制。
• 合同账户，由相应的合同代码控制，用于设置行动和操作。

外部拥有的帐户通过在私钥下创建和签署事务将消息发送到另一个外部拥有的帐户或合同帐户。在两个外部拥有的帐户之间传输的消息只是一个简单的值传递。但是，从外部拥有的帐户到合同帐户的消息将激活合同帐户中的代码，执行相应的操作（例如传输令牌、记录存储、生成新合同、铸造新令牌、计算值等）。与外部拥有的账户不同，合同账户不能自己发起交易。相反，合约账户只有在收到交易后才触发交易。EVM模型如图1所示。

这两种类型的账户都有四个组成部分：

• •Nonce：它表示外部拥有的账户发送的交易号，也表示合同账户创建的合同号。
• •Balance：表示地址的余额，以Wei为主，其中1 Ether=10^{18} Wei。
• •根：根表示Merkle Patricia树的哈希值，该树对每个帐户中存储内容的叠加哈希进行编码。
• •CodeHash：专门用于合同账户，智能合同的代码保存为CodeHash。 对于外部拥有的帐户，此字段为空字符串。

B. Features in EVM

a）gas费用：交易产生的每一个确定的计算都需要支付一定数量的成本。在每一次具体的计算中，煤气都是用来计量成本的单位。

相应地，gas价格是每种gas的价值，用“gwei”衡量，其中1 gwei=1000000000 wei。对于每笔交易，发送方需要设置两个参数，包括gas限制和gas价格。总金额代表发送方为执行交易愿意支付的上限。总金额按天然气限额和天然气价格限额计算，如下所示。
Gas Limit × Gas Price = Total amount

在交易结束时，任何未使用的gas都将退还给发送方进行赎回。如果没有足够的气体来执行交易，交易将被视为无效。在这种情况下，当所有更改的状态返回到初始状态时，进程终止。由于系统仍在进行gas耗尽前的计算，因此理论上不会有gas返回发送器。取而代之的是，执行过程中使用的所有费用都会作为奖励发给已经努力计算和核实交易的矿工。

b） Solidity中的回退函数：Solidity中的fallback 函数是唯一未命名的函数。只有当没有其他函数与指定的函数标识符匹配时，才会自动执行[2]。同时，当契约的地址接收到纯以太而没有消息时，可以调用函数。fallback 函数没有参数或不返回任何内容。更具体地说，当我们通过函数address.send(ether)在没有任何可读数据的情况下，合同将自动执行fallback功能，使状态转换继续进行。要使send输出为真，必须将fallback函数标记为payable。

由于send函数总是调用fallback，因此很容易受到像DAO[11]这样的恶意攻击者的攻击。特别是在分红的场景中，发送操作部署在一系列帐户上，如果存在至少一个恶意帐户持有无限循环的回退函数，则会导致所有发送进程在gas用完的地方失败。为了解决这个问题，send函数将限制的2300气体设置为最大值，即使气体足够。因此，除了在fallback函数中登录等操作外，很难保持整个系统的活跃.

c）** 时间戳**：时间戳，作为块和事务的一种标识符，以Unix时间的形式包含在每个块头中。此外，不可逆时间戳避免了对手伪造方块。基于时间戳，区块链系统确认每个区块是顺序连接的。时间戳证明了没有人可以篡改的事件序列。时间戳可以看作是区块链中公证人的角色，对公众参与者来说是可信的。

3 脆弱性

在本节中，我们将讨论智能合约中的三个常见漏洞，并给出攻击示例。

A 重入

递归是传统编程语言中广泛使用的一种逻辑处理方法，但这种操作很可能成为稳定性方面的一个弱点

图2 Ebank合同示出了公共银行合同的实施。任何用户都可以将Ether存入EBank，合同会记录每个帐户的Ether。在这种情况下，当合同提取存款（(withdraw(address to, uint256 amount))）时，它会确保账户有足够的余额（(require (balances[msg.sender] >amount)），并且银行有足够的资金用于取款。如果满足上述两个条件，合同将向用户发送Ether(to.call.value(amount)())并更改相应值（balances[msg.sender] -= amount)）。

在C语言和C++语言中，图2EBAR合同中的代码可以正确运行。然而，由于以太坊本身的语法，这段代码在其智能合约中可能会受到攻击。在图2 Ebank合同中，合同使用调用值（）发送给用户。区别于函数send（）和transfer（），call.value()()将所有剩余的gas提供给外部调用（fallback函数）。如果在进行以太事务时目标地址是合约地址，则默认情况下会调用合约的回退功能。

为了说明攻击者如何利用此漏洞，我们在图2中设计了一个攻击契约。在startAttack（）中，契约首先将deposit() 指定金额的代币存入银行，通过 withdraw()取一个代币。因为银行合同使用call函数将以太发送到目标，这将调用目标合同的fallback函数，该函数调用 withdraw().。用户余额在Ether被转移后被修改，攻击者帐户上的余额保持不变，攻击者可以随时从银行取出Ether。因此，bank和attack的两个契约进入递归状态，直到bank中的Ether被发送给攻击者或攻击者停止契约为止。

B Gasless 无气发送漏洞

EVM通常将gas极限设定为2300，善于计算的矿工可以利用精细的合约结构结合回退函数来耗尽gas。这将导致一个错误的运行合同，以便矿工可以从中获得利润或实现其他目标。

有一个名为KingOfTheEtherThrone [13] 的游戏，通过将以太发送到一个名为KotEt的智能合约来玩这个游戏（如图3所示）。想要成为国王的玩家必须向现在的国王支付一些Ether ，再加上一小部分费用给KotET合同。然后，国王将从他为王位支付的价格和其他玩家为成为新国王支付的价格之间的差额中获得利润。

假设一个玩家想成为国王，他想让KotET送一定数量的钱(msg.value) 。调用KotET的fallback函数，它将检查消息值大于上一个特大号设置的引号。如果它小于上一个国王设置的报价（即拍卖失败），它将被放弃。相反，玩家将获得王位并成为新国王。

这份合同看起来不错，但会有一个gasless send 错误。什么时候king.send(profit) 未能执行（gas不足以执行回退（）），王位将由本合同持有。

C 时间戳

在Solidity语言中，它定义了许多块状态变量[14]，如时间戳、随机种子和块编号。由于这些状态变量写在每个块的头部，恶意矿工可能会修改它并从中获利。这些块状态变量可以使Ether沿着不同的程序路径流动。这里我们使用时间戳来说明恶意矿工是如何利用这种漏洞的。

块时间戳传统上用于各种应用，例如用于随机数的函数、一段时间的锁定契约以及基于时变状态的各种条件状态。矿工有能力稍微调整时间戳，如果区块时间戳在智能合约中被误用，可能会被证明是相当危险的。

块.时间戳（或现在）可能被矿工操纵，如果他们有动机这么做的话。我们建立了一个容易被矿工开采的简单合同（图4）。

在图4中，这个合同是一个简单的彩票。每个区块有一笔交易，下注1 Ether，有机会赢得合同中的全部余额。这里的假设是块.时间戳分布均匀。如果是这样的话，中彩票的几率是1%

不过，据我们所知，矿工们可以根据自己的意愿调整时间戳。在这种特殊情况下，如果合同中有足够的Ether，挖掘区块的矿工将有动力选择一个区块块.时间戳（或现在）到100，时间戳为0。这样做，他们可以赢得Ether和块奖励在这个合同。

4 工具

A 模糊测试

Fuzzing[12]是一种随机生成输入以检查测试程序的技术。在大多数情况下，模糊化往往会使测试程序崩溃。此外，当它崩溃时，我们可以检查崩溃是否是一个bug。图5显示了模糊化的典型过程。在第一次执行时，模糊需要对原始输入进行变异。然后，对原始输入进行变异并生成新的输入，这将检查测试程序。在检查之后，模糊将检查新输入是否有趣。感兴趣的输入被保存为种子，这些种子将被选择作为输入。如果测试程序崩溃，我们必须验证崩溃是否是一个bug。

在蒋的工作[15]中，他们创建了一个新的模糊器，名为ContractFuzzer，这是一个新的模糊器来模糊以太坊智能合约。ContractFuzzer是一种基于传统的模糊化和静态分析相结合的漏洞检测工具。图6显示了ContractFuzzer如何对智能合约进行模糊化。它提供了一个离线EVM工具，可以监控智能合约的执行情况，以便进行后续分析。ContractFuzzer首先对合同数据集中收集的智能合同的ABI接口和字节码进行分析。然后，ABI函数参数和签名将为ABI特征分析。ContractFuzzer根据这两种分析生成在线模糊的输入种子，最后通过分析执行日志的漏洞开始进行模糊测试和安全检测。

B 形式化验证

在硬件和软件系统的上下文中，形式验证是使用形式化的数学方法证明或驳斥系统中涉及某种形式规范或属性的预期算法的正确性的行为。

与模糊等动态检测方法相比，对于以太坊来说，形式化验证等静态方法不需要模拟执行环境，在漏洞分析中提供了更好的精度和误报率[16]。一般来说，自动形式验证可以分为三种主要类型：1）自动定理证明，2）模型检查和3）抽象解释。对于智能合约平台，模型检查是合适的，因为智能合约的规模较小。

受处理JavaScript的过程[17]的启发，Bhargavan的团队[18]概述了一个使用正式验证来验证以太坊智能合约的框架。在将Solidity代码和EVM字节码翻译并反编译成名为F的函数式编程语言之后，他们将通过验证F语言结果中这两个代码的等价性来确定契约中是否存在漏洞（详细信息请参见图7）。

然而，这种方法仍有很大的局限性。Bhargavan在他们的评估部分还提到，这种基于语言的过程不能支持许多稳定的语言特性。它只能翻译和打字检查他们收集的396份合同中的46份https://etherscan.io。

ZEUS[19]在翻译智能合约语言方面做了更多的工作。ZEUS由三部分组成：a）策略生成器，b）源代码转换器，和c）验证器。策略生成器对智能合约代码执行静态分析，从策略条件中提取谓词，然后将断言插入合约代码。与[18]不同的是，ZEUS并不直接处理稳定的源代码，而是通过源代码转换器将其转换成LLVM字节码。最后，验证器将检查策略生成器之前插入的断言，然后确定冲突。图8是一个例子来解释ZEUS如何在智能合约上工作。首先，ZEUS将实体语义学形式化为抽象语言。对于这些代码中的条件策略，ZEUS创建了一个XACML样式的[20]五元组策略规范来描述这些策略并将其转换为assert语句。LLVM转换器然后帮助宙斯将这些固态代码转换成LLVM的字节码，最后用CHC[21]符号模型检查器验证代码。

C 符号执行

符号执行是一种基于形式验证的技术。它分析程序以测试是否可以违反特定属性。由于符号执行的性质，这种技术可以同时探索多条路径，从而对校验属性有很强的保证。符号执行的关键思想是基于符号值而不是具体的输入值来分析程序。

在符号执行中，由引擎执行的执行部分[22]维护每个探索的控制流路径。该引擎包含两个部分：1）一阶布尔公式描述路径分支中包含的条件；2）符号内存存储将变量映射到符号表达式。分支执行会在模型检查器验证是否存在任何冲突时更新公式。

Luu[16]基于符号执行技术创建了一个静态分析工具OYENTE，帮助开发人员避免编写智能合约时的漏洞。图9是OYENTE的概述。从EVM中提取智能合约字节码后，CFGBuilder为每个智能合约绘制主控制流图（CFG）。然后，Explorer对这些CFG执行符号执行，并根据路径约束使用Z3解算器[23]来完成CFG块输入条件。Core Analysis 对整理好的CFG进行漏洞分析，最后验证将验证分析结果。

D 语言转换

语言翻译是软件漏洞检测的常用支持工具。一般来说，它可以改变一些难读懂或不受欢迎的语言转换成一些著名的编程语言。对于漏洞分析的静态方法，如果您需要分析可执行文件，一般做法是将其转换为我们熟悉的高级语言，并使用反编译工具[24]供研究人员进一步处理。这种反编译是将汇编语言翻译成高级语言，如C、C++等。同样，解体可以帮助研究人员解决二进制文件的问题，本质上，它也是一种翻译技术。这种翻译技术不仅可以应用于不同层次的编程语言，而且有助于实现对等语言的转换，如C++到java（25）。这种翻译并非毫无意义。它可以把一些难以阅读的语言（如机器代码）变成有许多支持者支持的流行语言，这样程序就更容易理解，研究人员可以根据语言使用一些复杂的分析技术。

作为一种新技术诞生的新语言，智能合同的编程语言环境远不如其他成熟语言如C++等复杂。因此，许多研究团队选择将智能合约的语言翻译成他们想要的形式，然后使用现有的复杂软件分析技术来检测智能合约中的漏洞问题。Bhargavan的团队[18]将以太坊和智能合约翻译成F*，这是一种为程序验证而设计的函数式编程语言，用于分析平台运行时的安全性和功能正确性。类似地，在ZEUS的[19]工作中，他们实现了一个工具来将固态代码转换成LLVM字节码，并提出了一个基于LLVM字节码的模型检测方案。利用LLVM字节码可以帮助他们的分析工作利用LLVM平台上强大的行业工具的支持。Brent等人[26]使用了反编译方法。他们对从以太坊提取的智能合约字节码进行反编译和分析，得到可读的低级助记符，这些助记符用程序计数器地址进行注释，并帮助Vandal[26]生成这些智能合约的控制流图。

5 挑战

正如我们在本文中提到的，软件漏洞检测方法已经很好地应用于智能合约平台。然而，由于智能合约与传统软件程序之间的诸多差异，以及这些漏洞检测技术的瓶颈，我们在智能合约中的漏洞检测仍然面临着挑战。

A 模糊测试

由于智能合约的并发性和区块链的分布式设计，智能合约平台上的模糊化与传统意义上的模糊化有许多不同之处。在软件漏洞挖掘中，每当模糊化导致目标程序崩溃一次时，我们就认为它是一个潜在的漏洞（需要工具或手动验证）。在智能合约中，我们前面提到的漏洞几乎不可能使EVM崩溃，即使单个合约的崩溃不会影响整个EVM。因此，正如我们在ContractFuzzer中提到的，在智能合约中使用模糊化时，我们还需要记录每个模糊化执行结果的结果，并执行额外的分析来验证漏洞。ContractFuzzer使用预定义的测试oracle来解决这个问题。

例如，对于一个没有气体的问题，ContractFuzzer将重复执行单个合同，并检查结果分析中send（）函数的剩余gas值是否为零。但是，某些单合约执行的结果并未显示需要特殊情况（例如重入攻击，需要两个智能合约之间的交互调用）的漏洞。在[15]中，对于重入攻击，他们为call.value(). 在这种情况下，如果一个合同被模糊k次，ContractFuzzer将执行6（23）k次模糊，然后分析结果。对于这种再入攻击，我们可以使场景设计更加复杂，覆盖更多的场景，但同时，模糊化的执行时间和分析时间也会伴随着复杂性的增长。因此，如何在场景复杂度和漏洞模式覆盖率之间找到平衡点是模糊化方法面临的一个挑战。

同样，软件模糊测试中出现的一些问题也存在于智能合约中。程序中的健全性检查（如幻数或校验和条件检查）一直是模糊化的一个挑战，它的存在也增加了模糊化实验的误报率。由于模糊化生成的输入具有高度的随机性，模糊化很难通过条件检查，例如“Str==”HelloWorld“”，从而导致某些路径变得困难或无法访问。在智能合约中，这个问题变得更加严重。由于许多智能合约将外部属性作为验证的一部分（如时间戳），因此如果此时的环境不满足合约的要求（日期限制已过），则会导致这样的事实。然后，合同可能无法签订，合同中隐藏的漏洞可能无法检测到。

B 语言转换

由于目前还没有为智能合约平台设计的相关模型或工具，无论是符号执行还是形式验证都需要语言翻译来将不熟悉的语言转换成熟悉的语言。

例如，在符号执行中，其核心模型“SMT求解器”有许多现有工具（如Z3、SMT-ART等）可用，但这些工具仅支持特定语言，如C++、java或LLVM字节码。这意味着，如果我们想使用这些工具，我们必须首先将solidity编写的合同代码转换为与这些工具对应的语言。然而，由于solidity语言的一些独特特性，将其转换为另一种语言通常需要对某些指令进行额外的操作。例如，solidity中的调用可以分为三种类型：internal、external和call（）。大多数编程语言中都存在内部调用和外部调用，但是call（）可以调用其他约定中的方法，在其他编程语言中很少见，在翻译时需要特殊处理。形式验证也面临同样的问题。通常，当我们使用模型检查来指导应用程序的开发时，我们需要使用抽象语言或范例将需求转换为规范。通过模型检测器的检测后，可以将规范转换为应用代码。当我们需要验证应用程序是否有问题时，我们需要首先将代码转换为规范，但此时，转换可能会遇到许多问题。Bhargavan的团队[18]希望将稳定的代码转换成F，并将EVM中的字节码反编译成F，然后验证它们的等价性。然而，在评估部分，他们也提到，F*不支持许多稳固的句法特征，导致396份合同中只有46份被翻译。

一般来说，符号执行和形式化验证在软件漏洞挖掘技术中都得到了很好的发展。对于智能合约的新平台来说，应用这项技术的挑战在于如何将稳固性完全转化为所需的语言。

C 分析

无论是模糊化、符号执行还是形式化，它们在挖掘漏洞时最终都会使用静态分析方法。在[15]中，针对提出的7种不同的脆弱性，他们设计了相应的预言器，在分析模糊执行结果时判断契约是否脆弱。例如，对于gasless问题，如果在分析期间合同中call（）函数的gas值为0，则认为合同存在gasless问题。这里，合约中call（）的剩余gas数是否为0将被视为检测此漏洞的约束。这样的限制使得分析简单且易于自动化，但也带来了误报和漏报。

高度定制的静态分析方法也给可伸缩性带来了限制。现有的分析针对的是已经研究过的一些漏洞，因此这些方法无法识别其他未被发现或出现在未被注意的场景中的漏洞。当然，一个好的约束可以帮助我们覆盖同一漏洞的多种表现形式，但我们是否识别出该漏洞的所有模式取决于该漏洞本身的触发逻辑。

简而言之，如何设计一个能够捕获大多数漏洞模式的约束是这些静态分析方法面临的一个挑战。

6 总结

在本文中，我们调查了以太坊智能合约的几个漏洞，如重入攻击、无气体发送和时间戳漏洞。然后我们给出了它们的触发逻辑。简要介绍了软件脆弱性检测中常用的模糊化、符号执行、形式化验证和语言翻译方法，并概述了将这些方法应用于智能合约脆弱性检测的一些工具。

这些软件漏洞检测工具在智能合约漏洞检测方面表现出色，但同时，对于这样一个新的平台，智能合约的新特性也对这些工具的应用提出了挑战。对于不同的工具，我们分析了以太坊新特性带来的限制，并提出了可能限制其发展的挑战。

参考

[1] “Ethereum white paper,” 2019. [Online]. Available:https://www.ethereum.org
[2] “Introduction to smart contracts,” 2019. [Online]. Available: https://solidity.readthedocs.io/en/v0.4.24/introduction-to-smartcontracts.html
[3] N. Atzei, M. Bartoletti, and T. Cimoli, “A survey of attacks on ethereumsmart contracts sok,” in Proceedings of the 6th International Conferenceon Principles of Security and Trust - Volume 10204. Springer-VerlagNew York, Inc., 2017, pp. 164–186.
[4] A. Juels, A. Kosba, and E. Shi, “The ring of gyges: Investigating thefuture of criminal smart contracts,” in Proceedings of the 2016 ACMSIGSAC Conference on Computer and Communications Security, ser.CCS ’16. New York, NY, USA: ACM, 2016, pp. 283–295. [Online].Available: http://doi.acm.org/10.1145/2976749.2978362
[5] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Bunzli, and ¨M. Vechev, “Securify: Practical security analysis of smart contracts,”in Proceedings of the 2018 ACM SIGSAC Conference on Computerand Communications Security, ser. CCS ’18. ACM, 2018, pp. 67–82.[Online]. Available: http://doi.acm.org/10.1145/3243734.3243780
[6] I. Nikolic, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, ´“Finding the greedy, prodigal, and suicidal contracts at scale,” inProceedings of the 34th Annual Computer Security ApplicationsConference, ser. ACSAC ’18, 2018, pp. 653–663. [Online]. Available:http://doi.acm.org/10.1145/3274694.3274743
[7] P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, andM. Vechev, “Securify: Practical security analysis of smart contracts,” inProceedings of the 2018 ACM SIGSAC Conference on Computer andCommunications Security. ACM, 2018, pp. 67–82.
[8] C. Liu, H. Liu, Z. Cao, Z. Chen, B. Chen, and B. Roscoe, “Reguard:finding reentrancy bugs in smart contracts,” in Proceedings of the40th International Conference on Software Engineering: CompanionProceeedings. ACM, 2018, pp. 65–68.
[9] E. Hildenbrandt, M. Saxena, N. Rodrigues, X. Zhu, P. Daian, D. Guth,B. Moore, D. Park, Y. Zhang, A. Stefanescu, and G. Rosu, “Kevm: Acomplete formal semantics of the ethereum virtual machine,” in 2018IEEE 31st Computer Security Foundations Symposium (CSF), July 2018,pp. 204–217.
[10] F. Zhang, E. Cecchetti, K. Croman, A. Juels, and E. Shi, “Town crier:An authenticated data feed for smart contracts,” in Proceedings of the2016 ACM SIGSAC Conference on Computer and CommunicationsSecurity, ser. CCS ’16. New York, NY, USA: ACM, 2016, pp. 270–282.[Online]. Available: http://doi.acm.org/10.1145/2976749.2978326
[11] (2016) analysis of the dao exploit. [Online]. Available:http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/
[12] B. P. Miller, L. Fredriksen, and B. So, “An empirical study of thereliability of unix utilities,” Communications of the ACM, vol. 33, no. 12,pp. 32–44, 1990.
[13] “King of the ether throne smart contract,” 2016. [Online]. Available: https://solidity.readthedocs.io/en/v0.4.24/introductionto-smart-contracts.html
[14] “Units and globally available variables,” 2016. [Online]. Available:https://solidity.rtfd.io/en/develop/unitsandglobalvariables.html
[15] B. Jiang, Y. Liu, and W. Chan, “Contractfuzzer: Fuzzing smart contractsfor vulnerability detection,” in Proceedings of the 33rd ACM/IEEEInternational Conference on Automated Software Engineering. ACM,2018, pp. 259–269.
[16] L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Makingsmart contracts smarter,” in Proceedings of the 2016 ACM SIGSACConference on Computer and Communications Security, ser. CCS ’16.New York, NY, USA: ACM, 2016, pp. 254–269. [Online]. Available:http://doi.acm.org/10.1145/2976749.2978309
[17] N. Swamy, C. Fournet, A. Rastogi, K. Bhargavan, J. Chen, P.-Y. Strub,and G. Bierman, “Gradual typing embedded securely in javascript,” inACM SIGPLAN Notices, vol. 49, no. 1. ACM, 2014, pp. 425–437.
[18] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi,G. Gonthier, N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote,N. Swamy et al., “Formal verification of smart contracts: Short paper,”in Proceedings of the 2016 ACM Workshop on Programming Languagesand Analysis for Security. ACM, 2016, pp. 91–96.
[19] S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: Analyzing safetyof smart contracts,” in 25th Annual Network and Distributed SystemSecurity Symposium (NDSS18), 2018.
[20] (2013) extensible access control markup language (xacml) xml mediatype. [Online]. Available: https://tools.ietf.org/html/rfc7061
[21] K. L. McMillan, “Interpolants and symbolic model checking,” inProceedings of the 8th International Conference on Verification,Model Checking, and Abstract Interpretation, ser. VMCAI’07. Berlin,Heidelberg: Springer-Verlag, 2007, pp. 89–90. [Online]. Available:http://dl.acm.org/citation.cfm?id=1763048.1763057
[22] R. Baldoni, E. Coppa, D. C. Delia, C. Demetrescu, and I. Finocchi,“A survey of symbolic execution techniques,” ACM Computing Surveys(CSUR), vol. 51, no. 3, p. 50, 2018.
[23] (2018) z3. [Online]. Available: https://github.com/Z3Prover/z3
[24] (2015) ida. [Online]. Available: https://www.hex-rays.com/products/ida/
[25] (2019) the most accurate and reliable source code converters. [Online].Available: https://www.tangiblesoftwaresolutions.com/index.html
[26] L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli, R. Holz,and B. Scholz, “Vandal: A scalable security analysis framework for smartcontracts,” arXiv preprint arXiv:1809.03981, 2018.