实现L1EVM有效性证明所需的核心技术在很大程度上与其他两个领域共享：
L2的有效性证明（即ZKrollup）
无状态的STARK二进制哈希证明方法
在L1成功实现有效性证明，就能最终实现轻松的单人质押：即使是最弱的计算机（包括手机或智能手表）也能质押。这进一步提高了解决单人质押的其他限制（如32ETH最低限额）的价值。
此外，L1的EVM有效性证明可以大大提高L1的gas限值。
如果我们想用SNARK完全验证一个以太坊区块，那么EVM的执行并不是我们需要证明的唯一部分。我们还需要证明共识，即系统中处理存款、取款、签名、验证器余额更新以及以太坊权益证明部分其他元素的部分。
共识比EVM简单得多，但它面临的挑战是，我们没有L2EVM卷积，因此无论如何，大部分工作都要完成。因此，任何证明以太坊共识的实现都需要从头开始，尽管证明系统本身是可以在其基础上构建的共享工作。
信标链被定义为状态转换函数,就像EVM一样。状态转换函数主要由三部分组成：
ECADD（用于验证BLS签名）
配对（用于验证BLS签名）
SHA256哈希值（用于读取和更新状态）
在每个区块中，我们需要为每个验证器证明1-16个BLS12-381ECADD（可能不止一个，因为签名可能包含在多个集合中）。这可以通过子集预计算技术来弥补，因此我们可以说每个验证者只需证明一个BLS12-381ECADD。目前，每个插槽有30000个验证器签名。未来，随着单时隙终局性的实现，这种情况可能会向两个方向发生变化：如果我们采取蛮力路线，每个时隙的验证者数量可能会增加到100万。与此同时，如果采用OrbitSSF，验证器数量将保持在32768个，甚至减少到8192个。
BLS聚合如何工作：验证总签名只需要每个参与者一个ECADD，而不是一个ECMUL。但是30000个ECADD仍然是一个很大的证明量。
就配对而言，目前每个插槽最多有128个证明，这意味着需要验证128个配对。通过ElP-7549和进一步的修改，每个插槽可以减少到16个。配对的数量很少，但成本极高：每个配对的运行（或证明）时间比ECADD长数千倍。
证明BLS12-381运算的一个主要挑战是，没有曲线阶数等于BLS12-381字段大小的便捷曲线，这给任何证明系统都增加了相当大的开销。另一方面，为以太坊提出的Verkle树是用Bandersnatch曲线构建的，这使得BLS12-381本身成为SNARK系统中用于证明Verkle分支的自曲线。一个比较简单的实现每秒可以证明100G1的加法；要使证明速度足够快，几乎肯定需要像GKR这样的巧妙技术。
对于SHA256哈希值来说，目前最糟糕的情况是纪元转换块，整个验证器短平衡树和大量验证器平衡都会被更新。每个验证器的短平衡树只有一个字节，因此有1MB的数据会被重新取哈希。这相当于32768次SHA256调用。如果有一千个验证者的余额高于或低于一个阈值，需要更新验证者记录中的有效余额，这相当于一千个Merkle分支，因此可能需要一万次哈希值。洗牌机制需要每个验证器90比特（因此需要11MB的数据），但这可以在一个纪元的任何时间计算。在单槽终结的情况下，这些数字可能会根据具体情况有所增减。洗牌变得没有必要，尽管Orbit可能会在一定程度上恢复这种需要。
另一个挑战是需要重新获取所有验证器状态，包括公钥，才能验证一个区块。对于100万个验证器来说，仅读取公钥就需要4800万字节，再加上Merkle分支。这就需要每个纪元数以百万计的哈希值。如果我们必须证明PoS的有效性，一种现实的方法是某种形式的增量可验证计算：在证明系统内存储一个单独的数据结构，该数据结构经过优化，可以高效查找，并证明对该结构的更新。
总之，挑战很多。要最有效地应对这些挑战，很可能需要对信标链进行深入的重新设计，而这可能与转向单槽终结同时进行。这种重新设计的特点可能包括：
哈希函数的变化：现在使用的是完整的SHA256哈希函数，因此由于填充的原因，每次调用都要对应两次底层压缩函数调用。如果改用SHA256压缩函数，我们至少可以获得2倍的收益。如果改用Poseidon，我们可能会获得100倍的增益，从而彻底解决我们的所有问题（至少在哈希值方面）：在每秒170万哈希值（54MB），即使是一百万条验证记录也能在几秒钟内读取到证明中。
如果是Orbit，则直接存储洗牌后的验证器记录：如果选择一定数量的验证器（如8192或32768个）作为给定插槽的委员会，则将它们直接放入彼此旁边的状态中，这样只需最少的哈希就能将所有验证器的公钥读入证明中。这样还可以高效地完成所有平衡更新。
签名聚合：任何高性能签名聚合方案都会涉及某种递归证明，网络中的不同节点会对签名子集进行中间证明。这就自然而然地将证明工作分担给了网络中的多个节点，从而大大减少了最终证明者的工作量。
其他签名方案：对于Lamport+Merkle签名，我们需要256+32个哈希值来验证签名；乘以32768个签名者，就得到9437184个哈希值。对签名方案进行优化后，可以通过一个很小的常数因子进一步改善这一结果。如果我们使用Poseidon，这在单个插槽内就能证明。但实际上，使用递归聚合方案会更快。
简洁的以太坊共识证明（仅限同步委员会）
简洁SP1内的Helios
简明BLS12-381预编译
基于Halo2的BLS集合签名验证
实际上，我们需要数年时间才能获得以太坊共识的有效性证明。这与我们实现单槽终局性、Orbit、修改签名算法以及安全分析所需的时间大致相同，而安全分析需要足够的信心才能使用像Poseidon这样激进的哈希函数。因此，最明智的做法是解决这些其他问题，并在解决这些问题的同时考虑到STARK的友好性。
主要的权衡很可能是在操作顺序上，在改革以太坊共识层的更渐进的方法和更激进的一次改变许多的方法之间。对于EVM来说，渐进式方法是合理的，因为它能最大限度地减少对向后兼容性的干扰。对共识层来说，向后兼容性的影响较小，而且对信标链构建方式的各种细节进行更全面的重新思考，以最佳方式优化SNARK友好性也有好处。
在对以太坊PoS进行长期重新设计时，STARK友好性必须成为首要考虑因素，尤其是单槽终局性、Orbit、签名方案变更和签名聚合。
以上就是The Verge是什么？以太坊可能的未来The Verge的全部内容，望能这篇The Verge是什么？以太坊可能的未来The Verge可以帮助您解决问题，能够解决大家的实际问题是非常好学习网一直努力的方向和目标。