Sapio CTV 模拟器

Sapio CTV 模拟器定义了模拟器特质的实现，这些实现可以被 sapio 编译器库用户使用。这包括将模拟器实例组合成联邦多重签名的包装类型。

此 crate 还定义了希望提供模拟器服务的服务器逻辑。

有关如何运行服务器，请参阅 Sapio CLI。

工作原理

请参阅源代码以获取更详细的文档。

CheckTemplateVerify基本上相当于一个自签名的交易。也就是说，想象一下，你能否创建一个公钥，该公钥只能对符合特定模式的交易进行签名？

为了实现此功能，我们使用 BIP-32 HD 密钥与公共派生。

在初始化时，服务器选择一个种子 S 并从中生成一个根公钥 K，然后发布 K。

用户生成一个交易 T 并提取其 CheckTemplateVerify 哈希 H。然后，他们将 H 转换为 8 个 u32 和 1 个 u8 的派生路径 D，用于非强化派生（请参阅 hash_to_child_vec）。

然后将此派生路径应用于 K 以生成密钥 C。将此密钥与 CheckSig(SIGHASH_ALL) 添加到脚本中，以替换 CTV 条款。

然后，当用户希望使用此类密钥消费输出时，他们创建整个他们想要发生的交易并将其发送到模拟器服务器。

即使服务器没有检查密钥是否用于交易，它也会生成模板哈希 H'（应等于 H），然后签名，并将签名返回给客户端。

在创建合约之前，客户端可能希望收集所有可能的签名，以防止可用性故障。

此方案的好处是：

1. 合约规范可以在没有任何在线过程中发生
2. 服务器没有智能逻辑，所有保证都是结构性的。
3. 服务器是完全无状态的。
4. 可以使用多重签名来控制可用性/恶意行为。
5. 1:1功能映射到CTV。

这种仿真方法的缺点是：

1. 对于具有许多分支可能性的脚本，它不太高效。
2. 没有在用后删除密钥的内在机制，以防止未来的数据泄露。

为什么选择BIP-32

我们使用BIP-32，因为它是一个经过充分研究的基本原始数据，派生路径与现有的签名硬件兼容。虽然将32字节的调整直接应用于密钥可能更有效，但与现有工具的互操作性似乎是最好的路径。