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

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

• 1. 概述
• 2. 背景分析
• 3. 架构与安全机制

  • 系统架构

  • 安全机制

  • 4. TC PROTOCOL OVERVIEW

  • • 4.1 Datagram Lifecycle
    • 4.2 Data Flows
• 5. 两大核心安全特性
  • 5.1 气体可持续性
  • 5.2 混合型Tsb最小化

• 6. TOWN CRIER PROTOCOL

• • 6.1 Private and Custom Data Datagram

• 6.2 Enhanced Robustness through Replication

  • 7. SECURITY ANALYSIS
  • 8. EXPERIMENTS
  • • 8.1 Requesting Contracts
    • 8.2 Measurements

对于新手而言的初步认识：
论文地址
TC官方网站（里面有作者提供的案例）
[本文参考了这篇解读文稿,尤其是其前半部分内容,改动较少,谨致谢作者提供宝贵的解读文稿]

1. INTRODUCTION

这篇论文的重点研究对象是智能合约，并为此提供了一个经过身份认证的数据输送（data delivery）。类似于快递员将已通过身份认证打包好的数据运送到智能合约所在的平台或系统中进行处理与应用。其中该系统不仅提供了数据传输的功能保障，并且确保了数据的安全性以及不会被随意篡改或修改内容特征。

首先我们认识背景信息 智能合约是指由计算机程序自动执行合同条款的一种技术手段 例如日常的汽车贷款付款 保险等都可以借助智能合约实现自动化操作

但这意味着 智能合约的运行依赖于真实生活中的数据 例如运行汽车贷款支付相关的智能合约时 需要明确车主是否按时完成还款 以便确定车主取消交易后是否仍然保留实际访问权限

另一个问题是数据隐私性的保障。区块链技术通过分布式特点实现了个人记账功能（即每个人都能记录账目），从而实现了防止欺诈行为和防止数据篡改的作用（即防抵赖和防篡改）。然而从另一角度看这也是其局限性之一：由于所有的区块信息都是公开透明的这些数据流可能暴露用户的查询请求从而导致隐私性受到威胁

针对上述两个关键问题，研究者开发出了Town Crier——一种专为智能合约提供身份认证的数据流系统，在智能合约系统与外部网络之间搭建起连接这一领域的重要桥梁（论文假设认为外部提供的数据是可信赖且真实的）。

Town Crier

1. Town Crier网站收集数据后被命名为基于区块链的合同文件（datagrams）。
2. 小贩通过Intel可信组件SGX平台作为后端，在受信任的代码执行环境中运行智能合约作为前端。这种设计使得其核心功能得以安全运行，并能向远程客户端展示与合法SGX支持的TC实例交互的能力。（这项针对应用程序开发人员的英特尔技术通过使用受保护的安全区域即enclave实现对选择代码和数据的安全保护）
3. 小贩支持私密数据报请求（PDRs）与自定义数据报请求（CDRs）。当用户发起PDR请求时其参数采用公钥加密算法加密整个过程均在SGX内完成因此相关数据在区块链上被隐秘处理。当用户发起CDR请求时TC会接收加密后的凭据从而安全地访问请求者在线资源如在线账户这则使TC能够安全获取访问控制信息。

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

1. 论文展示了Town Crier的全面部署,这是一种经过身份验证的数据传输系统,能够有效解决分散式智能合约应用中的关键挑战。该系统结合了以太坊智能合约前端与SGX可信硬件后端的功能,无需依赖可信服务运营商即可提供身份验证数据给智能合约,同时支持私有化和自定义数据请求,具备加密请求与安全访问控制等特性,能够连接来自链上与链下组件的数据源。
2. 论文在通用组合（UC）框架内系统性地评估了TC的安全性,明确了链上与链下组件的关键功能代表。通过严谨定义并证明数据包的真实性和公平支出特性,以及气耗可持续性的基础属性——这是构建任何以太坊服务所必需的基本能力。
3. 论文提出了一种跨区块链与SGX enclave协同工作的可信计算架构（TCB）。为此开发了一系列优化措施来降低TCB代码规模,同时弥补各SGX平台漏洞的技术方案得以实施。（可信计算基（英语：Trusted computing base, TCB）是指整合硬件、固件及软件的安全保护机制集合,一旦其中某项组件出现程序错误或安全隐患将严重威胁系统安全;而除TCB外其他系统的故障只会泄露有限权限）
4. 该研究深入探索了几种基于TC的应用程序设计,这些应用充分展现了TC超越现有以太坊服务能力的巨大潜力。实验结果表明,基于TC实现的应用能够轻松满足现代分散式区块链网络所需的延迟与吞吐量需求。

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

1. 基于股票报价器相关数据开发出一系列金融衍生产品的工具。
2. 飞行保险合同基于航班取消事件中的私人或公司特定请求。
3. 定制化的数据分析请求用于访问用户的账户信息；通过 Steam marketplace 提供的数据服务中包含以太坊货币以太币（即 Ether），该合同允许销售虚拟商品和服务。

2. BACKGROUND

TC所引入的主要技术包括?> 信?用?计?算?平?台?> （研究论文中采用的是Intel ?> SGX ?> 技术体系；但如需深入研究相关领域也可参考?> Trusted Execution Engine ?> 的相关内容）、?> 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智能合约系统。CTC被视为一种特殊的智能合约，并被定义为TC的区块链前哨站（Front哨站）。它的主要职责是将来自合同执行方（CU）的请求转化为特定格式的数据报，并将处理后的反馈返回给CU。
2. Enclave：飞地与数据传输能力。在SGX环境中运行的TC实例代码被统称为Enclave，并以progencl标识符命名代码本身。Enclave不仅负责接收并处理来自区块链系统的相关数据报请求（Data包），还通过网络接口获取所需的数据源信息（特别是HTTPS加密的服务），最终将处理后的数据以数字签名的方式反馈回CU。
3. Relay：中继器与扩展功能。因为SGX架构缺乏直接的数据传输通道，在此基础上引入了中继器模块（R模块）来实现从Enclave向三个关键节点发送数据传输的能力——即连接到区块链系统、客户终端以及外部数据源。
   需要注意的是，在图示中R模块被集成进TC服务系统中，并未被SGX自身安全机制所覆盖，在面对外部攻击时可能会出现延迟或服务中断的情况。然而根据其设计初衷,R模块通常不会产生错误结果(否则可能触发支付气态事件),主要面临拒绝服务攻击等安全威胁。

需要注意的一点是Enclave和Relay均部署于计算平台之上，而TC智能合约则部署于区块链之中。

此外我们运用Town Crier服务将其设计为一种基于请求者与合同关系的智能合约并命名为"用户智能合约"即CU并赋予其所有权给客户或使用方

Security model

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

4. TC PROTOCOL OVERVIEW

TC的整体工作流程较为简单。一个用户合同CU向CTC智能合约发送数据请求后会引发以下步骤：首先由CTC接收该请求；接着将此请求转发给Enclave；最后将处理后的结果返回给CU。

4.1 Datagram Lifecycle

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

• 启动请求数据传输 。控制单元向计算节点发起关键数据传输请求数字。
  • 实现持续监控和转发功能 。通过持续监控和转发功能确保关键节点的数据完整性。
  • Enclave利用HTTPS协议与外部数据库建立连接并接收指定的数据包；随后将其转发至本地节点。
  • 本地节点成功接收并反馈相关响应信息至控制单元。

4.2 Data Flows

数据流分为以下4步：

1. CU通过消息m1=(... , callback)的形式向区块链上的CTC发送了一个数据报请求。该消息包含指定的数据报信息以及返回的入口点位置。
2. CTC创建了一个新的唯一标识符，并将编码信息以m2=(id, ...)的形式发送给Enclave节点。
3. TC服务收到回应信息m3=(id, ... , data)，其中包含所需的数据内容如股票行情价格等细节。
4. CTC验证了接收到的消息参数是否一致，并确认无误后会将处理后的数据传递到指定的回调接口处。为了简化说明，默认情况下我们假定CU仅发一次数据报请求。在这种情况下,CU可以直接关联对应的回调消息即可完成操作。

论文采用了完整的协议整合一个优化方案，在CTC完成m1流程后，系统将每个数据流的ID统一为所有数据流的一个一致标识符，并将其可靠地返回给CU节点。这一改进使得来自同一CU实例的数据报能够方便地被逐一处理。

图2呈现了处理数据报请求所涉及的数据流。

5. TWO KEY SECURITY PROPERTIES

5.1 Gas Sustainability

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

我们定义Ethereum wallet W的balance为bal(W)。（数学公式bal(W)原样保留）定义1（K-Gas可持续性）当且仅当该服务满足所有区块链功能f_i均属于集合F_k，并且其总gas消耗量不超过k \cdot bal(W)时，则称该服务满足K-Gas可持续性条件。（英文单词"service"保留）

1. 每当服务诚实运行时，在执行任何fi之前bal(W)≥K。
2. 将由W发起的fi每次执行时的balance值保持不低于K。

在以太坊网络中进行的一次gas不足的行为将会被截断,然而,在行为执行过程中所使用的gas仍然会被扣除。因此,在钱包提交交易时出现资金不足以覆盖费用的情况,钱包余额将被清空至零,从而导致整个系统出现不可逆转的状态变化。为了确保K-gas能够在K>0时持续运行,每个区块链调用都必须为发生的所有gas支出做出补偿;此外,该服务还必须能够通过每次调用或者与交易其他相关组件一起恢复所需的补偿量,这样才能保证系统的稳定性和可靠性

5.2 Hybrid TCB Minimization

在涉及智能合约与其他可信计算环境（如SGX）进行交互的系统中

在图中阐述了这两个TCB组件的概念框架。 为了区分这些抽象与形式化理想功能之间的差异，并标识可信组件为T Off 和 T On 的形式。 在此框架中:T Off标识为链外可信组件的抽象模型,而 T On 则代表链内可信组件的模型. OAuth机制则用于建模链上消息的身份验证过程. 如果输入数据是真实的区块链事务,该机制将输出确认结果.

基于以太坊块采用Merkle树进行自我认证的特点，在设计TCB时可以考虑嵌入以太坊客户端实现OAuth功能。然而这一做法会导致代码占用空间剧增，在实际应用中需要处理约50,000行C++代码量的核心逻辑。同样地，在智能合约中通过验证来自SGX的消息来完成身份认证功能是可行的。但值得注意的是，在智能合约内部实施这种认证机制不仅容易出错而且从计算资源（从而经济成本）角度来看也是十分高昂的。

处于链外状态（TOff），我们需要对接收到的区块链请求进行有效性验证；处于链内状态（TOn），我们需要对交易相关信息及其签名进行校验。这两项任务是耗时最长的关键环节（对应于图4中高亮显示的功能模块）。

因此作者开发了两种通用技术以消除不必要的调用从而最大限度地降低TCB中的代码规模。第一个适用于任何将TCB组件集成到区块链合同中的混合系统而第二个则适用于那些仅用于发送和接收请求而不做其他通信任务的任意混合系统

Binding T Off to W TC。将 T Off 绑定到 WTC。

由于链上TCB计算效率高但成本高昂，在实施签名验证方面存在较大挑战。相比之下，在现有交易签名验证机制基础上执行带TOff签名的验证仍需考虑其可行性。

另外一种方案是将公钥pkOff硬编码到TOn中，并由依赖客户端负责确保此公钥具有适当的SGX证明前被正确使用。

我们来详细分析图5所示的内容，它涉及用户的SGX离线认证流程。该流程要求客户端对飞地代码TOff以及公钥pkOff进行SGX认证。此外，在实际应用中，在使用主链代码TOn之前还需确认pkOff是否已嵌入到区块链合约TOn中。只要上述三个条件均满足，则可判定该主链代码方案为可信方案。

去除 O Auth。
为了减少从TOff发起OAuth请求的需求，作者提出了一种方法：所有来自TOff到TOn的消息都是针对现有请求的响应。
通过这一事实：所有来自TOff到TOn的消息都是针对现有请求的响应。
对于每个请求而言，在其处理过程中，在每个响应中都会包含该请求所必需的参数信息。
然后，在检查阶段会验证这些参数是否与存储的信息一致。
这种方法可能会导致新的攻击手段（例如中继节点可以伪造合法的身份认证）。
然而，在第7节中作者已经证明了此类攻击本质上是基于网络层面的影响，
而混合型TCB系统本身也容易受到这些潜在威胁的影响，
因此作者并未打算在TC层面上对这些安全漏洞进行额外防护措施。

6. TOWN CRIER PROTOCOL

为了掌握TC协议的基本内容, 我们需要做好一些基础准备工作的学习. 为了简化起见, 我们假设只有一个飞地实例, 即使扩展到多个飞地实例甚至多个主机的情况也是可行的. 然后TC智能合约归还TC所欠的gas费用. 通过让可信组件执行补偿任务, 我们可以确保恶意攻击者即使不提供有效的数据也无法窃取诚实用户的资金.

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

Initialization. 初始化。 TC向WTC至少存入$Gmax。

该智能合约系统接收CU的数据请求报及费用参数f，并为其分配唯一的标识符并进行记录。中继节点R持续监控数据请求并将其转发至Enclave节点处理。在收到WTC响应后，CTC系统通过参数验证确保操作合法。当所有条件满足时，CTC系统会通过指定回调函数将数据重新路由到主节点处理。为了确保所有用于交易的成本均能被合理报销，在子程序调用中设定gclbk变量值为$f减去不涉及 callbacks 的数据传输所需气量之差（即最大可报销金额=押金-不包含 callbacks 的 deliver 所需气量），并将此值一并返回给相关的回调函数。

如所述所示，在本节中我们详细阐述了基于Progencl框架下可信计算节点实现的关键技术架构。首先，在系统初始化阶段（Section 3），通过运行progencl启动初始化流程（Progencl.Initialize），系统能够接收并解析来自CTC的新请求（包括唯一的ID值及相关的参数集合）。随后，在执行数据转发任务时（Section 4），系统会利用两个关键命令：progencl重新启动并处理（Progencl.Resume）特定的（ID值及参数集合）以及将数据包转发至区块链网络。此外，在完成上述操作后（Section 5），系统会自动执行数据转发任务：将已签名交易通过WTC协议发送至区块链主网进行发布。其中WTC协议不仅代表交易已被TC私钥成功签名这一事实，并且确保了交易在整个网络中的不可篡改性与可追溯性

Enclave的扩展区域被称为飞地

该用户智能合约遵循图5中的协议进行验证。随后她准备了params以及callback，并将greq设为Request所需的开销。接着将f设定为Gmin加上执行callback所需的时间，并通过GASLIMIT greq进行调用Request(params,callback,f)。如果未执行callback，则可用GASLIMIT gcncl调用Cancel(id)来部分退款。每个诚实请求者最多只会调用一次Cancel指令。

Money Flow：红色箭头体现资金流动情况；棕色箭头则体现gas limits的情况。线条宽度则代表资源数量；其中gclbk箭头较窄是因为gclbk被限定为f−Gmin的情况。

6.1 Private and Custom Datagrams

• 除了普通数据报之外，在TC中还提供私密数据报（ private datagrams ）。其中，私密数据报是pkTC下 params 包中包含加密信息的请求。因此，在区块链系统中虽然存在公共可读性这一特性[注]：即所有参与者都可以读取该消息的内容[注] ，但通过使用私密数据报可以实现保密的应用。
• 在TC中还提供自定义数据报（ Custom datagrams ）。这种定制化类型的数据包允许合同明确指定特定的网络抓取目标，并可能涉及多个交互环节[注]：即合同可以在不同时间点触发不同的操作[注] 。这样一来，在使用这些定制化的合约时，默认的依赖范围将得到显著扩展。

6.2 Enhanced Robustness via Replication

• 为了避免单一SGX实例的风险, TC应从多个SGX实例中获取数据报, 并通过多数决策机制来确定最终结果.这种方法将导致额外的数据获取和存储开销增加.
• TC采用多源抓取策略, 在获得多个响应后以多数响应作为最终结果.

7. SECURITY ANALYSIS

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

定义2（数据流可靠性的评估）
对于任意能在Fsgx系统中交互的多项式时间算法A，在数据不是在时间T时由包含公钥pkurl指向特定URL的内容时（即参数_params被赋值为（url, pkurl, T）），诚实验证者无法通过该机制Resume（id, params）来实现对(pkTC, σatt, params)的有效接受。（此处模型中采用的是progencl.通过该机制Resume（id, params）来实现）
(其中negl()表示一个可忽略不计的小值.)

定理1 (可靠性) 基于∑sgx和∑作为安全签名方案这一前提条件，则可推导出TC协议依据定义2实现了数据流的安全性。

Fee Safety. 收费安全。

诚实用户的计算费用应仅按其真实行为计费。
当传递有效数据报时的成本等于固定常量与回调函数成本之和。
若无有效数据传输，则请求方可收回Deliver操作成本。
为确保定理2成立，在取消操作时CTC需预留小额费用。
我们已将这一直观思路正式化。

定理3 (公平支出策略)
对于所有参数组和回调函数，在发起请求时（即使用参数组、回调函数、以及变量$f与greq），变量G与F*分别代表诚实用户的期望值与实际支付额。当真实用户发起此类请求时

• 当有效数据报成功与请求参数 params 进行匹配，并在 callback 被触发时，则请求者的最大成本为 Greq + Gcncl + $F；
  • 请求者的最大成本为 Greq + Gcncl + $G0。

在第6.2节中，我们对除SGX隔离模型之外的基本TC协议中的潜在安全威胁也持高度关注。尽管我们在第8.1节简要提及了这一问题[1]，但在本论文中并未对此进行详细讨论的原因在于：网络对手可能通过流量分析手段窃取敏感信息；此外，在某些情况下（例如通过中间人未经授权地转发私有数据包），机密应用程序也可能遭受泄露风险[2]）。我们还注意到：尽管TC假设数据源是正确的[3]（即使在发生故障的情况下也会发送无效的数据包），但这些情况仍然会导致相关合约出现故障[4]）。

8. EXPERIMENTS

8.1 Requesting Contracts

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

8.2 Measurements

基于此,TBC尺寸问题已被深入研究并解决,现聚焦于解决 town-crai 的 tbv问题

Enclave Response Time. 飞地响应时间. 它被定义为（1）从中继发送请求至enclave以及（2）从enclave接收响应所经历的时间间隔。
表1汇总了飞地总响应时间及其在500次运行中的细分情况. 所有记录均以毫秒为单位计算, 包括平均值（mean）、占比百分比（%）、最大值（tmax）、最小值（tmin）以及标准差（σt）.
值得注意的是, Total端到端响应时间为非冲突响应时间之和. 由于忽略了某些微小开销, 所有总和可能不完全等于Total这一数值.
在本研究中的三个实现案例中, SteamTrade 的数据抓取过程所需时间最长, 达到了599 ms. 这种延迟源于其需进行多次交互以获取目标网站的相关数据报.

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

The Gas costs are a significant consideration in this context. The independent cost associated with data packets, specifically the cost related to the actual transmission rather than application operations, was calculated from TC (the Total Cost) and falls within a narrow range of 11.9 cents (CashSettledPut) to 12.9 cents (SteamTrade). This variation is primarily attributed to differences in parameter lengths and has minimal impact on overall system performance.

组件折损弹性即为Component-Compromise Resilience，在此应用中我们实现了并进行了评估两种多数表决机制。

• enclave内采用多数投票机制（三取二），这种设计能够有效容错数据源错误。在实验环境中，在现有的基础上增加了3倍的计算资源规模。
• 我们采用了多线程架构，并在每个线程间增加了同步机制以提高系统的稳定性。
• 该架构支持并行计算功能，并且能够动态分配资源以适应不同的工作负载需求。
• 实验结果表明，在现有基础上增加了3倍的计算资源规模后仍然保持了较高的系统性能。

离线测量方法主要基于以下原理：由于SGX中的clock()函数仅返回相对时间值，在此系统中无法直接获得设备级的绝对时间基准。为了实现TC的绝对时钟校准目标，在实验环境中可利用外部提供的真实世界时间戳来进行精确配置与验证。系统可通过请求数字签名的时间戳来验证Enclave内绝对时钟的一致性，并通过实验证明这一过程能够达到预期效果：中继发送至云域并接收响应所需的时间约为11.4±1.9毫秒（其中约需10.5±1.9毫秒用于数字签名操作）。此外还需考虑广域网传输过程中的延迟因素，在实际应用中通常不会超过几百年 milliseconds of延迟影响

这篇论文的一个有趣之处在于它将原本看似毫不相关的人工智能技术（SGX）与区块链技术中的智能合约相结合的方法论结合起来。这不禁让人想到提醒我们应当不断突破思维定式，在新领域中探索发现新的可能性。