可验证的云：EigenCloud如何开启加密应用和AI时代

序言 – 从内部链到云级可验证性

今天的区块链看起来很像 2000 年代早期的互联网：强大而安全，但又很僵化。在那个时代，构建互联网应用程序意味着架设自己的服务器、管理自己的网络并以艰难的方式维护正常运行时间。开发人员通常从 Rackspace 和 Equinix 等公司租用专用服务器或在主机托管中心租用机架空间。

然后出现了公共云。AWS 抽象掉了物理层，为开发人员提供了一系列专门构建的服务，并使任何人都可以访问可扩展的基础设施。结果是出现了大量新的应用程序类别，从 Airbnb 到 Stripe，以及 10 万亿美元市值的创建浪潮。

区块链开发的发展也遵循类似的弧线。在它的第一个十年中，我们看到了两个主要时代：像比特币和 Namecoin 这样的特定于应用程序的链的时代（定制安全性，自定义验证器集）以及像以太坊和 Solana 这样的通用 L1 的兴起，开发人员可以在预先存在的安全性和基础设施之上构建。每个时代都扩大了可以构建的表面积，但两者仍然需要团队自己管理区块链基础设施的核心部分。

为了释放下一波应用程序，尤其是金融领域之外的应用程序，加密货币需要它的云时刻。一个开发人员可以访问 “可租赁的” 可验证计算的平台，将其与一组富有表现力的可验证服务配对，并在无需接触验证器集或启动链的情况下进行部署。这意味着数据可用性、结算、链下执行，甚至 AI 推理都作为模块化、信任最小化的服务来提供。

EigenLayer 是第一步，它使开发人员可以按需访问由重新质押的运营商组成的全球网络以及 EIGEN 代币的加密经济安全性。借助 EigenCloud，该基础扩展到完整的、加密原生的云：丰富的第三方 AVS 目录、EigenDA、EigenVerify 和 EigenCompute 等内置原语，以及像 AWS 服务一样组合它们的能力。

结果是一个可验证的云，其中加密的保证与云计算的可用性相融合。正如公共云是网络经济的巨大解锁一样，可验证的云是基于信任的经济的巨大潜在解锁。

可编程性悬崖

加密货币在吞吐量方面取得了重大进展。在过去的十年中，定义早期区块链设计的扩展瓶颈已通过高吞吐量 L1、rollup、模块化 DA 层和越来越高效的证明系统得到很大程度的解决。然而，即使区块链现在可以处理数量级更多的交易，应用程序的类型仍然非常稀疏。

这里真正的限制因素不是区块空间，而是可编程性。在 web2 中，大多数云工作负载都以复制和粘贴现有应用程序的形式出现。直到现在，这在 Web3 中还是不可能的。

如果我们放大来看，可编程基础设施是使现代互联网经济成为可能的原因。AWS 使开发人员能够连接到任何 API、配置任何硬件以及组合托管服务（如数据库、身份提供程序或机器学习管道），而无需从头开始重建它们。无论是社交网络还是流媒体平台，这种灵活性是现代软件的每个类别仍然在公共云上运行的原因。

但是，与当今的现代云服务相比，区块链仍然在最狭窄的画布上运行。它们的执行环境是故意的确定性的，它们的硬件是统一的，并且它们的共识规则在协议级别是固定的。这些约束对于信任是必要的，但它们付出了高昂的代价，将设计空间缩小到传统计算中可能的一小部分。这就是为什么加密货币的杀手级应用程序到目前为止几乎完全集中在金融领域——确定性逻辑和独立的state工作效果最佳。

这个“可编程性悬崖”是阻止加密货币扩展到更广泛的软件经济中的原因。一旦开发人员需要 GPU、TEE、低延迟外部数据，甚至是社会解释的结果，当前的堆栈就会迫使他们离开链。并且一旦逻辑离开链，对该计算的信任就消失了。

EigenCloud 的目标是使加密货币更具可编程性；成为加密货币的云时刻，从而实现可验证的经济。

Web2 寓言

在云之前，在互联网上构建既是一个基础设施问题，也是一个软件问题。扩大规模是一场赌博：要么过度配置而浪费金钱，要么配置不足，如果你的应用程序获得任何合理的动力，就会失败。

AWS 在 2006 年通过推出 Elastic Compute Cloud (EC2) 和 Simple Storage Service (S3) 打破了这个循环。EC2 将计算变成了计量公用事业：你可以按需启动或关闭的虚拟机。S3 对存储也做了同样的事情，提供了无限可扩展的对象存储，而无需单个开发人员接触物理磁盘。它们共同抽象了基础设施的麻烦，让开发人员完全专注于应用层。

影响是立竿见影的。通过消除资本支出、运营复杂性和容量风险，AWS 释放了以前根本不可行的应用程序类别。启动 Web 应用程序的门槛直线下降，并且长尾软件蓬勃发展。小众 SaaS 产品和全球规模的市场都变得可行，因为基础设施摩擦已被消除。

但是，我想在这里做一个小的区分，即当我们比较 AWS 和 EigenCloud 时，消除了 capex。更准确地说，EigenCloud 抽象掉了在链上运行密集型工作负载的高昂成本。与其为每个 FLOP 燃烧 gas，不如将繁重的逻辑移到链下，同时仍然保留加密级别的可验证性。这两种方法在这方面有所不同，但抽象掉friction以部署更广泛的应用程序的比喻仍然成立。

AWS 也有一个战略性的逆转。在云之前的世界中，基础设施决定了什么是可能的。在云时代，基础设施屈服于应用程序的需求。AWS 的服务远远超出了计算和存储范围，扩展到数据库、分析、身份管理和机器学习，这使得小型团队可以在不拥有企业级系统的情况下站在企业级系统的肩膀上。

人工智能——代理碰撞路线

Web2 系统已经受到了不透明性的困扰。我们依赖声誉、品牌信任或监管监督，因为我们无法独立验证中心化基础设施内部发生的事情。现在，当你将像 AI 这样快速发展的技术叠加到它上面时，会发生什么，更具体地说，是代理？

没有可验证性的代理的根本问题是，它们会破坏自动化的信任模型。如果你无法验证代理如何做出决定，则你不能信任它代表你自主运行。与人类调解的系统不同，代理在执行之前不会暂停进行审查（除非另有明确规定）。

当代理从“决策支持”转移到“决策执行”时，风险会加剧。在聊天机器人设置中，无法验证的推理可能意味着幻觉答案。但是在交易代理中，无法验证的推理可能意味着定价错误的套利、被操纵的预言机或对抗性漏洞。一旦资产、法律承诺甚至人类生命受到威胁，无法验证代理输出的正确性就使得无法分配责任或保证。风险远远大于自动化。

在系统层面上，无法验证的代理会迫使我们回到 Web2 风格的孤岛。

让我们考虑以下示例：

一个 AI 系统负责裁决 Geico 和 Allstate 之间的车祸。两家保险公司都提交证据（照片、证人数据、警方报告），并且 AI 会生成故障确定结果。如果该输出无法独立验证，那么任何一方都无法信任该过程。一家保险公司可能会怀疑存在隐藏的偏见、篡改的输入或应用不当的逻辑。在保险等高风险领域，无法验证的计算与任意判断无法区分。信任崩溃，不是因为 AI 是错误的，而是因为无法证明其正确性。

但是，这里的挑战不仅限于信任，还在于实用性。AI 工作负载在计算上也比典型的链上交易高出几个数量级。即使是适度模型的推理也涉及数十亿次的浮点运算和千兆字节的参数。在链上运行它不仅效率低下，而且在当前的区块链约束下在经济和技术上都是不可能的。如果没有链下可验证性，这些工作负载仍将滞留在加密经济安全范围之外，仅限于不透明的、基于声誉的 Web2 系统。

EigenLayer：重新质押的不完整革命

在我们深入研究 EigenCloud 之前，有必要回顾一下 EigenLayer 的共享安全性和重新质押组件。

EigenLayer 通常被认为是通过重新质押将“以太坊的信任扩展”超出其原生共识的一种方式——允许 ETH 质押者重用他们现有的质押资金来保护新的和以前不可能的服务，这些服务被称为自治可验证服务 (AVS)。

从理论上讲，这是区块链架构中的一个阶跃变化。构建者可以利用以太坊现有的验证器集，继承其经济安全性，而无需重新创建共识，而不是启动具有定制验证器集或脆弱的 PoS 代币的新 L1。

但现实要微妙得多。重新质押并不能神奇地将以太坊的信任保证扩展到任何任意计算，而是创建了一种选择加入安全模型，其中验证器自愿执行 AVS 的规则。安全性在不同服务之间并不统一；它取决于验证器参与、AVS 削减逻辑和加密经济激励的强度。换句话说，EigenLayer 中的“共享安全性”与 L1 意义上的“以太坊安全性”不同。

虽然它可以通过削减来激励正确的行为，但这仍然是概率性强制执行；无法生成正确性加密证明的 AVS 要求参与者接受对验证器诚实性的一定程度的信任。“没有可验证性的质押”仍然受制于这种可编程性悬崖，因为仅重新质押是强大的，但不完整，因为它扩展了验证器参与，但没有解决如何使任意计算在可证明的意义是正确的。

EigenCloud 正是旨在解决这种不匹配的系统。它引入了一个框架，AVS 不仅可以继承以太坊的质押安全性，还可以利用可扩展的链下可验证性，从而使 EigenLayer 更接近于可以解释为完整的信任模型的东西。

EigenCloud 的诞生——设计目标和堆栈

EigenCloud 将 EigenLayer 从基础设施协议扩展到真正的开发人员平台。如果 EigenLayer 解决了引导 AVS 安全性的成本，那么 EigenCloud 解决了构建和使用 AVS 的成本。

EigenCloud 提供的组件使开发人员可以像 AWS 一样轻松地构建云规模的应用程序，但由加密保证而不是对提供商的不透明信任来支持。这里的框架很重要。正如 AWS 抽象掉了物理服务器并让开发人员以弹性计算的方式思考一样，EigenCloud 抽象掉了验证器集、削减逻辑和原始运营商协调。

该套件由三个组件组成：EigenDA、EigenVerify 和 EigenCompute。每个组件都对应于开发人员在尝试部署可验证的链下服务时面临的痛点。这些痛点包括：

• 发布和持久化数据
• 裁决正确性
• 容器化计算

让我们分解每个组件：

EigenDA 扮演着基础性的角色，类似于 AWS 中的 S3。链下可验证性取决于将输入和输出发布和检索到耐用、可审计、经济安全且抗审查的介质中的能力。如果没有超大规模 DA 层，证明和欺诈挑战将受到以太坊数据吞吐量和 gas 成本的限制。无论是证明对象、欺诈日志、rollup 交易数据还是大型链下数据集，EigenDA 都可以通过为这些类型的计算提供透明、低成本的存储，同时保持抗审查性来解决此问题。

这里最显著的解锁是开发人员不再需要在经济安全性和成本之间进行权衡。如果应用程序将数据发布到 EigenDA，任何观察者都可以重建、验证或质疑相关的计算。在实践中，这意味着 AI 模型推理日志、zk-proof 人工制品或欺诈证明跟踪可以普遍访问，而不会膨胀以太坊。

在我们的云提供商类比中，EigenDA 对于 EigenCloud 就像 S3 存储桶对于 AWS 一样。

EigenVerify 是强制执行层，相当于争端解决的法院系统。它的工作方式是通过允许重新执行工作负载以裁决它们是否正确运行。构建 AVS 的关键始终是为每个新工作负载编写自定义欺诈证明逻辑的复杂性。不幸的是，并非所有任务都是平等创建的。有些任务（如双重签名）很容易检测，但另一些任务（如验证复杂的 AI 推理或自定义 rollup VM）在历史上难以编码到链上合约中。

EigenVerify 通过提供用于客观验证（重新执行确定性代码以检查正确性）和主观间验证（裁决人类可以同意的结果，如预测市场）的标准化模块来抽象化此问题。

客观验证 适用于正确性纯粹是确定性的情况。如果服务输出结果（zk-SNARK 证明或价格feed），任何人都应该能够在给定相同输入的情况下重新计算或重新验证输出。

主观间验证 适用于无法简化为确定性正确性的服务。例如，预测市场支出或涉及“人类共识”的内容审核决策。在这些示例中，人们必须就什么是“正确”的结果达成一致。EigenVerify 通过主观间验证来标准化这一点：分叉选择规则、挑战机制和代币持有者裁决途径。

来源： EigenCloud 白皮书

通过将此服务锚定到削减的质押和 EIGEN 代币分叉机制，EigenVerify 引入了一个系统，该系统不仅可以轻松提出争议，而且验证集的勾结会受到核级别的惩罚——我们将在 EIGEN 代币经济学中介绍这一点。

EigenCompute 通过为开发人员提供抽象层来运行任意工作负载来完成三连胜，就像他们在 AWS ECS 或 Lambda 中部署容器一样。开发人员将应用程序逻辑打包到可验证的容器中，然后由 EigenLayer 运营商运行，由质押资本保护，通过 EigenDA 记录，如果受到质疑，则通过 EigenVerify 裁决——类似于智能合约 (可验证、强制包含等) 的保证。

现在，除了可验证的链下计算之外，当你开始在 EigenCloud 之上组合服务时，更有趣的解锁就来了。由于 EigenCompute 容器是可验证的并通过 EigenDA 记录，因此它们可以链接在一起，几乎就像 Web2 云中的微服务一样，但每个步骤都可以单独验证。

例如：

一项服务可能使用 EigenDA 作为其存储层 → 在 EigenCompute 上调用到 ML 推理容器 → 将结果传递到 EigenVerify 以进行客观裁决。

与其将可验证性视为仅在最终输出处强制执行的内容，不如将链中的每个服务都进行检查点并受 EigenLayer 的争议/分叉逻辑的约束。

信任拨盘

与其锁定在单一安全模型中（如 Eth L1 的刚性最终性或 rollup 的概率性最终性），我们可以将 EigenCloud 视为信任的连续体。每种模式都代表了延迟、活跃性和安全性之间频谱上的不同点，从而有效地创建了风险 API。

即时 → 乐观 → 可分叉 → 最终

在一种极端情况下，即时信任允许应用程序立即对结果采取行动，将输出视为最终结果，而无需验证开销。在这里，开发人员主要依赖 EigenDA，延迟最小。安全权衡是在此窗口期间未内置验证或削减。但是，如果以后对数据提出质疑，系统可能会有效地回滚。

对于乐观信任，EigenCompute 执行工作负载，结果发布到 EigenDA，EigenVerify 作为争端解决的守卫而待命。除非在宽限期内提出质疑，否则假定输出有效。如果标记了错误（通过重新执行或提出质疑），则 EigenVerify 会根据需要触发削减和回滚。

可分叉信任利用了 EIGEN 代币的可分叉性和受争议分叉的链上可观察性。对于具有主观结果的工作负载（例如，预测市场），社会共识或治理机制通过在共识偏离时选择性地触发代币分叉来解决争议。应用程序、链或服务可以预先承诺在此情况下与 EIGEN 一起分叉，从而确保它们遵循“规范结果”。

在最大安全性频谱上，EigenCloud 的所有组件都发挥着积极作用。工作负载通过加密证明、社会共识以及通过削减或分叉进行的经济强制执行来完全裁决。从本质上讲，最终信任开始接近传统的区块链安全性，但具有链下规模和可验证性。

容器如何成为智能合约

允许 EigenCloud 在保持加密级可验证性的同时提供云级可编程性的主要组件之一是开发人员部署链下容器以实现特定应用程序逻辑的能力。

该过程非常传统。开发人员将包含服务逻辑的容器（Docker/Nomad/Kubernetes）部署到 EigenCompute 中。与标准云部署不同，此容器不是孤立运行的，而是由重新质押的运营商进行抵押和强制执行的。

但是，这不应与 AVS 混淆。容器只是代码（服务逻辑、依赖关系、二进制文件）的打包运行时。它只是由质押支持的可部署单元。

仅当该质押容器被协议化 时，AVS 才会存在。这意味着你已指定：

• 服务规则 – 如何安排任务、如何验证结果以及什么构成不当行为。
• 削减条件 – 使运营商抵押品可以因故障而被削减的合约逻辑。
• 验证层 – 欺诈证明、ZK 证明、仲裁签名或任何其他验证方案。
• 链上锚定 – 输出发布回以太坊（或其他链）并被确认为最终结果的机制。

容器 = 构建块。AVS = 容器 + EigenLayer 规则 + 加密经济强制执行。

容器启动后，EigenCompute 会自动启动桩匹配过程。选择支持该服务的验证器和运营商分配重新质押的 ETH 或 LST 作为抵押品，从而有效地承保容器的正确执行。匹配不是任意的；它确保有足够的桩支持该服务，这与其经济和计算profile相关。从这里开始，容器不再只是“云中的计算”，而是具有经济担保（削减逻辑和质询响应规则）的可验证服务。

随着容器的执行，会根据开发人员定义的信任模式生成证明。这可能涉及有效性证明、具有争议窗口的乐观证明或加密证明。一旦这些证明通过 EigenVerify 传播，其他节点就可以验证容器的输出，而无需重新执行整个工作负载。

这里的关键点是执行与验证分离。容器可能在链下运行繁重的计算，但其结果通过加密证明变得轻量级和信任最小化。

传统上，如果你想在加密货币中部署链下服务（预言机、协处理器、zk-proof 或 AI 推理），你有两种选择：

1. 启动你自己的运营商集并引导信任（资本密集且高度分散）
2. 尝试将工作负载直接阻塞到链上（昂贵、吞吐量有限、对于繁重的计算不切实际）

部署容器使开发人员可以将这些任意工作负载打包成一个标准化单元，该单元可以直接插入 EigenLayer 的重新质押框架中。容器本身的概念并不新鲜，但新颖之处在于 EigenCompute 将该容器绑定到以太坊支持的抵押品和验证管道。

这在中间件层解锁了可组合性。开发人员可以发布容器并立即通过桩匹配继承以太坊的安全性。然后，该容器可以公开可验证的 API、参与质询响应游戏并在链上结算结果。所有这些都不需要下游用户信任开发人员的基础设施。

开发人员用户体验

借助 EigenCloud，开发人员不仅仅是租用基础设施，还支付其应用程序所需的经济安全性。通过“按质押付费”模型，你只需根据你的应用程序选择支持其链下逻辑的经济抵押品的安全保证金来承担成本。这意味着如果你为低风险的事情（例如，非金融 AI 推理）部署容器，你可以选择最小的桩支持，从而有效地节省资源。另一方面，如果你要为结算或合规逻辑提供高信任组件，则可以将桩提高到你需要的保证级别。

重要的是，你控制资本化风险曲线，并且你无需为服务所需的支付更多费用。

最重要的是，开发人员不必从头开始构建所有内容。巨大的用户体验胜利来自使用和组合现成的 AVS 的能力。这些是你可能想到的“可验证微服务”，例如 DA 层、rollup、预言机和 AI 推理应用程序。

AVS 的 web2 类比类似于导入 SaaS 库。你委派了底层复杂性，采用速度更快，并且你继承了可组合且安全的服务，而无需重建运营商/委派堆栈。

可验证性的经济学

EigenLayer 代币设计明确围绕着这样一种理念，即可验证性需要一种形式来承保检测、质疑和惩罚系统中外部化计算的不当行为的成本。为了解决这个问题，引入了一种双代币模型（EIGEN 和 bEIGEN），该模型既锚定了安全性又锚定了可验证性。

基础代币 EIGEN 充当系统的原生资产，并且是定义 EigenLayer 作为协议的可信承诺的资源。可以将一部分 EIGEN 锁定到其绑定形式 bEIGEN 中，bEIGEN 表示专门质押以支持验证的抵押品。

这种区别至关重要。虽然重新质押到 EigenLayer 中的 ETH（或 LST）可以确保 AVS 的执行，但 bEIGEN 可以确保其可验证性。它可以确保证明、质询和证明具有可强制执行的权重，因为持有 bEIGEN 的运营商实际上可以因未能验证或串通不准确的结果而被削减。

从这里开始，“分叉作为核威慑”机制开始发挥作用。其理念是，该系统必须始终保留在发生灾难性共识失败或系统性勾结时分叉 EigenLayer 的选项。这种威胁会产生激励对齐，如果运营商或代币持有人破坏验证市场，社区可以可靠地分叉链，使恶意行为者持有毫无价值的 EIGEN，而诚实的参与者则迁移他们的桩。因此，分叉的威慑效果直接嵌入到代币的价值主张中——只有当 EIGEN 保持抗分叉性时，它才会累积长期价值。

我会通过提到被动的 EIGEN 持有者不必参与甚至不知道分叉共识来限定这一点。设计目标是只有那些积极绑定 (bEIGEN) 或以其他方式参与保护/验证服务的人才需要担心分叉。分叉机制也应被视为最后的手段。

在收入方面，费用流旨在加强这种反馈循环。通过 EigenCompute/EigenCloud 部署的每个容器化服务都会产生费用，无论是从部署工作负载的开发人员还是从使用经过验证的输出的应用程序/用户那里产生。

这些费用的一部分流向质押 ETH/LST 以确保执行的运营商，而另一部分流向保证正确性的 bEIGEN 验证者。最终结果是，bEIGEN 累积价值作为网络的“验证抵押品”，而 EIGEN 累积元价值作为强制执行系统可信承诺的协调层（费用、削减和分叉威慑）。

与仅仅收集费用的通用质押代币不同，EIGEN 正式确定了可验证性的经济学。其绑定形式承保验证，其流动形式跨服务进行协调，其价值由 EigenCloud 工作负载的费用流以及分叉的系统性核选项支持。实际上，这意味着 EIGEN 与验证市场本身的增长相关。迁移到容器化 AVS 的链下计算越多，受 bEIGEN 保护的费用池就越大，EIGEN 作为网络 Schelling 点的威慑价值就越强。

当你可以拥有支持所有这些应用程序的底层——支持云的资本时，为什么要押注下一个获胜的应用程序是什么？

模式和寓言——你可以构建什么

当我们讨论获胜应用程序时，让我们探讨一下 EigenCloud 释放的一系列应用程序领域。

在 EigenCloud 优化的应用程序类型中，有一条清晰的思路。它们往往有一些共同的特征：

1. 它们依赖于以太坊或 L2 本身无法处理的大量链下计算
2. 他们需要信任最小化的保证
3. 它们位于加密货币和外部世界之间的边界，在那里，可验证性历来是最弱的

AI 推理

一个自然的领域是 AI 推理。如今，模型部署在由中心化提供商控制的黑盒 API 之后。这需要隐含的信任，即输出没有被篡改，并且运营商忠实地返回结果。即使恶意输出是我们最不关心的问题，但对模型偏见的争议在顶级 AI 实验室中也是非常真实的。如今加密货币中大多数当前的“AI 集成”可以说只是 OpenAI 或 Anthropic 周围的 API 包装器。

在可验证的云环境中，输出与证明相关联。这可能看起来像 zk 证明 (zkML)、输出繁重时的具有欺诈证明的乐观方案或确定性地在另一组运营商上重新运行模型以确保正确性的 EigenVerify 证明。

zkTLS 和数据通道

第二个应用程序类别是通过 zkTLS 和安全数据预言机的数据入口。如何证明来自外部世界的数据实际上来自声称的来源？

借助 EigenCloud，数据入口变得可验证。容器可以运行 zkTLS 协议来证明它们忠实地获取了网站或 API 响应，或者利用 enclave 证明来表明数据集是在没有操纵的情况下查询的。链上合约可以利用加密保证来使用外部数据，而不是信任预言机提供商。这为广泛的现实世界应用程序类别打开了设计空间，最显著的是预测市场。

具有最终性的预测市场

标准预测市场通常依赖于治理或预言机来解决结果。这些通常会引入延迟和攻击面，或者对于激励大规模参与以进行解决来说，预言机可能太昂贵了。在 EigenCloud 中，结果分辨率可以锚定在可验证的计算中。例如，体育赛事或选举的结果可以通过由绑定的 EIGEN 保护的数据源的 zkTLS 证明（如我们所提到的）来最终确定。

这会将预测市场变成实时交易场所，在该场所中，流动性的行为更像是衍生品或体育博彩平台。鉴于 Polymarket 最近的成功以及在线赌博的增长，这很可能成为自 Augur 在 2017 年率先推出的早期迭代以来最突出的用例之一。

主权 AI 代理

EigenCloud 最具前瞻性的应用也许是主权 AI 代理的兴起。这些是拥有密钥、持有资本并在链上生态系统中行动的自治实体。但要可信地发挥作用，他们需要的不仅仅是计算能力。他们需要与他们的目标可验证地对齐的计算、推理和工具调用，以及如果他们碰巧超出范围的保险。

让我们阐述一下当集成到 EigenCloud 堆栈中时，这在理论上会是什么样子：

代理的堆栈将在 Eigen 原语中整齐地分解。它通过可验证的入口（zkTLS 风格的公证人/enclave 证明）来感知世界，并将这些输入写入 EigenDA。它在 EigenCompute 上的容器内以显式的信任模式运行。并且它通过 EigenVerify 证明/捍卫其输出，削减语义甚至扩展到当大多数被破坏时与代币分叉对齐。

该框架提供了一个适当的对齐表面，而目前的“链上 AI”应用程序中缺少这一点。

Twitter 嵌入

10/ Web2 数据访问怎么样？

通过像 @OpacityNetwork 和 @reclaimprotocol 这样的 zkTLS AVS，第 1 级代理可以利用现有的 Web2 服务。

想象一下，可以验证地访问 Uber 或 Airbnb 的声誉数据来做出明智的决定。

— EigenCloud (@eigenlayer) 2025 年 2 月 4 日

对齐存在于三个都是可验证的地方：

• 策略合约（一种智能合约，用于编码允许代理执行的操作）
• 容器哈希（固定实现该策略的精确代码/模型/权重）
• 数据证明（代理观察到的内容）

这些中的每一个都具有链上承诺和削减路径。如果运营商交换模型或错误报告输入，则承诺不匹配是客观的并且可以削减。如果策略在语法上得到遵守但在语义上被违反（例如“公平执行”案例），则主观间验证提供了一个以 bEIGEN 为代价进行裁决的场所。这里的重点不是一切都变得纯粹客观，而是每种故障模式都有明确的追索权，并具有明确的成本。

但是我们多久才能期待这些服务，以及 EigenCloud 的时间表是什么样的？

路线图和领先指标

Eigen 经济已经积累了近 200 亿美元的总 TVL，2000 多个注册运营商，以及 40 多个活跃的 AVS，另有 150 多个正在开发中。主网上的 EigenDA V2 引入了 100MB/s 的吞吐量，远远超过了现有的竞争对手，主网发布了 slashing（罚没），并且已开始制定多链计划，第一个验证已集成到 Base。

EigenCloud 的路线图围绕四个主要支柱组织：开发者平台、可信原语（EigenDA/EigenCompute/EigenVerify）、EIGEN 代币，以及建立在 EigenLayer 上的承诺基础设施。该路线图的实际检验将是这些原语是否真正产生了一个双边市场（AVS 构建者和 stakers/operators），其中服务经济有机地从应用程序流向 stakers，而不是主要来自代币排放激励。

当前的流程：

开发者平台 – DevKit 最近在测试网上发布——一个 CLI 工具包，可以简化 AVS 的开发，并支持在实时环境中进行原型设计、测试和部署。它使用 Hourglass 基于任务的执行框架。Hourglass 标准化了开发者如何在去中心化运营商网络中定义、分发、执行和验证计算任务。

可信原语 – EigenDA v2 已成功引入了 100MB/s 的吞吐量，使其成为目前最快的 DA 解决方案——比其最初的 50MB/s 测试网目标提高了 2 倍。EigenVerify 和 EigenCompute 主网的推出计划在今年第三季度末/第四季度初。

经济基础设施（EIGEN 代币） – Programmatic Incentives V2。Eigen 基金会最近提议对其 Programmatic Incentives 进行改革，重点是提高总体奖励率，并重新平衡总分配，以向 staked EIGEN 排放更多激励。这里的目标是加速应用程序开发，并激励 EigenCloud 上的创新。

该提案将更新以下奖励分配（如果通过），如下所示：

• 3% 给 ETH stakers 及其运营商（无变化）
• 4% 给 EIGEN stakers 及其运营商（从 1% 增加）> 净增加 3%
• 1% 给业务发展和生态系统增长奖励（全新）

注意：在撰写本文时，这目前仍处于提案阶段。

承诺基础设施 – Redistribution 在主网上线。可重新分配的 slashing 是一种 EigenLayer 中的机制，允许 AVS 不仅通过燃烧其 stake 来惩罚行为不端的运营商，而且还可以将 slashed 的资金重新分配给指定的接收者。

多链验证 已经开始，在 Base 上进行了首次集成，EigenLayer 运营商集合和 stake 权重目前可在 Sepolia 测试网上使用。多链验证使 AVS 能够在多个网络上运行。

Eigen TAM & 竞争格局

当谈到竞争对手时，很可能的问题是：EigenLayer 与 Symbiotic 相比如何，EigenDA 与 Celestia 相比如何，EigenCompute 与 Akash 和 Render 等相比如何？

在提出这个问题时，我们意识到，单独比较每个 Eigen 原语并不能充分体现 EigenCloud 旨在捕获的实际市场。EigenCloud 最好的类比是当今的传统云服务。尽管 Symbiotic 和 Celestia 在某种程度上可以被认为是竞争对手，但加密领域中没有其他协议在积极尝试成为可验证的云。

将 EigenDA 与 Celestia 比较，或将 EigenCompute 与 Akash 或 Render 比较，不一定有意义，因为这些原语都不是孤立地运行，而是作为有凝聚力的组件，以实现大规模的可验证云服务。

例如，数据可用性可以说是利润极低的商品。Celestia 没有获得任何有意义的费用来证明其相对于 EigenDA 的竞争优势。这并不意味着 EigenDA 会累积更多的费用，而是作为 EigenCloud 保护伞下的一个组成部分，以实现最高的吞吐量，即使这意味着在此过程中充当亏损的产品。这里的最终目标是实现具有加密级可验证性的云规模可编程性，而 EigenDA 只是该架构的一个组成部分。

无论如何，即使我们进行比较，通过 V2，EigenDA 的性能也大大优于其直接竞争对手。

假设如此，那么 EigenCloud 最佳的比较对象就变成了传统的云市场。

但是 EigenCloud 不需要取代 AWS 或 Azure 来捕获这个 TAM，它只需要成为可验证性是产品的默认平台。因为可验证性具有信任溢价，即使传统云美元的零头也能转化为 EigenCloud 巨大的经济价值。

如果我们看看像 AWS 或 GCP 这样的传统云服务，它们的价格是按照原始计算周期、带宽和存储来计算的。经典的云价值主张是廉价、无处不在的计算。

对于 EigenCloud，方法略有不同。它不是最便宜的计算周期，而是将信任作为一种计量服务来销售。对于许多高价值应用程序而言，出错的边际成本比计算成本大几个数量级。

这些应用程序愿意为保证链下计算或裁决结果可审计、可重运行和经济上可执行而支付更多的费用。从理论上讲，与 AWS 上同等的原始计算作业相比，这会为每个可验证的工作负载带来更高的平均收入。

以下是我们假设的，如果我们将 EigenCloud 与当前的云市场进行比较，可能会是这样的：

在未来十年内，传统云 TAM 将达到数万亿美元（预计到 2030 年将达到 2 万亿美元），但其中大部分围绕着商品计算和存储。可验证云的 TAM 目前范围较窄，但可以说更具防御性且利润更高。从链上应用程序到可验证的 AI 服务，它始于需要加密经济保证的用例。在 Goldman Sachs 发布的调研报告 中，明确承认 AI 将为这种需求增长做出重大贡献。但是，如果这些 AI 服务需要一定程度的可验证性会发生什么？

下图是对未来几年 AI 云市场预测的保守估计。

虽然与所有云相比，这似乎是一个利基用例，但它是最有价值的工作负载子集，其中正确性比原始吞吐量更有价值。如果 EigenCloud 成为可验证计算的默认层，随着验证成为相邻市场的需求，其 TAM 也会扩展。

结论——迈向可验证的经济

在过去的十年中，我们已经看到了该领域基础设施设计的多种方法和迭代。加密领域中最大的两个架构理论是大链（单体环境）和应用链理论。EigenCloud 提出了第三种：云链理论——即“链”不再仅仅是交易账本，而是一个支持可编程信任的平台。

自成立以来，这一直是 Eigen 的理论。比特币引入了可验证的货币。像以太坊和 Solana 这样的 L1 已经实现了可验证的金融。EigenCloud 旨在创建一个可验证的经济，假设随着时间的推移，代理人将稳步增加并参与其中。

具有讽刺意味的是，加密技术的发展轨迹与互联网早期相似，现在正接近 2000 年代初期首次推出 AWS 时的类似拐点。正如传统云开辟了一整套新的应用类别并创造了一个 10 万亿美元的市场一样，可验证的云也可以做到同样的事情——只是这次是以一种无需信任的方式。

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