一种用于智能合约的可认证数据馈送

发表于 更新于

本文介绍一篇来自2016年CCS会议的论文，其题目是《Town Crier: An Authenticated Data Feed for Smart Contracts》，主要实现了一个用于智能合约的认证数据源，其DOI信息在这里。

摘要

智能合约是在区块链上自动执行的程序。它们所设想的主要适用途径（例如金融工具）要求它们从区块链以外的地方消费数据（例如股票报价）。因此，支持广泛的数据请求的可信数据馈送（data feed）对智能合同生态系统至关重要。

本文提出了一种叫做Town Crier (后文简称TC)的可认证数据馈送。TC充当了智能合约和现有web站点之间的桥梁，这些站点已经普遍信任非区块链应用程序。它结合了一个区块链前端和一个可信的硬件后端，以获取支持HTTPS的站点，并向依赖它的智能合约提供可认证源的数据。

TC还支持加密。它允许使用加密参数的私有数据请求。此外，在一个TC执行智能合约逻辑的实例中，系统允许安全使用用户凭证来获取具有访问控制的在线数据源。

文章描述了TC的设计原则和架构，并阐明了使用Intel最近提出的Software Guard Extensions (SGX)来为以太坊（Ethereum）智能合约系统提供数据的实现。文章在形式上建立了TC模型，并对其基本的安全特性进行了定义和证明。同时，计划尽快推出TC，作为一个在线公共服务。

简介

智能合约由Szabo于1994年首先提出。诸如比特币的密码学货币为智能合约提供了关键技术：通过程序直接控制资金，通过公平的、去中心化的协商一致机制实现自动代码执行。最近推出的以太坊支持图灵完备（Turing-complete）的代码，从而充分表达自我执行的去中心化智能合约——这是朝着研究人员和支持者的愿景迈出的一大步。

然而，正如Szabo的例子所显示的，智能合约最引人注目的应用（比如金融工具）还需要访问有关真实世界的事件和数据。数据馈送的目标是满足这个需求。简单来说，数据馈送是在区块链上的合约，它能够为其它合约提供数据请求服务。现在，一些以太坊上的数据馈送提供来自可信站点的数据，但是不能保证正确地将这些数据传递给他们的操作者（通常是个人或小型实体）之外。使用HTTPS连接到一个可信赖的网站似乎提供了一个解决方案，但是智能合约缺乏网络访问，HTTPS也没有对数据进行数字签名来进行带外（out-of-band）验证。

文章提出了一种叫做Town Crier (TC)的系统，可以通过为智能合约提供可验证的数据馈送，来解决这个问题。TC就像一个高度可信的桥，架设在启用HTTPS的数据站点与以太坊区块链之间。它从站点取回数据，之后把数据作为数据报（datagram）提供给它依赖的合约。TC使用一种新型的SGX与智能合约前端的组合，它将其核心功能作为可信代码在SGX安全区（enclave）中执行。它可以防止恶意的进程或操作系统，并且可以向远程客户端证明其正在使用一个合法的、SGX支持的TC代码实例。智能合约前端可对区块链上的合约请求作出类似下面的回复：“参数params指定的数据报X在指定的时间帧T中由一个启用了HTTPS的网站Y提供。”之后依赖的合约可以在这样的数据报中验证X的正确性，前提是只信任SGX的安全性、(已发布的)TC代码，以及在指定的时间间隔内的源数据的有效性。

使用智能合约的另一个关键障碍是当今的生态系统缺乏机密性：所有的区块链状态都是公开可见的，并且现有的数据馈送公开地暴露请求。TC通过支持私有数据报请求来提供机密性，在这类请求中，参数是在TC公钥中加密的，因此隐藏在区块链中。TC还支持自定义数据报请求，它通过接收加密的用户凭证来安全地处理请求者的在线资源（例如在线帐户），允许TC安全地检索访问控制的数据。

智能合约是在一个敌对的环境中执行的，在这种环境中，当事人可以通过破坏他们所依赖的合约或服务来获得经济收益。因此，正式的安全至关重要。文章定义和证明TC实现了数据报的基本属性——TC忠实地从目标网站上转发了数据。此外，我们还为一个诚实的请求者提供了公平的费用，即使TC主机是恶意的，用户合同调用TC所支付的费用最多也只是TC服务的运营成本的一小部分。

文章工作的其他两个贡献是介绍与展示如何实现两个关键的安全特性：Gas可持续性与可信计算基础（trusted computing base，TCB）代码最小化。因为去中心化执行代码需要花费大量资源，且存在应用层拒绝服务攻击（denial-of-service，DoS）的风险，以太坊使用Gas支付执行费用。Gas可持续性意味着一个以太坊应用不会用尽它的Gas。文章认为，区块链与SGX的结合将被证明是一种强大的、通用的方法，可以在智能合约系统中实现机密性，并将它们与离线系统连接起来。然而，这种新的安全模式引入了一种跨越不同信任模型的组件的混合TCB。文章引入了使用这种混合TCB的技术，同时最小化TCB代码的大小。

文章对三种情景下的应用做了测试：

  1. 依赖股票行情数据的金融衍生工具（现金结算看跌期权）
  2. 一份依赖取消航班请求的私人数据的飞行保险合约
  3. 一份销售虚拟物品和在线游戏（通过Steam市场）的合约，用于以太货币，使用自定义的数据请求来访问用户帐户。

背景

这里主要介绍SGX与智能合约。

SGX

软件应用通常需涉及诸如密码、账号、财务信息、密钥和健康档案等私人信息。操作系统的任务对计算机系统实施安全策略，以避免这些机密信息无意间暴露给其他用户和应用。操作系统会阻止用户访问其他用户的文件（除非访问已获得明确许可），阻止应用访问其它应用的内存，阻止未授权用户访问操作系统资源（除非通过受到严格控制的界面进行访问）。应用通常还会采用数据加密等其它安全保护措施，以确保发送给存储器或者通过网络连接而发送的数据不会被第三方访问到——即使是在操作系统和硬件被盗用的情况下。

尽管有这些措施提供保护，但大部分计算机系统仍然面临着一项重大安全隐患：虽然有很多安保措施可保护应用免受其它应用入侵，保护操作系统免受未授权用户访问，但是几乎没有一种措施可保护应用免受拥有更高权限的处理器的入侵，包括操作系统本身。获取管理权限的恶意软件可不受限制地访问所有系统资源以及运行在系统上的所有应用。复杂的恶意软件可以锁定应用的保护方案为目标进行攻击，提取密钥，甚至直接从内存提取机密数据。

为对这些机密信息提供高级别的保护，同时抵御恶意软件的攻击，英特尔设计了SGX。SGX是一套CPU指令，可支持应用创建安全区：应用地址空间中受保护的区域，它可确保数据的机密性和完整性——即便有获取权限的恶意软件存在。

安全区内的进程不能进行系统调用，但可以读写安全区外的内存。因此，在SGX中的隔离执行可以被看作是一个理想的模型，在这个模型中，一个进程被保证正确地执行并且具有完全的机密性，但是依赖于一个（可能具有恶意的）网络和文件系统访问的操作系统。

SGX允许远程系统验证安全区中的软件，并安全地与之通信。当一个安全区被创建时，CPU会产生一个被称为评价（measurement）的初始状态的哈希散列。在安全区中的软件可以在稍后的时间请求一份报告，其中包括由该进程提供的评价和补充数据，例如公钥。该报告使用硬件保护密钥进行数字签名，以证明被测软件在SGX保护的安全区中运行。这个证明可以通过远程系统来验证。

智能合约

尽管TC可以支持任意的智能合约系统，本文主要介绍其在以太坊中的用途。

以太坊的智能合约被描述为一个合约帐户，它含有代码，一个货币余额，以及一个键/值存储形式的持久存储空间。合约接受消息作为任意数量函数的输入。由合约创建者确定的这些入口点代表了合约的API。一旦创建，合约将自动执行，它会无限期地持续下去，甚至它的创建者也无法修改它的代码。合约代码是在收到来自另一个合约或非合约账户的信息时执行的，这个账户被称为钱包。因此，合约执行总是由交易发起的。合约只在被“触发”的时候执行，并且通过一系列的入口点执行，直到没有进一步的消息传递发生（或Gas用尽）。作为一个简单的抽象，智能合约可以被看作是区块链上的自治代理。

以太坊有它自己的货币，叫以太（Ether）。为了防止DoS攻击，防止在合约中可能产生的无限循环，并且控制网络资源消耗，以太坊允许基于以太购买一种被称为Gas的资源来驱动合同。每个操作，包括发送数据、执行计算和存储数据，都有固定的Gas成本。交易含有GASLIMIT与GASPRICE两个参数，GASLIMIT用于函数（父）调用另一个函数（子）时，规定子函数所能使用父函数的最多Gas量。GASPRICE是交易愿意为每个单位Gas支付的最多以太数。只有当GASLIMIT与GASPRICE的乘积足够高，被系统（矿工）接受时，交易才会成功。

结构与安全模型

结构

Town Crier包含三个主要结构：TC合约（The TC Contract），安全区（the Enclave）与中继（the Relay）。使用TC服务的智能合约称为请求者或依赖合约（requester or relying contract）。数据源是一个启用HTTPS的线上服务器，TC利用它提供的数据来形成数据报。

Basic Town Crier architecture

各结构功能如下：

  • TC合约。它是一个作为TC前端的智能合约。它为依赖合约提供一个简单的API，将其请求传递给TC。
  • 安全区。文章将在SGX安全区内运行的程序代码简单地称为安全区。安全区处理执行来自区块链的请求。
  • 中继。安全区缺少直接的网络连接。因此，中继代表安全区来处理双向网络流量。具体来说，中继提供从安全区到三种不同类型实体的网络连接：区块链（TC合约到安全区的数据中继）、客户端（运行一个支持HTTPS的服务器处理链外请求）、数据源。

安全模型

文章作出如下假设：

  • TC合约。它在区块链上全局可见，且其源码对客户端公开，因此可假设TC合约诚实运行。
  • 数据源。假设客户端信任TC数据报中的信息，且数据稳定，在请求者指定的时间间隔T中，生成的数据报是一致的。
  • 安全区。三个假设：安全区诚实运行、安全区生成的私钥仅为安全区所知、安全区有内部准确的时钟。
  • 区块链通信。交易和消息可验证，被完整保护（因为它们是由发送方数字签名的），但不是机密的。
  • 网络通信。中继（以及TC服务器的其他不受信任的组件）可以被篡改或延迟通信的进出。因此，认为中继被控制网络的敌手所控制。

数据流

系统数据流如下图所示。

Data flows

数据报的生命周期可以简要分为以下四步：

  • 初始请求。依赖合约向TC合约发送数据报请求。
  • 监视与中继。中继对TC合约保持监视，将所有传入的数据报请求转交给安全区。
  • 安全地获取馈送。为了处理指定的请求，安全区通过HTTPS联系数据源，并获取请求的数据报。它通过中继向TC合约转发数据报。
  • 返回数据报。TC合约将数据报交给依赖合约。

结语

本篇文章内容复杂，涉及细节较多，但作为CCS会议论文，深度和权威性是可以保证的。如果对区块链的底层开发有兴趣，可以深入学习。