Blockchain and Trusted Computing Problems, Pitfalls, and a Solution for Hyperledger Fabric

在区块链中智能合约和交易都是透明的，数据会在每个参与区块链的节点上进行复制。
为了解决这个问题，将区块链和可信执行环境进行结合 (TEE)，如英特尔的SGX。
SGX 会在CPU中使用一个可信的执行环境，将这个环境中的数据、程序和主机上的操作系统分隔开，从而创建一个飞地。飞地中的代码不会被主机篡改，代码的执行过程对于主机来说也是不可见的。

一个应用的例子： Vickrey 拍卖，密封投标(sealed-bid) 拍卖，只有拍卖师能够知道投标的细节，其他人都不知道投标的细节。转移到区块链上，智能合约要在竞拍的过程中记录出价、结束拍卖、评估出价。

如果在SGX 中执行拍卖的智能合约，使用公钥来对投标进行加密，只有智能合约掌握了私钥，能够对投标进行解密。

一个恶意节点可能影响交易的执行顺序，通过观察和操纵交易执行的顺序，恶意节点可能推断出关于密封出价的信息。例如，如果交易顺序影响了拍卖结果（比如先到先得的规则），恶意节点可以通过调整顺序来推测出价大小。对于拍卖的场景来说，如果恶意区块链节点可能影响飞地执行交易的顺序，则即使该节点无法解密出价，也可以破坏密封出价拍卖的机密性。可能会导致 enclave 多次执行评估交易，并在每次新的出价存储在区块链上时再次重置 enclave。从而节点可以了解其他出价的信息。

因此要克服执行顺序被篡改的问题，如果按照唯一的、已经提交的区块链状态执行智能合约，可以防止回滚攻击，交易的顺序已经确定。

对于 non-final 共识协议来说，比如POW，还是会出现分叉和回滚。TEE 也无法解决对于 non-final共识引起的回滚攻击的问题，因此在这篇中的也不能使用 non-final 共识。

Hyperledger Fabric

这篇文章中，使用SGX 和Hyperledger Fabric 设计了一个区块链的安全解决方案。

Fabric 是一个许可链，使用的是final 共识方式，执行过程是 执行-定序-验证 。

基本交易流程如下：(1) client通过向一个或多个peer发送交易来调用chaincode，(2) 执行chaincode并生成称为endorsement(背书)的提案响应。 (3) 然后，客户端收集背书并将其组装成交易提交给 ordering service。 (4) ordering service建立所有交易的总顺序，并将它们作为交易块广播给网络中的所有节点。当peer收到块时，它会验证每个交易，消除基于已无效状态的交易，并将有效交易提交到其本地分类帐。

问题：他有如下的过程，也就是说只能的执行结果是基于之前的状态的，获取到执行结果之后并没有直接上链，之后再上链，之前的状态可能已经无效了，所以要将某些交易剔除。

When a peer receives a block, it validates every transaction, eliminates those that were based on state that has become invalid, and commits the valid ones to its local ledger.

Fabric 在执行的过程中并不会直接修改peer 当前的状态，而是将修改记录写入到 writeset 中。并且所有访问的key和version 都被保存在readset 中(fabric 使用key-value store)。
将所有的execution result、 readset、writeset 打包为proposal response 或者 endorsement，并返回给client。

client 收集到做够多的 endorsement 之后将交易发送到 ordering service，ordering service将收到的交易排序，并打包为区块。使用gossip 协议分发给所有的peer。

每个peer 使用validattion system chaincode (VSCC) 来验证每个区块中的交易的有效性。每个peer 都会检查交易的 endorsement 和交易的readset 的版本。如果检查通过，将会把交易的writeset 中的内容添加到本地的账本。

SGX TEE

SGX 能保证chaincode的运行在一个可信的执行上下文中，称为飞地。

"飞地 "定义了一个隔离的内存区域，该区域由硬件强制机制保护，即使整个平台遭到破坏，也能保证 "飞地 "的机密性和完整性。
SGX 是在内存中裕兴飞地，如果程序重启或者崩溃中间状态将丢失，因此使用data sealing将数据加密存储，进行备份。但是从加密数据中恢复的方式并不能阻止回滚攻击，因为攻击者可能使得 enclave 从部分不完整的记录中进行恢复。

Threats

恶意peer可以使用任何输入并以任意顺序调用链码飞地。对等方可以拦截、修改、重新排序、丢弃或重放链码操作，并且当链码飞地访问 KVS 时，peer可以向其提供任何区块链状态。

对于在飞地中运行的安全应用程序，恶意主机可能会通过触发飞地在“不正确”的输入上执行来破坏机密性。在区块链上下文中，这意味着链代码执行偏离基于共识的交易顺序。

strawman approach

如果对于先定序，在执行的交易来说，这个是保证不会有回滚攻击的。但是，对于Fabric 来说，需要将整个过程全部打包进SGX 中，这就造成了trust computing base 过大的问题，违反了minimizing TCB的原则。TCB 越小，有更少的error，减少受攻击的 surface

另一个问题是 enclave 中的内存是有限的大小。enclave page cache EPC 目前限制为128M大小。

Approach for Hyperledger Fabric

如果将交易定序和交易执行的代码分开，交易定序的代码不会遭受到回滚攻击，不在飞地中执行，而只讲交易执行的代码放入飞地，这样是可行的。但是这并不使用于 Fabric，因为Fabric 是执行-定序-验证的方式。

Fabric 中的采用投机(speculative)执行的方式，会导致交易的执行顺序被host 操控，从中推断出秘密信息。

因此在Fabric 的场景下，应用程序必须考虑循序他的执行方式。 以拍卖为例，设置一个barrier，当barrier被储存在区块链上时，才可以对拍卖进行评估(evaluate)。并且，不接受barrier 之后的交易。

secure up to resets（直到重置为止是安全的）是一个安全概念，用于描述在可信执行环境（TEE，如Intel SGX）或其他安全环境中，系统或应用的安全保证持续有效，直到发生重置事件。
恶意的peer可能和client进行串通等，能够获取到当前账本的状态。因此需要barrier 来将 Fabric 转为先定序在执行的过程。

Chaincode enclave. 在enclave中执行一部分需要被信任的的chaincode。chaincode library 充当 chaincode enclave 与外界的接口。

Ledger enclave。通过维护区块链最新的完整性元数据维护区块链账本的状态。

Enclave registry. 运行在enclave 之外的一段chaincode，维护了已经注册的chaincode enclave并对其进行认证。

Enclave transaction validator. 用于验证 enclave 生成的交易。

ledge enclave 和 chaincode enclave 都可以生成自己的公私钥，并作为自己的身份标识

管理员启动 chaincode enclave 步骤如下：
(1) creating the chaincode enclave;
(2) registering with the enclave registry;
(3) provisioning of secrets;
(4) binding the chaincode enclave to the ledger enclave.

chaincode 执行

client 查新peer的enclave的公钥，使用PKCC公钥对chaincode operation进行加密，并将proposal发送给peer，peer 提取 chaincode operation并转发给 enclave执行。并将执行结果使用私钥SKCC 进行签名，并使用client的公钥进行加密返回给client。

client 收集执行结果和背书并交给ordering service将交易进行排序，打包成区块。

peer接收到区块之后调用VSCC 交易验证器将交易标记为有效，peer将交易提交到其本地分类账，并相应地更新区块链状态。

重启和恢复

chaincode 和 ledger 定期写入持久性存储中。

ledger enclave 每当有新的区块被处理之后，都需要向disk 同步。

chaincode enclave 初始化后密封并保存一次就足够了。当chaincode enclave重新启动并从密封状态恢复时，它将保留相同的enclave身份，不需要再次执行注册或远程证明。