TrustChain: 一种赋能去中心化服务经济的信任即服务 (TaaS) 协议
作者: 0xwilsonwu
1.1 Web3 未兑现的承诺
区块链创新的第一个十年主要由数字资产的金融化主导。比特币和以太坊等协议出色地解决了去中心化价值转移的问题，有效地充当了全球性的、抗审查的结算层。在 Alice 向 Bob 发送 100 USDT 的标准交易中，区块链的角色严格限于验证 Alice 拥有资金并不可篡改地记录状态变更。
至关重要的是，这种模式在一个重大的假设下运作：Alice 信任 Bob。 他们可能在链下相互认识，或者该交易可能只是链上资产的简单原子交换。协议本身并不关心 Bob 是否真正交付了他为换取资金而承诺的现实世界服务、数字产品或链下计算。
2. 系统架构
2.3 基础数据结构变更：类型化信封范式
为了在不通过标准交易膨胀或为每个新功能要求硬分叉的情况下启用此功能，TrustChain 采用了类型化交易信封范式。
基础协议定义了一个通用信封，根据类型 ID 多态地持有不同的交易类型，而不是僵化的、单体交易结构。
// 现代的、可扩展的交易信封type Transaction struct { // 核心字段 1: 类型 ID (例如, 0x02=标准, 0x03=TaaS_托管交易) Type uint8 // 核心字段 2: 多态交易负载。 Inner TxData }// 所有具体交易类型实现的接口type TxData interface { txType() byte // ... 访问发送者、Gas 设置等的标准方法}
这种架构允许我们为 TaaS 功能（类型 0x03）定义专用的结构，同时保持标准交易（类型 0x02）的原样和高效。
TaaS 托管交易结构 (类型 0x03):
// TaaS 托管交易的具体结构type EscrowTxData struct { // --- 标准字段 (继承以保持基础层兼容性) --- Nonce uint64 To *common.Address // 服务提供商 (卖家) Value *big.Int // 总金额 (价格 服务费) // ... Gas 和签名 ... // --- TrustChain 创新字段 (类型 0x03 独有) --- // 明确分配给验证器/中继器的费用。 VerifierFee *big.Int // 验证器合约的地址 (替代静态的验证器类型)。 // 这指向实现了 IVerifier 的已部署智能合约。 VerifierAddress common.Address // 服务协议或预期输出的加密哈希。 ConditionHash common.Hash // 买家可以发起时间锁定退款的区块高度。 // 包含强制性的“宽限期”以防止拥堵攻击。 TimeoutHeight uint64}
3. 可插拔验证器框架
3.3 标准验证器接口
该框架依赖于标准化的 IVerifier 接口，允许 EEE 统一地与各种证明机制交互。
// 可插拔验证器模块的标准接口type IVerifier interface { // 针对交易条件验证提交的证明 VerifyProof( escrowID common.Hash, conditionHash common.Hash, proofData []byte ) (bool, error)}
4.1 概述
TrustChain 采用稳健的加密经济模型来协调所有参与者的激励。该系统旨在自我维持，确保保护网络的人获得充分补偿，而恶意行为者受到惩罚。
4.4 质押与罚没机制
为了确保托管验证者的诚实行为：
- 质押要求: 验证者必须锁定大量的原生代币作为安全保证金，才有资格接收验证任务。
- 罚没条件: 如果验证者被证明有恶意行为（例如，通过加密欺诈证明被证实证明了欺诈性 TEE 报告），其质押代币的一部分或全部将被瞬间罚没（销毁或重新分配）。这种经济惩罚旨在超过合谋带来的任何潜在短期收益。
5.2 人工仲裁的角色
虽然核心协议专注于加密和客观证明，但 可插拔验证器 架构允许“人机回环”解决方案（例如 Kleros, Aragon Court）来处理主观争议。然而，这些是更高层的抽象。在基础层，TrustChain 保证 凭证明结算，消除了不付款或不交付的交易对手风险，但它并不取代对链下声誉或用于定性争议的法律框架的需求。
