资产提取
通过 TEE + zk 证明和原生桥接实现快速、安全的应用链资产提取。关键概念和所需配置。
互操作性对于应用链最大化覆盖范围、实用性和用户体验至关重要。Syndicate 的提取系统结合了可信执行环境 (TEE) 和 zk 验证的证明，支持无需许可的非交互式验证。通过取代基于挑战的欺诈证明，它以原生桥接的安全性提供接近即时的最终性，结合了快速桥接的速度和规范桥接的安全性，无需分叉或额外的操作开销。
设计原理
我们定制的排序层改变了交易的处理、排序和派生方式，这带来了两个选择：
- 分叉 Arbitrum Orbit 并定制其欺诈证明系统（违反我们的无分叉原则，延迟更新，并且每个汇总框架都需要定制工作）
- 构建一个通用的解决方案，适用于任何汇总框架（无分叉，无定制欺诈证明）
我们选择了通用的解决方案。
核心组件
TEE (AWS Nitro):
提供一个安全的计算环境。（注意：AWS Nitro TEE，不是 Arbitrum Nitro）
- 角色： 执行派生，验证排序/应用链转换，并输出签名的提取声明。
- 信任： 只有其证明（PCR 测量值）通过 zk 验证的 enclave 才会被链上白名单允许。
- 链上检查：
TeeModule验证 ECDSA 签名；TeeKeyManager接受由 zk 验证器证明的密钥。 - 开发者体验： 像往常一样使用原生桥接；提议者与 enclave 交互。升级只需重新证明/白名单密钥，而无需更改应用程序。
zkVM (Succinct SP1)
- 角色： 证明 AWS Nitro 的证明有效，而无需透露完整文档。
- 链上：
AttestationDocVerifier检查 SP1 证明（Groth16/Plonk），并强制执行预期的根证书、PCR 和有效期，返回tee_signing_key以供白名单使用。 - 公开输出： 根证书哈希、有效期、PCR0/1/2 和
tee_signing_key。 - 开发者体验： 您无需调用 zkVM。证明提交者生成证明并在链上注册/轮换 enclave 密钥。
未来升级
- 支持不同云服务提供商的多 TEE
- 支持多提供商的多 zkVM 系统
- 需要多个参与方的签署
- 包括系统意见不一致时的挑战机制
提现流程
[User/Appchain] -- withdrawal request
|
v
[Proposer] -- validate request + build trusted input
|
v
[TEE Enclave] -- verify state + sign assertion --> [TeeModule on settlement]
|
|-- attestation verified on-chain -------> [TeeKeyManager + zk verifier]
|
[TeeModule] -- finalize -----> posts to rollup (e.g., Base) -> withdrawals enabled- 请求接收： 系统接收提现请求
- 验证与签署：
- 确认提现请求中的所有状态转换均有效
- 验证提现请求已以抗重组的方式作为状态根提交到结算链
- 执行标准检查：用户余额验证、状态有效性、状态货币
- TEE 签署： 如果验证通过，TEE 使用其内部密钥进行签署
- 密钥验证： TEE 的密钥被认为有效，因为 ZKVM 的证明已验证其有效性
- 桥接集成： 通过 Arbitrum 的快速提现机制（使用数据可用性委员会接口，但由我们的提现系统提供签署而非 DA 层）与 Arbitrum 的原生桥接集成。无需对 Arbitrum 桥接本身进行修改。
主要优势
- 框架无关性： 可与任何 Rollup 框架配合使用，无需定制
- 无需分叉维护： 客户可以立即整合 Arbitrum Orbit 更新
- 原生桥接安全性： 无需自定义桥接来存放资金。资金存放在 Arbitrum 的桥接中，并使用现有功能实现提现
- 安全性升级： 对争议情况提供快速提现和挑战机制
- 去中心化操作： TEE 可由任何人运行，而不仅限于核心团队
- 多提供商冗余： 未来的多 TEE/多 zkVM 架构可防止单点故障
当前状态
- 提现系统目前正在开发中
- 从一个 TEE 和一个 zkVM 实现开始
- 将逐步增加更多的提供商
注意：这是一个正在开发中的新系统。架构已稳定，但细节可能会有所变化。如有疑问或反馈，请联系 Syndicate 团队。
- 挑战期： 提现可被争议的时间窗口（由 chain 所有者配置，建议为 60 分钟）
- 批量发布间隔： 提现批次发布到 L1 的频率（1 小时）
- L1 最终确认： 以太坊 L1 的最终确认大约需要 12.8 分钟
提现时间的变化取决于您的提现在批量发布窗口中的位置。如果您在下一个每小时批次之前提交，您将获得最短时间。如果您在批次发布后提交，则需要等待下一个批次周期。
60 分钟挑战期（推荐）
在 60 分钟挑战期内：
| 指标 | 时间 |
|---|---|
| 最短 | ~73 分钟 |
| 平均 | ~133 分钟 |
| 最长 | ~193 分钟 |
60 分钟的挑战期提供了强有力的安全保障，并为 TEE 验证器检测和标记无效提现提供了足够的时间。未被争议的提现将在 3.5 小时内完成。
更短的挑战期
挑战期可以由 chain 所有者随时配置，但较短的挑战期会增加操作风险。chain 所有者可以选择使用时间锁合约来管理挑战期的更改。较短的时间窗口意味着 TEE 验证器检测和挑战无效提现的时间更少——如果 TEE 验证器在短挑战期内出现停机，无效提现可能会无人争议。
例如，使用 5 分钟的挑战期：
| 指标 | 时间 |
|---|---|
| 最短 | ~18 分钟 |
| 平均 | ~50 分钟 |
| 最长 | ~83 分钟 |
虽然这提供了更快的未被争议提现，但缩短的时间窗口需要更高的 TEE 验证器正常运行时间保证。
受质疑的提现
当 TEE 验证者检测到无效提现（表明可能存在漏洞或 TEE 被攻破）时，会触发质疑。受质疑的提现将被发送至安全委员会进行人工解决。由于争议情况较为罕见，此过程不受上述正常时间预期的限制。
即时桥接与用户体验
在实际操作中，大多数桥接路径使用即时桥接，将提现时间对终端用户的影响抽象化。用户会看到提现在几秒内完成，且滑点极小。底层提现时间仅影响即时桥接重新平衡其流动性的速度。
对于即时桥接的流动性重新平衡，少于 4 小时的提现时间已经足够。这意味着当集成即时桥接时，技术提现时间对实际用户体验的影响微乎其微。
L1 最终性约束
提现速度不能快于以太坊 L1 的最终确认时间（约 12.8 分钟）。尝试在未最终确认的区块上处理提现会引入重组风险——以太坊 L1 大约每两小时会发生一次重组，这可能导致资金损失。
结算链的位置（L2 或 L3）不会影响此约束。所有提现都受 L1 最终性限制，无论桥接位于何处。
时间公式
供参考，提现时间可以通过以下公式计算：
Min: 1 × challenge period + 0 × batch interval + 12.8 min
Average: 1.5 × challenge period + 0.5 × batch interval + 12.8 min
Max: 2 × challenge period + 1 × batch interval + 12.8 min当前状态
- 提现系统已启用
- 从一个 TEE 提供商和一个 zkVM 实现开始
- 将逐步增加更多提供商
注意：这是一个正在开发的新系统。架构已稳定，但细节可能会有所变化。如有问题或反馈，请联系 Syndicate 团队。