仅有面向人工智能的 L1 并不够：Ritual 为何以及如何与众不同

仅为 AI 设计的 L1 并不足够：为什么 Ritual 与众不同以及如何不同

人们在链上执行的计算和操作正变得越来越复杂，需要高效的执行和定价。未来的计算将需要更多。人们的主要注意力已被 AI 计算所吸引，AI 计算具有复杂的逻辑，并且大多数主要协议都精确地关注这一点。

然而，AI 并非唯一具有复杂计算逻辑的领域：还存在更多技术，例如链抽象、TEE 执行、ZK 证明等等。大多数 crypto x AI 区块链都专注于 AI，但 @ritualfnd 的方法却截然不同。

与其他主要的 Crypto x AI 协议相比，Ritual 有何不同？

以下是 Ritual 的运作方式：

1. 将每个智能合约变成 AI、数据和其他类型繁重计算的可验证网关，然后

2. 将这些网关连接成一个全球性的、自我激励的系统

听起来很有趣，但你可能会说，有像 @bittensor_、@SentientAGI 或 elizaOS 这样的协议也在做同样的事情，对吧？这是不正确的。

• Bittensor 专注于为 AI 模型创建一个去中心化市场

• Sentient 专注于开发社区驱动的、忠诚的 AI，重点是可盈利性

• ElizaOS 是一个用于自主 AI 代理的框架，目标是区块链特定的任务

长话短说，Bittensor 是一个市场，Sentient 是一个更开放的市场，elizaOS 是一个代理框架。

Ritual 通过其机制之一提供了一个市场和开放市场的设计，但这只是其中的一部分。Ritual 绝对不是一个代理框架，但其基础设施可以用来创建代理，所以它也是其中的一部分。

• 主要的 crypto x AI 项目确实是核心意义上的 crypto x AI 项目。

• Ritual 是不同的：它具有 AI 操作和随之而来的复杂性，但它不仅限于这些类型的计算。

Ritual 的设计旨在为链上环境提供尽可能通用和富有表现力的功能。这意味着什么？

这意味着我们正在走向复杂性。

我们从简单的交互（比如将资产从一个地址转移到另一个地址）转向真正复杂的交互（AI 推理、证明者系统、TEE 执行等等）。在那里，出现了两个主要问题：

1. 区块链缺乏针对特定类型操作进行优化的定制能力

2. 区块链的计算能力不足以进行复杂的计算（太慢和/或太昂贵）

Ritual 提供对 GPU 和 CPU 计算的访问，这取决于用户所需的特定工作负载。LLM 调用可以利用 GPU，而某些 ML 或回归模型更适合 CPU。

• 开发者可以使用 Ritual 做更多的事情，而不是使用其他 crypto-AI 解决方案，因为它针对一般的复杂计算进行了优化，而不仅仅是 AI。

• 应用程序可以从 Ritual 上的智能合约原生访问该计算上的模型（例如，需要复杂证明生成的 rollup，请求源自 Ritual 的跨链执行）。

这种可定制的 L1 得益于一种独特的架构，该架构包括许多不同的核心部分。让我们研究一下 Ritual 在哪些方面有所不同。

Resonance（共振）：如何匹配供需，提供更好的费用？

我在之前的关于 Ritual 的系列文章中简要提到了 Resonance，但我没有解释它背后的主要动机。

Ritual 的动机不是解决经典区块链系统中待处理交易被丢弃的问题。其动机是创建一个高效的市场，可以公平地为各种类型的计算定价，同时提供出色的用户体验。

在这样的系统中，用户可以放心地为计算任务设定其真实的价格，而无需担心。（例如，价格被经纪人或节点提供商利用或操纵）。

• 传统 L1 设计：交易由其他节点验证，一些节点超时，因为每个节点都具有不同的执行能力（较弱的节点无法处理较强的节点可以处理的请求）。

• Resonance 的设计：不同的交易与合适的节点进行匹配以进行执行，然后再进行验证。

Resonance 基本上是供需之间的匹配引擎，旨在提供价格合理且高效的执行。你可以在下面了解更多关于该设计的信息。

该方案显示了用户、经纪商、节点、拍卖商和 Ritual 链本身之间的交易流程

Resonance 与其他 AI L1 设计有很大不同。例如，在 Bittensor 的子网模型中，激励系统依赖于验证者，其中奖励根据性能得分进行分配。这种模型对于跨各种任务的计算定价效率不高，因为定价是由特定标准而不是统一的市场决定的。

Symphony（交响乐）：减少重复执行的附加组件

在大多数区块链设计中，所有节点都会重新执行每个区块，以确保区块有效并更新其本地状态的副本。但是，当工作负载变得更重且不太直接时，这种设计会变得效率低下（重新执行每个区块既昂贵又耗时）。

这就是构建 Symphony 的主要思想：重新思考这种设计并减少重复执行。在 Symphony 中，选定的计算节点执行工作负载并为计算创建简短的子证明，因此可以更有效地处理验证。

当证明大小变得更大（对于复杂模型）时，它会增加区块大小并降低网络性能。Symphony 通过四部分验证策略来解决这个问题：

1. 将证明分成子证明

2. 将子证明分配给验证者的子集

3. 将验证者组织成按模型类型进行专门化的组

4. 允许在不等待完全验证的情况下进行区块处理

注意执行证明立方体

如果我们将 Ritual 的 Symphony 与 Sentient 进行比较，我们可以看到一些有趣的事情。

• Sentient 使用 Polygon 的 PoS，这自然限制了复杂 AI 计算的能力和性能（高费用 + 重复执行）。

• Sentient 比计算效率和执行优化更关注模型管理和完整性。

• 是的，Sentient 也支持模型的货币化，但它缺乏防止价格效率低下的机制。

Symphony 更适合为去中心化 AI 提供计算。

EVM++: 构建真正智能合约的扩展

EVM++ 是默认 EVM 的扩展，其增强功能包括预定交易、账户抽象、按需 EIP 扩展以及不同形式的表现力计算。

但是，为什么要对 EVM 进行新的扩展呢？在这种情况下，我们不能只使用现有的 EVM 吗？

我们可以，但是这些功能中的大多数在 EVM 上都不是原生启用的，甚至大多数新的 EIP 由于实现的复杂性而被延迟集成。

正如大多数人所知，账户抽象带来了更好的用户体验，而不同的 EIP 可以引入各种新功能。EVM++ 中有四个主要的 EIP：

• EIP-665 和 EIP-7212 通过预编译合约添加了对新签名验证的支持。

• EIP-5920 添加了一个新的操作码，用于在不转移执行上下文的情况下发送 ETH。

• EIP-5027 通过动态 gas 移除了代码大小的限制。

如果说不同形式的表现力计算，这意味着每种类型的计算都经过优化，以通过执行 sidecar 以最有效的方式执行。

• Sidecar 与 Ritual 执行客户端一起工作，由 EVM 预编译接口触发。

• 独立运行，可以根据操作员的需要打开或关闭。

• 灵活的设计通过 EVM、SVM 和 MoveVM 支持各种计算环境，因此 EVM++ 不仅仅是关于 EVM 的。

我在 EVM++ 中发现的最有趣，乍一看也是最基本的功能是原生交易调度，因为在 EVM 或其他虚拟机上都无法原生调度交易。

请注意，特权交易具有独占的区块顶部包含

调度合约使开发人员能够定义智能合约函数的调用频率。

• 例如，借贷协议可以使用它来自动化清算，从而使合约能够独立管理逾期贷款，而无需依赖外部 keeper。

• 区块生产者监控这些预定的调用，如果有效且资金充足，则将其包含在每个区块的开头，从而确保优先放置。

对于复杂或资源密集型的预定任务，Resonance 保证及时包含，而不会中断区块链的状态。没有其他区块链具有原生交易调度程序。

来源：x.com/ritualnet/status/1933217735351415285 ##

Ritual 的发展方向是什么？

如果生态系统是多样化的，并且有大量有时看起来完全并行运行的不同功能，那么 Ritual 的总体方向是什么？

主要重点是执行，更准确地说是异步操作的 sidecar 的有状态执行。这意味着什么？

这意味着应用程序可以外包密集计算并访问计算能力，以执行诸如 AI 模型推理、zk 证明生成和去中心化数据处理之类的任务。还有许多计划用于改进 Symphony、Resonance 和经济设计，例如确保适当的激励对齐并增加更多的经济安全性。

但是，Ritual 主要希望关注 3 个要点：节点专业化、异构计算和灵活验证。我已经在前一篇文章中讨论了节点专业化。

· 4 月 25 日 我们是否需要一个单独的链上 AI 区块链？现在加密货币中有很多 AI。据 @cbventures 称，有超过 120 多个 crypto x AI 协议。项目越多，问题也就越多。许多协议只是没有任何空的炒作

158 1.5 万 今天的重点将是异构计算和灵活验证。但是这些术语实际上是什么意思呢？

异构计算

另一个有趣的观点是，Ritual 将自己定位为现存最具表现力的区块链。

一个有表现力的区块链意味着它的架构专注于异构计算。但是异构计算到底是什么？

有两种主要类型的计算：同构计算和异构计算。

• 在 Ritual 的上下文中，同构计算意味着网络（如 Ethereum）中的所有节点都以有限的资源执行相同的计算。

• 它确保每个节点在同一时间运行相同的代码，从而保持整个网络的结果一致。

• 另一方面，异构意味着完全相反：它指的是本质上复杂或独特的计算或交易。

像世界上每个系统一样，区块链随着时间的推移变得越来越复杂：从 Ethereum 上针对同构计算优化的简单交易开始，发展到允许并行交易执行、实时交互等的区块链。

交易的复杂性继续增长，并且将来会增长更多。我们已经从地址之间的简单转移转变为具有非常复杂逻辑的应用程序。

这就是为什么 Ritual 的重点主要放在异构计算上，这在其 L1 的整个架构中都已清楚地显示出来。

• EVM++ 中的节点专业化优化了用于特定计算的节点。

• 对于 ML，跨各种模型架构和大小的推理和微调等任务在成本和复杂性方面差异很大。

• EVM++ 包括自定义预编译，以有效地执行和定价这些不同的计算，以确保最佳的硬件利用率。

单个区块链中的多种验证类型以及谁需要它们

每个开发人员可能需要不同的东西，而且通常 L1 本身并没有提供太多的灵活性。Ritual 允许用户为其应用程序和预算选择多种验证类型。

因此，需要 TEE 的性能和适用于实时应用程序等功能的某人最终可能会使用 ZK 证明，甚至使用某种乐观有效性证明来代替 TEE。

正是出于这个原因（为了让开发人员有更大的灵活性），Ritual 提供了四种主要的验证类型：ZKML、OPML、PPML 和 TEE。

一些缩写对于大多数人来说听起来很熟悉，但有些则不然。因此，让我们仔细看看：

1. ZKML 代表零知识机器学习，它使用 ZK 证明来确保 AI 模型的执行已正确完成。EVM++ 具有 ZK 生成和验证 sidecar，因此开发人员可以原生实现此类型。

2. OPML 代表乐观机器学习，它假定模型执行最初是正确的，在不确定正确性的情况下可能需要验证。

3. PPML 代表概率证明机器学习，对于大多数人来说是一个新术语，因为它是 Ritual 提出的。此方法专为计算复杂的模型操作而设计，并使用统计证明来提供验证。

4. TEE 代表可信执行环境，它允许在隔离的环境中安全地运行代码。EVM++ 具有一个 TEE 执行 sidecar，可以原生执行 TEE 内部的 AI 模型。

使用下面的图像，开发人员可以决定哪种验证方法最适合他们。

注意每种方法的优缺点

如何提高 AI 代理的质量并使它们变得智能？

AI 代理领域已经变得非常流行。但是，代理框架面临风险，例如无法验证代理行为的正确性以及代理之间的糟糕可组合性。

• Ritual 提供了用于构建代理的各种功能，最重要的是，所有这些功能都存在于链上，执行逻辑就在其中发生。

• 这包括更多与 AI 相关的任务，如 AI 推理，甚至与 DeFi 相关的活动，如跨链交易和 LP 管理。

• 开发人员可以从可验证的执行、不同代理之间的跨链可组合性、预定交易以及用于钱包管理的适当的账户抽象模型中受益。

如果我们从更广泛的意义上考虑代理的可组合性，那么主要的挑战在于代理之间一致且可靠的交互。

当多个代理在共享任务或数据集上进行协作时，可能会出现状态不一致的情况。同样，当代理依赖于外部服务或数据源时，在查看或访问这些数据源的相同版本时可能会出现不一致的情况。

Ritual 在代理可组合性领域提供安全的消息传递、状态同步和冲突解决，从而使人们可以从多个可互操作的代理中创建整个系统。

最后的想法和结论

我再说一遍：是的，Ritual 很复杂。有许多不同的功能，机制设计解决方案等等。但是，它之所以复杂是有原因的。

仅针对 AI 计算优化 L1 是有益的，并且还有其他协议可以做到这一点。你可以通过这种方式实现高效的计算，从而使 AI 推理成为人们考虑复杂计算时的第一个想法。

许多其他领域也需要大量的计算，尤其是 ZK，它由于加密货币而迅速发展。随着越来越多的人希望将复杂的逻辑放在链上，甚至日常交易的复杂性也在增加。

我认为这种情况将继续增长，因此，采取一种更广泛的方法，不仅关注 AI，而且关注一般的异构计算，这是非常有意义的。

• 原文链接： x.com/paramonoww/status/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～