如果攻击者能够构建一个能阻塞证明者十分钟时间的区块，那么仅仅在4秒内证明一个普通的以太坊区块是不够的。所需的以太虚拟机（EVM）改变大致可以分为以下几类：
1. gas成本的变化：如果一个操作需要很长时间才能证明，那么即使它的计算速度相对较快，也应该有很高的gas成本。EIP-7667提出了一个EIP来处理这个问题，它大大增加了（传统）哈希函数的gas成本，因为这些函数的操作码和预编译相对便宜。为了弥补这些gas成本的增加，我们可以降低证明成本相对较低的EVM操作码的gas成本，从而保持平均吞吐量不变。
2. 数据结构替换：除了用对STARK更友好的方法替换状态树外，我们还需要替换事务列表、收据树和其他证明成本高昂的结构。Etan Kissling将事务和收据结构移至SSZ的EIP就是朝着这个方向迈出的一步。
此外，上一节提到的两个工具（多维gas和延迟状态根）也能在这方面提供帮助。然而，需要注意的是，与无状态验证不同，使用这两个工具意味着我们已经拥有了足够的技术来完成我们目前所需的工作，而即使使用了这些技术，完整的ZK-EVM验证也需要更多的工作，只是需要的工作更少而已。
上文没有提到的一点是证明器硬件：使用GPU、FPGA和ASIC更快地生成证明。Fabric Cryptography、Cysic和Accseal是三家在这方面取得进展的公司。这对L2来说非常有价值，但不太可能成为L1的决定性考虑因素，因为人们强烈希望L1保持高度去中心化，这意味着证明生成必须在以太坊用户的合理范围内，而不应受到单个公司硬件的瓶颈限制。L2可以做出更积极的权衡。
在这些领域中，还有更多的工作要做：
1. 并行化证明：要求证明系统的不同部分可以共享内存，例如查找表。我们知道如何实现这样的技术，但需要进行实际的实现。
2. 进行更多的分析：以找出理想的gas成本变化集，以最大程度地减少最坏情况下的验证时间。
3. 在证明系统方面做更多的工作。
可能的代价包括：
1. 安全性与验证器时间之间的权衡：如果选择更激进的哈希函数、更复杂的证明系统或更激进的安全假设或其他设计方案，有可能缩短验证器时间。
2. 去中心化与验证器时间之间的权衡：社区需要就所针对的验证器硬件的规格达成一致。要求验证者是大规模实体可以吗？我们希望高端消费笔记本电脑能在4秒内证明一个以太坊区块吗？介于两者之间？
3. 打破向后兼容性的程度：其他方面的不足可以通过更积极的gas成本变化来弥补，但这更有可能不成比例地增加某些应用程序的成本，迫使开发人员重写和重新部署代码，以保持经济可行性。同样，这两个工具也有其自身的复杂性和弊端。
它与路线图的其他部分如何互动？
实现L1 EVM有效性证明所需的核心技术在很大程度上与其他两个领域共享：
1. L2的有效性证明（即「ZK rollup」）
2. 无状态的「STARK二进制哈希证明」方法
通过成功实现L1有效性证明，最终可以实现轻松的单人质押，即使是最弱的计算机（包括手机或智能手表）也能质押。这进一步提高了解决单人质押的其他限制（如32ETH最低限额）的价值。
此外，L1的EVM有效性证明可以大大提高L1的gas限值。
共识的有效性证明
我们要解决什么问题？
如果我们想用SNARK完全验证一个以太坊区块，那么EVM的执行并不是我们需要证明的唯一部分。我们还需要证明共识，即系统中处理存款、取款、签名、验证器余额更新以及以太坊权益证明部分其他元素的部分。
共识比EVM简单得多，但它面临的挑战是，我们没有L2 EVM卷积，因此无论如何，大部分工作都要完成。因此，任何证明以太坊共识的实现都需要从头开始，尽管证明系统本身是可以在其基础上构建的共享工作。
它是什么，如何工作？
信标链被定义为状态转换函数，就像EVM一样。状态转换函数主要由三部分组成：
1. ECADD（用于验证BLS签名）
2. 配对（用于验证BLS签名）
3. SHA256哈希值（用于读取和更新状态）
在每个区块中，我们需要为每个验证器证明1-16个BLS12-381 ECADD（可能不止一个，因为签名可能包含在多个集合中）。这可以通过子集预计算技术来弥补，因此我们可以说每个验证者只需证明一个BLS12-381 ECADD。目前，每个插槽有30000个验证器签名。未来，随着单时隙终局性的实现，这种情况可能会向两个方向发生变化：如果我们采取「蛮力」路线，每个时隙的验证者数量可能会增加到100万。与此同时，如果采用Orbit SSF，验证器数量将保持在32768个，甚至减少到8192个。
BLS聚合如何工作：验证总签名只需要每个参与者一个ECADD，而不是一个ECMUL。但是30000个ECADD仍然是一个很大的证明量。
就配对而言，目前每个插槽最多有128个证明，这意味着需要验证128个配对。通过EIP-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的有效性，一种现实的方法是某种形式的增量可验证计算：在证明系统内存储一个单独的数据结构，该数据结构经过优化，可以高效查找，并证明对该结构的更新。
总之，挑战很多。要最有效地应对这些挑战，很可能需要对信标链进行深入的重新设计，而这可能与转向单槽终结同时进行。这种重新设计的特点可能包括：
1. 哈希函数的变化：现在使用的是「完整」的SHA256哈希函数，因此由于填充的原因，每次调用都要对应两次底层压缩函数调用。如果改用SHA256压缩函数，我们至少可以获得2倍的收益。如果改用Poseidon，我们可能会获得100倍的增益，从而彻底解决我们的所有问题（至少在哈希值方面）：在每秒170万哈希值（54MB），即使是一百万条验证记录也能在几秒钟内「读取」到证明中。
2. 如果是Orbit，则直接存储洗牌后的验证器记录：如果选择一定数量的验证器（如8192或32768个）作为给定插槽的委员会，则将它们直接放入彼此旁边的状态中，这样只需最少的哈希就能将所有验证器的公钥读入证明中。这样还可以高效地完成所有平衡更新。
3. 签名聚合：任何高性能签名聚合方案都会涉及某种递归证明，网络中的不同节点会对签名子集进行中间证明。这就自然而然地将证明工作分担给了网络中的多个节点，从而大大减少了「最终证明者」的工作量。
4. 其他签名方案：对于Lamport+ Merkle签名，我们需要256 + 32个哈希值来验证签名；乘以32768个签名者，就得到9437184个哈希值。对签名方案进行优化后，可以通过一个很小的常数因子进一步改善这一结果。如果我们使用Poseidon，这在单个插槽内就能证明。但实际上，使用递归聚合方案会更快。
与现有研究有哪些联系？
– 简洁的以太坊共识证明（仅限同步委员会）
– 简洁SP1内的Helios
– 简明BLS12-381预编译
– 基于Halo2的BLS集合签名验证
还有哪些工作要做，如何取舍：
实际上，我们需要数年时间才能获得以太坊共识的有效性证明。这与我们实现单槽终局性、Orbit、修改签名算法以及安全分析所需的时间大致相同，而安全分析需要足够的信心才能使用像Poseidon这样「激进」的哈希函数。因此，最明智的做法是解决这些其他问题，并在解决这些问题的同时考虑到STARK的友好性。
主要的权衡很可能是在操作顺序上，在改革以太坊共识层的更渐进的方法和更激进的「一次改变许多」的方法之间。对于EVM来说，渐进式方法是合理的，因为它能最大限度地减少对向后兼容性的干扰。对共识层来说，向后兼容性的影响较小，而且对信标链构建方式的各种细节进行更「全面」的重新思考，以最佳方式优化SNARK友好性也有好处。
它与路线图的其他部分如何互动？
在对以太坊PoS进行长期重新设计时，STARK友好性必须成为首要考虑因素，尤其是单槽终局性、Orbit、签名方案变更和签名聚合。
