Aligned Layer:trustless应用的通用验证层

1. 引言

Aligned Layer近期获得了2000万美金的A轮融资,Aligned Layer:

L2IV Research参与了Aligned Layer 的本轮融资。随着 ZK proofs的应用继续以前所未有的速度增长,对强大、高效和可扩展的验证基础设施的需求也越来越大。 Aligned Layer 旨在通过为 ZK 证明提供通用且模块化的验证层来填补这一关键空白,使开发人员能够轻松构建和部署隐私保护和去信任的应用程序。

凭借对成本效益、可扩展性和安全性的承诺,Aligned Layer 将在塑造隐私保护和去信任应用程序的未来、解锁整个区块链生态系统的新用例和机遇方面发挥至关重要的作用。

Aligned Layer 的主要目的是:

  • 解决,在以太坊上验证 ZK proofs 相关的高成本和低效率问题。

目前,在以太坊上验证 ZK proofs (特别是对于某些证明系统而言)既昂贵又耗时。这造成了一种不公平的市场状况,某些证明的验证成本比其他证明的验证成本更高,从而给想要将 ZK 解决方案集成到其应用程序中的项目和开发人员带来了障碍。

Aligned Layer 背后的孵化团队LambdaClass认识到该问题,并着手创建一个通用验证层,作为证明验证的专用且优化的基础设施。目标是提供一种经济高效、快速且可扩展的解决方案,使以太坊和其他协议受益。通过降低验证成本、提高效率并为基于 ZK 的应用程序实现更快的finality,Aligned Layer 旨在释放 ZK 技术的全部潜力,并培育一个蓬勃发展的 ZK-powered 解决方案生态系统。

2. 当前现状

Aligned Layer 解决的主要问题是在以太坊上验证 ZK proofs的成本高且效率低。该问题主要原因在于:

  • 1)以太坊上的验证成本高昂:目前,对于许多证明系统来说,在以太坊上验证 ZK proofs的成本很高。这是因为验证过程需要大量的计算资源和gas手续费。因此,某些证明系统的验证成本比其他系统更高,从而造成不公平的市场状况。
  • 2)缺乏通用验证层:以太坊目前缺乏专用且优化的层来验证来自不同证明系统的 ZK proofs。每个证明系统都有自己的验证要求和成本,导致碎片化和复杂性。
  • 3)批量验证导致的延迟问题:团队通常会在一段时间内组合多个证明,并在以太坊上批量验证,以分摊高昂的验证成本。然而,这样会带来延迟,因需要时间来积累足够的proofs,然后将其组合在一起。
  • 4)有限的可扩展性和高昂的 Gas 成本:以太坊当前的架构和 Gas 模型对 ZK proofs的广泛采用提出了挑战。随着越来越多的项目和用户依赖 ZK 技术,验证的需求增加,导致更高的 Gas 成本和潜在的可扩展性问题。

从技术上讲,Aligned Layer可通过以下方式解决以上问题:

  • 1)利用单独的验证网络:Aligned 创建了一个专门为验证 ZK proofs而设计的专用网络。该网络由运行验证算法并就证明的有效性达成共识的operators组成。通过将验证过程转移到专门的网络,Aligned 减轻了以太坊的负担,并实现更快、更便宜的验证。
  • 2)支持各种证明系统:Aligned 旨在与各种 ZK 证明系统兼容,如 Plonk、STARKs、Groth16 等。这种通用性使项目和开发人员能够为其用例选择最合适的证明系统,而无需担心底层验证基础设施。 Aligned 提供了用于提交和验证证明的标准化接口,从而简化了集成过程。
  • 3)递归证明组合:Aligned Layer 引入了一种采用递归证明组合技术的聚合模式。通过使用 Halo2 或 Risc0 等证明系统,Aligned Layer 可有效地将多个经过验证的proofs聚合为单个proof。然后可在以太坊上验证该聚合证明,从而降低总体验证成本和延迟。递归组合允许更紧凑、更有效地表示证明,从而更容易扩展。
  • 4)与 EigenLayer 集成并支持 zkEVM :Aligned Layer 旨在与 zkEVM 无缝协作。通过利用 zkEVM 提供的安全性和基础设施,Aligned Layer 受益于restaking和objective slashing等功能。
    • restaking允许operators使用其质押的 ETH 参与 Aligned Layer 的共识和安全
    • 而objective slashing则可对报告错误验证结果的operators进行惩罚。这种集成确保了验证过程的安全性和可靠性。

Aligned Layer 提供两种不同的验证模式来满足不同的用例和需求:

  • 1)快速验证模式:优先考虑实时响应和低延迟的应用程序,可从快速验证模式中受益。
  • 2)聚合模式:旨在最小化验证成本并处理大量证明的应用程序,可利用聚合模式。

Aligned Layer 提供了根据应用需求灵活选择最合适的验证模式,使开发人员能够有效优化其基于 ZK 的解决方案。

3. Aligned Layer系统架构

在这里插入图片描述
Aligned Layer 的架构旨在促进使用各种证明系统(如 Plonk、STARKs、Groth16 等)生成的proofs的验证:

  • 旨在从不同客户接收这些proofs,安全存储proofs,并通过operators网络进行有效验证。

Aligned Layer 的核心是一个允许客户(可以是个人、项目或应用程序)提交proofs进行验证的系统。这些proofs可使用不同的证明系统生成,每个证明系统都有其独特的属性和特征。如:

  • Plonk 证明以其short proof size和快速验证时间而闻名。
  • STARK 提供透明度和可扩展性。
  • Groth16 因其效率和与各种应用程序的兼容性而被广泛使用。

当某客户向 Aligned Layer 提交某proof时:

  • 该proof首先存储在专用的数据可用性 (DA) 层中。
  • 一旦该proof存储在 DA 层中,Aligned Layer operators 就可对其进行验证。
  • Aligned Layer 依赖于去中心化operators网络来负责验证所提交的proofs。这些operators通常是在Aligned Layer 网络中拥有利益的个人或实体,且有动力准确有效地执行验证工作。

注意:

  • EigenDA 是默认的 DA 层,但 Aligned Layer 也可与 Celestia 和 Avail 集成。

基于预定义的分配机制,来将proofs分配给operators进行验证。该机制保证了每个operator都被分配了一个特定的proof来验证,防止重复工作并确保operator之间验证任务的公平分配。

  • 当某operator被分配一个要验证的proof时,其会从 DA 层检索该proof。检索过程被设计为高效且安全,允许operator访问该proof,而不会出现任何不必要的延迟或安全风险。
  • 一旦operator检索到该proof,就会运行与用于该特定proof的证明系统相关联的相应验证算法。每个证明系统都有自己的验证算法,旨在检查该proof的有效性和正确性。如,Plonk proofs的验证算法将不同于 STARK 或 Groth16 proofs所使用的验证算法。
  • 验证算法执行必要的计算和检查,以确定该proof是否有效并满足所需的标准。该过程涉及证明系统特有的数学计算和密码学操作。operator执行这些计算以确保该proof是可靠的并且未被篡改。
  • 当所有operators完成所分配proofs的验证过程后,会采用共识机制就每个proof的有效性达成一致。一旦达成共识,验证结果就会发布到以太坊智能合约中。智能合约充当proof验证结果的防篡改且可公开验证的记录。通过将结果发布到以太坊链上,Aligned Layer 利用了以太坊提供的安全性和不变性。

通过智能合约与以太坊集成有多种用途:

  • 首先,提供了一种trustless无需信任且transparent透明的方式来跟踪和验证该proof验证过程。任何人都可访问智能合约并查看验证结果,确保透明性和问责制。
  • 其次,在以太坊上发布验证结果允许其他应用程序和协议依赖经过验证的proof。其它dapp可与智能合约交互以检查proofs的有效性并根据验证结果做出决策。这实现了 Aligned Layer 和基于以太坊构建的其他系统之间的无缝集成和互操作性。

4. Proof aggregation

虽然在以太坊上发布验证结果可提供透明度和互操作性,但在以太坊上验证每一单个proof可能效率低下且成本高昂,尤其是随着proofs数量的增长。为了应对该挑战,Aligned Layer 引入了一个执行proof aggregation的聚合器组件。
在这里插入图片描述
上图说明了 Aligned Layer 架构中的证明聚合过程,展示了不同类型的 ZK 证明如何有效聚合并发布到以太坊区块链上。

  • 由不同证明系统(如 STARKs、Plonk 和 Groth16)生成的证明被传递到通用prover组件,该组件由针对每种证明类型的专门verifier组成。这些verifier验证证明,然后使用递归验证技术聚合这些proofs。
  • 聚合过程涉及使用 Halo2 或 Risc0 等通用provers将证明转换为一致的格式(如 Risc0 STARK proof),然后执行递归验证。递归证明组合是一个强大的概念,可将多个证明有效地组合成一个紧凑的证明。
  • aggregator利用先进的密码学技术和证明系统,如 Halo2、Risc0、Groth16 或 Plonk,来实现递归证明组合。这些证明系统允许将多个proofs有效地组合成单个紧凑的proof,同时保留其有效性和安全性。通过聚合证明,Aligned Layer 显著减少了以太坊网络上的计算和存储开销,使验证过程更具可扩展性和成本效益。
  • 无需在以太坊上单独验证每个proof,只需验证聚合后的proof。该aggregated proof代表了由 Aligned Layer 验证的所有单个proofs的有效性。通过验证aggregated proof,以太坊可间接验证所有底层proofs的有效性,而无需单独处理各个proofs,最大限度地减少验证负担,同时受益于 Aligned Layer 的安全性和可靠性。

此外,aggregator组件被设计为灵活且可适应不同的证明系统。

  • 可处理各种证明系统生成的证明,并将这些proofs组合成一致的格式(如前面提到的 Risc0 STARK proof)。这种灵活性确保 Aligned Layer 可支持各种基于 ZK 的应用程序和用例,无论其使用哪种特定证明系统。

5. Recursive Proof Composition 递归证明组合

在这里插入图片描述
上图说明了 Aligned Layer 架构中的递归证明组合过程。展示了如何以分层方式聚合和验证多个proofs,以创建可在以太坊链上有效验证的单个紧凑proof。

  • 在树的底部,初始proofs(Proof 1 到 Proof 8)由不同的证明系统生成并提交给Aligned Layer进行验证。每对初始证明都分配给General Prover Verifiers,General Prover Verifiers使用相应的验证算法来验证这些proofs的有效性。
  • 验证后,General Prover Verifiers使用递归证明组合技术将各个proofs聚合为单个proof。该过程递归持续,更高级别的General Prover Verifiers验证和聚合已聚合的proofs,直到获得单个final proof。
  • final proof代表所有初始proofs的汇总和验证证明。final proof,这种紧凑的proof可在以太坊链上进行高效验证,减少验证负担和成本。

递归树图展示了证明聚合过程的层次性质,其中逐步验证和组合证明,直到获得单个final proof。该方法允许通过利用递归证明组合技术来有效验证大量proofs。

6. Dual Staking 双重质押机制

双重质押机制是 Aligned Layer 架构的一个组成部分,有两个主要目的:

  • bootstrapping proof-of-stake网络:Aligned Layer 利用 EigenLayer 框架来重新质押以太坊validators所质押的 ETH。这使得 Aligned Layer 能够安全地启动其PoS网络,以额外奖励吸引validators,同时受益于以太坊的安全性。
  • 并确保系统的长期安全性和去中心化
    • 用于治理和主权的原生代币质押:Aligned Layer 引入了用于治理和长期主权的原生代币。代币持有者可参与决策过程,如协议升级和参数更改。原生代币质押还提供了额外的安全层,并激励对网络的长期承诺。

双重质押模型结合了以太坊已建立的质押基础设施的优势和原生代币治理的优势。该方法使 Aligned Layer 能够安全地引导其网络,同时过渡到更加去中心化的治理模型。

通过要求持有大量原生代币,该协议对恶意行为产生了强大的威慑力,因为攻击者需要获取大量代币才能潜在地损害网络的安全性或活跃性。
在这里插入图片描述
就成本而言,与单独的以太坊相比,Aligned Layer 中的soft finality和hard finality模式都更便宜。这种成本效率是一个显著优势,因为其使得 ZK 证明验证对于资源有限的项目来说更容易访问且更具成本效益。通过降低成本障碍,Aligned Layer 鼓励更广泛地采用和试验 ZK 技术。

在 Aligned Layer 和以太坊的比较中,安全性至关重要。虽然以太坊提供了基础级别的安全性,但具有soft finality的 Aligned Layer 提供了与以太坊成比例的安全性。这意味着soft finality模式的安全性源自以太坊的底层安全性,为信任和可靠性提供了坚实的基础。另一方面,Aligned Layer中的hard finality模式继承了以太坊的完整安全保证,确保了verified proofs的最高级别的保证。

此外,在soft finality和hard finality模式之间进行灵活选择,使项目能够根据其特定需求优化其验证过程。

  • 优先考虑速度和成本效益的应用程序可以选择soft finality,
  • 而需要最高级别安全性的应用程序可以选择hard finality模式。

这为 Aligned Layer 提供了越来越多可供探索和依赖的用例。

7. 所支持的证明系统

在这里插入图片描述
Aligned Layer 一大显著优势在于支持多种证明系统,其允许开发人员根据自己的具体要求选择最合适的系统。无论项目优先考虑证明大小、验证时长、后量子安全性还是prover效率,Aligned Layer 都能提供满足不同需求的灵活性。这种多功能性使 Aligned Layer 成为各种 ZK 应用程序的有吸引力的平台,促进 ZK 生态系统的创新和采用。

除了以上表中提到的证明之外,Aligned Layer 很快将集成 Jolt proofSP1

至此,了解了Aligned Layer 架构,Aligned Layer中证明验证的基本流程可以总结如下:
在这里插入图片描述

  • 1)证明提交:客户将使用各种证明系统生成的proofs提交给Aligned Layer。
  • 2)数据可用性:提交的proofs安全地存储在 DA 层中。
  • 3)Operator分配:使用公平分配机制将proofs分配给各operator进行验证。
  • 4)检索和验证:从 DA 层检索proofs并运行特定的验证算法来验证该proofs。
  • 5)共识:Operator采用共识机制来确保大多数人同意每个proof的有效性。
  • 6)发布结果:验证结果被发布到以太坊智能合约中,以实现透明度和不变性。
  • 7)聚合:可使用递归证明组合技术来聚合已验证的proofs,从而降低以太坊上的验证成本。

8. Aligned Layer的当前统计数据

在过去的几周里,Aligned Layer 团队回答了有关其运营、测试网和合作伙伴关系的几个问题。

  • 1)为何在 Aligned Layershang 验证proof,比在L2上验证,有更便宜的 Gas 成本?
    根据当前的benchmarks,Aligned Layer 的目标是与在 L2 上验证proofs相比,成本降低 90%。计算将在专门设计用于运行verifiers的专用网络中执行,在普通计算机上大约需要 100 毫秒。使用 Aligned Layer 的主要成本将是发布在以太坊上的数据,包括proof commitment的哈希值、publics以及结果为True或False。验证 BLS 签名也存在挑战,这是许多基于 zkEVM 的应用程序面临的常见问题,但该问题已在 zkEVM 中解决,且 Aligned Layer 提供了解决方案,可根据Operators数量扩展验证过程。

  • 2)在 Aligned Layer 中使用不同证明类型和手续费机制的动机是什么?
    Aligned Layer 中,所有证明类型都被同等对待。验证手续费将根据验证最昂贵的证明类型(目前为 STARK 证明)的手续费而定。用户需要提前支付费用。 Aligned Layer 系统具有高度可扩展性,因此没有理由预期手续费会出现长期问题。该系统旨在高效处理大量证明,确保收费机制保持可持续性。

  • 3)Aligned Layer 中的slashing条件
    Aligned Layer 采用slashing机制来阻止恶意行为并保持验证过程的完整性。slashing条件旨在惩罚违反协议规则或提供不正确验证结果的operators。Aligned Layer 中有两种主要的slashing方法:

    • 3.1)(短期计划)主观削减:短期内,当Aligned Layer投入生产时(目前仍在测试网中),将实施简单的sub-slashing机制。其依赖于绝对多数(如,三分之二)operatos的共识来最终确定并将验证结果发布到以太坊。在该机制下,如果某operator属于少数,且报告proof不正确,而大多数operators认为该proof有效,那么少数operator将被削减。需注意,此时该sub-slashing机制并不完美,因为其没有利用 zkEVM 提供的所有功能。然而,这是确保验证过程的安全性和完整性的起点。
      主观惩罚机制的工作原理如下:
      • operators参与验证过程并提交验证结果。
      • operators对验证结果达成了绝大多数共识。
      • 提供与绝大多数验证结果不同的operators被识别为潜在的恶意行为者。
      • 该协议削减了不合规operators的股份,惩罚其恶意行为。

    虽然主观削减并不完美,因其没有利用 zkEVM 提供的所有功能,但可作为确保验证过程的安全性和完整性的起点。主观削减的有效性依赖于大多数operators是诚实的且以网络最佳利益为出发点的假设。由于Aligned Layer客户端被设计为轻量级且硬件要求低,因此鼓励具有更多operators的更加去中心化的网络,从而降低了共谋的风险。

    • 3.2)(长期计划)客观削减:从长远来看,Aligned Layer 的目标是实现更先进的削减机制。客观削减涉及使用 zkEVM 直接在链上运行验证计算。此时削减条件是根据 Aligned Layer 支持的特定证明系统来定义的。由于并非所有与 Aligned Layer 集成的证明系统都可在以太坊中进行完全链上验证,因此客观削减可能不适用于所有证明系统。然而,对于可在链上验证的证明系统,如Cairo proofs,可实现客观削减。客观削减机制的工作原理如下:
      • operators参与验证过程并提交验证结果。
      • 多数operators同意验证结果的,视为有效。
      • 若大多数operators恶意行事并提供错误的验证结果,诚实的operators或第三方可能会触发削减事件。
      • 削减事件启动了一个挑战过程,其中有争议的验证结果使用 zkEVM 在以太坊上进行了完全的链上验证。
      • 如果链上验证证明大多数operators有恶意行为,其质押就会被削减,从而对其不当行为进行惩罚。

    客观削减通过利用以太坊和 zkEVM 的链上验证功能提供更高级别的安全性。即使大多数operators串通一气,也能确保恶意行为能够被检测到并受到惩罚。

每个验证都会有不同的链上计算成本,因此需要考虑到这一点并进行彻底测试以创建强大的削减机制。

参考资料

[1] L2IV Research 2024年5月14日博客 Aligned Layer: The Universal Verification Layer for Trustless Applications

相关推荐

  1. 探索计算机网络:应用魅力

    2024-05-25 19:11:02       63 阅读
  2. 探索计算机网络:应用魅力

    2024-05-25 19:11:02       57 阅读
  3. 探索计算机网络:应用魅力

    2024-05-25 19:11:02       55 阅读

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-05-25 19:11:02       98 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-05-25 19:11:02       106 阅读
  3. 在Django里面运行非项目文件

    2024-05-25 19:11:02       87 阅读
  4. Python语言-面向对象

    2024-05-25 19:11:02       96 阅读

热门阅读

  1. Redis实现MQ

    2024-05-25 19:11:02       32 阅读
  2. 定时器

    定时器

    2024-05-25 19:11:02      33 阅读
  3. eclipse 快捷键

    2024-05-25 19:11:02       36 阅读
  4. pytest

    2024-05-25 19:11:02       31 阅读
  5. uniApp 创建Android.keystore证书&IOS的证书

    2024-05-25 19:11:02       37 阅读
  6. Spring Boot中的缓存注解

    2024-05-25 19:11:02       32 阅读
  7. (九)npm 使用

    2024-05-25 19:11:02       32 阅读
  8. android关于framework层的中间件jar的流程

    2024-05-25 19:11:02       34 阅读
  9. 日用百货元宇宙 以科技创新培育产业新质生产力

    2024-05-25 19:11:02       33 阅读
  10. npm,yarn,cnpm,tyarn,pnpm 安使用装配置镜像

    2024-05-25 19:11:02       35 阅读
  11. vscode终端运行pnpm,yarn不成功问题

    2024-05-25 19:11:02       32 阅读
  12. 设计模式 16 解释器模式 Interpreter Design Pattern

    2024-05-25 19:11:02       29 阅读
  13. react 低代码平台方案汇总

    2024-05-25 19:11:02       30 阅读