论文阅读：《Town Crier：An Authenticated Data Feed for Smart Contracts》

初学者的一些粗略理解，如果有错，欢迎指正。
论文地址
TC官方网站（里面有作者提供的案例）
本文参考了这篇解读，尤其是前半部分，删改不多，感谢作者

1. INTRODUCTION

这篇论文主要针对的是智能合约，为智能合约提供一个经过身份验证的数据馈送（data feeds）。
（个人理解有点像快递员，把经过验证打包的数据递送给智能合约，它提供验证和传递，但是不会改变数据的内容。）

首先我们了解一下背景信息，智能合约是自动执行合同条款的计算机程序，比如日常的汽车贷款付款、保险等都可以通过智能合约自动完成。
但这意味着，智能合约的执行离不开真实生活中的数据。比如执行汽车贷款支付的智能合约需要知道车主是否及时付款，以确定车主取消是否依旧享有实际访问权限等等。

另一个问题则是数据的隐私性。区块链的分布式的特点能够让每个人都去记账，从而达到防抵赖、防篡改的目的，但从另一个角度来看也是区块链的缺点，所有区块状态都是公开可见的，data feeds可能会暴露出用户的请求，隐私性被破坏。

针对以上两个问题，作者提出了Town Crier——为智能合约提供一个经过身份验证的data feed，在智能合约和外部网络（论文假设外部的数据是可信的、真实的）中构建一座数据流通的桥梁。

Town Crier

1. Town Crier检索网站数据，然后将其作为依赖于区块链上的合同的数据，称之为数据报（datagrams）。
2. 小贩利用Intel可信组件SGX（ Software Guard Extensions）作为后端，智能合约作为前端。以SGX安全区中受信任的代码段的形式执行其核心功能，从而保护其免受恶意进程和OS的侵扰，并可以向远程客户端证明该客户端正在与SGX支持的合法TC实例进行交互。(这个Software Guard Extensions是一项针对应用程序开发人员的英特尔技术，旨在保护选择的代码和数据不被泄露或修改。SGX通过使用围圈，或者称之为飞地（enclave），即内存中受保护的执行区域，使这种保护成为可能。)
3. 小贩也支持私密数据报请求（private datagram requests）和自定义数据报请求（ custom datagram requests）。用户请求private datagram requests时，参数被小贩的公钥加密，加密过程在SGX中完成，因此数据报和数据的请求在区块链上是被隐藏起来的。用户请求custom datagram requests时，TC通过接收加密的用户凭据，安全地访问请求者的在线资源（如在线帐户），从而允许TC安全地检索访问控制数据。

Contributions
论文的主要奉献有以下4点：

1. 论文介绍并报告了Town Crier的端到端实施，这是一种经过身份验证的数据馈送系统，可解决采用分散式智能合约的关键障碍。TC将以太坊中的智能合约前端和基于SGX的可信硬件后端结合在一起，以在没有可信服务运营商的情况下将经过身份验证的数据提供给智能合约，以及支持私有和自定义数据请求，支持加密请求和安全使用访问控制的链下数据源。
2. 论文在通用组合（UC）框架内正式分析TC的安全性，定义了代表链上和链外组件的功能。 正式定义并证明数据报真实性和公平支出以及gas可持续性的基本属性，这是任何以太坊服务的基本可用性属性。
3. 论文引入了跨区块链和SGX enclave的混合可信计算基（TCB），这是可信赖系统组成的强大新范例。 我们提供了有助于在此模型中缩小TCB代码大小的通用技术，以及弥补各个SGX平台漏洞的技术。（可信计算基（英语：Trusted computing base, TCB）是指为实现计算机系统安全保护的所有安全保护机制的集合，机制可以硬件、固件和软件的形式出现。一旦可信计算机基的某个构件出现程序错误或者安全隐患，就对整个系统的安全造成危害。 与之相反，如果除可信计算基之外的系统的其他部分出现问题，也只是泄漏了系统安全策略赋予它们的相关权限而已，这些权限一般都是比较低的。）
4. 论文探索了三种TC应用程序，这些应用程序显示了TC能够支持远远超出当今以太坊的服务范围的能力。 这些应用程序的实验还表明，TC可以轻松满足现代分散式区块链的延迟和吞吐量要求。

论文实现的三种智能合约实例为：

1. 使用股票报价器数据的金融衍生产品；
2. 依赖于有关航班取消的私人数据请求的飞行保险合同；
3. 使用自定义数据请求访问用户帐户的以太坊货币以太币（通过Steam Marketplace）销售虚拟商品和在线游戏的合同。

2. BACKGROUND

TC主要引入的技术包括可信执行环境（论文使用的是Intel的SGX，我的老师建议也了解一下TEE）、TLS/HTTPS以及智能合约。

1. 可信执行环境SGX是通过硬件实现或者软件技术实现的一个安全的代码运行环境，可以理解为一个黑盒子，将执行的代码放在黑盒子里，提供输入最后获取输出，整个执行的过程不能被外界更改，也不能被观察到，可以认为是安全的模型。
2. HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。TLS，安全传输层协议，用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。TC利用了HTTPS的重要功能，即可以将其划分为可互操作的层：与Web服务器交互的HTTP层，处理握手和安全通信的TLS层以及提供可靠数据流的TCP层。
3. 智能合约（Smart contract ）是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。

3. ARCHITECTURE AND SECURITY MODEL

Architecture

TC包含三个主要组件：The TC Contract (C_TC), the Enclave (代码标记为prog_encl), and the Relay (R).

这个图给出了TC的架构示意图，显示了它与外部实体的交互，绿色的部分是被信任的组件。
我们看看它的三个主要组件：

1. Tc contract：TC智能合约。C_TC是一种智能合约，充当TC的区块链前端。 它旨在为依赖合同C_U提供一个简单的API，以向TC提出请求。 其接受来自C_U的数据报请求，并从TC返回相应的数据报。
2. Enclave：飞地。在SGX enclave中运行的TC智能代码实例简称为Enclave，并用prog_encl表示代码本身。Enclave提取并完成来自区块链的数据报请求。 为了获取要包含在数据报中的数据，它查询外部数据源，特别是启用HTTPS的Internet服务。 它将数据报作为数字签名的区块链消息返回到请求合同C_U。
3. Relay：中继器。由于在SGX中缺少直接的网络访问，因此将R布置在enclave中代替其处理双向的数据流量处理，提供了从飞地到三个不同实体的数据连接，即区块链、客户和数据源。
   注意：图中R作为TC Server的一部分，不受到SGX的保护，可以被外部攻击，从而导致延迟和失败。但根据TC实际的初衷，R一般不会产生错误的数据（因为这样他们可能会支付gas），只会产生拒绝服务攻击。

需要注意的是Enclave和Relay都是部署在TC服务器上的，而TC智能合约是部署在区块链上的。

另外我们将利用Town Crier服务作为请求者或依赖合同的智能合约称为“用户智能合约”，表示为C_U，并将其所有者称为客户或用户。数据源是一个在线服务器（运行HTTPS），该服务器为TC提供用来构成数据报的数据。

Security model

• TC Contract。TC智能合约全局可见，且源代码被客户共享，因此假设C_TC行为诚实可信。
• Data Source。假设客户信任从HTTPS上获得的数据报，同时假设数据源稳定、在特定的时间间隔可以产生请求者所需要的数据。
• Enclave。作者做了三个假设：1）飞地程序正确执行合约代码；2）每个飞地产生的公私钥对（sk_TC，pk_TC），私钥只有飞地自己知道；3）飞地程序内部有确切的时间。
• Blockchain communication。交易和消息源是可验证的，即，接收方帐户将从钱包W_X发送的交易m标识为源自X。交易和消息受到完整性保护，但不是机密信息。
• NetWork comunication。 中继可能会篡改或延迟与Enclave之间的通信。 正如我们在SGX安全模型中所解释的那样，中继不能以其他方式观察或改变安全区的行为。因此，中继可以被控制网络的对手所占领。

4. TC PROTOCOL OVERVIEW

TC的整体流程相对简单，一个用户合约C_U向TC智能合约C_TC请求数据，C_TC将请求转发给Enclave，并将结果返回到C_U。

4.1 Datagram Lifecycle

数据报周期大致可以分为以下几个步骤：

• 初始化请求。C_U给C_TC发送一个数据报请求。
• 监视和中继。 中继监视C_TC，并将带有参数params的数据报请求中继到飞地。
• 飞地获取数据。 为了处理在params中指定的请求，Enclave通过HTTPS与数据源联系并获取请求的数据报。它通过中继将数据报转发到C_TC。
• 返回数据报。 C_TC将数据报返回给C_U。

4.2 Data Flows

数据流分为以下4步：

1. C_U发出的数据报请求采用消息m1=(params, callback)的形式发送给区块链上的C_TC。 params指定所请求的数据报，例如params=(url，spec，T），其中url是目标数据源，spec指定要检索的数据报的内容（例如，特定时间的股票行情自动收录器），以及T指定数据报的传递时间（通过抓取数据源启动）。 m1中的参数callback指示数据报将返回到的入口点。
2. C_TC生成一个新的唯一ID，并将m2=（id，params）转发给Enclave。
3. 作为响应，它从TC服务接收m3 =（id，params，data），其中data是所请求的数据报（例如所需的股票行情价格)。
4. C_TC检查请求和响应上的参数的一致性，如果匹配，则将数据转发到消息m4中的回调入口点。为了简单起见，我们假设CU发出一次数据报请求。因此，它可以简单地将m4与m1匹配。

论文的完整协议包含一个优化，通过该优化，C_TC在m1之后将ID作为所有数据流的一致，可信赖的标识符返回给C_U。这使得直接处理来自相同C_U实例的多个数据报请求成为可能。

图2显示了处理数据报请求所涉及的数据流。为简单起见，该图省略了中继，该中继仅负责数据传递。需要数字签名来验证消息，例如m3，这些消息将从外部来源进入区块链。我们让（sk_TC，pk_TC）表示与Enclave关联的用于此消息身份验证的私钥/公钥对。为了简单起见，图2假定Enclave可以将签名的消息直接发送到C_TC。

5. TWO KEY SECURITY PROPERTIES

5.1 Gas Sustainability

以太坊的费用模型要求gas费用由发起交易的用户支付，包括因交易确认不断调用而产生的所有费用。这意味着发起对以太坊合约的调用服务必须花费金钱来执行那些调用。如果没有精心设计，这可能会导致财务耗尽，并导致应用程序层拒绝服务攻击。因此，对于基于以太坊的服务的可用性至关重要的是，始终向其发起的区块链计算报销它们的费用。
为了确保服务不会受到此类攻击的影响，作者定义了gas可持续性，这是基于区块链合同的服务的活力所必需的新条件。gas可持续性是任何以太坊服务永续发展的基本要求。它也可以推广到以太坊之外；任何基于分散式区块链的智能合约系统都必须收取某种费用，以补偿矿工进行和验证计算的费用。

令bal(W)表示以太坊钱包W的余额。
定义1（K-Gas可持续性) 具有钱包W和区块链功能f1,…,fn的服务是K-gas可持续的充分条件是：

1. 如果在执行任何fi之前bal(W)≥K；且服务诚实运行
2. 则在每次执行由W发起的fi时，bal(W)≥K。

在以太坊进行的gas不足的调用将会中止，但依然会消耗所有提供的gas。所以如果钱包提交的交易资金不足，钱包的余额将降至0。因此，要使K-gas在K>0的情况下可持续，服务发出的每个区块链调用都必须补偿gas支出。此外，该服务必须为每次调用或者与交易的其他部分一起恢复的补偿提供足够的gas。

5.2 Hybrid TCB Minimization

在涉及智能合约与链下可信计算环境（例如SGX）交互的系统中，TCB是具有不同属性的两个组件的混合体。智能合约中的计算速度慢，成本高且完全透明，这意味着它不隐秘。 SGX飞地具有强大的计算功能并可以私下执行，但是所有外部交互（尤其是与合同的通信）都必须经过不受信任的中介。尽管此混合TCB的功能强大且远超过TC，但仍带来了挑战：如何在组件之间建立安全的通信，同时最大程度地减少TCB中的代码。

作者在这个图中定义了两个TCB组件的抽象。
为了将这些抽象与形式化的理想功能区分开来，作者使用T表示可信组件。
T_Off：链外TCB的抽象
T_On：链内TCB的抽象
O_Auth：信息馈送，用来对链上消息的身份验证进行建模，如果输入是有效的区块链事务，该模型将返回true。

由于以太坊块是使用Merkle树进行自我认证的，因此原则上我们可以通过在TCB中包含以太坊客户端来实现O_Auth。但是这样做极大地增加了代码占用空间，以太坊的核心实现大约是5万行C ++。类似地，智能合约可以通过检查证明来验证来自SGX的消息，但是在智能合约中实现认证将很容易出错，并且在计算上（因此在经济上）昂贵。

在链外TCB（T_Off），我们需要验证收到的区块链请求是否有效；在链内TCB（T_On），我们需要验证请求，信息和签名。这两个是开销最大的地方（图片4中标红的函数）。

所以作者提出了两种通用技术来避免这些调用，从而最大程度地减少TCB中的代码大小。第一种适用于任何TCB组件为区块链合同的混合系统。第二个适用于TCB组件仅通信以发出和响应请求的任何混合系统。

Binding T_Off to W_TC。将T_Off绑定到W_TC。

由于链上TCB的计算速度快且成本高，我们希望避免实施签名验证。确实存在一个预编译的以太坊合同，以验证ECDSA签名，但是操作需要高昂的gas费用。
取而代之的是，作者将T_Off的身份绑定到以太坊钱包，这使TOn可以简单地检查消息发件人，该消息发件人已经作为以太坊交易协议的一部分进行了验证。这其中的关键是信息只能作为来自钱包的交易插入以太坊区块链。因此，中继器将消息从T_Off中继到T_On的唯一方法是通过钱包W_TC。由于以太坊本身已经验证了交易上的签名（即用户通过经过身份验证的渠道与以太坊进行交互），因此我们可以在现有交易签名验证机制的基础上执行带T_Off签名的验证。
简而言之，T_Off使用新的公钥pk_Off创建W_TC，该公钥的密钥只有T_Off知道。为了使这个想法充分发挥作用，必须将公钥pk_Off硬编码到T_On中。创建或依赖使用T_On的合同的客户负责确保与T_On交互之前，此硬编码的pk_Off具有适当的SGX证明。
通过假设依赖客户端已经验证了T_Off的证明，我们可以假定从W_TC发送的数据报被信任为源自T_Off。这样就无需在T_On中进行昂贵的EPID签名验证。
另外，SGX可以将pk_Off密封在非易失性存储中，同时保护完整性和机密性，使我们可以通过服务器重启来保持相同的绑定。

具体我们可以看一下图5，它是用户的SGX认证离线验证。它要求客户端检查飞地代码T_Off和公钥pk_Off的SGX认证。同时在使用T_On之前检查pk_Off是否硬编码到区块链合约T_On中。
如果三个认证都能通过的话就认为T_On是可信的。

Eliminating O_Auth。消除O_Auth。
为了消除从T_Off调用O_Auth的需要，作者利用这样一个事实：从T_Off到T_On的所有消息都是对现有请求的响应。我们不需要在T_Off中验证请求参数，而是可以在T_On中验证T_Off是否响应了正确的请求。
对于每个请求，T_On存储该请求的参数。在每个响应中，T_Off都包含它用来完成请求的参数。然后，T_On可以检查响应中的参数是否与存储的参数匹配，如果不匹配，则直接拒绝。存储参数和检查相等性是简单的操作，比在T_Off中调用O_Auth要简单得多。
这种方法可能会开启新的攻击（例如，中继可以发送TOff响应的虚假请求）。但是作者在第7节中所证明了，所有此类攻击都会减少为来自网络的DoS攻击或中继攻击，而混合TCB系统本身就很容易受到这些攻击的影响，并且作者并不打算在TC中对它们进行保护。

6. TOWN CRIER PROTOCOL

为了了解TC协议，我们需要进行一些预备工作。为简单起见，我们假设只有一个飞地实例，其实这个系统是可以扩展多个飞地，甚至多个主机的。
为了确保gas可持续性，TC要求申请人提前支付gas费用。然后TC智能合约偿还TC的gas费用。通过让可信组件执行补偿，我们还可以保证恶意TC在不提供有效数据的情况下无法窃取诚实用户的资金。

Notation.
首先是符号说明。
我们使用符号m_i标记与图2中的消息相对应的消息。
付款时，$g表示gas，$f表示非gas货币。为简单起见，作者假设gas和货币采用相同的单位（这样可以避免显式转换）。我们使用以下标识符来表示货币和gas。

Initialization. 初始化。 TC向W_TC至少存入$G_max。

The TC Contract C_TC. TC智能合约。 TC合约接受来自C_U的数据报请求和费用$f，为其分配一个唯一id，并对其进行记录。然后中继器R监视请求并把它们转发到Enclave。在收到W_TC的响应后，C_TC验证参数以确保有效性。如果请求有效，C_TC通过调用初始请求中指定的callback来转发生成的数据报。为了确保所有花费的gas都可以报销，C_TC在这个子调用中设置$g_clbk:=$f-$G_min。（可以报销的最大值=押金-不包含callback的deliver需要的gas），然后把这个值连同数据报一起返回给callback。

The Relay R. 中继器R。 如前面所述，R通过三种方式架起了Enclave和区块链之间的桥梁。
1 它从C_TC里获得新请求 (id, params)。
2 使用这两个命令prog_encl.Initialize() 和prog_encl.Resume(id, params) 向飞地传入请求。
3 它将数据报从Enclave转发到区块链。
它将已经签署的交易作为W_TC转发给区块链。函数AuthSend将交易插入区块链，以W_TC的形式，表示交易已被TC私钥签名。诚实的中继器只会为每个有效请求的参数调用一次prog_encl.Resume。

The Enclave prog_encl. 飞地。 当通过 Initialize()初始化时，prog_encl接收当前的挂钟时间；通过存储该时间并设置时钟参考点，它校准其绝对时钟。它生成一个ECDSA密钥对（pk_TC，sk_TC）（在以太坊中参数化），其中pk_TC通过插入到证明中绑定到prog_encl实例。在调用Resume(id, params) 时，prog_encl通过HTTPS联系params指定的数据源，并检查相应的证书是否有效。然后prog_encl获取请求的数据报，并将其返回给中继器R，包含params*、id和GASLIMIT $g_dvr:=$G_max，所有这些都是用sk_TC数字签名的。

The Requester Contract C_U . 用户智能合约。 诚实的请求者首先遵循图5中的协议来验证SGX证明。然后她准备params和callback，用params将$g_req设置为Request的开销，将$f设置为$G_min加上执行callback的开销，并用GASLIMIT$g_req调用Request(params, callback, $f)。
如果没有执行callback，她可以使用GASLIMIT$g_cncl调用Cancel(id)来接收部分退款。一个诚实的请求者将为她的每个请求最多调用一次Cancel，且不会为任何其他用户的请求调用Cancel。

Money Flow。红色箭头表示资金流动，棕色箭头表示gas limits。线条的粗细表示资源的数量。$g_clbk箭头很细，因为$g_clbk被限制为$f−$G_min。
（我个人理解$f就是用户垫付的用于支付Deliver所需的gas的费用。）

6.1 Private and Custom Datagrams

• 除了普通数据报之外，TC还支持私密数据报（private datagrams），私密数据报是pk_TC下params包含密文的请求。因此，尽管区块链具有公共可读性，但私密数据报可以实现保密应用。
• TC也支持自定义数据报（Custom datagrams），它允许合约指定特定的web抓取目标，可能涉及多个交互，从而大大扩展了TC可能依赖的合约的范围。

6.2 Enhanced Robustness via Replication

• 为了防止单个SGX实例的危害，TC可以从多个SGX实例请求数据报，并在响应之间实现多数投票。这种对冲需要增加额外请求和存储返回数据的gas支出。
• TC可以通过为相同的数据抓取多个数据源并选择多数响应来避免数据源的损害。

7. SECURITY ANALYSIS

Authenticity. 可靠性。 直观地说，可靠性意味着对手（包括恶意的用户、中继或其两者结合起来）无法说服C_TC接受与在指定时间抓取指定数据源获得的预期内容不同的数据报。
在我们的正式定义中，我们假设用户和C_TC的行为是诚实的。回想一下，用户必须预先验证为飞地公钥pk_TC担保的证明σ_att。

定义2（ Data Feed的可靠性) 对于能与任意F_sgx交互的多项式时间A，当data不是时间T时具有公钥pk_url的url中的内容时，A无法让诚实的验证者接受(pk_TC, σ_att, params := (url, pk_url, T), data, σ)。(在这个模型中是prog_encl.Resume(id, params) )
// negl()指可忽略不计的。

定理1 (可靠性)
假设∑_sgx和∑是安全签名方案，那么，TC协议在定义2中实现了Data Feed的可靠性。

Fee Safety. 收费安全。

一个诚实的用户应该只需要为代表她诚实执行的计算付费。如果传递了有效的数据报，则这是一个常量值加上执行callback的成本。否则，请求者应该能够收回执行Deliver的成本。为了使定理2成立，C_TC必须在取消时保留少量费用，但我们允许用户收回除此少量固定金额之外的所有费用。我们现在将这种直觉形式化。

定理3 (诚实请求者的公平支出)
对于任何params和callback，在提交请求（params，callback，$f，$g_req）时，$G_req和$F分别是诚实选择的$g_req和$f值。对于诚实用户提交的任何此类请求，有以下情况之一:

• 当有效数据报成功匹配请求参数params， callback被调用时，请求者最多花费$G_req+$G_cncl+$F；
• 请求者最多花费$G_req+$G_cncl+$G₀。

Other security concerns. 其他安全问题。 在第6.2节中，我们讨论了对基本TC协议中包含的SGX隔离模型之外的攻击的关注。虽然我们在第8.1节中简要讨论了这一问题，但我们在TC中没有提到的威胁是网络对手进行流量分析的风险或针对机密应用程序（例如，使用private datagrams）的中继泄露的风险。我们还注意到，虽然TC假设数据源的正确性，但如果发生刮取故障，TC会传递一个空数据报，从而使依赖的合约失败。（即使传递了无效的空数据报，但依然会花费使用者的gas。）

8. EXPERIMENTS

8.1 Requesting Contracts

• Financial Derivative (CashSettledPut). 金融衍生工具是最常被引用的智能合约应用之一，也是金融工具 data feed需求的例证。我们为现金结算看跌期权实现了一个示例合约CashSettledPut。这是一方在特定日期或之前以约定的价格从另一方购买资产的协议。这是“现金结算”，因为销售是隐性的，即没有资产变动，只有反映资产价值的现金。
• Flight Insurance (FlightIns). 航班延误或取消时的航班保险赔偿。我们实施了一个简单的飞行保险合约，叫做飞行保险。我们的实现展示了TC的private-datagram特性，以解决一个明显的问题：客户可能不希望在区块链上公开他们的旅行计划。客户向C_TC提交了一个在Town Crier 飞地公钥pk_TC下加密的请求Enc_pkTC(req)。飞地解密req并检查其格式是否正确（例如，是否在起飞时间之前很久提交）。飞地随后将在指定的时间从目标网站获取飞行信息，并向C_TC发送一份数据报，表明飞行是否延迟或取消。最后，为了避免通过计时（例如，访问飞行信息网站或发送数据报时）泄露信息，引入了随机延迟。
• Steam Marketplace (SteamTrade). 经过身份验证的数据源和智能合约可以在没有预先建立信任的互联网用户之间公平地交换数据商品。我们为Steam开发了一个支持虚拟物品公平交易的示例应用程序，Steam是一个在线游戏平台，支持数千个游戏并维护自己的市场，用户可以在这里交易、购买和销售游戏和其他虚拟物品。我们实现了一个销售以太游戏和物品的合同，展示了TC通过使用steam的访问控制API对定制数据报的支持。在我们的实现中，卖家将Enc_pkTC(account credentials，req)发送给C_TC，这样Enclave就可以作为卖家登录，并从网页上判断虚拟物品是否已经发货。

8.2 Measurements

TCB Size. TCB大小。 Town-Crier的TCB包括Enclave和TC-Contract。Enclave包括大约46.4K的C/C++代码行，其中绝大多数（42.7K行）是修改的mbedTLS库。mbedTLS的源代码已经被广泛部署和测试，而Enclave代码库的其余部分足够小，可以进行正式验证。TC合约也很紧凑；它由大约120行实体代码组成。

Enclave Response Time. 飞地响应时间。 它的定义为（1）中继向enclave发送请求和（2）中继从enclave接收响应之间的间隔。
表1总结了飞地的总响应时间及其在500次运行中的细分情况。所有时间都以毫秒为单位，包括平均值（mean）、比例（%）、最大值（tmax）、最小值（tmin）和标准差（σt）。注意，Total是端到端响应时间，定义为非冲突响应时间。由于较小的开销没有计入，时间总和可能不等于这个总数。对于作者实现的三个应用程序，enclave响应时间从180 ms到599 ms不等。响应时间显然是从网站获取请求的信息所需的时间。在评估的三个应用程序中，SteamTrade的web scraper时间最长，因为它通过多次往返与目标网站交互以获取所需的数据报。

Transaction Throughput. 吞吐量。 我们执行了一系列实验，测量交易吞吐量，同时将单个支持SGX的主机上并发运行的Enclave的数量从1扩展到20。20 TC enclaves是我们使用的特定机型上的enclave内存限制的最大可能值。图10显示，对于所评估的三个应用，单个SGX机器可以处理15到65 tx/秒。
几个重要的数据点显示了TC如何有效地满足当今区块链对认证数据的需求：以太坊目前平均处理低于1tx/秒。比特币目前的处理速度略高于3tx/秒，其最大吞吐量（在全块利用率下）约为7tx/秒。据我们所知，还没有对以太坊对等网络的吞吐量界限进行测量研究。最近的研究[19]表明，如果不重新设计协议，比特币不能扩展到26 tx/秒以上。因此，使用很少的主机，TC可以很容易地满足分散区块链的数据馈送需求。
（我的老师说这里的数据有点问题，以太坊的处理速度应该是比比特币要快的。）

Gas Costs. Gas花费。 从TC获取数据报的总callback独立成本（即，数据报的成本，而不是应用程序的成本）范围为11.9¢ (CashSettledPut）至12.9¢ (SteamTrade）。（差不多人民币7-8毛钱）。这种变化是由不同的参数长度引起的。

Component-Compromise Resilience. 组件折损弹性。 对于CashSettledPut应用程序，我们实现并评估了两种多数表决模式（如第6.2节所示）：

• enclave内三取二多数投票，针对数据源出错提供健壮性。在我们的实验中，enclave从三个不同的数据源（彭博社、谷歌财经和雅虎财经）对当前的股价进行了简单的顺序刮取。在这种情况下，会导致飞地响应时间变长，但gas成本没有变化。
• 请求者合同中三取二多数投票，这提供了针对SGX出错的稳健性。我们运行了三个SGX enclaves实例，所有实例都使用相同的数据源。在这种情况下，gas成本将增加3倍，再增加5.85¢。

Offline Measurements. 离线测量。 因为clock()在SGX中只产生相对时间，所以TC的绝对时钟通过外部提供的挂钟时间戳进行校准。用户可以通过请求数字签名的时间戳来验证Enclave绝对时钟的正确性。实验表明，中继发送时钟校准请求到飞地和接收到响应之间的时间是11.4（1.9）ms，其中10.5（1.9）ms用于签署时间戳。除此之外，还必须加上广域网的往返延迟，很少超过几百毫秒。

————————
感觉这篇论文有意思的点就在于把SGX和智能合约两个完全不相干的东西联系在了一起，有时候就应该多多扩展思维，往不同的方向尝试。