[论文02]ZEUS Analyzing Safety of Smart Contracts

最新推荐文章于 2024-04-09 19:58:18 发布

念书就像坐牢

最新推荐文章于 2024-04-09 19:58:18 发布

阅读量1k

点赞数 1

分类专栏： # 论文文章标签：区块链

本文链接：https://blog.csdn.net/weixin_41787421/article/details/110315711

版权

论文专栏收录该内容

3 篇文章 0 订阅

订阅专栏

ZEUS是一个结合抽象解释和符号模型检查的智能合约验证框架，它首次建立了Solidity到LLVM字节码的转换器，并能自动插入策略断言。通过Seahorn等工具进行验证，ZEUS在安全性和效率上优于其他工具，如Oyente。其重点在于分析合约的安全属性，确保状态可达性，并提供策略独立于主程序的验证。

摘要由CSDN通过智能技术生成

ZEUS: Analyzing Safety of Smart Contracts

0.ABSTRACT

1. introdution

贡献 :happy:

分类已知或者之前发现但为研究漏洞，报告可能会带来的金钱损失。
❓本文结合抽象解释和符号模型检测，提出了一种用于验证智能合约的实体性执行语义的形式抽象
ZEUS: 抽象解释和符号模型检查的框架，首次建立solidity到llvm字节码的转换器，并且通过已给策略自动插桩。建立谓词提取工具，使多方交互变的容易
检验结果，但未调查这些错误的实际可利用性。也是仅挑选几个有代表性的合约来特定安全标准。
ZEUS表现比Oyente好。
在Fabric上进行验证，我们还通过使用 SMACK 进行验证，来演示将Zeus应用于所选 verifier 的简易性。

3. MOTIVATION

4. ZEUS

静态分析智能合约源码，并在正确的程序点插入assert语句。（如何确定正确的程序点，规则是什么？）
将插了policy assertions的智能合约源码转换为LLVM字节码。（怎么保证无损？什么policy？）
最后，ZEUS调用verifier来确定断言违规，表示 policy violation 。（什么verifier）

策略：状态可达性问题。是否存在从开始状态时可达的，而该状态下没有此策略？正式的说，当N|=φ时，策略φ保持在程序P上，其中N是程序P作为状态转移有限自动机的形式表示

抽象语言中的Assert(EXP)与高级语言(如C)中的Assert语句具有不同的语义

1. 文章符号定义

T ----变量类型（参数l是post的一部分）

S -----程序方法

2. 安全性

将智能合约转换成带assertion的抽象语言最终转换为llvm字节码，三步：

转换成抽象语言不影响语义行为
加入的assert不会改变方法的安全性
减少状态可达性的问题
solidity程序上下文的状态可达性定义

5. IMPLEMENTATION

solidty → LLVM： C++

符号模型检查： Seahorn

6. ENVALUATION

7. RELATED WORK

Smart contract bug detection

本文将ZENUS和Oytente，Bhargevan等人的工作，以及后文提及的Why3 进行了对比和比较（mythril 和securify 呢？），Delmolin等人记录了开发合约的几种类型的错误，建议减少这些错误的方法，并倡导编写智能合约的最佳实践（这句话是不是为了来凑数的）。与之相反，ZEUS提出了一个形式化验证框架，用户可以基于该框架验证智能合约的正确性与公平性。
Policy specification

Naccio , PoET/Pslang 和Polymer 描述了策略规范。像前人做的工作一样，zeus可以确保验证策略独立于主程序。对逻辑分离会使安全策略更容易理解，验证和修改。XACML 定义了一个声明性细粒度（什么是声明性的）、基于属性的访问控制策略语言，启发了Zeus用于策略声明的语法。

8. 结论

提出了zeus框架来分析智能合约安全属性
```
 2. zeus利用抽象解释器和符号执行检查，以及CHC来快速验证条件。
```
1. 建立了第一个solidity到LLVM字节码的转换器，根据安全策略来自动插入验证条件（插桩？不是说分离的吗）
  
  调用函数接口，建立审计系统

补充知识：

声明性的（declarative）

Hyperledger Fabric 、 Corda 和以太坊的对比

博客原文地址：https://www.cnblogs.com/X-knight/p/10252229.html

三种不同的框架

我们从 Hyperledger Fabric、R3 Corda和以太坊的白皮书中可以看到，三种框架在可能的应用领域上分别具有完全不同的想法。

Fabric[1] 和 Corda[2] 的开发是受具体用例驱动的。其中，Corda 的用例来自于金融服务行业，这也是 Corda 可见的主要应用领域。Fabric 设计提供一种模块化、可扩展的架构，可用于从银行、医疗保健到供应链等各个行业。

以太坊表现出完全独立于任何特定的应用领域 [3]。然而与 Fabric 相比，以太坊并未突出模块化，而重在为各种交易和应用提供一个通用平台。

对等端的参与

在传统的集中式数据存储中，只有一个实体（即所有者）可以保留账本这一底层数据库的副本。因此，该实体控制了哪些数据可以提供，以及允许其它实体提供什么数据。DLT 的出现，从根本上改变了分布式数据存储的方式，实现了多个实体拥有底层数据库副本，自然也支持每个拷贝做出贡献。参与分布式数据存储的所有实体，形成一种由所谓“节点”或“对等端”构成的网络。由于数据是分布式存储的，因此难以确保所有节点对一些“共同事实”（例如，账本的正确性）达成一致。因为一个节点所做的更改，必须传播到网络中的所有其它的对等节点上。达成共同事实的结果，称之为节点间的“共识”(consensus)，将在下文介绍。

针对是否参与达成共识，存在两种操作模式，即无授权（permissionless）和有授权（permissioned）。如果参与无需授权，那么任何人都可以参与网络。授权模式适用于作为公共区块链的以太坊。另一方面，如果参与需授权，那么参与者是经过预先选择的，并且仅限于这些参与者访问网络。Fabric 和 Corda 都属于后者。选择无授权或有授权的参与模式，将对达成共识具有深远的影响。

共识以太坊

使用以太坊，无论参与者是否参与了某个特定的交易（Transaction），所有参与者必须就全部已发生交易的顺序达成共识。交易的顺序对账本的一致状态至关重要。如果无法建立明确的交易顺序，那么可能会出现双重支付（double-spends）问题，即两笔并行交易将同一枚货币转账给了不同的收款人，使其凭空受益。由于网络所涉及的各方可能是互不信任的，并且是匿名的，因此必须采用共识机制来保护账本免受双重支付欺诈，或者心怀鬼胎参与者的影响。在目前的以太坊实现中，这种共识机制的建立是使用基于工作证明（PoW，Proof of Work）方案的挖矿。所有参与者必须认同一个共同账本，并且可以访问账本中所有的记录条目。其结果是，PoW 会对交易的处理性能产生不利的影响 [5]。尽管记录是匿名的，但是存储在账本中的数据仍然可供所有参与者访问。因此对于有更高隐私度需求的应用而言，这种机制存在问题。

不同于以太坊，Fabric 和 Corda 给出了更精细的共识设计，不再仅仅局限于基于 PoW 或其它衍生物的挖矿。由于 Fabric 和 Corda 运行在许可模式下，因此可为记录提供更细粒度的访问控制，从而增强了隐私。此外，由于只有参与交易的各方才必须要达成共识，因此在性能上有所提高。

Fabric

Fabric 提供了范围很广的共识理解，涵盖从将交易提交网络到将交易记录到账本的整个交易流程 [6]。此外，节点在达成共识的过程中承担了不同的角色和任务。这完全不同于以太坊，其中参与达成共识的节点具有相同的角色和任务。

Fabric 将节点区分为客户节点（Client）、对等节点（Peer）和订购节点（Orderer）[7]。客户节点代表最终用户，创建并调用交易。他们与对等节点和订购节点沟通。对等节点维护账本，并接收订购节点订购的更新消息，以向账本提交新的交易。背书节点（Endorser）是一类特殊的对等节点，任务是通过检查自身是否满足一些必要的和充分的条件（例如提供所需的签名），对交易提供背书。订购节点在客户节点和对等节点间提供了通信通道，用于广播包含交易的消息。特别是对于共识，这些通道确保了所有已连接的对等节点按照完全相同的逻辑顺序传递完全相同的消息。

但是问题会出现在这一点上。如果其中涉及多个互不信任的订购节点，在传递消息时可能会出现错误。因此，必须引入一致性算法，使得在出现故障（例如，消息顺序不一致）时仍然可以达成一致，从而使分布式账本的复制过程支持容错。Fabric 所采用的算法是“可插入的”，即可以根据特定应用的需求而使用各种算法。例如，为了处理如上所述的随机或恶意复制错误，我们可以使用拜占庭式容错（BFT）的一种变体算法。此外，通道划分了消息流，这意味着客户节点只能看到它们连接通道中的消息及相关联的交易，而不知道其它通道的情况。通过这种方式，对交易的访问将仅限于相关方。其结果是只能在交易层面达成共识，而不能像以太坊那样在账本层面达成共识。

上面介绍了节点，现在介绍交易流的上下文。客户节点向已连接的背书节点发送交易，启动对账本的更新。所有背书节点都必须就提出的交易达成一致，因此需要根据更新所建议的账本达成某种共识。客户节点依次收集所有背书节点的批准，然后将经批准的交易发送给已连接的订购节点，由这些订购节点再次达成共识。随后，交易将被转发给持有分类账的对等节点，以提交交易。

我们在此不再做进一步的详细介绍。很显然，Fabric 支持对共识做细粒度的控制，并提供对交易的受限访问，这提高了性能的可扩展性和隐私性。

Corda

类似于 Fabric，Corda 的共识也是在交易层面达成的，仅涉及交易的各方。交易取决于共识是满足交易合法性（validity），还是交易唯一性（uniqueness）[8]。交易合法性通过运行与交易相关联的智能合约代码（智能合约将在下文给出详细介绍），检查需要的所有签名，并确保所引用的任何交易也是有效的。交易唯一性涉及交易的输入状态。具体而言，必须确保有疑问的交易是所有输入状态的唯一消费者。换句话说，不存在任何消耗同一状态的其它交易。这是为了避免产生双重支付。实现交易唯一性的共识，是在称为“公证人”（Notary）[9] 的参与节点中达成的。其中使用的算法和 Fabric 一样，是“可插拔的”。因此，我们同样可以使用 BFT 算法。

智能合约

在第一次接触“智能合约”（smart contract）一词时，人们难免会产生相当大的误解，将其理解为某种智能地表达了某人利益的合约。尽管合约的本质仍然存在含糊不清之处，但是在直观上它似乎应与法律有关。也就是说，我们所关注的合约在本意上并非智能的，至少目前仍尚未由人工智能驱动，也尚未在其中编入具有法律约束力的义务和权利。Clark 及其同事 [10] 在给出“智能合约”这一有用术语时，强调指出了该术语的两种不同的常用方式。第一种方式是智能合约代码（smart contract code），另一种方式是智能法律合约（smart legal contracts）。本文着重介绍两者间的区别。

智能合约代码就是用某种编程语言编写的软件。它作为一个软件代理，或是代表其中某一方，目的是履行某些义务、行使某些权利，并以自动的方式控制分布式账本中的资产。因此，智能合约通过代码执行模拟，或模拟现实世界中合约逻辑，承担了分布式账本的任务和责任，尽管其合法性可能尚未明确。

所有的 DLT 都支持以智能合约代码的形式履行智能合约。代码可以使用 Go、Java for Fabric [11]、Solidity[12] for Ethereum，以及 Java/Kotlin for Corda [13] 编写。在 Fabirc 中使用了术语“链码”（chaincode），以此作为智能合约的同义词。举例说明，Corda 为确保交易的有效性，会提醒读者在共识机制中使用智能合同代码。一方面，Fabric 和 Ethereum 之间存在着显著的差异。另一方面，这是与 Corda 使用另一种“智能合约”方式相关。

在 Corda 中，智能合约不仅可以包含代码，还允许包含法律行文（Legal Prose）。因此，上述智能法律合约是法律行文，其制定方式可以通过智能合同代码来表达和实施。其背后的基本原理，是赋予植根于相关法律行为的代码以合法性。这种结构称为“Ricardian 合约”[14]。这清晰地表明，Corda 是设计用于金融服务行业这一受严格监管的环境。而 Fabric 和 Ethereum 都不具备此功能。

代币

另一个值得注意的区别，是以太坊提供一种称为“以太”的内置加密货币。以太用于向帮助通过挖矿达成共识的节点支付奖励，并支付交易费用。因此，去中心化应用（DApps）可以基于支持货币交易的以太坊构建。此外，通过部署符合预定义标准的智能合约，可以创建为用例定制的数字代币 [15]。使用这种方式，人们可以定义自己的货币或资产。

Fabric 和 Corda 不支持通过挖矿达成共识，因此不需要内建的加密货币。但是使用 Fabric，也可以开发本地货币，或是带有区块链代码的数字代币 [16]。使用 Corda，不建议创建数字货币或代币 [17]。

总结：定制平台对比通用平台

一方面是 Fabric 和以太坊。它们在不同的方面上具有非常大的灵活性。以太坊是一种强大的智能合约引擎，基本上可作为任何类型应用的通用平台。但是，以太坊的无授权操作模式及全面透明度，是以牺牲性能可扩展性和隐私性为代价的。Fabric 采用有授权的操作模式，即使用 BFT 算法和细粒度访问控制解决了性能可扩展性和隐私问题。此外，Fabric 的模块化体系结构使其可以针对众多应用进行定制。我们可将 Fabric 比做一个多功能的工具箱。

另一方面是 Corda。它专门设计为一种用于金融服务行业的 DLT。应注意的是，Corda 通过增加法律行文的智能合同，考虑了受高度管制的环境。

显然，与 Fabric 相比，专注于金融服务交易使 Corda 得以简化其架构设计。因此，Corda 可以提供更多的开箱即可用体验。不过，Fabric 的模块化支持定制类似于 Corda 的功能集。一些工作力图将 Corda 纳入 Hyperledger 项目。因此，不能将 Corda 视为 Fabric 的竞争对手，而更多的是一种补充。