智能合约是数字化强制执行的协议，强制执行不信任方之间的协议。通常在区块链上强制执行，它们通过强大的完整性保证来强制执行信任：即使是智能合约的创建者也无法修改其代码或破坏其执行。已经提出了智能合约来改善各行各业的应用，包括金融，保险，身份管理和供应链管理。
智能合约继承了一些不受欢迎的区块链属性。为了在共识期间验证状态转换，区块链数据是公开的。结果，现有的智能合约系统缺乏机密性或隐私性：它们不能安全地存储或计算敏感数据（例如，拍卖出价，金融交易）。区块链共识要求也妨碍了在计算能力，存储容量和事务吞吐量方面表现不佳的智能合约。以太网是最受欢迎的分散式智能合约平台，目前几乎专门用于技术简单的应用程序（如令牌），并且可以比普通的云计算环境产生大量成本（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个数量级。 （对于具有大型州的合同，例如我们的令牌合同，读写操作的优势更大。）
II。背景
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]。 Ekiden与现有的防御相兼容[17]，[61]，[51]，[78]，[66]。我们讨论方面
第III-A节中的通道电阻。
III。 TEE-BLOCKCHAIN的技术挑战
混合系统
在深入研究Ekiden的具体细节之前，我们首先描述并解决在协调TEE和区块链时出现的基本陷阱。这些解决方案是Ekiden协议的构建模块，我们相信从Ekiden获得的见解将证明在混合TEE区块链系统中具有广泛的重要性。
A.容忍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节。
C. TEE中的密钥管理
使用区块链来保持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（k，m1）。一旦P确认收到mc1，TEE就会向区块链发送m2。最后，在看到m2的出版证明πm2后，TEE将k发送给P.
上述协议实现了原子传递。一方面，由于TEE可以通过验证πm2来确定m2的传递，因此仅在传递m2时才显示k。另一方面，如果已经交付m2，则最终将释放k，因为至少有一个TEE可用且密钥管理协议确保k的可用性。
IV。 EKIDEN概述
在本节中，我们概述了Ekiden的设计和安全属性。

image.png

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

B. Ekiden概述
从概念上讲，Ekiden为丰富的用户定义的智能合约实现了安全的执行环境。 Ekiden合同是一种确定性的有状态计划。在不失一般性的情况下，我们假设合同程序采用以下形式（outp，stnew）：= Contract（stprev，inp），作为输入摄取先前的状态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给Comp。Comp压缩负载合同进入TEE（此后称为合同TEE），并开始初始化。合同TEE创建一个新的合同id cid，从密钥管理TEE中获得新的（pk^in_cid，skin_cid）对和k^{state_cid并生成加密的初始状态Enc（k}state_cid，0->）和证明σ_TEE，证明初始化的正确性，pk^{in_cid是合同cid的相应公钥。最后，Comp获得了σ_TEE正确性的证明通过联系证明服务（详见下文）;这个证明和σTEE捆绑在“认证”证明π中。然后Comp将（Contract，pk}in，Enc（k^{state_cid，0->），π）发送给共识节点。合同创建的完整协议在Prot_Ekiden的“create”调用中指定（图2）。共识节点在接受Contract之前验证π，加密的初始状态和pk}in_cid为有效并将其放置在区块链上。
c）请求执行：图1所示的请求执行步骤如下：
(1)要启动使用输入inp执行合同cid的过程，P首先从区块链获得与合同cid相关联的pk^in_cid，计算inp_ct = Enc（pk^in_cid，inp）并向Comp发送消息（cid，inp_ct），如Prot_Ekiden的第8-11行。
(2)每个合同还与秘密状态密钥k^state_cid相关联并只合同和密钥管理知悉。当执行一个合同时，Comp从区块链中检索合同代码和st_ct：= Enc（k^state_cid，st_prev），加密的先前合同cid状态，并将st_ct和inp_ct加载到TEE中并开始执行，如第30行所述-33 of Prot_Ekiden。
(3-4)从密钥管理TEE，合同TEE获得k^{state_cid和sk}in_cid，用于解密st_ct和inp并执行，生成输出outp，新的加密状态st'_ct：= Enc（k^state_cid，st_new），以及签名π，证明正确的计算，如第7-13行所述。 TEE Wrapper（图9）。密钥管理在第V-C节中讨论。
(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来验证它。
C. Ekiden安全目标
在这里，我们总结了Ekiden的安全目标。简而言之，Ekiden旨在支持执行通用合同，同时强制执行以下安全属性：
a）正确执行：合同状态转换反映了在给定状态和输入上正确执行合同代码。
b）一致性：区块链在任何时候都存储与每个计算节点的视图一致的单个状态转换序列。
c）保密：在没有任何TEE违规的期间，Ekiden保证合同状态和诚实客户的输入对所有其他方保密。此外，Ekiden可以抵御一些被破坏的密钥管理TEE。
d）优雅的机密性降级：如果在计算节点（与密钥管理器节点相对）中发生机密性破坏，Ekiden提供前向保密和与受影响的TEE的合理隔离。具体来说，假设在t处发生机密性泄露。攻击者最多可以访问历史直到t-Δ，其中Δ是系统参数。此外，受损的TEE只能影响合同的子集。
非目标：Ekiden不会阻止合同级泄漏（例如通过隐蔽通道，错误或侧通道）。因此，合同开发商有责任确保通过公共产出不泄露任何秘密，并且合同没有错误和副渠道。我们将在第V-E节讨论支持的缓解措施。
D.假设和威胁模型
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.符号和初步
a）证明执行：为了在可信硬件上正式模拟证明的执行，我们采用了[65]中定义的理想功能Gatt。非正式地，一方首先将程序prog加载到具有“安装”消息的TEE中。在“恢复”调用中，程序在给定输入上运行，生成输出outp以及证明σTEE=ΣTEE.Sig（skTEE，（prog，outp）），硬件密钥skTEE下的签名。公钥pkTEE可以从Gatt.getpk（）获得。有关详细信息，请参见[65]。
实际上，允许TEE输出未包含在证明中的数据是有用的。我们稍微扩展Gatt以允许这样：如果TEE程序prog产生一对输出（outp1，outp2），证明只签署outp1，即σTEE=ΣTEE.Sig（skTEE，（prog，outp1））。常见的模式是在outp1中包含outp2的散列，以允许各方分别验证σTEE和outp2。在[81]中使用了类似的技术。
按照[44]，[78]中的表示法，我们使用契约包装（在图9中定义）抽象出常规功能，例如状态加密，密钥管理等。用包装器增加的合约c表示为^c。
b）区块链：Fblockchain [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（存储，（h，st_new，σ_TEE））=真当且仅当h = H（st_prev）其中st_prev是存储中的最近状态和ΣTEE.Vf（pk_TEE，σ_TEE，（h，st_new））。这保证了在任何时候都存在与每一方的视图一致的单个状态转换序列，即状态转换链是无分叉的。
B.议定书的正式规范
Ekiden协议在ProtEkiden中正式指定（图2）。 ProtEkiden依赖于Gatt和Fblockchain，这是证明执行和区块链的理想功能。 ProtEkiden还使用数字签名方案Σ（KGen，Sig，Vf），对称加密方案SE（KGen，Enc，Dec）和非对称加密方案AE（KGen，Enc，Dec）。
a）共享状态密钥：每个合同都与一组密钥相关联。如第V-C节所述，合同TEE将密钥管理委托给密钥管理器TEE。在ProtEkiden中，使用keyManager函数抽象出与密钥管理器的通信。
b）合同创建：为了在Ekiden中创建合同，客户端Pi使用输入合同（一段合同代码）调用计算节点Comp的create子程序。Comp
将Contract加载到TEE并开始初始化，调用“create”函数。如图9所示，合同TEE创造一个新的合同cid，获得新的（pk^in_cid，skin_cid）对和k^{state_cid来自密钥管理器并生成一个加密的初始状态st_0和证明σ_TEE。证据证明了st被正确初始化并且pk}in_cid是合同cid的相应公钥。计算节点Comp向F_blockchain发送（Contract，cid，st_0，pk^in_cid，σ_TEE）等待收据。 Comp将合同cid返回给Pi，后者将验证合同cid是否正确存储在F_blockchain上。
c）请求执行：执行合约请求cid，客户端Pi首先从F_blockchain获得输入加密密钥pk^in_cid。然后Pi调用Comp的请求子程序
输入（cid，inp_ct），其中inp_ct是Pi被pk^in_cid加密的输入并能被spk_i认证。 Comp获取加密的前状态st_ct来自Fblockchain并加载合约^TEE以及合约代码和输入（cid，inp_ct，st_ct）。
如图9所示，如果σ_Pi验证，则合约TEE用从密钥管理器获得的密钥解密st_ct和inp_ct，并执行合约程序Contract以获得（st_new，outp）。为确保新状态和输出以原子方式传递，Comp和Pi进行原子传递定义如同第III-D节中规定的协议：
•首先，合同TEE计算outp = Enc（k^out_cid，outp）和st'ct = Enc（kstate，stnew），并发送两个和适当的证明经由epki建立的安全通道给Pi。
•Pi通过调用Comp的声明输出子程序来确认接收，触发合同TEE将m1 =（st'_ct，outp_ct，σ）发送到Fblockchain。 σ保护m1的完整性，并以加密方式将新状态和输出绑定到先前的状态和输入，因此恶意Comp不能篡改它。
•一旦F_blockchain接受了m1，合同TEE就会在安全通道中将outpct的解密发送给Pi。

C.密钥管理
每个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←$ S，f_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)：
fs(x)= H(x)^S = H(x)^E_i∈A-S_iλ_i=yλii---TODO 公式
i∈A其中λi是拉格朗日系数λi=􏰖-j。---TODO 公式
4）协议书：
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)并将kc，t，i发送给Comp。后
收集来自A⊆KMC的f + 1结果，Comp 能用kc构造周期t的短期密钥，t =􏰖kλii∈Ac，t，i（---TODO 公式）其中λi是拉格朗日系数。
c）违反隔离：我们主动隔离机密通过为每个计算节点强制执行隐私预算。为此，我们假设合同TEE具有不可伪造的主机标识（例如，SGX中的可链接EPID公钥提供了一个）。密钥管理器节点为每个计算节点Comp维护计数器K_Comp以记录查询的数量。计数器随着周期的推进而重置。仅当某些系统参数κ的K_Comp<κ时，密钥管理器节点才满足查询。有了这个，无论被破坏的计算节点产生多少TEE，它最多都可以获得κ个密钥。实际上，对耗尽的诚实计算节点的请求可以重定向到其他节点，从而仅产生适度的开销。
D. Prot_Ekiden的安全性
定理1描述了ProtEkiden的安全性。证明草图在第XII节中给出。
定理1（ProtEkiden的安全性）。假设Gatt的证明方案ΣTEE和数字签名Σ在选择的消息攻击（EU-CMA）下是存在不可伪造的，H是第二个前映像抗性，并且AE和SE是IND-CPA安全的。然后ProtEkiden在（Gatt，Fblockchain） - 混合模型中安全地实现了FEkiden，用于静态对手。
E.减轻应用程序级别的泄漏
虽然Ekiden保护TEE内部数据，但它并非旨在保护合同接口处的数据，即合同设计导致的数据泄漏。 （例如，可以通过客户端查询“提取”秘密预测模型[77]。）最小化此类泄漏的常用方法，例如，基于请求者身份或差异隐私预算来限制请求[27]，[42] ，需要持久性计数器。SGX的单调计数器是不值得信赖的[53]。
Ekiden通过启用持久应用状态（例如计数器，总消耗的差异隐私预算等）来支持有状态的方法来缓解应用程序级别的隐私泄漏，从而在链上安全地维护。此外，上述原子传递保证确保仅在正确更新此状态时才显示输出。
F.性能优化
给定一个额外的撤销机制，一个简单的修改就消除了对IAS的依赖，而不是初始化。初始化时，安全区会创建签名密钥（pk，sk），并输出带有证明的pk。随后，证据被替换为sk下的签名。由于pk绑定到TEE代码（通过初始证明），sk下的签名证明了输出的完整性，就像证明一样。与其他键一样，（pk，sk）由密钥管理器管理（参见章节V-C）。
在第XIII节中，我们讨论了协议的扩展版本以及其他几个性能优化。

X. 补充体系
A.理想的功能Fekiden
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。如果一个请求包含一个非法的TEEid，Fekiden抛出错误如果它是A构建的话。否则，这完美的功能忽略eids，后者被包含在Fekiden中仅作为一个技术需要用来确保接与Portekiden兼容，在下文中给出来。
d)正式安全和隐私保证：Fekiden封装了如下安全和隐私属性。首先，查询执行正确反映合约创建者提供的代码，第二，输出和新状态被原子分离的，举例来说，输出仅在新转台提交的时候才会被显示出来。我们在第三节D中讨论了这个属性的实现。
Fekiden提供隐私性的意义在意无论其他方或者对手方学习诚实方的秘密输入会比允许泄露的l更多。一个客服端与合约互动，不会学习到超过它的输入和输出。合约状态对于所有方都是保密的，A包括，除非故意通过输出来显示。然后，合约代码是公开显示的，所以用户可以检查它在使用之前。我们将支持隐私合约代码的工作留到未来（比如使用一个类似的技术【72】）。

B.完美区块链
在图8中

C.合约TEE包装
在图9中

XI.出版证明
发表协议的证明（图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并需要一个证明者去发布（m，r）。根据从P，E接收到的一个证明π(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节中给出。
我们证明了Prot_Ekiden [λ，AE，SE，Σ，{Pi}i∈[N]] UC-实现了关于泄漏函数l（x）的理想函数FEkiden[λ，l，{Pi}]揭示x的长度，即l（x）= 0 ^| x |。在协议中，l（·）是用IND-CPA加密方案实现的。

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

   （2）查询执行：

case 1：当一个诚实方Pi被Z给予input("request", cid, inp, eid)，Sim工作如下：
根据从Fekiden收到的(cid, Pi, l(inp))，Sim查询Fekiden的“read”接口来获取cid的虚拟状态（i.e. 一个随机字符串与真实状态的长度一致），表示为s。Sim计算c_inp = Enc(pk^in_cid，->0)使用长度了l(inp)，并代表Pi用输入（“request”，cid，cinp，s）模拟Gatt的“resume”消息。
根据从Fekiden收到lst'和l(outp)，Sim计算c=（k^out_cid，0|outp|）并代表Pi向Gatt仿真一个消息((“atom-deliver”, H(c_inp ), H(s), lst′ , H(c), spk_i ), σTEE , c)。
Sim通过模拟Fblockchain和Gatt之间的交互以及从Gatt到Pi的消息(“output”, Enc(epk_i , 0^|outp| ), σTEE )来进行。
最后，Sim通过发送“ok”消息指示FEkiden。

case 2：当一个损坏的派对Pi被Z给出输入（“request”，cid，inp，eid）时，Sim在Sim工作时学习输入如下：
•如果Pi向Fblockchain发送（“read”，cid），则Sim从FEkiden获取最新状态（表示为s），并代表Fblockchain将s发送给Pi。
•如果Pi通过输入（“request”，cid，inpct，s）向Gatt发送“resume”消息，则Sim模拟Gatt，如下所示：Sim查询FEkiden检查s是否不是最新状态，Sim中止。 Sim计算inp'= Dec（skin，inp）。然后Sim'cidct代表Pi向FEkiden发送（“请求”，cid，inp，eid）。
•从FEkiden收到lst'ct和l（outp）后，Sim计算c = Enc（kout，0 | outp |）并发送cid（（“atom-deliver”，H（inpct），H（s），lst' ct，H（c）），σTEE，c）从Gatt到Pi。Sim记录c。
•如果Pi通过输入（“声明输出”，cid，（st'ct，outpct，σ，epki））向Gatt发送“恢复”消息，则Sim模拟Gatt，如下所示：Sim首先检查Gatt先前已发送输出到Pi和那个（st'ct，σ）已由Fblockchain存储。如果上述任何检查失败，则Sim将中止。 Sim从FEkiden获得outp并将（“输出”，Enc（epki，outp），σ）发送到Pi。

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

（4）腐败的飞地：
当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替换输入和输出的加密，并用具有相同长度的随机字符串替换状态加密。相邻杂种之间的必要性如下所示。
除了Sim模拟Gatt和Fblockchain之外，Hybrid H1在现实世界协议中继续进行。特别是Sim为ΣTEE生成密钥对（pkTEE，skTEE）并发布pkTEE。每当A想要与Gatt通信时，Sim会记录A的消息并忠实地模仿G Sim通过在内部存储项目来模拟Fblockchain。
由于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和H1，Z和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之间的差异如下。
•任何消息（“atom-deliver”，hinp，hprev，s，houtp，c）从Gatt发送到Pi，其中s = SE .Enc（kstate，st'）和c = SE .Enc（kout，outp））in H4被替换为（“原子传递”，hinp，hprev，lst'ct，H（c'），c'），其中c'= Enc（kout，0 | c |）。回想一下l'是一个长度为| st'ct |的随机字符串在产生状态时由FEkiden选择。

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

XIII. Ekiden性能扩展
在本节中，我们将讨论对简单协议的几种性能优化。这些优化共同减少了区块链所需的往返次数和存储容量，并减少了计算节点的工作量。正如我们在第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可以防止对手降低目标应用程序的服务质量。