基于SGX的区块链交易隐私安全保护方法

范俊松，陈建海，沈 睿，刘振广，何钦铭，黄步添

1.浙江大学计算机科学与技术学院，浙江杭州310027

2.杭州云象网络技术有限公司，浙江杭州310012

3.浙江工商大学计算机与信息工程学院，浙江杭州310018

区块链技术提供去中心化的信任机制以确保数据存储的安全性和可靠性，能依靠去中心化的节点处理以及自动执行的智能合约来防止用户的请求历史与习惯等被特定的第3 方获取。与传统交易方式相比，基于区块链的交易在保护用户隐私安全方面更具优势。大量不同规模的区块链网络在比特币[1]、以太坊[2]、超级账本[3]等典型区块链架构的基础上诞生并逐渐投入实际应用，为多个领域的从业者和开发者提供服务。

在移动支付盛行的当下，区块链系统也需要提供移动端的交易发起功能与交易确认机制，但大部分移动设备无法支持存储区块链全部数据的空间需求，因而大多数区块链系统根据简单支付验证（simple payment verification,SPV）模式[1]为区块链网络使用者提供轻量型客户端的解决方案。移动设备运行的客户端只存储区块链网络的极少部分索引数据，依靠存储着区块链全部数据的全节点完成区块链交易功能。然而，简单运用SPV 模式带来了一定风险，如果大量轻量型客户端接入同一个全节点，区块链网络就在全节点处产生中心化现象，此时用户的交易请求记录会被全节点获取。在这种情景下，提供全节点服务的系统或者与全节点在同一物理平台上的特权软件能够收集区块链用户的请求，匹配用户信息与用户请求内容，而这些相关性正是区块链系统所极力避免的。此外，区块链的地址等密码学信息提高了区块链系统的入门门槛，不利于区块链技术的推广。因此，区块链系统急需轻量型客户端解决方案来兼顾隐私安全性和使用便利性。

1 研究现状与存在问题

关于简单运用SPV 模式带来的隐私安全风险，之前的研究在一定程度上给出了解决方案。Hearn 和Corallo 在BIP-37[4]中介绍了Bloom 过滤器，在SPV 模式的基础上提出了改进措施。客户端将生成一个Bloom 过滤器并发送给区块链的全节点，凡是在全节点上符合该过滤器条件的交易都会发送给对应的客户端，从而将用户真实需求的交易隐藏在更大的交易集合中达到隐藏用户地址的目的，因此基于Bloom 过滤器的方案已用于大部分区块链系统。此外，文献[5] 也提出了一种修改方案，由全节点创建过滤器发送给客户端，再由客户端检查该过滤器处理后的交易集合中是否包含特定交易，从而决定是否还要向该全节点请求交易集合。文献[6] 提出了BITE 系统，以软件防护扩展（software guard executions,SGX）机制和茫然随机访问机（oblivious random access machine,ORAM）的思路保护比特币轻量型客户端，对访问和存储进行茫然化处理后将数据处理部分放置在安全区中加以保护。

上述方案虽然在一定程度上为区块链交易提供了隐私安全保护，但在隐私安全性和用户友好性方面仍存在局限性。

1.1 隐私安全性有待提高

文献[7] 指出，Bloom 过滤器的原理是将目标地址隐藏在一系列地址中，但攻击者仍能以很高的正确率猜测出用户的目标地址，这对于交易的隐私性来说是致命的。如果在云服务器上架设全节点服务器，那么用户的请求数据最终仍以明文方式存放在用户级内存上，不可避免地遭到恶意软件、特权软件和操作系统的窥探和窃取，可见这类系统存在着暴露用户信息的风险。

与Bloom 过滤器的方式相比，基于SGX 的BITE 系统为比特币交易提供了更好的安全防护和更少的性能开销，但尚未在比特币以外以智能合约为主导的主流区块链系统中实现。

1.2 用户友好性存在缺陷

现有的区块链钱包具有一定的入门门槛，而提高用户友好性又会带来安全问题。在以分层确定性（hierarchical deterministic,HD）钱包[8]为代表的协议中，根据区块链的隐私性设计要求可知区块链用户钱包无法直接与用户身份相绑定，其地址也不支持挂失和找回功能。在一般情况下，用户会选择使用辅助记忆工具（例如随身便签、其他网络存储服务等）来保存生成钱包的助记词，因为该辅助工具的安全性直接影响钱包的安全性。

在实际使用中，接收交易的用户通常对外公开地址的公钥。因为多个交易使用同一个地址可能暴露用户隐私，所以安全交易的最佳方案就是为每次交易创建地址并发送给交易对象，但严重影响了交易效率。对于Trezor 等支持扩展公钥的钱包，可以使用扩展公钥为每次交易自动生成独立的地址，但是将该扩展公钥公开给第3 方会暴露用户的所有交易历史，在满足使用便利性要求的同时也引起了安全性问题。

2 关键技术

2.1 Intel SGX 安全保护技术

Intel 于2013年提出了SGX[9]，包括基于Intel CPU 的SGX 指令及其对应的安全保护机制。在SGX 提供的设计理念中，程序可分为可信部分和不可信部分。SGX 能够为可信部分的代码和数据创建可信的加密内存区域—— 安全区，从而保证运行过程中代码的完整性和数据的一致性。安全区基于硬件支持提供加密和安全保护，其数据只允许授权部分的代码访问，而任何同一平台上的恶意软件、特权软件甚至是操作系统本身都无法在未经授权的前提下访问，从而防止安全区内部的数据泄露，杜绝安全区执行过程中的数据和代码的恶意篡改。SGX采用远程认证机制确保安全区本身是可信的，于是通信发起方可根据官方提供的认证服务器验证SGX 安全区是否正确运行。为了在SGX 内部实现加密，Intel 提供了基于开源密码学库OpenSSL 的SGX SSL 库，为SGX 安全区提供密码学支持，因此对数据的加解密操作不再需要外部不可信部分的支持。

基于SGX SSL 加密库，Intel 为SGX 提供了受保护的文件系统库（SGX protected file system library,SGX PFS）。通过SGX PFS 生成与访问的文件只能使用在安全区内随机生成的密钥进行加密，经加密后的文件存放于本地存储介质。若不通过额外渠道保存密钥，则该加密文件只能由生成该文件的安全区在一次生命周期中访问，而其他安全区以及安全区外的不可信部分都无权访问；该安全区在重启后将会丢失密钥，也无权再访问该文件，从而确保文件读写的机密性。

上述措施并不能完全保证数据的安全性，虽然使用了SGX PFS 但也可能有部分信息被外部程序与操作系统所探知。在本系统涉及的数据访问要素中，仅凭SGX PFS 无法保护读写操作时涉及到的访问偏移量，以致暴露此次访问对象的数据访问模式—— 存储位置信息。恶意攻击者即使无法获知信息的确切内容也能根据统计学原理推断出用户隐私，必须采用额外的保护措施来隐藏隐私数据的访问模式。

2.2 ORAM 技术与应用现状

ORAM 最初由Goldreich 等[10]提出，是一种由数据混洗与再加密等技术组成的算法。当客户端访问远程服务器上的数据时，该算法可以隐藏数据访问模式，保证了客户端访问的安全性。ORAM 算法的基本思路如下：对数据进行访问时附带对大量冗余数据的请求，因此在数据存储的服务端侧，即使攻击者在数据存储的服务端侧观察到物理存储的访问位置，也无法了解到客户端真实的数据访问模式，而客户端侧可以从返回的大量数据中挑选真实需求的数据。

目前已有多种基于ORAM 的改进算法[11]，但ORAM 本身的应用存在局限性。与直接进行文件访问相比，ORAM 方法在提高安全性的同时却带来了巨额的性能开销。在ORAM算法中，即使是性能最优的Path ORAM[12]算法，在磁盘读写和网络通信方面也会带来lbN级别的开销[11]。鉴于磁盘读写速度远大于网络通信速度，成倍的磁盘读写需求对系统执行效率的影响微乎其微，而成倍的网络通信需求将直接影响系统处理请求的最大并行量，因此系统产生的额外通信带宽将成为ORAM 算法实用化的最大瓶颈。

当改变系统环境的安全假设，将安全可信的粒度从单个物理系统细化到单个应用程序甚至应用程序的单个部分时，网络通信将不再成为性能评估需要考虑的部分，且额外的磁盘读写需求也是实际可容忍的性能开销。在之前有关SGX 的研究中，就有Oblix[13]、ZeroTrace[14]以及OBLIVIATE[15]等在SGX 内采用ORAM 算法实现相关功能，这也给本文的系统设计提供了思路。因此，在可信执行环境所构筑的安全假设中，ORAM 技术成了隐藏数据访问模式、实现安全数据访问的一种可能的解决方案。

3 SGXTrans 系统设计

3.1 系统模型

本文提出的系统包含四部分：区块链客户端及其用户C、提供密钥托管服务的服务器S1（又称为密钥服务器）、运行区块链全节点并提供交易验证服务的服务器S2（又称为交易服务器）以及区块链网络B。其中，服务器S1与S2不必在物理层面上分离，服务提供者可以在同一台服务器上同时运行密钥托管服务和交易验证服务。服务器S1与S2的核心安全程序分别运行在安全区E1与E2中。系统的简要模型如图1所示。

图1 SGXTrans 系统架构Figure 1 SGXTrans architecture

本文为SGXTrans 的具体实行方式提出了以下2 种可行的方案：密钥托管方案和全权托管方案。对于第1 种方案，密钥服务器S1仅为用户存储密钥，而与交易服务器S2的交互由客户端C独立完成。对于第2 种方案，客户端C将与区块链相关的功能全权托管给密钥服务器S1。用户在进行区块链相关请求的过程中，所有的实际请求内容均由密钥服务器S1代为生成。密钥服务器S1作为客户端用户的代理人，持有用户的密钥，可以根据客户端C的指示请求生成实际请求后与交易服务器S2进行通信。

以上2 种方案的关键区别如下：第1 种方案的密钥最终交由用户自行处理，这便于用户对自身密钥以及交易采取不受本系统约束的操作行为，为用户尤其是该领域专家在使用本系统提供安全保障的同时并不限制他们的操作行为。第2 种方案的用户在整个请求过程中均不会获得与用户密钥相关的任何数据，降低了用户密钥在客户端侧被窃取的可能性；此外，与密钥相关的请求交由服务器安全区自动运行，于是区块链服务的提供者可以在服务端侧添加用户密钥相关的管理功能而不必担心用户隐私问题，因此区块链上的交易与用户行为经过程序封装后更贴近传统交易方式，且用户友好性高。

3.2 安全假设

本节将对SGXTrans 系统的安全性范围以及相关系统假设给出如下说明：

1）客户端安全性

本文假设用户侧的客户端本地环境是安全的，客户端的请求在经过HTTPS 协议打包之前不会泄露。

2）安全区安全性

本文假设Intel 提供的SGX 安全保护机制是安全的，安全区内的数据和代码既不会被任何不可信的外部程序访问又不会在攻击者的攻击下泄露。

3）服务器安全性

在本文设想的安全环境中，服务器S1与S2可运行不可信的操作系统与恶意攻击软件，而在服务器上运行的安全区E1与E2则运行SGXTrans 核心程序，由SGX 安全保护机制确保可信。此外，允许网络通信环境不可信。

4 运行过程及安全分析

本节阐述了SGXTrans 系统的整个运行过程，包含初始化阶段、密钥托管阶段和交易处理阶段，分析了运行流程的数据安全性以及潜在攻击场景，从而阐明了系统的安全性。

4.1 初始化阶段

在初始化阶段，密钥服务器和交易服务器执行相似的初始化过程，主要包括SGX 程序的环境监测和本地文件的创建。特别地，系统需要通过加密存储模块为安全区处理数据过程中产生的持久化数据和状态提供本地介质的存储功能，以减少占用的内存。

在文件的读写过程中，使用SGX PFS 确保秘密读写，根据Path ORAM 算法将所读写的数据以键值对的形式存储在加密文件中，避免数据访问模式造成的隐私泄露。密钥服务器S1存储用户身份验证信息与对应的区块链密钥，交易服务器S2存储区块链地址和包含该地址的交易信息。每个键值对为一条记录，存放在Path ORAM 的二叉树节点的数据块中，记录的ORAM 位置图信息和记录缓存都存放在SGX 安全区的可信内存中，无法被外部程序访问。

由于数据按块存储，存在单条记录过长而无法存入单个数据块中的情况。在本文系统中，这通常意味着单个用户持有过多区块链密钥或单个区块链地址关联过多交易，因而并非常见现象，且能通过设计单个数据块和单条记录的长度上限而减小发生的可能性。本文为每条记录加入了参数group，能使过长的数据分段存储与读写。同时，为了减少数据分段、提高系统运行效率，根据大部分区块链系统的实践调研评估结果，最终采用32 kB 的数据块、每块包含16 条记录的形式进行数据存储。

在系统运行过程中，密钥服务器S1的数据由用户请求来更新，而交易服务器S2的数据由区块链中新区块的产生来更新。这意味着交易服务器S2需要监听区块链的区块更新，当产生新区块时，需要及时解析区块中的交易内容并更新至本地存储。关于更新过程中产生的数据不一致性可能会造成的影响，本文将于第5 节的实验部分进行说明。

4.2 密钥托管阶段

在密钥托管阶段，用户侧客户端C向密钥服务器S1发起密钥托管请求。用户的请求数据包括以下3 项内容：1）用户的密钥服务请求类型，在这里为密钥托管请求；2）用户的身份验证数据；3）用户的公私密钥地址。特别是当用户的密钥地址为空时，密钥服务器S1可为用户生成对应区块链上新的密钥地址。

密钥托管阶段涉及到用户侧客户端C向服务器发送隐私信息的过程。在本系统所设想的安全环境中，各端之间的通信网络是不可信的。为了确保用户的数据在通信过程中不被第3方监听、窃取与篡改，本系统采用HTTPS 协议防止隐私数据泄露。

然而，若直接运用HTTPS 协议，那么服务器上的恶意软件等仍然能够在通信数据经协议解密后以直接读取内存的方式获取通信数据的明文内容，因而数据的解密过程必须在SGX安全区提供的可信内存空间中进行。本系统引入并修改了OpenSSL 库的HTTPS 通信相关函数，在确保HTTPS 协议正确执行的同时将用于加密的公私密钥置于SGX 安全区内，且服务端侧的数据加密与解密过程均移至SGX 安全区内进行。

除此以外，本文系统采用统一包格式以及随机时间发送无效数据包的方式来防止基于数据包大小和请求时间的攻击。统一包格式指数据包大小全部统一为固定值，不会因请求中数据长度而发生变化，于是对小于该固定值的数据进行填充，对大于该固定值的数据分割后分别填充。随机时间发送无效数据包的方式可以防止攻击者通过用户请求时间和区块链上交易产生时间的比对来缩小用户密钥范围，从而防止攻击者多次尝试后推断出用户密钥。

基于上述安全措施，用户通过特制的用户侧客户端向密钥服务器S1发起密钥托管请求，将用户身份验证数据与用户密钥发送给密钥服务器。密钥服务器S1利用4.1 节所述的本地加密存储方式将用户密钥进行本地存储。之后，用户可通过之前提供的用户身份验证数据来访问获取对应的用户密钥，用该密钥参与区块链交易。

4.3 交易请求阶段

在密钥服务器S1提取到用户密钥以后，由于用户的密钥托管方案以及交易请求类型的不同，客户端与服务器之间将产生不同的数据流。

4.3.1 密钥托管方案

在密钥托管方案中，用户首先向密钥服务器S1发送密钥获取请求，随后密钥服务器S1根据用户请求附带的用户身份信息提取到用户密钥。通过HTTPS 通信将用户密钥返回给用户侧客户端之后，密钥服务器S1不再参与数据处理。用户获取到用户密钥后，通过用户密钥独自与交易服务器S2进行HTTPS 通信。

在交易验证请求中，用户侧客户端C向交易服务器S2发送请求的内容包括交易验证请求标识和请求验证的公钥列表。交易服务器一旦接收到交易验证请求，便会根据请求验证的公钥列表从本地加密存储中提取对应的交易列表，将其打包后返回给用户。该过程以及后续所述通信过程的安全保护措施均与密钥托管阶段相同。用户侧的客户端接收到交易列表后，即可进行交易验证。

在交易构造请求中，用户侧客户端C向交易服务器S2发送请求的内容包括交易构造请求标识、用户的公私钥数据、用户的交易内容。用户的交易具体内容由区块链具体数据结构来决定。交易服务器S2接收到交易构造请求后，首先检查交易内容所包含的各项数据是否满足交易构造条件；然后根据用户提交的交易输入方密钥列表，在本地加密存储的交易数据库中查询密钥对应的所有交易，从而单独执行交易可行性的验证。若交易构造请求内容满足交易构造条件并通过了交易可行性验证，则根据区块链具体设计方案生成对应的区块链交易请求，再由交易服务器S2上运行的全节点发布到区块链网络上。

4.3.2 全权托管方案

全权托管方案与密钥托管方案的核心不同点在于：由密钥服务器S1直接与交易服务器S2进行交互，而用户侧客户端C只接收由密钥服务器S1发回的信息对请求处理结果进行确认。

在交易验证请求中，用户侧客户端C直接向密钥服务器S1发送交易验证请求，请求的内容包括交易验证请求标识和用户的身份验证数据。密钥服务器根据用户身份信息提取到密钥后直接向交易服务器发送交易验证请求，之后的过程与密钥托管方案的交易验证请求处理过程相同。在收到交易服务器S2返回的交易列表后，密钥服务器S1可以对交易信息进行再处理，有选择地将处理结果返回给用户。

在交易构造请求过程中，用户侧客户端C直接向密钥服务器S1发送交易构造请求，请求的内容包括交易构造请求标识、用户的身份验证数据、用户的交易内容。密钥服务器S1根据用户身份信息提取密钥后向交易服务器S2发送交易构造请求，之后的过程与密钥托管方案的交易构造请求处理过程相同。值得注意的是：由于交易内容会提交到密钥服务器S1，密钥服务器S1可以对交易内容进行二次处理，这意味着可以通过密钥服务器S1的额外设计提供密钥共享、额度管理等账户操作。由于此类行为可在安全区内独立完成，不必让用户承担额外的密钥泄露风险。

4.4 关键数据流分析

本节将分析SGXTrans 中的关键数据流，进而阐明SGXTrans 系统是如何确保数据可信的。图2展示了SGXTrans 中的关键数据流，但省略了建立可信通道以及SGXTrans 所用安全区以外的应用程序部分的数据交互过程。当采用全权托管方案时，g、h的数据流如实线所示；当采用托管密钥方案时，g、h的数据流如虚线所示。接下来对两端之间或服务器内部的数据流分别进行分析。

图2 SGXTrans 的关键数据流Figure 2 SGXTrans critical data flow

1）客户端C与服务器S1

客户端C与服务器S1之间涉及数据a、b。数据a为客户端发起的请求，包含了用户的身份验证信息，在全权托管方案中还额外包含了对服务器S2的请求数据。这些内容将在客户端侧根据HTTPS 协议使用约定的加密密钥进行加密。数据b包含安全区E1生成的请求处理结果，该结果在安全区内根据HTTPS 协议使用约定的加密密钥进行加密。因此，在服务器S1上安全区E1以外的部分无法访问到这些信息，而在与客户端C的通信过程中只能得知请求发起的时间。

2）客户端C与服务器S2

客户端C与服务器S2之间涉及密钥托管方案中的数据g、h。数据均以HTTPS 协议加密传输，但不在安全区外进行解密操作。因此，服务器S1上的其他程序在与客户端C的通信过程中只能得知请求发起的时间。

3）服务器S1与S2

服务器S1与S2之间涉及全权托管方案中的数据g、h。数据均以HTTPS 协议加密传输，且不在安全区外进行解密操作。在此过程中，服务器S2无法得知该数据与哪一个客户端关联。因此，服务器S1上的其他程序在与服务器S2的通信过程中只能得知请求发起的时间，而无法得知该访问的最初发起客户端。

4）服务器S1和S2内部

服务器S1和S2内部之间涉及数据c、d、e、f和i、j、k、l。数据c和i将HTTPS 协议的加密数据送往安全区；数据d和j（不包括交易明文内容）将依照HTTPS 协议要求加密后的数据送至安全区外。在这两个过程中，系统都无法得知数据的明文内容。数据e、f、k、l涉及对本地存储介质的读写过程。由于SGXTrans 结合了SGX PFS 与ORAM 算法，外部程序无法得知本地文件的明文内容，也无法得知安全区真实需求的数据所在位置，因此服务器上的其他程序在服务器内部处理过程中只能得知数据访问的时间以及数据j中由安全区程序构造完成的交易明文内容，但无法得知该访问的最初发起客户端。

5）服务器S2和区块链网络B

服务器S2和区块链网络B之间涉及数据m和n。数据m是服务器S2向区块链网络广播明文的交易内容，由于区块链网络中存在大量交易转发现象，任一区块链节点都无法得知该交易的最初发起者。数据n是服务器S2与区块链网络同步区块的数据，该过程不存在任何隐私数据。

综上所述，在本系统的数据流中位于不可信部分的数据，除了最终生成的交易内容之外均以密文的形式存在。在真实请求以外存在一定量频率的无效请求，因此针对时间的攻击难以获得成效，所有加密数据也难以与发起请求的客户端产生关联。最终生成明文交易的请求都已经过安全区的处理，并在全权托管方案中经过密钥服务器的处理，故真实请求发起的最初来源和时间难以被恶意攻击者探知，也就无法将该交易联系到任一客户端。

4.5 潜在攻击场景分析

由于确保了数据流的安全，SGXTrans 排除了第3 方监听造成隐私泄露的可能性，但仍无法说明其他积极性攻击行为对该系统可能造成的影响。本节将阐述并分析可能的攻击场景，从而进一步阐明SGXTrans 的安全性与可靠性。

4.5.1 伪造请求

攻击者尝试通过伪造合法请求来获取其他用户的数据，在本系统的场景中分为2 种攻击方式：1）尝试伪造其他用户身份来获取用户数据，2）尝试使用合法客户端来获取其他用户数据。对于第1 种攻击方式，SGXTrans 确保了安全的数据流，使攻击者无法从本系统的数据流中直接获取用户身份。即便使用重放攻击，攻击者也只能接收到加密的响应包而无法获取具体的用户数据。对于第2 种攻击方式，即使攻击者持有合法的身份，本系统也只会返回与该攻击者合法用户身份对应的用户数据，因此攻击者无法获取其他用户的数据，也无法通过伪造请求发动有效攻击。

4.5.2 系统伪装

在一个已运行有SGXTrans 的服务器上，攻击者会尝试另行开启一个经过恶意修改的SGXTrans 系统，从而尝试以下2 种攻击方式：1）伪造本系统与用户客户端建立联系而直接获取用户请求内容；2）伪造本系统读取本地存储的加密用户密钥数据库与加密交易数据库。对于第1 种攻击方式，客户端可凭借远程认证机制检查该安全区中运行代码的摘要，确保安全区内代码不会遭到恶意修改。只要安全区内代码正常执行，改造系统的持有者就无法获得用户的任何信息。对于第2 种攻击方式，鉴于各安全区的加密文件相互独立，加密文件所需密钥也只在安全区代码运行过程的可信内存中随机生成而不会泄露给外部，即使运行一个伪造系统也无法读取现有加密文件的真实内容。因此，攻击者无法通过系统伪装方法发动有效攻击。

4.5.3 本地文件破坏

系统在运行过程中会生成加密的持久化数据。若攻击者尝试直接删除这部分文件，则会对系统的运行造成影响。在实际部署过程中，可以在同一个区块链网络中部署多个独立运行本系统的交易服务器，以避免服务的失效。针对密钥托管功能，客户端可搜索具有该功能的服务器，将自身的密钥在不同服务器上备份；针对交易验证和构造功能，服务器的加密交易数据库由区块链数据产生，即使本地文件遭到破坏，系统检测到该情况后也可以通过扫描区块链来重新生成该加密文件。因此，本地文件的破坏虽然对系统的响应能力产生影响，但不会对系统的安全性造成影响。

5 实验与分析

本文基于上述内容实现了SGXTrans 的原型系统，该系统使用SGX SDK 2.9.1 版本、SGX SSL 2.9 版本（基于openssl-1.1.1d 重构）、gcc 7.5.0 版本构建，运行于Docker 提供的Ubuntu18.04（64 bit）镜像中。随后根据VNTChain[16]的主网交易数据历史进行存储性能分析，并运用该系统在VNTChain 的测试网上进行请求测试。测试部分将系统架设于Intel(R)Xeon(R) E3-1240 v6 CPU(3.70 GHz) 以及16 GB 内存的支持SGX 功能的服务器上。

5.1 存储能力测试

本文系统需要在内存中存放各类临时数据和持久数据，由于临时数据数量少、其空间能够反复利用，本节将仅讨论持久数据，主要为各服务器上的ORAM 位置图信息。密钥服务器S1以及交易服务器S2的内存持久数据存储能力与SGXTrans 安全区内存堆大小的关系如图3所示，图中采用了对数坐标轴，可见其基本为线性关系。因为对于绝大部分区块链地址，单个数据块足以存下对应交易，所以对应位置数组中只存储了一条ORAM 路径。当安全区内存为64 MB 时，交易服务器内存中的最大索引数量约为260 000 个交易地址，这超过了VNTChain 现有的账户数量。对于密钥服务器，由于一个用户通常拥有数个甚至数十个交易地址，密钥服务器的存储需求远小于交易服务器。因此，本系统可以安全地存储所有数据。对于需要存储更多索引数量的区块链网络（如以太坊等），可以采用二次ORAM 方法将位置图信息也在本地存储介质上加密保存。

图3 服务器内存持久数据记录数量与安全区内存堆大小关系Figure 3 Relation between persistent data in server memory and heap size of enclave

在SGXTrans 系统，安全区除了内存存储以外还要在本地介质维护持久化数据，因此需要考虑系统产生的额外磁盘存储需求。本文基于VNTChain 的交易历史统计了交易量和存储空间的对比情况，对总交易量N，大约需要O(lbN) 的存储空间才能满足对交易的本地存储。在VNTChain 主网上，当本地存储空间为26.3 GB 时，进行SGXTrans 部署所消耗的额外存储空间为256 MB。由此可见，在VNTChain 主网节点上部署SGXTrans 带来的额外空间开销仅为1%。由于不同区块链系统的交易与地址之间的比率也不同，预计其他以太坊架构的区块链系统使用SGXTrans 在全节点服务器上的额外空间开销不超过5%。

5.2 数据更新测试

本文针对SGXTrans 系统运行过程中产生的不同深度的ORAM 二叉树分别构建1 000次数据更新请求，最后计算其平均值从而获得单次数据更新耗时的测试结果。图4展示了ORAM 数据库二叉树深度与平均每次数据更新的关系。

图4 ORAM 二叉树深度与平均每次数据更新耗时的关系Figure 4 Relation between ORAM binary tree depth and time per data updating

随着区块链用户和区块链上交易数据的增多，ORAM 数据库二叉树深度将逐步增加，单个数据更新耗时与二叉树深度基本呈线性关系。由于用户密钥的产生速度远低于区块链交易产生的速度，因而只需重点考虑区块链交易数据更新对服务器性能的影响。以平均每秒产生15 个交易、平均每次数据更新花费20 ms 来估计，服务器每秒需要花费约1/3 的时间来更新区块链数据。一方面，这意味着SGXTrans 能够普遍支持区块链数据的处理，如以太坊大约需要13 s 产生一个平均包含200 个交易的新区块；另一方面，由于该处理时间会对用户请求处理造成影响，本文推荐采用多个系统交叉并行的方式。

5.3 请求处理测试

表1和2 展示了本文提出的两种方案在VNTChain 上进行300 次模拟请求的平均测试结果，包括各阶段的网络通信、外部程序本地处理、安全区加密数据读写、安全区其他处理等耗时。

表1 密钥服务器请求处理耗时测试Table 1 Cost time of key server request handling test ms

表2 交易服务器请求处理耗时测试Table 2 Cost time of transaction server request handling test ms

由表1和2 可知，在本系统执行过程中，网络通信占据了大部分时间，而安全区的处理时间仅占总时间的4%。加密读写以外的操作复杂度均为O(1)，不会对系统运行总耗时造成较大的影响。随着区块链系统上数据量的增加，加密读写过程的时间耗时也随之增加。由5.2 节测试数据推算，SGXTrans 在现有的各类区块链系统上拥有不超过10%的额外时间开销。

考虑到网络通信占比较大，将密钥服务器与交易服务器合并于同一台物理设备。以本地通信代替网络通信能大幅减少全权托管方案的系统运行耗时，但是对密钥托管方案没有帮助，这也是本文更推荐全权托管方案的另一个原因。开发者可根据测试结果和实际需要综合考虑实施方案。

6 结 语

本文针对区块链技术在实践过程中出现的使用性问题与隐私安全性问题，在探索已有解决方法时发现现行的区块链轻量型客户端及其改进方案并不能有效解决上述问题，于是在前人研究的基础上使用SGX 安全保护机制和ORAM 技术给区块链交易设计了SGXTrans系统，不但为区块链用户从密钥管理到交易请求等一系列过程提供了强大的隐私安全保护，而且安全地向对用户隐藏了区块链的密码学细节，提高了系统的实用性。经分析和实验表明：SGXTrans 系统具有良好的性能，有望成为区块链交易隐私安全保护的一种行之有效的解决方案。