在当前的以太坊生态中，存在着许多的中间件（Middleware）。

左侧是应用端的视角。一些 dApp 的运行依赖于中间件：例如 DeFi 衍生品依赖于预言机喂价；例如资产的跨链转移依赖于跨链桥作为第三方中继。

右侧是模块化的视角。例如在 Rollup 排序中我们需要构建 Sequencer 网络；在链下数据可用性中我们有 DAC 或者 Polygon Avail 和 Celestia 的 DA-Purpose Layer1。

这些大大小小的中间件独立于以太坊本身而存在，运行着验证者网络：即投入一些代币和硬件设施，为中间件提供服务。

我们对中间件的信任源于 Economic Security，如果诚实工作可以得到回报，如果作恶则将导致质押代币的 Slashing。这种信任的级别来源于质押资产的价值。

如果我们把以太坊生态中所有依赖 Economic Security 的协议/中间件比作一个蛋糕，那么看起来会像是这样：资金根据质押网络的规模被切分成大大小小的部分。

　　然而，当前的 Economic Security 仍然存在一些问题：

　　对于中间件。中间件的验证者需要投入资金以守护网络，这需要一定的边际成本。出于代币价值捕获的考虑，验证者往往被要求质押中间件原生代币，由于价格波动导致其风险敞口存在不确定性。

　　其次，中间件的安全性取决于质押代币的总体价值；如果代币暴跌，攻击网络的成本也随之降低，甚至可能引发潜在的安全事件。该问题在一些代币市值较为薄弱的协议上尤为明显。

　　对于 dApp。举例而言，一些 dApp 不必依赖于中间件（设想一个 Pure Swap DEX），而只需要信任以太坊；对于一些依赖中间件的 dApp（如需要预言机喂价的衍生品），实际上其安全同时依赖于以太坊和中间件的信任假设。

　　中间件的信任假设本质上来源于对分布式验证者网络的信任。而我们看到由于预言机错误喂价导致的资产损失事件不在少数。

　　这样，进一步地带来木桶效应：

　　假设某个可组合性极高的 DeFi 应用 A，相关牵扯的 TVL 达到数十亿级别，而预言机 B 的信任仅仅依赖于数亿级别的质押资产。那么一旦出现问题，由于协议间关联所带来的风险传导和嵌套，可能无限放大预言机所造成的损失；

　　假设某模块化区块链 C，采用数据可用性方案 D、执行层方案 F 等等，如果其中的某一部分出现行为不当/遭受攻击，波及范围将是 C 整条链本身，尽管系统其他部分并没有问题。

　　可见系统安全取决于其中的短板，而看似微不足道的短板可能引发系统性风险。

　　EigenLayer 做了什么？

　　EigenLayer 的想法并不复杂：

　　类似于共享安全，尝试把中间件的 Economic Security 提升至等同于以太坊的级别。

　　这是通过「Restaking」（再质押）来完成的。

　　Restaking 即是把以太坊验证者网络的 ETH 敞口进行二次质押：

　　原先，验证者在以太坊网络上进行质押以获得收益，一旦作恶则将导致对其质押资产的 Slash。同理，在进行 Restaking 之后能够获得在中间件网络上的质押收益，但如果作恶则被 Slash 原有的 ETH 质押品。

　　具体 Restake 的实施方法是：质押者可以把以太坊网络中提款地址设置为 EigenLayer 智能合约，也即赋予其 Slashing 的权力。

　　来源: Messari, IOSG Ventures

　　除直接 Restake $ETH 之外，EigenLayer 提供了其他两种选项以扩展 Total Addressable Market，即分别支持质押 WETH/USDC 的 LP Token 和 stETH/USDC 的 LP Token。

　　此外，为了延续中间件原生代币的价值捕获，中间件可以选择在引入 EigenLayer 的同时保持对其原生代币的质押要求，即 Economics Security 分别来源于其原生代币和以太坊，从而避免单代币的价格暴跌引发的「死亡螺旋」。

　　可行性

　　总体来看，对验证者来说，参与 EigenLayer 的 Restaking 有资本要求和硬件要求两点。

　　参与以太坊验证的资本要求是 32 ETH，在 Restaking 上保持不变，但在引入到新的中间件时会额外增加潜在的风险敞口，如 Inactivity 和 Slashing。

　　而硬件设施方面，为了降低验证者的参与门槛，实现足够的去中心化，合并后以太坊验证者的硬件要求很低。稍好的家用电脑其实已经可以达到推荐配置。这时一些硬件要求其实是溢出的。类比于矿工在算力资源足够的时候同时挖多个币种，仅从硬件方面来说，Restaking 相当于用溢出的这部分硬件 Capability 去为多个中间件提供支持。

　　听起来很像 Cosmos 的 Interchain Security，仅此而已？实际上，EigenLayer 对后合并时代以太坊生态的影响可能不止于此。本文我们选取 EigenDA 来做进一步阐述。

　　EigenDA

　　注：此处仅十分简略地介绍数据可用性（DA）、纠删码和 KZG 承诺。数据可用性层是模块化视角下的拆分，用于为 Rollup 提供数据可用性。纠删码和 KZG 承诺是数据可用性采样（DAS）的组成部分。采用纠删码使得随机下载一部分数据即可验证所有的数据可用性，并在必要时重建所有数据。KZG 承诺用于确保纠删码被正确编码。为避免偏离本文主旨，本节将省略一些细节、名词解释和前因后果，如对本节 Context 有疑问，可阅读 IOSG 此前的文章「合并在即：详解以太坊最新技术路线」以及「拆解数据可用层：模块化未来中被忽视的乐高积木」。

　　作为简单回顾，我们把当前的 DA 方案划分为链上和链下两部分。

　　链上部分，Pure Rollup 是指单纯把 DA 放到链上的方案，即需要为每个字节恒定支付 16 gas，这将占到 Rollup 成本的 80%-95% 之多。在引入 Danksharding 之后，链上 DA 的成本将得到大幅降低。

　　在链下 DA 中，每种方案在安全性和开销上有一定的递进关系。

　　Pure Validium 是 指仅把 DA 放在链下，而不做任何保证，链下数据托管服务商随时有关机下线的风险。而特定于 Rollup 中的方案包括 StarkEx、zkPorter 和 Arbitrum Nova，即由一小部分知名第三方组成 DAC 来保证 DA。

　　EigenDA 属于通用化的 DA 解决方案，与 Celestia 和 Polygon Avail 同属一类。但 EigenDA 和其余两者的解决思路又有一些差异。

　　作为对比，我们首先忽略 EigenDA，来看 Celestia 的 DA 是如何工作的。　　

　　以 Celestia 的 Quantum Gravity Bridge 为例：

　　以太坊主链上的 L2 Contract 像往常一样验证有效性证明或欺诈证明，区别在于 DA 由 Celestia 提供。Celestia 链上没有智能合约、不对数据进行计算，只确保数据可用。

　　L2 Operator 把交易数据发布到 Celestia 主链，由 Celestia 的验证人对 DA Attestation 的 Merkle Root 进行签名，并发送给以太坊主链上的 DA Bridge Contract 进行验证并存储。

　　这样实际上用 DA Attestation 的 Merkle Root 代替证明了所有的 DA，以太坊主链上的 DA Bridge Contract 只需要验证并存储这个 Merkle Root。对比将 DA 存储到链上而言，这样使得保证 DA 的开销得到了极大的降低，同时由 Celestia 链本身提供安全保证。

　　在 Celestia 链上发生了什么？首先，Data Blob 通过 P2P 网络传播，并基于 Tendermint 共识对 Data Blob 达成一致性。每个 Celestia 全节点都必须下载整个 Data Blob。（注意，这里仅讨论全节点，Celestia 的轻节点可以采用 DAS 来确保数据可用，这里不再展开）

　　由于 Celestia 本身仍然作为 Layer1，需要对 Data Blob 进行广播和共识，这样一来实际上对网络的全节点有着很高的要求（128 MB/s 下载和 12.5 MB/s 上传），而实现的吞吐量却未必高（1.4 MB/s）。

　　而 EigenLayer 采用了不同的架构——不需要做共识，也不需要 P2P 网络。

　　如何实现？　　

　　首先，EigenDA 的节点必须在 EigenLayer 合约中 Restake 他们的 ETH 敞口，参与到 Restaking 中。EigenDA 节点是以太坊质押者的子集。

　　其次，数据可用性的需求方（例如 Rollup，称为 Disperser）拿到 Data Blob 后，使用纠删码和 KZG 承诺对 Data Blob 进行编码（大小取决于纠删码的冗余比例），并把 KZG 承诺发布到 EigenDA 智能合约。

　　随后 Disperser 把编码后的 KZG 承诺分发给 EigenDA 节点。这些节点拿到 KZG 承诺后，与 EigenDA 智能合约上的 KZG 承诺进行比较，确认正确后即对 Attestation 进行签名。之后 Disperser 一一获取这些签名，生成聚合签名并发布到 EigenDA 智能合约，由智能合约进行签名的验证。

　　在这个工作流中，EigenDA 节点仅仅对 Attestation 进行了签名，来声称自己对编码后的 Data Blob 进行了存储。而 EigenDA 智能合约仅仅对聚合签名的正确性进行验证。那么我们如何确保 EigenDA 节点真的对数据可用进行了存储呢？

　　EigenDA 采用了 Proof of Custody 的方法。即针对这样一种情况，有一些 Lazy Validator，他们不去做本应该做的工作（例如确保数据可用）。而是假装他们已经完成了工作并对结果进行签名。（例如撒谎声称数据是可用的，实际上他们并没有这样做）

　　Proof of Custody 的做法类似于欺诈证明：如果出现 Lazy Validator，任何人可以提交证明给 EigenDA 智能合约，由智能合约进行验证，如验证通过即对 Lazy Validator 进行 Slashing。（更多有关 Proof of Custody 的细节可参考 Dankrad 的文章，此处不再展开*https://dankradfeist.de/ethereum/2021/09/30/proofs-of-custody.html*）

　　小结

　　经过上述讨论和比较，我们可以看到：

　　Celestia 的思路与传统的 Layer1 一致，做的其实是 Everybody-talks-to-everybody（共识）和 Everybody-sends-everyone-else-everything（广播），而区别是 Celestia 的共识和广播是针对 Data Blob 来做的，即仅确保数据可用。

　　而 EigenDA 做的是 Everybody-talks-to-disperser（即步骤 [3] Disperser 获取 Attestation）和 Disperser-sends-each-node-a-unique-share（即步骤 [2] Disperser 分发数据给 EigenDA 节点），把数据可用性和共识进行了解耦。

　　EigenDA 不需要做共识和参与 P2P 网络的原因是，它相当于搭了以太坊的「便车」：借助 EigenDA 部署在以太坊上的智能合约，Disperser 发布 Commitments 和 Aggregated Attestations、由智能合约验证聚合签名的过程都是在以太坊上发生的，由以太坊提供共识保证，因此不必受限于共识协议和 P2P 网络低吞吐量的瓶颈。

　　这体现为节点要求和吞吐量之间的差异。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。