介绍
2020 年 5 月，Tyler van der Hoeven 撰写了一份名为 TSS（图灵签名服务器）的实验性恒星生态系统智能合约引擎的提案。在 Script3，我们一直在研究在 Stellar 上构建 DeFi（去中心化金融）协议，因此我们立即参与了该项目。一旦 TSS 成为现实，我们与 SDF 和 JST Capital 合作创建了 Project Venus，这是一种 DeFi FX 短期远期协议，作为基于 TSS 的 DeFi 协议的概念证明。
TSS 概述
TSS 是一个服务器网络（称为塔楼），用于存储智能合约，并将根据用户请求上传的智能合约规范构建和签署交易。用户可以将智能合约上传到任何转台，转台将创建一个密钥对，用于签署此智能合约生成的交易，然后将该密钥对的公钥返回给用户。
将此网络与 Stellar 的多重签名功能相结合，可以在 Stellar 上实现去信任的 DeFi 协议。开发者将 DeFi 协议的智能合约上传到多个受信任的炮塔，并在协议账户上添加相关的公钥作为签名者。接下来，开发人员修改协议帐户的签名者权重和阈值，以要求大多数转塔在交易有效之前对其进行签名。然后用户可以通过在所有转塔上运行智能合约并聚合返回的签名来运行智能合约，直到他们有一个充分签名的交易。
因此，TSS 在不需要链上虚拟机的情况下，在 Stellar 上启用了免信任的 DeFi 协议。因此，智能合约引擎不会给网络增加过度拥塞，并保持 Stellar 提供的效率。
金星计划的初始目标
启动金星计划时考虑了两个主要目标。首先，也是最重要的一点，TSS 需要通过安全性和功能性的审查。其次，在 Stellar 的网络中增加短期远期合约功能可以解决 Stellar 金融机构的长期痛点。
TSS 系统与 DeFi 生态系统中典型的智能合约引擎完全不同。传统上，引擎通过让链上虚拟机运行智能合约来遵循以太坊虚拟机 (EVM) 模型。这使引擎能够“实时”访问分类帐状态。在链上也迫使合约遵守分类帐状态，因为分类帐是合约可以访问的唯一输入。这种模式的缺点是在链上运行智能合约在资源、时间和金钱上都很昂贵。
TSS 试图通过在炮塔上运行智能合约来避免链上智能合约的执行。然而，TSS 智能合约的链下特性意味着它们失去了实时账本状态执行和账本数据访问，这对 DeFi 协议至关重要。TSS 通过仍然要求将交易提交到分类帐来强制执行分类帐状态；如果交易不符合当前分类帐状态，则会被拒绝。Stellar Horizon API 提供对分类帐数据的访问，因此炮塔可以从分类帐中获取近乎实时的信息。理论上，这些足以让 TSS 托管 DeFi 协议，但还需要进一步验证以确保协议在这种环境中发挥作用。
短期远期是 Stellar 生态系统中理想的实用工具，因为它们通过允许实体锁定价格并将结算延迟到稍后时间来实现资本效率。作为一个额外的好处，远期将信用引入 Stellar 生态系统，大多数金融系统都建立在信用基础上。基于恒星币的汇款公司将能够立即利用这项服务来提高他们的资本效率。通常，提供支付服务的公司会将价格发现的需求与其交易结算分开。他们希望在收到客户的资金以结算汇款之前“锁定”与客户的交易价格。
从历史上看，Stellar 的汇款实体很难为客户提供报价，因为价格发现和结算在 Stellar DEX 上同时发生。为汇款公司提供签订智能远期合约 (SFC) 的能力，允许这些实体向客户提供报价，锁定他们的价格和利润，同时为他们提供时间来结算交易，直到证监会到期。使用证监会允许汇款公司在不改变其现有业务工作流程的情况下利用智能合约和区块链技术的力量。
合并这些目标是很自然的，因为 TSS 上的去中心化短期转发协议提供了一个完美的场景来验证 TSS。
使用 TSS 实施和测试
在 TSS 上构建短期转发协议面临着一系列独特的挑战。依靠 Stellar Horizon API 将分类帐数据提供到智能合约中意味着我们无法确定 Horizon 提供的数据在运行智能合约的所有转塔中是否一致或正确。我们通过编写智能合约来处理这个问题，允许意外的事情发生，但不允许不可接受的事情发生。
在实践中，这种设计意味着如果发生不可接受的结果，我们将强制生成的交易失败。例如，在每个结算期结束时，Venus 协议通过在 DEX 上交易超重资产来重新平衡其结算池中的资产。我们使用 pathPayment 操作来实现这一点并设置一个可接受的滑点阈值，以便如果 DEX 价格在交易创建和交易提交之间人为下降，则必须重新运行智能合约，使价格正常化。
Stellar 的签名者限制也给构建智能合约带来了一些困难。Stellar 对每个帐户的签名者限制为 20 个，因为每个为帐户运行智能合约的转塔都必须是该帐户的签名者。此签名者限制还限制了我们可以在协议中使用的智能合约的数量以及我们可以将智能合约上传到的转塔数量。为了解决这些限制，我们最终将一些智能合约整合到一个执行多个协议操作的大型合约中。将来，我希望通过进一步探索 musig (https://github.com/future-tense/stellar-musig) 系统并允许它与 M-of-N 签名者一起工作来解决这个问题，而不是M-of-M。
尽管有一些成长的痛苦，但 TSS 提供的一个巨大优势是能够使用任何 Web 程序集兼容语言构建合约。在 DeFi 领域，用户需要承受很大的压力来理解他们正在输入的智能合约。他们需要知道它的作用，它是否安全，以及在他们可以安全地签订合同之前会发生什么。对于普通用户来说，用像 Solidity 这样年轻、有限的语言来消化这一点是很困难的。能够在 Typescript/Javascript 中编写智能合约为用户提供了一个更容易消化的合约，然后他们才能真正理解。此外，使用成熟的编程语言带来了强大的最佳实践和测试机制，有助于构建可读、值得信赖的合约。
事实证明，TSS 上的测试协议是一种流畅、熟悉的体验。获取 turret 测试环境就像将 turret 部署到 Stellar 测试网一样简单。这很令人兴奋，因为这意味着您可以针对真正的炮塔运行集成级别的测试！合约开发人员可以利用这种接近生产的测试环境来确保合约准备就绪后无缝过渡到主网。此外，TSS 还利用了 AWS Lambda 等常见的无服务器工具，这些工具最近已成为开发人员工具箱中的关键工具。对于熟悉无服务器计算框架的人来说，监控、调试和深入了解 Turret 中的合约性能将成为他们的第二天性。
Stellar 上 TSS 和 DeFi 的下一步是什么
DeFi 和 TSS 可以彻底改变 Stellar 生态系统。Stellar 对效率的关注和对传统金融的支持创造了卓越的协同效应，可以让 DeFi 生态系统真正与传统金融融合。要实现这种潜力，需要采取一些合乎逻辑的后续步骤。在 Script3，我们已经自己推动了其中的一些变化，但我们希望看到更多的生态系统组织参与进来！如果您所在的组织有兴趣帮助构建 TSS 生态系统，请随时与我们联系！
首先，生态系统需要决定转塔供应商的标准化最佳实践。炮塔是这个智能合约引擎的支柱。它们需要安全、可靠、快速且便宜。这些目标是可以实现的，标准化的最佳实践将帮助炮塔提供商满足这些要求，并使智能合约开发人员更容易识别优质炮塔。
此外，生态系统需要创建一个标准化的自定义 Horizon 实现，炮塔有望提供。正确的账本数据访问对于 TSS 智能合约至关重要。智能合约必须保证对 Horizon 的访问以及过滤潜在交易垃圾邮件的能力，这样他们的智能合约就不会被破坏。如果炮塔可以在本地访问 Horizon 实例，将大大降低 Horizon 无法被智能合约访问的风险。自定义实现还将允许智能合约进行更具体、更安全的分类帐数据查询。
最后，我们希望看到一些将受监管金融资产锚定在 Stellar 上的项目，以支持智能合约协议。Stellar 的区块链可以说是处理股票、债券和共同基金等传统金融资产的最佳设备。鼓励这些资产锚与 DeFi 项目合作，将受监管的资产添加到智能合约协议中，将使 Stellar DeFi 生态系统成为该领域最有用的生态系统，并大大扩展 Stellar 赞助全球经济可及性的目标。