前沿：TEE在跨链桥中的应用
作者：Middle.X
感谢 Ronnie @Bool Network、Aki @Darwinia 参与本文内容的探讨。
本文部分内容原载于《 PAKA跨链研究报告 》，点击查看完整报告。
与我交流：
Twitter：@middlex0
VX：xuezhijie156
在众多的跨链安全事故中，私钥泄露是其中一个重要类型。典型的案例是今年 3 月份Axie Infinity 官方桥 Ronin Bridge 遭遇的情况和 6 月份 Harmony 官方桥 Horizen Bridge 遭遇的情况，二者都因为跨链桥的验证人节点私钥泄露而导致重大损失。
由于验证人节点需要用程序来对跨链事件执行签名，这使得私钥不得不暴露在网络中，极易成为黑客攻击的目标。然而这样的问题，其实通过用 TEE 来管理节点私钥就可以很大程度上避免。TEE 还能以多种方式被应用于跨链桥，能够在优化跨链桥的安全性和性能上都发挥积极作用。
TEE 全称为可信执行环境（ Trusted Execute Environment ），它对于我们的日常生活而言并不陌生，手机上的指纹验证就是在 TEE 中运行的。
TEE 是在给定设备上运行的与主操作系统隔离的计算环境，就像一块飞地（Encalve）。这种隔离是通过硬件强制实现的。在 TEE 中运行程序的过程是隐蔽的，外界不可感知，这减少了 TEE 遭受黑客攻击的可能性。程序在 TEE 中运行完成后，输出的计算结果会被附上一个由设备生成的签名，该签名将被设备供应商远程验证，并生成远程验证证明。远程验证证明能够向外界证实该程序在TEE中被完整的执行，没有被篡改和干预。正因为如此，TEE 可以运行具有高安全性要求的应用程序，例如加密密钥管理、生物特征认证、安全支付处理等。
我们将结合 pNetwork、Avalanche、Bool Network、LCP 的案例来说明 TEE 在跨链桥中的具体应用。
pNetwork
pNetwork 是有 Provable Things 团队开发的一个跨链桥，于 2020 年 3 月推出，是一座 Wrap 桥，Wrap 资产被称为 pTokens。
Wrap 桥的基本模型是 Lock-Mint 和 Burn-Unlock，pNetwork 通过 一个 TEE节点组成的网络来负责验证源链上的 Lock 和 Burn 行为，并在目标链上执行 Mint 和 Unlock 。
任意拥有 TEE 设备的主体可以质押 200 $PNT（至少3个月），即可成为 pNetwork 的 TEE 节点。pNetwork 中的 TEE 节点网络将负责对跨链消息进行共识签名。在初始化时，TEE 节点集需要共同参与秘钥的计算，以生成公钥和私钥碎片，其中公钥只有一个，处于公开状态，私钥碎片则是在本地生成后，存入 TEE 中“密封”。即便是 TEE 节点的运行者也无法知道私钥碎片。
TEE 节点除了需要运行 Enclave 内的程序，还需在 Enclave 外运行接入链的全节点，以便于 Encalve 内的轻节点查询区块头。
pTokens 之旅
- 从 Token 到 pToken 的过程如下：
用户调用源链智能合约的 Lock 函数，发起 Lock 交易 T ，将 Token 存入 源链 托管地址，在交易备注字段中提供他们想要收款的目标链地址；
TEE 节点监听到交易后，进一步获取交易 T 所在区块的区块头 N 的所有 Lock 交易，向 Enclave 中传入，同时也会将区块头 N 及这些 Lock 交易的默克尔路径传入；
Enclave 中的轻节点程序首先验证区块头 N，然后用区块头 N 验证所有 Lock 交易；
一旦通过验证，Enclave 就会签名一批 Mint 交易，为所有目标地址 Mint 对应数量的 pToken；
各 Enclave 相互进行加密通讯，以合成完整的签名（2/3以上的私钥碎片签名可以合成完整签名），并提交这些 Mint 交易；
交易被广播到目标链，被目标链确认后，用户的目标地址就获得了 pToken。
- 从 pToken 到 Token 的过程如下：
用户调用源链智能合约，发起 Burn 交易 T ，将 pToken 发送到销毁地址，备注字段中写明目标链上的收款地址；
TEE 节点监听到交易后，进一步获取交易 T 所在区块的区块头 N 的所有 Burn 交易，向 Enclave 传入，同时也会将区块头 N 及这些 Burn 交易的默克尔路径传入；
Enclave 中的轻节点程序首先验证区块头 N ，并用区块头 N 验证这些 Burn 交易；
一旦验证通过，Enclave 就会签名一批 Unlock 交易，从托管地址中向所有目标地址转出对应数量的 Token；
各 Enclave 相互进行加密通讯，以合成完整的签名，并提交这些 Unlock 交易；
交易被广播到目标链，被目标链确认后，用户的目标地址就获得了 Token。
由于私钥在Enclave 中保管，且验证和签名的过程也在Enclave中进行，恶意攻击者攻击网络在经济上和实践上都不方便。此外，pToken Network 还鼓励TEE节点采用不同厂商的设备，不同厂商的 TEE 设备的具体原理可能是不同的，多元化厂商的 TEE节点 将进一步提高攻击者的攻击难度，因为攻击者需要攻破多个厂商的TEE设备才有可能实施攻击。
因此，采用 TEE 节点组成的 MPC 网络，相比非 TEE 节点组成的 MPC 网络，增加了一层安全保护。此外，pNetwork 选择将代码开源，开源代码明确了 Encalve 当中进行的每个过程，而远程证明中包含程序的哈希根，任何人都可以验证 Enclave 中执行的代码与 pNetwork 公开的代码的一致性，这是进一步的安全声明，因为排除了程序编写者作恶的可能性。
2021 年 10 月，pNetwork V2 发布，该版本将 pNetwork 拓展为了一座 AMB 桥。
pNetwork V2 延续了 V1 的核心特性，依旧使用 TEE节点组成的 MPC 网络来验证跨链消息，但 V2 版本将不局限于资产跨链相关的消息。
Avalanche Bridge
Avalanche Bridge (AB) 是 Avalanche 的官方跨链桥，目前支持 Avalanche C 链与 Ethereum 之间的跨链资产传递。
与 pNetwork 相同，Avalanche Bridge 用 TEE 节点组成的 MPC 网络来验证跨链事件，Avalanche Bridge 的 TEE 节点被称为 Warden（看守人）。为了追求更低的费率和更快的速度，Avalanche Bridge 在设计上做了些许优化。
首先，为了加快验证效率，Avalanche Bridge 直接在 TEE 内运行全节点，并在 Enclave 内建立索引来查询交易，而不像 pNetwork 的 TEE 节点在 Enclave 外运行全节点，在 Enclave 内运行轻节点。当然，pNetwork 现在支持 9 条链的资产传递，未来可能支持更多，如果这么做， Enclave 的存储空间可能会构成挑战。
其次，Avalanche Bridge 使用普通地址，而非合约地址来托管锁定资产。这避免了一部分合约调用的费用。
初始化的时候，Warden 之间相互加密通信，创建一个托管地址，并将私钥碎片密封在 各自的 Enclave 中，该托管地址是一个 0x 开头的 EOA 地址，既可以用于以太坊，也可以用于 Avalanche C 链。
我们以 ERC20 资产的跨链为例，来阐述 Avalanche Bridge 处理资产跨链的步骤：
- Wrap：Ethereum -> Avalanche
用户在以太坊上发起存款交易（无需调用合约），将需要跨链的 ERC20 资产转入托管地址；
每个 Warden 监控该地址，以发现这笔存款交易（Warden 不会监听链上的消息，而是直接通过 Avalanche bridge 前端界面的用户请求来发现存款交易，这意味着如果用户不通过 Avalanche bridge 前端界面发起交易，而直接向托管地址转账，Warden 是不会进行任何处理的）；
Warden 将交易传入 Enclave，Enclave 进行验证；
验证通过后，Warden 会用各自的私钥碎片签署一笔 Mint 交易，并相互进行加密通讯以合成完整签名（3/4以上的私钥碎片签名可以合成完整签名）。
Warden 向 Avalanche C 链提交 Mint 交易，使得托管地址调用 Mint 合约，为用户铸造 Wrap 资产（为了安全考虑，Avalanche Bridge 仅支持资产跨链至与发起地址相同的目标地址)。
- Unwrap：Avalanche -> Ethereum
用户在 Avalanche C 链上调用桥合约中的 Burn 函数，发起一笔销毁交易，将需要跨链的 Wrapped 资产发送到指定的销毁地址；
Warden 监控到这笔交易后，将交易传入 Enclave ；
Enclave 各自对这笔交易进行验证；
验证通过后，Enclave 各自用自己的私钥碎片签名一笔 Unlock 交易，以将托管地址中对应数量的原生资产发送给用户的 Ethereum 地址（无需调用合约）；
Enclave 相互进行加密通讯以合成完成签名，并将 Unlock 交易提交到 Ethereum，交易被确认后，用户将在以太坊上收到托管地址的转账。
我们发现 Avalanche Bridge 的资产跨链流程中，只有 Mint 交易和 Burn 交易需要调用合约，而 Lock 和 Unlock 交易只是普通的转账，不需要调用合约。这样的设计降低了Gas消耗，从而降低了用户端的跨链手续费。
无论是 pNetwork 和 Avalanche Bridge，都充分利用了 TEE 的特性，让私钥被外部攻击者窃取的可能性大幅降低。但我们要注意到，这依旧不能阻止 TEE 节点的内部串谋。
- 如果 TEE 节点之间合谋，可以试图合成私钥、替换Enclave里的程序，或者通过分叉源链制造虚假事件骗取 Enclave 的签名。
而我们下文要讲的 Bool Network，则可以做到“外防攻击，内防串谋”。
Bool Network
Bool Network 也是一个采用 TEE 节点网络作为外部验证者的跨链桥项目。Bool Network 做了进一步的创新—— 增加了 TEE 节点的轮值机制和匿名机制。
Bool Network 被设计为了一个 任意消息跨链桥，支持任意第三方在其上构建跨链应用。Bool Network 参考 Cosmos IBC，引入了 Channel 的概念，部署在不同链上的两个应用程序之间可以建立 Channel，以实现二者之间消息的有序传递。每个 Channel 都会对应至少一个 MPC 委员会。该委员会在当前 Epoch 内负责对该 Channel 内的跨链消息进行共识签名。这个 MPC 委员会是轮值的，任期只有 1 个 Epcoh，每个 Epcoh 都会重新选举。
- Bool Network 目前会为每个 Channel 分配两个委员会，互为备份，以提高服务可用性。
任何人都可以通过质押 $BOL 成为候选的 TEE 节点。每个 Epoch 开始前，Bool Network 会通过 Ring VRF 算法，为每个 Channel 选举 MPC 委员会。被选为 MPC 委员会成员的节点会获得一个用于通讯的临时身份（公私钥对），用于在共识签名过程中与同一委员会中的其他 TEE 节点通讯。当一个 Epoch 结束时，所有的临时身份都会失效，然后网络将重新进行节点选举，选出新的轮值 MPC 委员会，赋予他们新的临时身份。
尽管每个候选的 TEE 节点在注册的时候，需要提供永久身份信息（设备编码），但节点在通讯时使用的临时身份并不会暴露永久身份信息。换句话说，节点在通讯时是相互匿名的。如果候选节点有 100 个，那么你只能知道与你通讯的节点是这 100 个当中的 1 个，而不知道具体是哪一个。
每个 Channel 的 MPC 委员会需要多少个 TEE 节点，签名的门限是多少，是由 Channel 创建人自定义的。常用的门限数值有15-of-21、13-of-19、5-of-9。
同一个 Epoch 内，不同 Channel 的 MPC 委员会成员可能会有重叠，也有可能有部分候选节点没有被选入任何一个委员会，而出现闲置的状态。这些情况都是正常的。
我们发现，Bool Network 通过 TEE、轮值机制、匿名机制的组合，构建了一个牢不可破的黑箱。由于签名程序运行在匿名节点的 TEE 中，而且它们之间的通讯内容是加密的，当处于工作状态时，TEE 节点的运行者本人无从知晓自己被选入哪个 Channel 的 MPC 委员会，与哪些节点进行了共识通讯，签名了哪些消息，连“自知”都做不到，更谈不上“知人”。这基本上让节点串谋变的不可能。
从外部攻击者的角度，如果要攻击某个特定的 Channel，攻击者无从知晓当前的 MPC 委员会背后是哪些设备、哪些主体，也无法从通讯中截获这些信息。无论是内部串谋，还是外部攻击，都只能选择攻破所有候选节点中的大多数，才有可能攻击成功，这无疑代价是巨大的。
Bool Network 是一个仍在开发中的项目，还有些技术细节没有完全确定。
LCP
LCP 的全称是 Light Client Proxy （轻客户端代理），是 Datachain 提出的一个将 TEE 用于跨链桥的新范式，本文撰写时，LCP 尚处于概念阶段，没有代码实现。LCP 与前述三者完全不同。pNetwork、Avalanche Bridge、Bool Network 的思路都是用TEE 来管理私钥、验证消息、执行签名。LCP 的思路则是用 TEE 来运行轻客户端。
LCP 的思路或多或少借鉴了 LayerZero，LayerZero 用外部预言机网络来运行超轻客户端（Ultra Light Client），但这个“超轻客户端”并不会像一个真正的链节点那样对新获取的区块头进行验证，而是通过预言机网络的节点们共识签名来确认区块头的有效性。LCP 则希望在 TEE 内运行货真价实的轻客户端。
我们知道，轻客户端跨链桥是安全性最高的跨链桥技术类型，它通过在目标链上部署源链的轻客户端来使得目标链对源链的交易有验证能力。但其缺点非常显著：
链上的存储和计算资源紧张，链上的轻客户端在同步和验证区块头的过程中会消耗较多的 Gas，这会使得链上轻客户端很昂贵，有些情况下甚至不具备经济可行性。尽管有一些方案，可以构建相对轻量级的链上轻客户端，但这些方案又会增加开发难度和代码复杂度。
将轻客户端放到链下执行可以有效解决上述问题，但我们需要链上对链下轻客户端的运行状态进行验证，这点可以通过 TEE 的远程证明实现。理论上，LCP 仅需一个 TEE 节点，并不需要多个节点对交易的真实性进行共识确认。但为了保证可用性，安排一定的冗余还是有必要的。
当有交易 T 需要验证时：
交易 T 会首先被提交给 TEE 节点；
TEE 节点将交易 T 、交易 T 所在区块高度 N 、交易 T 的默克尔路径传入 Enclave
Enclave 中的轻客户端运行更新程序，更新到的区块高度 N （需要连接外部的全节点，但并不需要信任），并用高度为 N 的区块头对交易 T 执行 SPV 验证。
Enclave 在验证完成之后，通过远程认证，生成远程认证证明
TEE 节点将交易 T 的验证结果及远程认证证明提交到目标链
目标链上的校验程序检查远程认证证明的有效性，确认程序的确是在 TEE 中运行的，以及运行的程序是正确的轻客户端程序。
需要辨明的是，尽管 pNetwork 的 TEE 节点也会在运行轻客户端，但该轻客户端在验证交易之后会触发本地私钥碎片对交易的签名，链上最终验证的是签名，而非 TEE 内运行的程序本身，因此 pNetwork 依旧属于外部验证的范畴。LCP 则是向链上提交远程认证证明，这当中会包含程序哈希以供链上检查 TEE 中运行了正确的轻客户端程序，用「原生验证的扩展」来归类 LCP 会更为恰当。
在 TEE 中运行轻客户端，事情变的简单许多，轻客户端不再需要考虑如何节约存储和计算资源，不需要复杂的“瘦身”和“扩容”方案。但我们需要认识到，在 TEE 中运行轻客户端，始终要比在链上运行轻客户端的安全等级降低了一些。因为 TEE 并不是绝对安全，其技术防护手段有可能被攻破，且 TEE 设备的厂商也有微小的可能性作恶。不过这个问题可以通过 TEE 节点的冗余和设备厂商的多元化来弥合。
小结
以上我们讨论了 TEE 被应用于跨链桥的几种情况。
TEE 在跨链桥中最直接的应用便是保管私钥，正如我们所列举的pNetwork、Avalanche Bridge 和 Bool Network，在人们对跨链桥安全性忧心忡忡的当今此时，我们或许应该期待用 TEE 管理私钥成为多签类跨链桥的标配手段。 对于防止 TEE 节点的串谋，Bool Network 将节点匿名化的思路给了我们很好的启示，而 LCP 的方案，为轻客户端跨链桥提供了一个新的范式，它在基本保持轻客户端桥的理论安全度的前提下，提升了轻客户端桥的通用性和可扩展性。
跨链桥依旧在激烈的演化之中，TEE 的运用只是其演化方向之一。我们还在观察其他的演化方向，我们对更加安全的跨链桥充满期待。
参考资料
https://medium.com/pnetwork/introducing-pnetwork-v2-bfa7fcdcedb8