原文:
https://blog.altlayer.io/introducing-restaked-rollups-ac6a1e89b646
现在大家已经一致认为，rollups 是将交易执行移出以太坊的最佳方式，因此有助于扩展基础链。此外，随着 OP Stack、Arbirum Orbit、Polygon CDK 和 ZKSync 的 ZK Stack 等不同 rollup SDK 的发布，现在比以往任何时候都更容易启动通用智能合约汇总的应用程序定制实例。这些 SDK 使新汇总的部署像部署智能合约一样简单。此外，借助 AltLayer、Conduit 等多个 rollup-as-a-service（RaaS） 提供商，dApp 开发人员甚至不需要自己托管任何节点基础设施，并且可以让 RaaS 提供商代表他们运行和管理 rollup，从而可以在几分钟内启动一个完全可操作的 rollup。
但是，在包含数千个汇总的世界中，任何偏离理想设计和实现的汇总都会通过汇总 SDK 进行大规模放大。这篇文章旨在强调和解决数以千计的特定于应用程序的汇总世界中固有的一些关键问题。我们首先讨论了一些影响应用程序定制卷叠的去中心化、安全性、互操作性、用户和开发体验等核心问题，然后提出了一种新的卷叠设计，称为 retaked rollups，旨在通过利用 EigenLayer 的重新绑定机制来解决这些问题。
重新集成的汇总是一组三个垂直集成的主动验证服务，即为给定汇总按需创建的 AVS。这些 AVS 共同为应用程序 rollup 提供了三个关键服务，即去中心化排序、验证 rollup 的状态正确性和更快的终结性，这反过来又有助于 rollup 的去中心化、更好的安全性和跨 rollup 的互操作性，同时通过重新质押利用以太坊的信任网络。Resaked rollup 设计有三个模块化组件，称为：
VITAL（用于对 rollup 状态进行去中心化验证的 AVS）
MACH （用于快速终结的 AVS）
SQUAD（用于分散测序的 AVS）
但是，在我们进一步讨论重新汇总之前，让我们深入探讨一下它们旨在解决的特定于应用程序的汇总上下文中的问题。
问题 1：验证
乐观卷叠是安全的，前提是至少有一个诚实的一方来检查卷叠运算符在以太坊上提交的状态是否确实对应于一组交易上状态转换函数的正确执行以及先前验证的状态。
然而，大多数特定于应用程序的 rollup 可能没有像流行的通用 rollup 那样成熟的生态系统，因此可能没有足够的生态系统参与者具有隐性动机来关注网络。
此外，在 L1 以太坊智能合约中，还有一种新兴的模式，即有人承诺计算的输出，然后可以证明存在欺诈行为。另一个例子是 AltLayer 引入的临时 rollups，其中 rollup 排序器在结算时将 rollup 的状态提交到以太坊，其中状态表示对某个应用程序（如 Dark Forest）的 rollup 进行链下计算的结果。有了这些按需系统，拥有一个可以检测和挑战汇总状态的去中心化验证器网络变得极为重要。
问题 2：缓慢的终结性
以太坊是最去中心化的网络，拥有近 1M 个验证者。它也是流动性最强的网络，因此以太坊成为当今大多数 rollup 的首选结算层也就不足为奇了。然而，以太坊作为一个网络并不是完成和结算交易最快的，因为完成交易大约需要 13 分钟。
考虑到交易完成所需的时间，旨在为延迟敏感型应用程序（如游戏和社交应用程序）提供服务的应用程序特定汇总通常最终依赖于排序器提供的承诺，即在未来的某个时候，它将在链上发布交易。
在 rollup sequencer 由受信任方操作的情况下，这可能是可以接受的，但是，当它由没有先前声誉的匿名开发人员操作时，sequencer 的承诺肯定不值一分钱。此外，由于这些集中式测序仪没有经济利益，因此它们提供的软终结性保证没有经济支持。
此外，由于定序器提供的最终性保证不强，因此定序器生成的接收不足以实现互操作性。例如，对于在 rollup A 上销毁和在 rollup B 上铸币的样式交叉 rollup 消息，rollup B 需要有强有力的保证，即 rollup A 的 sequencer 确实在 rollup A 上销毁了一定数量的令牌。
问题 3：集中排序
rollup 的第一个也是主要问题是 sequencer 的集中化。
如今，大多数 rollup 都使用由开发协议的实体操作的集中式排序器运行。尽管让单个排序器操作汇总并不理想，但对于一个成熟的通用汇总来说，拥有一个集中式排序器在某种程度上是可以接受的，因为对运行排序器的实体有一定的信任，不会参与会损害其声誉的活动。然而，这种协议外的信任不能扩展到可能由没有声誉的匿名开发人员操作的特定于应用程序的卷叠的长尾。
与集中排序相关的另一个问题与 RaaS 提供程序有关。尽管 RaaS 提供商提供了非常有用的服务，并且可以帮助计划启动汇总的团队节省大量财务和人力资源。然而，他们的商业模式在很大程度上依赖于集中排序和执行的存在。大多数（如果不是全部）RaaS提供商都会收取部分测序收入，因此，出于业务可行性的原因，他们被鼓励尽可能长时间地锁定客户。供应商锁定会带来平台风险，即受欢迎的 RaaS 提供商可能会单方面决定决定收费模式或提取任意 MEV 以最大化其利润。
此外，当今大多数 RaaS 提供商运营的集中式排序器/执行器模型并不理想，因为它们呈现了一个封闭的环境，原则上违背了开放、透明和去中心化 web3 的精神。
Resaked Rollups 概述
如果没有一个通用的、可信的中立网络来促进这些服务，许多这些特定于应用程序的汇总很可能最终会创建自己的孤立和寻租生态系统，对最终用户体验几乎没有灵活性和控制力。重新绑定的 rollups 旨在改变这种状况。
Resaked rollup 的设计具有以下关键特征：
模块化，因为它们可以与任何卷叠堆栈、任何替代 DA 层（如 EigenDA 和任何结算层）一起使用，并且其组件可以独立使用
加密经济安全，可处理任何恶意网络参与者
支持 ZK 和乐观汇总
足够通用，可以支持不同的证明系统和运行时
整体系统架构如下：我们假设有三个系统参与者：a） 具有 ET 的用户，b） 希望委托 rollup 的开发人员，c） AVS 操作员
用户首先质押她的 ETH，然后获得一个 LST，然后她通过 EigenLayer 重新质押。然后，希望重新集成 rollup 的开发人员将设置 AVS 合约，以允许 AVS 运营商注册 SQUAD（用于排序）、VITAL（用于验证）和 MACH 以实现快速最终确定。设置这些 AVS 并注册操作员后，他们就可以开始操作汇总。
在以下各节中，我们将解释 AVS 的每个组件的工作原理。
验证程序 AVS 又名 VITAL
VITAL 充当 rollup 的神圣验证层。它由一个 AVS 注册运营商网络组成，用于验证 SQUAD 运营商提出的所有新状态。它运算符检测无效的状态根，并可以在二分协议中质询 SQUAD 运算符。
VITAL 还可以使用乐观的ZK证明进行操作，即 VITAL 运营商要求 SQUAD 运营商为有争议的状态根创建 ZK 证明，而不是参与二分协议。另一种操作模式是验证不需要转到 L1 的中间证明。VITAL 至关重要，因为最后一个 AVS MACH 利用它来提供快速的终结层。
快速终结性 AVS 又名 MACH
为了解决 rollup 的缓慢终结性问题，我们提出了 MACHI：以太坊 rollup 的快速终结层，具有以下关键特征：
快速确认汇总交易
加密经济安全，以处理任何恶意网络参与者
支持 ZK 和乐观汇总
足够通用，可以支持不同的证明系统和运行时
为了保证最终性，MACH 作为一个网络需要验证 rollup 状态的有效性，以确保 rollup 算子正确遵循了状态转换函数。为此，MACH 支持三种状态有效性模式。
悲观模式
在悲观模式下，默认情况下，每笔交易都被视为无效，因此需要重放。因此，rollup 算子将交易数据直接提供给 MACH 网络，MACH 网络又重新执行交易，并由 rollup operator 就提议状态的有效性达成共识。
虽然这种操作模式是最简单的，但它的主要缺点之一是它不是很高效，因为 MACH 实际上作为汇总的全节点网络运行。这导致了强大的节点需求。
未来的工作是构建无状态客户端，这些客户端需要较小的状态占用空间来操作汇总节点。
乐观模式
在这种模式下，rollup 运算符对 MACH 断言一个状态声明，声明特定事务块的执行会导致特定的状态承诺。然后，MACH 网络中的任何节点都可以通过在二分协议中与 rollup 运算符合作来质疑该声明并证明新状态无效。
请注意，只有当挑战者认为状态承诺无效时，才会触发二分协议。也可以用按需 ZK 证明来代替二分协议，其中 ZK 证明仅在存在挑战时生成。
此设置假设 MACH 网络中至少存在一个诚实节点，并且网络节点大多处于观察模式。
有效性证明模式
在这种模式下，MACH 网络充当去中心化的验证者网络，用于有效性证明。汇总运算符（如排序器）将提交到一组新的事务、结果状态以及 MACH 上的有效性证明。然后，MACH 网络将验证并就证明的有效性达成共识。
尽管明确使用有效性证明，但此模式也可以很好地与乐观汇总配合使用。通过乐观汇总，任何具有正确激励（在 MACH 之外）的指定证明者都可以生成有效性证明并将其提交给 MACH 网络，而 MACH 网络又会验证证明的有效性并达成共识。
请注意，对于 ZK rollups，证明者可以在 MACH 上比在以太坊上更频繁地生成和提交证明，并且他们这样做对于更快的最终确定性很重要。此外，这不需要以牺牲更多的证明工作为代价：证明者可以实时创建证明并将其发送到 MACH 并使用递归将它们聚合成一个批量证明，而不是等待创建单个批次证明，稍后可以进入以太坊。只要增量证明立即分发给 MACH，交易就会快速完成。
实现
我们已经将 MACH 实现为 AVS，用于在 Rust 中实现乐观的 rollup，并在 WASM 上提供故障保护。该汇总运行 Sputnik VM（EVM 的 Rust 实现）作为执行引擎。rollup 客户端将 Sputnik VM（在 Rust 中）编译为 WASM 指令，然后通过 WASM 运行二分协议。
在本节中，我们将介绍通过二分协议实现具有故障证明的乐观模式。
每个 MACH 节点都充当一个 AVS 操作员，严格验证汇总状态，并主动质疑在指定质询窗口期间观察到的任何差异。MACH 网络中的挑战者节点遵循以下步骤：
通过 EigenLayer 进行取样
在 EigenLayer 上注册为 AltLayer AVS 算子并选择削减
注册后，节点可以在质询期间质询任何汇总状态
如果挑战者希望对任何 rollup 状态提出异议，它可以在 MACH 上的 rollup 合约上创建质询请求
创建质询后，质询者和汇总操作员之间的平分协议将开始。找到有争议的指令后，将在 MACH 上执行，挑战结束
请注意，如果挑战失败，挑战者会在 EigenLayer 上被冻结（并受到砍杀）。
下面是一个快速演示，说明如何端到端地实现这一点。
https://drive.google.com/file/d/1c_Oo6gJiXHNULmqXxEBL64Jy3IjP7QXj/view?usp=sharing
我们还实现了按需 ZK 证明来取代二分协议。详细信息可以在与RISC Zero团队的联合工作中找到。
分散测序 AVS 又名 SQUAD
SQUAD 提出了一个 rollup 专用的去中心化测序器网络。简单地说，SQUAD 是一个节点网络，任何人都可以在 AVS 注册后加入。
要成为 SQUAD 的验证者，节点必须质押一定数量的 LST。这为卷叠的安全性提供了经济保障，并且可能会被削减。
运营商可以自己引入所需的最低 LST 质押，也可以实施委托质押机制，允许 LST 持有者与运营商进行质押。在 SQUAD 上进行质押是在 AVS 合约中原生实现的。
结论
Resaked rollup 是 rollup 的新设计和实现，它通过三个垂直集成的 AVS 提供分散的排序、验证和快速终结。这些 AVS 可以与任何 rollup 堆栈一起使用，并且可能与任何选择的 DA 层一起使用，并且对于在 dApp rollup 的长尾中建立信任非常有用。