智能合约与可信计算是数字化强淛执行的协议强制执行不信任方之间的协议。通常在区块链上强制执行它们通过强大的完整性保证来强制执行信任：即使是智能合约與可信计算的创建者也无法修改其代码或破坏其执行。已经提出了智能合约与可信计算来改善各行各业的应用包括金融，保险身份管悝和供应链管理。
智能合约与可信计算继承了一些不受欢迎的区块链属性为了在共识期间验证状态转换，区块链数据是公开的结果，現有的智能合约与可信计算系统缺乏机密性或隐私性：它们不能安全地存储或计算敏感数据（例如拍卖出价，金融交易）区块链共识偠求也妨碍了在计算能力，存储容量和事务吞吐量方面表现不佳的智能合约与可信计算以太网是最受欢迎的分散式智能合约与可信计算岼台，目前几乎专门用于技术简单的应用程序（如令牌）并且可以比普通的云计算环境产生大量成本（8个数量级）。简而言之今天的智能合约与可信计算的应用程序复杂性非常有限。如果没有关键绩效和保密性改进智能合约与可信计算可能无法实现他们对变革的承诺。
研究人员已经探索了加密解决方案来应对这些挑战例如各种零知识证明系统[44]和安全的多方计算[84]。但是这些方法具有显着的性能开销，仅适用于计算相对简单的有限用例更高的性能和一般选项是使用可信执行环境（TEE）。
TEE提供了一个完全隔离的环境可以防止其他软件應用程序，操作系统和主机所有者篡改甚至了解TEE中运行的应用程序的状态例如，Intel Software Guard eXtensions（SGX）提供了TEE的实现 Keystone-emblave项目[7]旨在提供开源TEE设计。
推动我们系统设计的关键观察是TEE和区块链的互补性一方面，区块链保证了其状态的强大可用性和持久性而TEE无法保证可用性（因为主机可以自行決定终止TEE）并且无法可靠地访问网络或持久存储。另一方面区块链具有非常有限的计算能力，并且必须暴露其整个状态以进行通用认证而TEE与本机计算相比产生最小的开销，并通过远程证明提供可验证的计算机密性 。因此构建兼具两者的混合协议似乎很有吸引力。
但昰协调TEE和区块链是一项挑战。当两个人完全粘在一起时会发生微妙的陷阱一个这样的陷阱源于基本限制
TEE：恶意主机可以随意操纵其调喥和I / O.因此，TEE可能随时终止对丢失和/或冲突的国家构成风险和挑战。 TEE（特别是SGX）中所谓的可信定时器只能提供“不早于”时间概念因为惡意主机也可以延迟读取时钟，因此这个问题更严重（通过总线传输的消息）因此，虽然很容易使用区块链来检查TEE的状态（例如[43]）但缺乏可靠的计时器使得TEE难以确定区块链的最新视图。正如我们稍后将要展示的那样n??vestate-checkpointing协议打开了倒带攻击（第III部分）。另一个有趣且危险的后果是看似无关的攻击向量起作用例如，受区块链的完整性攻击可能会损害受TEE保护的内容的机密性：例如攻击者可以通过提供偽造的区块链来逃避其执行并随意向其发送许多查询来逃避TEE强制执行。隐私预算已实施其他挑战包括容忍受损的TEE，在TEE崩溃时支持强大且┅致的故障转移以及飞地的密钥管理。我们系统地识别并解决了本文中的每个陷阱
遵循上述设计原则，我们提出了Ekiden一种高性能和保密的智能合约与可信计算系统。据我们所知Ekiden是第一个可以每秒执行数千笔交易的机密智能合约与可信计算系统。这一成就的关键是区块鏈和可信硬件的安全性和原则的结合 Ekiden将任何必需的底层区块链系统（允许或不允许）与基于TEE的执行相结合。锚定在正式的安全模型中
為了解决TEE的可用性和网络安全限制，Ekiden支持合同状态的链上检查点和（可选）存储因此，Ekiden支持跨不同信任域的长期智能合约与可信计算之間的安全交互为了解决潜在的TEE故障，例如侧信道攻击我们建议采取缓解措施以保持完整性并限制数据泄漏（第III-A节）。假设区块链完整性用户不需要信任智能合约与可信计算创建者，管理者节点运营商或任何其他实体的活跃性，持久性机密性或正确性。因此Ekiden支持洎我维持的服务，可以比任何单个节点用户或开发工作更长久
技术挑战和贡献。我们在Ekiden的工作解决了几个关键的技术挑战：
?正式的安铨建模：虽然直观清晰但Ekiden所需的所需和可实现的安全属性正式定义具有挑战性。我们以理想的FEkiden功能表达了Ekiden的全方位安全要求我们概述叻Universal Composability（UC）框架中的安全证明，该框架显示Ekiden协议在并发组合下匹配FEkiden
?混合TEE-区块链系统的原理方法：我们系统地列举了融合区块链和TEE所产生的基本缺陷，并提供了克服它们的一般技术此外，我们表明通过吸引加密理想功能，这些技术可以以原则性可证明安全性和高性能的方式应用，我们认为可以推广到广泛的混合TEE-区块链系统
?性能：区块链可能是TEE区块链混合系统的性能瓶颈。我们提供优化最大限度地減少区块链的使用而不降低安全性：我们表明他们实现了与未优化协议相同的FEkiden功能。
评价我们评估Ekiden在一系列应用程序上的性能，这些应鼡程序可以运用全系列的系统资源并演示Ekiden如何实现应用程序部署，否则由于隐私和/或性能问题而无法实现应用程序部署它们包括机器學习框架，我们在其中实施医疗诊断和信用评分应用程序智能建筑热模型和扑克游戏。我们还将以太坊虚拟机实现移植到Ekiden以便现有的匼同（例如，用Solidity编写）例如Cryptokitties [1]和ERC20令牌，也可以在我们的框架中运行我们报告开发工作，表明Ekiden中的编程模型有助于简单直观的应用程序开發在Ekiden流程交易中的合同比以太坊更快和更高的吞吐量2-3个数量级。我们的性能优化还极大地压缩了区块链上存储的数据量比基线提高了2-4個数量级。 （对于具有大型州的合同例如我们的令牌合同，读写操作的优势更大）
a）智能合约与可信计算和区块链：基于区块链的智能合约与可信计算是由与计划状态达成一致的参与者网络执行的程序。现有的智能合约与可信计算系统在系统中的所有节点上复制数据和計算这样单个节点就可以验证合同的正确执行。提供所有节点上的完全复制
1我们的系统名称Ekiden指的是这个属性 “Ekiden”是日本长距离接力跑仳赛的术语。
高水平的容错能力和可用性像以太坊[29]这样的智能合约与可信计算系统已经证明了它们在各种应用中的实用性。
但是一些關键的限制阻碍了当前智能合约与可信计算系统的更广泛采用。首先完全复制的智能合约与可信计算的链式计算本质上是昂贵的。例如在2017年8月，在以太坊智能合约与可信计算[29]中将两个数字加在一起一百万次花费26.55美元，比AWS EC2高出约8个数量级[69]此外，目前的系统不提供隐私保障用户通过假名识别。正如许多研究表明[67][56]，[59][68]，假名仅提供弱隐私保护此外，合同状态和用户输入必须是公开的以便矿工验证囸确的计算。缺乏隐私从根本上限制了智能合约与可信计算的应用范围
b）具有证明的可信硬件：Ekiden的关键构建块是可信执行环境（TEE），其保护计算的机密性和完整性并且可以发布证明（称为证明）计算正确性的证明。 Ekiden采用英特尔SGX [9][36]，[55]一种特定的TEE技术，但我们强调它可以使用任何具有证明能力的TEE例如正在进行的努力Keystone-emblave [7]旨在实现开源安全硬件飞地。我们现在提供关于TEE的简要背景重点是英特尔SGX。
英特尔SGX提供基于CPU的TEE实现 - 在SGX中称为飞地 - 用于通用计算主机可以实例化多个TEE，这些TEE不仅彼此隔离而且还与主机隔离。在TEE内运行的代码具有受保护的地址空间当来自TEE的数据从处理器移动到存储器时，它使用仅供处理器使用的密钥进行透明加密因此，操作系统管理程序和其他用户无法访问飞地的内存。 SGX内存加密引擎还可以保证数据完整性并防止内存重放攻击[34]英特尔SGX支持证明执行，即它能够通过发出远程证明，数芓签名使用只有硬件知道的私钥，通过程序和执行输出来证明程序的正确执行远程证明还允许远程用户为飞地建立加密和认证的通道[9]。假设对硬件的信任以及验证证明密钥的英特尔除了SGX平台之外的任何实体都不可能生成任何证明，即证明是存在性的不可伪造的
但是，由可信硬件实现的证明执行并不完美例如，仅SGX无法保证可用性恶意主机可以任意终止包围区或丢弃消息。即使是诚实的主人也可能茬发生电力循环时意外失去飞地新交所的弱势可用性对Ekiden的设计提出了根本性的挑战。此外最近对英特尔SGX的攻击表明，当前的实施通常會通过旁道泄漏信息[80][63]。 第III-A节中的通道电阻
在深入研究Ekiden的具体细节之前，我们首先描述并解决在协调TEE和区块链时出现的基本陷阱这些解决方案是Ekiden协议的构建模块，我们相信从Ekiden获得的见解将证明在混合TEE区块链系统中具有广泛的重要性
虽然设计用于执行通用程序，但可靠嘚硬件并不是万能的在这里，我们分析TEE的限制及其对TEE-区块链混合协议的影响
a）可用性故障：通常，可信硬件无法确保可用性在SGX的情況下，恶意主机可以终止飞地即使是诚实的主机也可能在电源循环中失去飞地。 TEE-区块链系统必须能够容忍此类主机故障确保崩溃的TEE最哆可以延迟执行。
我们的高级方法是将TEE视为可消耗且可互换的依靠区块链来解决由并发引起的任何冲突。为了确保任何特定的TEE易于替换TEE是无状态的，并且区块链存储任何持久状态我们稍后将讨论TEE如何在调用中保持软状态作为性能优化，但我们强调Ekiden中的技术确保在任何時候丢失此类状态都不会影响安全性
b）侧面渠道：尽管TEE旨在保护机密性，但最近的工作已经通过旁道攻击发现了数据泄漏现有防御通瑺是应用程序和攻击特定的（例如，加密库避免某些依赖于数据的操作[17]）;推广这种保护仍然具有挑战性因此，Ekiden在很大程度上推迟了对应鼡程序开发人员的保护
尽管对于所有侧通道攻击可能没有明确和实用的灵丹妙药，但仍然希望限制受损TEE的影响并在面临小规模妥协时提供优雅降级我们的方法是在空间和时间上划分区域。我们在Ekiden中设计了关键组件例如密钥管理器，针对强大的对抗模型允许攻击者打破一小部分TEE的机密性，并限制从其他组件访问密钥管理器我们还采用主动键旋转[35]来限制泄漏密钥的范围。密钥管理是TEE区块链系统可用性嘚基础如下所述。
c）定时器故障：TEE通常缺少可信时间源在SGX的情况下，虽然可信的相对定时器可用但是安全区和定时器之间的通信（甴CPU外组件提供）可以被OS延迟[41]，[40]此外，服务器级Intel CPU在撰写本文时不支持SGX计时器因此，TEE-区块链混合协议必须最小化对TEE计时器的依赖
我们的方法是设计不需要TEE来获得区块链的当前视图的协议。具体而言我们的技术不依赖于TEE来区分陈旧状态和当前状态（没有同步时钟，也没有對网络对手延迟来自区块链的消息的明确对策）我们的技术依赖于区块链来主动拒绝任何基于a的更新。陈旧的输入状态（更新中包含其散列）
丢失的计时器也使得TEE难以验证区块链中是否存在项目，即建立“发布证明”如[43]所述。然而[43]没有考虑TEE中缺乏可靠时间所造成的威胁 - 例如，注入旧的虚假的，易于控制的块 - 这在基于PoW的区块链中是至关重要的我们的一个贡献是一个基于时间的通用发布证明协议，咜可以防止网络对手延迟时钟读取正如我们现在简要解释的那样。
B. PoW区块链的出版证明
为了利用区块链作为持久存储TEE必须能够有效地验證项目是否已存储在区块链中。对于许可的区块链这种证明可以包含来自法定数量的共识节点的签名。为了建立基于PoW的区块链的发布证奣TEE必须能够验证新的块。如[23]所述需要一个可靠的计时器来防御隔离飞地并呈现无效子链的对手。不幸的是如上所述，通过安全信道（例如SGX定时器）的定时源不能保证有限的响应时间为了解决这个限制，我们利用TEE的机密性以便攻击者延迟计时器的响应不能阻止飞地荿功验证区块链内容。我们的解决方案甚至可以在没有SGX定时器的情况下工作例如，启用TLS的NTP服务器由于空间不足，我们将PoW区块链的出版粅证明协议下放到第XI节
使用区块链来保持TEE状态的一个基本限制是缺乏机密性。我们之前通过在上传到区块链之前要求对状态进行加密来展示如何避免此问题然而，这会导致另一个问题：如何持久加密密钥
通常，该方法是跨多个TEE复制密钥然而，另一方面是在面对机密性破坏时（例如通过旁道攻击）最小化关键的泄漏风险的挑战暴露风险和可用性之间通常存在基本的紧张关系：更高的复制因子不仅意菋着更好地恢复状态损失，而且意味着更大的攻击面因此，权衡和可实现的属性将取决于威胁模型
由于可能没有确定且实用的全系统側通道缓解，我们的方法是针对更强大的对抗模型设计密钥管理器允许攻击者破坏一小部分TEE的机密性，并限制访问权限其他组件。我們在第V-C节中概述了密钥管理协议
D.执行结果的原子交付
在区块链系统中，确保执行的原子性即执行e1，e2完成或不执行任何执行都是一个基本问题，例如原子交叉链互换[14]在TEE-区块链杂交中出现类似但更复杂的问题。
对于一般的有状态TEE区块链协议TEE执行产生两条消息：m1，它将輸出传递给调用者; m2它通过对抗通道将状态更新传递给区块链。我们强调强制执行两条消息的原子传递至关重要，即m1和m2都已传送或系统詠久不可用当呼叫者收到m1时，将传送m1新区域m2一旦被区块链接受即可交付。拒绝状态更新不被视为已交付
a）没有原子传递的攻击：要查看原子传递的必要性，考虑可能的攻击当它被违反时，即只传递两个消息中的一个
首先，如果只传送输出m1则可以进行倒带攻击。甴于TEE无法判断输入状态是否为新鲜因此攻击者可以提供陈旧状态以从旧状态恢复TEE的执行。这可以对随机TEE程序进行磨削攻击攻击者可能會反复回放，直到收到所需的输出另一个例子是倒带可能会破坏基于预算的隐私保护，例如差异隐私
另一方面，如果仅传递状态更新m2则用户可能会永久性地丢失输出，因为可能无法以更新的状态再现相同的输出
b）协议：假设TEE和呼叫客户端P之间的安全通信信道（实际仩可以用远程证明构建），我们通过以下两阶段协议实现m1和m2（上面定义）的原子传递：为了启动原子传递TEE从密钥管理器获得新的密钥k，並通过安全信道向P发送证明的mc1 = Enc（km1）。一旦P确认收到mc1TEE就会向区块链发送m2。最后在看到m2的出版证明πm2后，TEE将k发送给P.
上述协议实现了原子傳递一方面，由于TEE可以通过验证πm2来确定m2的传递因此仅在传递m2时才显示k。另一方面如果已经交付m2，则最终将释放k因为至少有一个TEE鈳用且密钥管理协议确保k的可用性。
在本节中我们概述了Ekiden的设计和安全属性。

图1：Ekiden架构和工作流程概述客户端向保密的智能合约与可信计算发送输入，这些合同在任何计算节点的TEE内执行区块链存储加密的合同状态。有关详细信息请参见第IV-B节。
作为激励我们工作的一個例子考虑一个信用评分应用程序 - 我们在第VI-A节中实现和报告的一个例子。贷款人保险公司和其他人广泛使用信用评分来评估消费者的信誉[8]。尽管收入可观（2017年为108亿美元[38]）但美国的信用报告行业集中在少数信用局[38]。这种集中化造成了巨大的单点故障和其他问题最近的數据泄露事件突显了影响近一半的美国人口[16]。
因此基于区块链的分散信用评分是一种有吸引力且受欢迎的替代方案。例如Bloom [48]是一家在以呔坊上提供信用评分系统的创业公司。然而他们的方案仅支持静态信用评分算法，该算法省略了重要的私人数据不能支持预测建模。這些应用程序受到当前智能合约与可信计算系统的两个关键限制的困扰：（1）缺乏保护敏感消费者记录所需的数据机密性（例如信用评汾的贷款服务历史）以及从中获取的专有预测模型和（2）无法实现处理全局工作负载所需的高性能。
为了支持信用评分等大规模隐私敏感的应用程序，必须满足这两个要求同时保留区块链提供的完整性和可用性 - 所有这些都不需要受信任的第三方。 Ekiden提供了一个机密值得信赖且高性能的平台，可以实现智能合约与可信计算执行的精确目标

从概念上讲，Ekiden为丰富的用户定义的智能合约与可信计算实现了安全嘚执行环境 Ekiden合同是一种确定性的有状态计划。在不失一般性的情况下我们假设合同程序采用以下形式（outp，stnew）：= Contract（stprevinp），作为输入摄取先前的状态stprev和客户端的输入inp并生成输出outp和新状态stnew。
一旦部署在Ekiden上智能合约与可信计算就具有很强的机密性，完整性和可用性保证 Ekiden通過结合可信硬件和区块链的混合架构实现了这些特性。
图1描绘了Ekiden的架构和Ekiden智能合约与可信计算的工作流程如图所示，Ekiden中有三种类型的实體：客户端计算节点和共识节点。
?客户是智能合约与可信计算的最终用户在Ekiden，一个客户可以使用秘密输入创建合同或执行现有合同在任何一种情况下，客户端都将计算委托给计算节点（下面讨论）我们希望客户端轻量级，允许移动和Web应用程序与合同进行交互
?計算节点实例化多个TEE以运行合同程序。他们还实例化了一项名为TEE中密钥管理的服务计算节点通过在合同TEE中运行合同并生成证明状态更新囸确性的证明来处理来自客户端的请求。具有支持TEE的平台的任何人都可以作为计算节点参与从而有助于系统的活跃性和可扩展性。计算節点还对密钥管理器中的合同执行密钥管理根据合同TEE的要求，密钥管理器TEE根据需要创建或检索现有密钥我们将密钥管理的细节推迟到苐V-C节。密钥管理器TEE通过区块链同步其状态
?共识节点通过运行共识协议来维护分布式仅附加分类帐，即区块链合同状态和证明持续存茬于此区块链中。共识节点负责使用TEE证明检查状态更新的有效性如下所述。
a）工作流程：我们现在概述合同创建和请求执行工作流程提供有关图1的更多详细信息。详细的正式协议在第V-B节中介绍
为简单起见，我们假设客户端具有要使用的计算节点的优先级列表在第XIII节Φ，我们描述了一个促进计算节点发现和负载平衡的协调器我们将客户端表示为P，将计算节点表示Comp
b）合同创建：在创建合同时，P发送┅份合同代码Contract给CompComp压缩负载合同进入TEE（此后称为合同TEE），并开始初始化合同TEE创建一个新的合同id cid，从密钥管理TEE中获得新的（pk^in_cidskin_cid）对和k^{state_cid并生荿加密的初始状态Enc（k}state_cid，0->）和证明σ_TEE证明初始化的正确性，pk^{in_cid是合同cid的相应公钥最后，Comp获得了σ_TEE正确性的证明通过联系证明服务（详见下攵）;这个证明和σTEE捆绑在“认证”证明π中。然后Comp将（Contractpk}in，Enc（k^{state_cid0->），π）发送给共识节点。合同创建的完整协议在Prot_Ekiden的“create”调用中指定（图2）共识节点在接受Contract之前验证π，加密的初始状态和pk}in_cid为有效并将其放置在区块链上。
c）请求执行：图1所示的请求执行步骤如下：
(5a, 5b)最后Comp和P進行原子递送协议，该协议将outp递送到P和（st'ctπ）到共识节点。我们将原子传递的细节推迟到第III-D部分。简而言之图1中的步骤5a和步骤5b以原子方式执行，即当且仅当（st'_ct，π）被共识节点接受时，outp才被显示给P共识节点在接受新状态为有效并将其置于区块链之前验证π。

d）并发：Ekiden计算节点同时接收输入并生成状态更新。因此竞争条件是可能的，但是由共识层处理如果两个计算节点同时更新相同的状态，则共識层只接受一个被拒绝的计算节点将通知客户端重试。

e）将共识与计算分离：与以太坊相反其中合同执行由区块链中的所有节点复制鉯达成共识，Ekiden将共识与合同执行分离对于每个客户端请求，合约仅需要由K个计算节点针对一些小K（安全性参数）执行（例如在图1中，峩们设置K = 1这在实践中可能是合理的选择）。
对于合同执行的细节不可知共识节点只需要验证由TEE生成的π。在我们的实现中，Comp从英特尔證明服务（IAS）获得π[39]。由于SGX证明是一个组签名因此作为组管理的IAS可以促进其验证。为了验证证明σ_TEE的正确性Comp首先将σ_TEE发送给IAS，IAS回复“認证”证明π：=（bσ_TEE，σ_IAS）其中b∈{0,1}表示σ_TEE和σ_IAS的有效性是IAS在b和σTEE上的签名。由于π只是一个签名，共识节点既不需要可信硬件也不需要联系IAS来验证它
在这里，我们总结了Ekiden的安全目标简而言之，Ekiden旨在支持执行通用合同同时强制执行以下安全属性：
a）正确执行：合同狀态转换反映了在给定状态和输入上正确执行合同代码。
b）一致性：区块链在任何时候都存储与每个计算节点的视图一致的单个状态转换序列
c）保密：在没有任何TEE违规的期间，Ekiden保证合同状态和诚实客户的输入对所有其他方保密此外，Ekiden可以抵御一些被破坏的密钥管理TEE
d）優雅的机密性降级：如果在计算节点（与密钥管理器节点相对）中发生机密性破坏，Ekiden提供前向保密和与受影响的TEE的合理隔离具体来说，假设在t处发生机密性泄露攻击者最多可以访问历史直到t-Δ，其中Δ是系统参数。此外，受损的TEE只能影响合同的子集。
非目标：Ekiden不会阻止匼同级泄漏（例如通过隐蔽通道错误或侧通道）。因此合同开发商有责任确保通过公共产出不泄露任何秘密，并且合同没有错误和副渠道我们将在第V-E节讨论支持的缓解措施。
a）TEE：最近的工作表明SGX飞地的机密性可能会受到旁道攻击的影响。鉴于这种威胁我们假设对掱可能会损害一小部分TEE的机密性。如上所述影响取决于违规是否会影响密钥管理器或计算节点。我们假设TEE硬件以其他方式正确实施和安铨制造
b）区块链：Ekiden旨在与基础共识协议无关。只要满足下面指定的要求它就可以部署在任何区块链实现之上。
我们假设区块链将正确執行规定的计算并始终可用特别是，Ekiden依靠共识节点来验证证明我们进一步假设区块链提供了一种有效的方法来构建区块链上的项目包含证明，即公开证明如第III-B节所述。
c）威胁模型：系统中的所有各方都必须信任Ekiden和TEE我们假设攻击者可以控制除一个计算节点之外的所有操作系统和网络堆栈。在受控节点上攻击者可以对消息进行重新排序并任意调度进程。我们假设攻击者可能会损害一小部分（例如f％）TEE嘚机密性攻击者可以观察全球网络流量，并可以任意重新排序和延迟消息
对手可能会破坏任意数量的客户。客户端不需要自己执行合哃也不需要可信硬件。我们假设诚实的客户信任他们自己的代码和平台但不信任其他客户。每份合同都有明确的政策规定如何处理數据和处理请求。 Ekiden没有（并且不能合理地）阻止合同通过软件错误有意或无意地泄露秘密

V.协议细节和安全证明
在本节中，我们指定了Prot_Ekiden即Ekiden的协议实现。它旨在实现通用可组合性（UC）[20]理想功能FEkiden我们因缺乏空间而推迟到X部分，并鼓励读者进行咨询在第十二节中，我们证明Prot_Ekiden UC實现了FEkiden
a）证明执行：为了在可信硬件上正式模拟证明的执行，我们采用了[65]中定义的理想功能Gatt非正式地，一方首先将程序prog加载到具有“咹装”消息的TEE中在“恢复”调用中，程序在给定输入上运行生成输出outp以及证明σTEE=ΣTEE.Sig（skTEE，（progoutp）），硬件密钥skTEE下的签名公钥pkTEE可以从Gatt.getpk（）获得。有关详细信息请参见[65]。
实际上允许TEE输出未包含在证明中的数据是有用的。我们稍微扩展Gatt以允许这样：如果TEE程序prog产生一对输出（outp1outp2），证明只签署outp1即σTEE=ΣTEE.Sig（skTEE，（progoutp1））。常见的模式是在outp1中包含outp2的散列以允许各方分别验证σTEE和outp2。在[81]中使用了类似的技术
按照[44]，[78]Φ的表示法我们使用契约包装（在图9中定义）抽象出常规功能，例如状态加密密钥管理等。用包装器增加的合约c表示为^c
[succ]（在X节中给絀）定义了一个由通用区块链协议实现的通用附加分类账（在附录中的图8中正式定义）。参数succ是一个函数它指定要添加到存储的新项的條件，对事务有效性的概念进行建模我们保留区块链的仅附加属性，但是抽象地在块中包含状态更新我们假设将区块链数据与id相关联嘚重叠语义。除了读取和写入接口之外Fblockchain还提供了一个方便的界面，客户可以通过该界面确定区块链中是否包含某个项目实际上，该接ロ避免了下载整个区块链的开销
c）参数化Fblockchain：在Ekiden中，存储的内容被解析为状态转换的有序数组定义为trans_i =（H（st_i-1），st_iσ_i），前一状态的散列嘚元组新的状态，以及来自TEE的证明证明了状态转型的正确性。 （请注意作为一种性能优化，大型用户输入 - 例如ML合同中的训练数据 - 可能不会存储在链上）存储可以被解释为一个特殊的初始状态，后面跟着一系列状态转换：存储=（ （合约st_0，σ_0）{trans_i}i≥1）。
要使状态转换囿效它必须扩展最新状态，并且证明必须验证形式上，这是通过使用后继函数succ（·，·）参数化Fblockchain来实现的这样succ（存储，（hst_new，σ_TEE））=真当且仅当h = H（st_prev）其中st_prev是存储中的最近状态和ΣTEE.Vf（pk_TEEσ_TEE，（hst_new））。这保证了在任何时候都存在与每一方的视图一致的单个状态转换序列即状态转换链是无分叉的。
a）共享状态密钥：每个合同都与一组密钥相关联如第V-C节所述，合同TEE将密钥管理委托给密钥管理器TEE在ProtEkiden中，使用keyManager函数抽象出与密钥管理器的通信
b）合同创建：为了在Ekiden中创建合同，客户端Pi使用输入合同（一段合同代码）调用计算节点Comp的create子程序Comp
c）请求执行：执行合约请求cid，客户端Pi首先从F_blockchain获得输入加密密钥pk^in_cid然后Pi调用Comp的请求子程序
如图9所示，如果σ_Pi验证则合约TEE用从密钥管理器获嘚的密钥解密st_ct和inp_ct，并执行合约程序Contract以获得（st_newoutp）。为确保新状态和输出以原子方式传递Comp和Pi进行原子传递定义如同第III-D节中规定的协议：
?Pi通过调用Comp的声明输出子程序来确认接收，触发合同TEE将m1 =（st'_ctoutp_ct，σ）发送到Fblockchain σ保护m1的完整性，并以加密方式将新状态和输出绑定到先前的状態和输入因此恶意Comp不能篡改它。

每个Ekiden合约都与一组密钥相关联包括用于状态加密的对称密钥和用于加密客户端输入的密钥对。这里我們讨论这些key的生成分发和流转。
1）对抗模型：我们认为对手可以打破TEE的某些部分（例如f％）的机密性例如通过旁道攻击。 f的确切值取決于部署和注册模型如果注册仅限于管理良好的节点，例如由有能力且声誉良好的组织托管的节点则f可以是非常低的值。但是当部署茬更开放的环境中时f需要相当高。我们假设参与的主机具有（至少部分）Sybil抗性身份实现此目的的一种方法是要求安全存款加入协议。
此外我们假设任何时候有足够多（例如超过2f％）的参与者在线，以便保留密钥的可用性在实践中，参与可以通过经济奖励和惩罚来激勵我们将激励设计留给未来的工作。
2）期望的属性：由于解密密钥最终显示给合约TEE因此TEE本身也回受到损害，主动使用的密钥（即热键）必须是短期的从较少暴露的长期主密钥中获得。理想情况下密钥管理协议应满足以下属性：
?机密性：对手（在我们的模型中）不能泄露长期主密钥。
?可用性：诚实合约TEE始终可以访问解密密钥
?前向保密：如果短时密钥在时间t受到损害，则对于某些系统参数Δ，它不能用于解密在t-Δ之前加密的消息。
3）构建块：下面我们概述了满足上述要求的密钥管理协议我们首先简要回顾一下构建模块，包括汾布式密钥生成（DKG）协议和分布式伪随机函数（PRF）
a）分布式密钥生成（DKG）：DKG协议（例如[32]）允许一组N方生成无偏的随机密钥。 DKG协议的运行結果是一个秘密但是使用秘密共享方案（通常是Shamir）的各方共享。
b）分布式PRF：非正式地PRF是函数F = {f_s}s∈S的集合，使得对于随机索引s←$ Sf_s（·）与随机函数无法区分。Naor等人[60]引入分布式PRF，这样拥有s的份额的各方可以在不重建s的情况下评估fs（·）。具体来说，让G为Schnorr组，g为生成元设H：{0,1} →G为散列函数，[60]表示fs（x）= H（x）s是PRF族
假设使用（k，n）-secret在各方之间共享s分享模式为了评估fs(x)，i方简单地计算并输出yi = H(x)^s_i用其共享s_i计算。在收集至少k + 1的{yi}之后可以通过指数中的多项式插值得出fs(x)：
a）主要管理委员会和长期关键：
假设Sybil抗性身份，我们可以从参与者中抽取N个节点形荿一个密钥管理委员会（KMC）。 N是系统参数在初始化合同c时，KMC运行DKG协议以生成长期密钥kc以便使用（?fN?，N） - 秘密共享方案在KMC成员之间秘密共享kc先前关于主动秘密共享的工作（例如[35]，[71]）可用于定期轮换委员会而不改变秘密 [71]也允许委员会动态扩展。
b）生成短期密钥：假设短期密钥每个时代都到期获得合同的短期关键在时间t，计算节点Comp首先建立安全通道并与KMC中的成员进行身份验证一旦验证Comp确实正在执行c，每个KMC成员i计算k_c,t,i = H(t)^(ki_c)并将kct，i发送给Comp后
收集来自A?KMC的f + 1结果，Comp 能用kc构造周期t的短期密钥t =?kλii∈Ac，ti（---TODO 公式）其中λi是拉格朗日系数。
c）违反隔离：我们主动隔离机密通过为每个计算节点强制执行隐私预算为此，我们假设合同TEE具有不可伪造的主机标识（例如SGX中的可链接EPID公鑰提供了一个）。密钥管理器节点为每个计算节点Comp维护计数器K_Comp以记录查询的数量计数器随着周期的推进而重置。仅当某些系统参数κ的K_Comp<κ时，密钥管理器节点才满足查询。有了这个，无论被破坏的计算节点产生多少TEE它最多都可以获得κ个密钥。实际上，对耗尽的诚实计算节点的请求可以重定向到其他节点，从而仅产生适度的开销。
定理1描述了ProtEkiden的安全性证明草图在第XII节中给出。
定理1（ProtEkiden的安全性）假设Gatt的證明方案ΣTEE和数字签名Σ在选择的消息攻击（EU-CMA）下是存在不可伪造的，H是第二个前映像抗性并且AE和SE是IND-CPA安全的。然后ProtEkiden在（GattFblockchain） - 混合模型中咹全地实现了FEkiden，用于静态对手
E.减轻应用程序级别的泄漏
虽然Ekiden保护TEE内部数据，但它并非旨在保护合同接口处的数据即合同设计导致的数據泄漏。 （例如可以通过客户端查询“提取”秘密预测模型[77]。）最小化此类泄漏的常用方法例如，基于请求者身份或差异隐私预算来限制请求[27][42] ，需要持久性计数器SGX的单调计数器是不值得信赖的[53]。
Ekiden通过启用持久应用状态（例如计数器总消耗的差异隐私预算等）来支歭有状态的方法来缓解应用程序级别的隐私泄漏，从而在链上安全地维护此外，上述原子传递保证确保仅在正确更新此状态时才显示输絀
给定一个额外的撤销机制，一个简单的修改就消除了对IAS的依赖而不是初始化。初始化时安全区会创建签名密钥（pk，sk）并输出带囿证明的pk。随后证据被替换为sk下的签名。由于pk绑定到TEE代码（通过初始证明）sk下的签名证明了输出的完整性，就像证明一样与其他键┅样，（pksk）由密钥管理器管理（参见章节V-C）。
在第XIII节中我们讨论了协议的扩展版本以及其他几个性能优化。

a)理想功能：我们在图7中定義了理想功能Fekiden的安全目标Fekiden允许各方创造合约并与他们交互。
每一方Pi被一个唯一的id定义简单的以Pi表示。各方通过验证通道发送消息从加密数据中捕捉泄露的允许信息，我们遵从【20】的约定并参数化Fekiden使用一个泄露函数l(·)我们使用标准延迟输出术语【20】来建模网络对手的仂量。特别是当Fekiden发送一个延迟输出到P，这意味着输出首先被发送到的对手方A并经其确认后转发给P如果消息是秘密的，只有容许的数量嘚泄露显示给S
一个合约时一个用户提供的程序，比如智能合约与可信计算每一个合约都关联一块存在的存储存放合约代码和st。存储是公开的Fekiden允许任何一方，包括A读取存储内容。信息泄露通过这种读取方式仍然被泄露函数l定义
用户能发送请求到Fekiden来执行合约代码，使鼡用户提供的数据合约的执行将得到秘密的输出（outp）返回给调用者，同时一个秘密的转变到一个新的合约状态（st'）直观地等同于一个嫼盒合约执行（模漏）。尽管任意一方可以发送消息到合约合同代码可以根据传递给合同的调用假名强制执行访问控制。
b)会话ID（SID）：在UC【20】中每个功能实例和唯一的会话ID(SID)关联。SID对于组合定理至关重要因为它确保并发的协议实例彼此分离。为了减少混乱我们在Fekiden中忽略叻SIDs的处理。
c)威胁模型：Fekiden采用标准的威胁模型【20】A可以破坏任意数量的客户端，最多只能破坏一个合同执行者当A破坏一个TEE(或者类似于一方），A发送消息（“corrput”eid）到Fekiden。如果一个请求包含一个非法的TEEidFekiden抛出错误如果它是A构建的话。否则这完美的功能忽略eids，后者被包含在Fekiden中僅作为一个技术需要用来确保接与Portekiden兼容在下文中给出来。
d)正式安全和隐私保证：Fekiden封装了如下安全和隐私属性首先，查询执行正确反映匼约创建者提供的代码第二，输出和新状态被原子分离的举例来说，输出仅在新转台提交的时候才会被显示出来我们在第三节D中讨論了这个属性的实现。
Fekiden提供隐私性的意义在意无论其他方或者对手方学习诚实方的秘密输入会比允许泄露的l更多一个客服端与合约互动，不会学习到超过它的输入和输出合约状态对于所有方都是保密的，A包括除非故意通过输出来显示。然后合约代码是公开显示的，所以用户可以检查它在使用之前我们将支持隐私合约代码的工作留到未来（比如使用一个类似的技术【72】）。

发表协议的证明（图10）包含了一个验证者E以合约TEE的形式，和一个非置信的证明者P高级的想法是仅仅给予P一个有限时间去发布block中的消息在一个足够难度的子链中，因此一个对手方不能可行的伪造它
E存储了一个近期的区块链中的检查点区块CB，来自于某一个难度的δ(CB)比如，在区块nonce中左边的零可鉯被计算。E将发出一个（可证明的）CB版本给任意请求的客户端让其去验证CB的新鲜给予一个合法的近期CB，E能验证新区块基于δ(CB)假设那个難度是相对固定的。（为了简化我们的分析我们假设一直存在难度，但我们的分析可以在有限难度变化的假设下得到扩展）
去初始化m嘚出版，E调用定时器获得一个时间戳t1正如讨论中的，E会在一哥延时之后收到t1收到t1之后（可能比t1更晚），E产生了一个随机nonce r并需要一个证奣者去发布（mr）。根据从PE接收到的一个证明π(m,r)（一个自恋包含（m，r））再次调用计时器获得t2
设nc为（m，r）中的确认次数τ是预期的块间隔（区块链的不变量），ε是乘法松弛因子，它考虑生成块的时间的变化，这是一个随机过程。例如ε= 1.5意味着允许π（m，r）的产生比主链上的预期慢1.5倍只有当t2 -t1 <nc×τ×ε时，E才接受π（m，r）上述协议在图10中规定。

 将ε设置为高值会降低错误拒绝的可能性（即，在主链增长在某个时间范围内非常缓慢时拒绝来自诚实P的证据）。然而，高ε也增加了错误接受的可能性即接受伪造的子链。对于任何ε> 1可能需偠足够大的nc，以便成功攻击的概率可以忽略不计然而，大的nc意味着诚实的P需要等待很长时间才能获得输出这会影响Ekiden的用户体验。
 对于控制区块链网络总挖掘功率的p分数的攻击者我们在表I中提供了nc和ε的示例性具体参数。例如，对于具有25％散列功率的强大攻击者（大致昰已知存在的最大挖掘池）在撰写本文时，在比特币和以太坊中）设置nc = 80和ε= 1.6意味着攻击者需要预期的2112哈希来伪造出版证明^ 3，而诚实的证據将以2-19的概率被拒绝在最近提出的基于Tesseract TEE的加密货币交换[14]中使用了类似的块同步技术和分析。
 很容易看出延迟计时器的响应不会给攻击鍺提供比t2-t1更多的时间。延迟时间戳t1缩短了这个明显的时间间隔使攻击者处于不利地位。通过发布空消息可以使用相同的协议更新E的检查点块。请注意一旦TEE成功发布消息，其他TEE可以通过证明建立的安全通道获取证明从而节省重复协议的成本。

XIII.主要原理的证明
这里我们給出原理1的证明在V节中给出。

证明让Z成为一个环境而A是一个“虚拟对手”[20]，他只是简单地在Z和各方之间传递信息为了表明ProtEkiden UC-实现FEkiden，我們在下面指定一个模拟器Sim这样没有环境可以区分ProtEkiden和A之间的交互与FEkiden和Sim的交互，即Sim满足
a）Sim：Sim的构建通常如下：如果一个诚实的一方向FEkiden发送消息则Sim使用从FEkiden获得的信息模拟Z的适当的真实世界“网络流量”。如果被腐败的一方向FEkiden发送消息Sim将在FEkiden的帮助下提取输入并与损坏的一方进荇交互。我们提供有关特定消息处理的更多详细信息
在这两种情况下，Sim都代表对手或诚实的各方模拟Blockchain和Gatt之间的互动

(3)公开读取：在Pi的任哬调用（“read”，cid）上Sim模拟向Fblockchain发送的“读取”消息。如果Pi被破坏Sim代表Pi向FEkiden发送“读取”消息并将响应转发给A.

当Z腐蚀它们时，Sim获得损坏的飞哋的eids在现实世界中，Z可以在任何时候终止腐败的飞地或者可以策略性地丢弃一些消息，同时允许其他人通过为了忠实地模仿Z的“伤害”，Sim将每个留下或进入破坏的飞地的消息发送给Z并且只有在Z允许的情况下才发送消息。如果模拟执行过早地被Z终止则Sim指示FEkiden中止。具體地在从FEkiden接收（cid，l（st'）l（outp），eid）时只有当Z允许来自Gatt的相应“输出”消息时，Sim才回答“ok”
b）Sim的有效性：我们表明，没有环境可以通過混合参数区分与A和ProtEkiden的交互与Sim和FEkiden的交互考虑一系列混合，从真正的协议执行开始
Hybrid H1让Sim模仿Gatt和Fblockchain。 H2过滤掉针对ΣTEE的伪造攻击 H3过滤掉针对哈唏函数的第二次前映像攻击。 H4让Sim模拟创建阶段 H5用加密0替换输入和输出的加密，并用具有相同长度的随机字符串替换状态加密相邻杂种の间的必要性如下所示。
由于A中的A视图在现实世界中被完美模拟因此Z无法区分H1和实际执行。
除了以下修改之外混合H2在H1中继续进行。如果A使用正确的消息调用Gatt则合同和σTEE是skTEE下的证明。设Ω表示所有这些元组的集合。每当A向Fblockchain或一个诚实的派对Pi发送一个证明输出（outpσTEE）?∈Ω时，Sim就会中止。
H1和H2之间的不可区分性可以通过以下对Σ的EU-CMA属性的减少来显示：在H1中如果A向Fblockchain或Pi发送伪造证明，Fblockchain或诚实方Pi的签名验证将夨败除了概率可以忽略不计。如果Z可以区分H2和H1Z和A可以用来赢得签名伪造的游戏。
除了以下修改之外杂合H3与H2相同。如果A使用正确的“請求”消息调用Gatt则Sim在输出之前记录执行结果outpct。每当A向Gatt发送“声明输出”消息时输入输出以前不是由Gatt生成的，Sim就会中止
H3和H2之间的不可區分性可以通过降低散列函数的第二前映像电阻特性来显示。在H2中A通过“请求”调用从Gatt获得H =?H（outpict）?和?i?iO = outpct i。如果A发送具有outpct?∈O嘚“声明输出”消息则Gatt中止，除非H（outpct）∈H如果Z可以将H3与H2区分开，则遵循A可以打破第二前映像抵抗性
混合H4与H3相同，但Sim模仿合同创建即诚实的派对将向FEkiden发送“创建”。 Sim如上所述模拟来自Gatt和Fblockchain的消息如果Pi被破坏，Sim将（“创建”合同）作为Pi发送给FEkiden。
很明显A的视图分布与H3唍全一样，因为Sim可以完美地模拟Gatt和Fblockchain
混合H5与H4相同，只是诚实的各方也向FEkiden发送“请求”消息如果Pi被破坏，Sim将在FEkiden的帮助下模拟真实世界的消息如上所述。
在A的观点中H5和H4之间的差异如下。
|的随机字符串在产生状态时由FEkiden选择

H5和H4之间的不区分可以是直接的
降低到AE和SE的IND-CPA属性。在鈈知道密钥的情况下A无法区分->0的加密和其他消息的加密。请注意我们不需要IND-CCA安全性，因为A无法直接访问解密oracle
仍然需要观察H5与理想方案相同。在整个模拟过程中我们保持以下不变量：FEkiden始终拥有最新状态，无论谁创建合同以及谁查询了合同这种不变性确保H5精确地反映叻FEkiden的理想执行。

在本节中我们将讨论对简单协议的几种性能优化。这些优化共同减少了区块链所需的往返次数和存储容量并减少了计算节点的工作量。正如我们在第VII节中所展示的那样影响是显着的，对于写入繁重的工作负载来说效果要高出200％。尽管性能有所提高泹所有优化对安全接口都是透明的：我们对简单和扩展协议使用相同的理想功能。我们提出了一个正式的协议块用于定义图11中的增强协議Protfull.Ekiden目前，我们提供了对每个应用程序所涉及的洞察力和挑战的高级描述
a）使用预写日志：在原始协议中，在每次查询后将整个加密状态stct寫入区块链整个状态需要重新加密，因为修改副作用不应泄露给对手的信息但是，当每个st非常大但每个查询只修改一小部分时这种方法效率很低。例如在我们的令牌应用程序中，我们为具有500,000个不同用户帐户的令牌建模即使每个事务仅扣除一个帐户并相互抵消。
我們的第一个观察是使用预写日志可以减少这笔费用我们修改协议，以便只将状态的“差异”Δstct写入区块链为了确定当前状态，包围区必须从初始状态开始解析整个diff序列并应用每个补丁。在令牌应用程序中每个事务触及恒定数量的记录，因此如果存在M个用户，则与簡单协议中的O（MT）相比T事务需要O（M + T）存储复杂度。
diffΔstct的加密可能泄漏有关调用哪个查询的信息令牌应用程序具有常量时间查询，但在┅般应用程序中可能需要绑定查询的大小并填充密文。最后我们注意到理想的功能FEkiden由泄漏函数l参数化，因此符号用于模拟由未填充查詢产生的效果泄漏
b）在飞地中缓存中间状态：在简单协议中，每一轮开始从区块链中读取状态密文然后从区块链中写入下一个状态密攵。在我们的扩展协议中我们乐观地使用Cache中的先前状态（如果可用）。当相同的包围区域用于多个顺序查询时这导致性能提高。当预寫日志变大时这尤其有用。
每当查询被发送到新的飞地时似乎都需要从创世开始引导（例如，因为先前使用的飞地主机已经崩溃）茬实践中，我们还通过在每个固定数量的间隔之后存储整个状态（不仅仅是差异）来为检查点定义策略我们将这种概括的正式介绍留给未来的工作。
c）离线批处理事务：就像上面的缓存优化消除了从每个查询中的区块链中读取的需要一样我们也可以将多个顺序查询的写叺合并到区块链的单个消息中。这减少了网络往返次数以及总通信成本当批处理中的多个查询写入同一位置时，只需要将最后一次写入存储在区块链中
在我们的协议中，我们没有为批量中必须进行的事务定义策略相反，我们正式将此选择暴露给对手批量策略的选择對我们形式主义的安全保障没有影响。每个查询调用只是将输入存储在缓冲区中并且攻击者可以随时调用commitBatch方法来提交整个缓冲区。
配料鈈是灵丹妙药为了保持安全性，除非更新状态Δstct在区块链中提交否则解密输出不得离开包围区。因此在提交整个批处理之前，用户無法从查询接收输出因此只有与输入无关的查询才能出现在同一批处理中。
d）协调计算节点的选择：Eki-den协议将其留给客户端来决定查询哪個计算节点和包围区无论这种选择如何，FEkiden的所有安全保障都会成立作为一种实用的解决方案，我们建议让客户遵循集中协调器这些協调器根据声誉和先前的经验执行负载平衡以及将计算节点随机分配给任务。如果某个任务在一些超时后没有完成协调器可以通知客户端在另一个飞地重复查询。随机化可以确保主机无法自适应地选择特定目标任务来降低服务质量通过这种方式，Ekiden可以防止对手降低目标應用程序的服务质量