蚂蚁区块链第6课 TEE硬件隐私合约链(含标准合约链)的框架和功能概述
1，摘要
本文介绍蚂蚁区块链的TEE硬件隐私合约链和标准合约链的框架和功能介绍，说明开发流程。 TEE 硬件隐私合约链是在标准合约链功能基础上采用TEE硬件叠加隐私保护相关功能。
2，蚂蚁区块链标准合约链介绍
蚂蚁区块链合约链通过引入 P2P 网络、共识算法、虚拟机、智能合约、密码学、数据存储等技术特性，构建一个稳定、高效、安全的图灵完备智能合约执行环境，提供账户的基本操作以及面向智能合约的功能调用。基于合约平台提供的能力和功能特性，应用开发者能够完成基本的账户创建、合约调用、结果查询、事件监听等。
蚂蚁区块链合约链系统架构：
蚂蚁区块链合约链核心逻辑：
3，蚂蚁区块链功能特性
按照不同访问对象，可以将合约平台的基本功能划分为 账户操作、合约访问、区块查询、交易查询、事件监听 等多种类型。除此之外，合约平台还具备 数据隔离、隐私保护、SPV 验证 等功能特性，以满足各种业务场景的需求。
3.1 账户体系
合约平台所有交易操作均是围绕账户体系来进行，因此在发送执行交易之前需确保您已在合约平台创建对应的账户，然后可使用创建好的账户提交交易，还可以基于该账户结构完成相关账户配置的修改。
具体的账户数据结构模型字段和说明如下：
字段 | 说明 |
|---|---|
id | 账户的标识 |
auth_map | 账户或者合约的公钥和权重值 |
recover_key | 恢复公钥，用于账户私钥丢失的情况 |
balance | 余额 |
recover_time | 上次成功恢复的时间 |
status | 状态， 0：正常；1：冻结；2：恢复中 |
encryption_key | 加密公钥，用来加密智能合约中的交易金额 |
其中，账户包含三种类型的密钥： 权限密钥（auth_map）：用于账户发送正常交易时使用的签名密钥，支持多个密钥，按权重分配实现多签名，是区块链节点判断交易是否有效授权的依据。 恢复密钥（recover_key）：重置账户权限密钥时使用的签名密钥，对于已经存在的账户，合约平台提供重置、更新账户授权密钥以及重置账户恢复的能力。 加密密钥（encryption_key）：用于隐私保护场景下的数据加密密钥，可被交易参与方获取并用于隐私数据的加密。
合约平台采用将账户与密钥解耦的方式来实现，从一定程度上防止因为密钥丢失带来的链上数据丢失等安全隐患。合约平台支持的主要账户操作包括： 创建账户：在区块链平台上创建一个唯一的账户数据结构，主要用于记录链上账户的公钥。 更新密钥：修改区块链平台上特定账户下的注册公钥，主要应用于交易签名密钥的更改和权重变更。 重置密钥：基于账户的重置密钥来重置区块链平台上特定账户下的注册公钥。 账户冻结：冻结区块链平台上的特定账户，阻止该账户后续继续发送交易。 账户解冻：解冻区块链平台上已经处于冻结状态的账户，恢复其发送交易的能力。
3.2 合约体系
合约平台内置了 EVM（Ethereum Virtual Machine）和 WASM（WebAssembly）两种智能合约执行引擎，支持多种合约编程语言，如Solidity 和 C++。您可以在合约平台上部署编写的智能合约并进行业务逻辑的调用。
合约平台上的合约数据结构模型如下：
参数 | 说明 |
|---|---|
id | 合约的标识 |
auth_map | 账户或者合约的公钥和权重值 |
recover_key | 恢复公钥，用于账户私钥丢失的情况 |
balance | 余额 |
recover_time | 上次成功恢复的时间 |
status | 状态， 0：正常；1：冻结；2：恢复中 |
storage_root | 世界状态的默克尔哈希根 |
code_hash | 合约代码哈希 |
code | 合约代码 |
相比于账户结构，合约中有额外的代码和存储相关的字段。
合约平台提供合约部署、升级、调用、冻结、解冻等生命周期的管理，这些操作均通过交易来实现。 合约部署：在区块链平台上创建一个智能合约账户，并在该账户下绑定特定的智能合约编译字节码。 合约升级：升级区块链平台上的一个智能合约账户代码，主要应用于合约代码功能的迭代和缺陷的修复后升级（需要满足一定的升级约束）。 合约调用：基本的合约方法调用能力，通过交易调用智能合约的特定功能入口，修改或者检索智能合约中的存储数据。 合约冻结：冻结区块链平台上的特定智能合约账户，被冻结的智能合约代码不能被用户调用，主要应用于智能合约发现缺陷后的紧急处理以防止缺陷的扩散。 合约解冻：解冻区块链平台上的特定智能合约账户，主要应用于被冻结的缺陷代码修复后的恢复操作。
3.3 区块查询
合约平台以区块的形式组织交易历史和管理世界状态，系统根据给定的参数配置按照一定的规则执行交易并打包生成区块。在合约平台上，一个区块包含区块头和区块体两个部分。
区块头数据结构模型如下：
参数 | 说明 |
|---|---|
hash | 区块头的哈希 |
version | 版本 |
number | 区块号 |
parent_hash | 上一区块哈希 |
transaction_root | 区块体中的交易构成的默克尔哈希根 |
receipt_root | 区块体中的收据构成的默克尔哈希根 |
state_root | 世界状态的默克尔哈希根 |
gas_used | 交易执行的总消耗量 |
timestamp | 时间戳 |
log_bloom | 日志布隆过滤器 |
区块体数据结构模型如下：
参数 | 说明 |
|---|---|
transaction_list | 交易列表 |
receipt_list | 收据列表 |
consensus_proof | 共识证明 |
系统提供一系列的功能完成对已经生成的区块数据的查询需求，具体功能如下： 区块头查询：基于给定的区块号或哈希，返回该特定区块头数据结构，包括区块哈希、区块版本、块号、父区块哈希、交易列表根哈希、收据列表根哈希、世界状态根哈希、燃料消耗值、时间戳信息、共识证明等。 区块体查询：基于给定的区块号或哈希，返回该特定区块体的详细信息，包括交易列表、收据列表和共识证明。
3.4 交易查询
合约平台的所有数据变更均是基于交易形式来完成的。合约平台的交易根据类型的不同可以分为创建账户、余额转账、部署合约、更新合约、调用合约、设置恢复密钥、预重置权限密钥、重置权限密钥、更新权限密钥、冻结账户、解冻账户、隐私交易等。
交易数据结构模型如下：
参数 | 说明 |
|---|---|
hash | 交易的哈希，由 signature 字段以外的所有字段构成。 |
type | 交易的类型 |
timestamp | 交易的时间戳 |
nonce | 防止重放攻击 |
period | 单位为毫秒，事务开始或结束的时间，为未来扩展使用。 |
from | 交易的发送者 |
to | 交易的接收者 |
value | 转账金额 |
gas | 交易执行的消耗费用 |
data | 交易数据内容的编码 |
group_id | 交易在一个 group 中执行 |
signature | 签名，使用一个或者多个私钥对 hash 加签 |
extensions | 交易扩展字段，类型为 vector，元素类型为TransactionExtension。TransactionExtension 包含key_(uint32_t) 与 value_(bytes) 两个字段，目前用于智能合约中的证明数据。 |
交易收据是合约平台中交易打包执行后的结果数据，用以标识交易的执行成功与否，执行后的返回数据以及产生的相关事件等。
交易收据数据结构模型如下：
参数 | 说明 |
|---|---|
result | 交易执行成功与否标识，0 标识成功，非 0 标识失败。 |
gas_used | 执行交易所消耗的燃料费用，代表交易执行的复杂度。 |
logs | 交易执行所产生的日志或者事件列表。 |
output | 交易执行返回的数据内容。 |
通过 SDK 可以对某一个具体交易的信息进行查询，从而可以检索已经存在于块链结构中的任意交易信息。在系统中发生的每一笔交易都会对应一笔交易收据，交易收据也可以通过 SDK 查询。
交易查询：基于给定的交易哈希，返回该特定交易的详细信息，包括所在块号、交易号索引、交易哈希、交易类型、交易时间戳、交易 nonce、发起方、接收方、交易值、交易燃料消耗上限、交易输入数据、交易签名信息等。 交易收据查询：基于给定的交易哈希，返回该特定交易的收据详细信息，包括所在块号、交易号索引、交易结果、实际燃料消耗、交易执行输出、日志记录（发起方、接收方、交易类型、日志数据元信息）等。
3.5 事件监听
合约平台在执行交易和打包生成区块时会产生一系列的业务日志事件和系统日志事件，这些事件代表合约平台的一些运行状态。合约平台提供了一套基于事件订阅发布的机制来实时推送平台的日志事件给感兴趣的客户端。合约平台支持订阅账户事件、合约事件、特定主题事件、区块事件。
事件数据结构模型如下：
参数 | 说明 |
|---|---|
from | 交易的发起方 |
to | 交易的接收方 |
topics | 事件对应的主题 |
log_data | 事件所携带的具体数据 |
您可通过 SDK 订阅感兴趣的事件，使用地址标识或者主题标识来请求合约平台相关事件推送。
事件订阅：给定事件过滤器来订阅合约平台的事件通知。 取消事件订阅：取消已经完成的事件订阅，告知合约平台不再推送事件通知。
3.6 隐私保护
合约平台通过引入密码学的一些特性来支持账户信息敏感数据的隐私保护能力，通过在智能合约层面扩展相关的指令函数来实现智能合约中金额的加密存储以及加减操作。只有获得有效密钥的个体才能解密智能合约中的敏感数据，查看原始金额信息。
目前，合约平台引入的密码学特性包括零知识证明，即通过引入零知识证明来实现加密密文条件下转账金额的合法性证明。
3.7 数据隔离
为能够满足更多的隐私保护诉求，合约平台引入数据隔离来实现业务敏感数据的交易的可见性。借助合约平台数据隔离的能力，可以实现交易请求仅仅在有限的区块链节点之间得以查看和被执行，同时敏感隐私数据也仅仅在有限的节点内被存储。
根据不同的环境依赖和信任基础，数据隔离功能包含以下三种操作：
- ENCRYPTION_ENVELOPE：加密信封交易，通过信封加密技术将原始交易加密并在合约平台的公开账本上进行传播，掌握解密密钥的节点解开信封获取原始交易在本地执行。这样的操作对节点网络的依赖度相对较低，信任的基础是密码学技术。
- DEPOSIT_ENVELOPE：存证信封交易，通过信封加密技术点对点传播，并将原始交易的哈希存储在公开账本上，用以实现对存证信封交易的共识。这样的操作对节点的网络依赖度相对较高，信任的基础是控制数据的有限范围传播。
- GROUP_ENVELOPE：子链信封交易，通过衍生一个与公开账本的并行账本来实现隐私交易的执行和结果共识。不仅对私有账本数据的隐私交易进行保护，还实现了私有账本数据的执行结果共识操作。
3.8 SPV 验证
简单支付验证（Simplified Payment Verification，SPV）验证是合约平台提供的一种数据验证能力，能够在付出很小的存储代价和数据同步代价情况下完成对合约平台上存储数据的合法性校验。基于这种能力，您可以快速实现一个合约平台的轻客户端，完成与其他区块链平台的数据同步和访问。
SPV 的验证能力能够对合约平台上的以下数据给出有效性的证明：
- 区块证明：用于证明一个指定的区块是否在合约平台的账本数据中存在。主要利用区块的链式结构和平台的共识证明来实现证明。
- 交易证明：用于证明一个指定的交易或者交易执行结果是否在合约平台的账本数据中存在。主要利用交易默克尔证明结合区块证明来实现。
- 账户证明：用于证明一个指定的账户数据是否在合约平台的指定区块的账本数据中存在。主要利用存储默克尔证明结合区块证明来实现。
- 存储证明：用于证明一个指定的存储数据是否在合约平台的指定区块下账户中存在。主要利用存储默克尔证明结合区块证明来实现。
4，蚂蚁区块链TEE硬件隐私合约链介绍
目前，TEE 硬件隐私合约链仅供 蚂蚁区块链创新大赛 试用，尚未正式对外发布。 隐私保护是区块链技术赋能金融应用场景中所不可缺少的需求。通用高效的区块链隐私保护技术一直是工业界和学术界关注的重点。金融领域复杂的应用场景通常要求区块链隐私保护至少具备以下四方面的能力：
全生命周期的保护：合约和交易的内容、执行过程中状态以及执行结果都可能涉及企业的商业信息，隐私保护应该包括数据全生命周期的机密性。 全网范围保护：隐私保护技术的引入不能打破区块链原有的共识信任模型，即全网（或一定数量的子集）节点应该具有独立验证隐私数据相关交易的能力。 灵活支持复杂隐私模型：隐私模型的灵活度和复杂度，即在复杂多变的金融应用场景中，隐私模型的定义要足够灵活，能够动态更新以适应需求变化。 高性能的保护：隐私保护技术的引入必须兼顾平台的性能。 从技术上来说，要同时满足上述四点要求极具挑战。
蚂蚁区块链的 TEE（Trusted Execution Enviorment）硬件隐私合约链（以下简称“TEE 合约链”）充分利用硬件 TEE 技术，为金融级别企业用户提供高效、通用、安全的区块链隐私保护能力。同时，TEE 合约链的开发者无需具备深厚的密码学背景，便可将已有的智能合约无缝迁移至 TEE 合约链平台并通过隐私模型的定义来启用隐私保护功能。
4.1 技术架构
TEE 合约链架构在蚂蚁区块链合约平台之上，作为核心组件提供通用高效的隐私保护能力。在蚂蚁区块链平台通用框架下，TEE 合约链利用 TEE 技术将合约引擎和必要的交易处理以及密码学运算单元集成封装在“TEE安全区”内，配合一系列严谨的安全协议流程达到隐私保护的目的。该架构充分利用蚂蚁区块链平台已有的功能特性，最大限度增加了 TEE 合约链与已有蚂蚁区块链平台的兼容性，方便用户开发使用具有隐私保护能力的区块链应用。同时最小化安全可信基，符合安全技术方案设计的原则。
下面是 TEE 合约链与蚂蚁区块链平台结合的总体框架图：
- 区块链的隐私保护体现在对交易全生命周期的保护，需要保护交易本身、合约代码、全局状态数据以及交易回执。
- 在 TEE 合约链中，交易分为隐私交易和明文交易。明文交易即无需隐私保护的交易，其执行过程与现有蚂蚁区块链平台一致；隐私交易是利用密码学技术进行保护的交易，交易内容只有在 TEE 内才安全可见，其执行过程中产生的全局状态数据以及交易回执均采用密码学技术进行加密保护。
- 在 TEE 合约链中，合约分为隐私合约和明文合约。隐私合约的代码和相应的数据加密存储，仅在 TEE 内部解密执行，相应的回执和状态均加密存储于外部数据库。
下图对比蚂蚁区块链合约平台和 TEE 合约链的交易处理流程：
4.2 功能特性
4.2.1 交易与合约类型定义
- 明文交易 v.s. 隐私交易 明文交易指的是公开的、未启用隐私保护的区块链交易。交易内容以明文发送至区块链节点运行且明文记录；隐私交易指的是启用隐私保护的交易，交易内容加密发送至节点，在 TEE 中运行并加密记录于区块中。隐私交易默认对发送者以外的人不可见。
- 明文合约 v.s. 隐私合约 明文合约是通过明文交易部署的合约，合约执行过程中的全局状态明文存储于区块链节点本地数据库，调用接口完全开放；隐私合约是启用隐私保护的合约，通过隐私交易发起部署，合约执行过程在 TEE 中，所有的全局状态均加密存储，调用接口有限开放。
4.2.2 支持多种隐私操作
- 合约：隐私合约部署、隐私合约调用、保护合约调用（直接调用和代理调用均支持）、隐私合约升级。
- 查询：隐私链上数据存储查询（全局状态、交易、回执、日志）。
4.2.3 交易隐私
TEE 合约链支持加密交易发送，保护交易全生命周期的隐私性，包括：
- 交易在客户端完成数字信封加密，发送至节点过程中通过 SSL/TLS 信道保护，到达节点后交由 TEE 处理。
- 隐私交易进入 TEE 后进行相应的解密操作，完成必要的检查后开始执行。
- 执行完成后所有合约状态加密存储，并生成加密回执。
- 交易发送者通过客户端 SDK 提供的接口完成回执解密。
4.2.4 通用高效
TEE 由 CPU 硬件提供保护：
- 具有高度安全隔离和可证明特性。
- 支持通用 CPU 指令，支持各类合约虚拟机指令操作。
- 高效利用 CPU 特有指令集对包括加解密算法的操作进行通用加速。
4.2.5 权限控制
TEE 合约链支持用户自定义隐私权限控制：
- 合约编写者根据需求指定合约调用、查询权限保证数据隐私完全自主可控。
- 权限控制模型支持合约层面的灵活定制和无缝升级。
4.2.6 安全易管
金融级别的密钥管理体系——根据需求可以灵活配置和管理。
4.3 使用场景
TEE 合约链适用于以下任意场景：
- 需要隐私保护的合约逻辑复杂。
- 隐私模型本身复杂，需要灵活定制和动态更新。
- 对隐私保护有较高的性能要求。
- 隐私方案需要对开发者透明友好，不需要深入的密码学基础。
- 已有业务向隐私保护模型迁移时需要对应用层透明。
4.4 注意事项
TEE 合约链最大限度的保持了与蚂蚁区块链平台的兼容性，但不可避免的需要引入一些特殊特性来完成全生命周期的交易隐私保护。TEE 合约链提供相应的客户端 SDK，为您提供简洁一致的隐私交易构造接口。在使用 SDK 进行应用开发的过程中，需注意以下三个事项：
- 交易根密钥：用户需保管好自己的交易根密钥，且根密钥切勿随意导出分享。
- 节点 RSA 公钥：可公开下载TEE合约链节点RSA公钥，用户需下载该公钥提供给SDK相应接口用于生成隐私交易。用户可以同时下载TEE合约链的节点认证报告，通过报告中的RSA公钥哈希值确保所使用的RSA公钥的完整性。
- 隐私权限模型：TEE 合约链配合用户隐私权限模型达到隐私保护的目的。安全合理的隐私权限模型是整个隐私保护的基础，需要由用户严格定义。
5，蚂蚁区块链应用开发框架和流程
传统的 Web 应用开发通常由客户端和后端服务组成。而基于合约平台的应用开发除了客户端和服务端开发，还需要开发区块链上运行的智能合约。
5.1 开发框架
传统后端服务主要由“计算逻辑”和“数据库”组成，智能合约恰好也包含了“计算逻辑”和“状态存储”。对由于某些场景，合约平台的应用可以直接通过客户端调用智能合约的方式实现，此时智能合约替代了传统的后端服务。
传统 Web 应用开发框架图：
基于合约平台的应用开发框架图：
基于合约平台开发应用时，您可以有以下 3 种选择：
- 选项 1：通过 SDK 在命令行与区块链合约平台交互。
- 选项 2：通过 Web 应用（Client）集成 SDK 直接与区块链合约平台交互。该方式让客户端直接访问区块链平台，去掉了中间的后端服务，更加透明，比较适合轻量级的合约调用、查询等操作。
- 选项 3：与传统 Web 应用开发相似，访问后端服务（Service），后端服务集成 SDK 后与区块链合约平台交互。该方式适合与传统的业务系统相结合，在后端服务层实现一些比较重要的业务逻辑和计算任务。 在实际操作中，选项 2 和 3 比较常用，您可以根据具体应用场景进行选择。
5.2 开发流程
在实际业务实现中，基于合约平台的应用开发并不约束于具体的开发流程。在联盟链多方参与的场景中，建议按照以下过程梳理业务场景，按步骤实现：
- 定义多方协作中，智能合约需要实现的逻辑和功能，实现智能合约。
- 定义各参与方客户端或后端服务的业务逻辑，以及与智能合约交互的接口逻辑，集成 SDK 实现。
- 集成 SDK 的业务逻辑与智能合约交互，测试功能。
- 多方参与的功能性集成测试。
5.3 工具和 SDK 选择
为提高基于区块链合约平台的开发效率，BaaS 平台提供了辅助开发工具和多语言的 SDK 支持。
5.4 Cloud IDE 合约开发环境
Cloud IDE 是一个在线的合约开发环境，此工具提供以下功能：
- 合约编辑与编译，展示编译结果字节码和接口说明（ABI）。
- 合约的部署和调用；提供默认体验链环境和测试账户，用来部署和调用合约。
- 解析合约方法的返回值、事件日志等，辅助调试合约；保存合约到 BaaS 合约管理。
更多 Cloud IDE 相关信息，参见 Cloud IDE 合约开发环境 相关文档。
5.5 多语言 SDK
合约平台提供多语言 SDK 支持，包括：
SDK 语言 | 功能特性 | 说明 |
|---|---|---|
Java | 功能最丰富，覆盖合约平台所有的功能。 | 适合用于后端服务层。更多信息，参见 Java SDK 说明 。 |
C++ | 功能丰富，与 Java SDK 功能相似。 | 比较适合与传统 C++ 服务相结合。更多信息，参见 C++ SDK 说明。 |
Java Script | 覆盖基本常用的 API，支持 Node.js 和浏览器环境运行，不支持国密。 | 适合客户端 Web 应用集成。更多信息，参见 JS SDK 说明。 |
6，参考
（1）合约平台概述 https://tech.antfin.com/docs/2/101801 （2）TEE 合约链概述 https://tech.antfin.com/docs/2/107468
腾讯云开发者
