Vitalik Buterin 相信，拥有多个客户端可以降低一次实施中出现单个灾难性错误的风险，从而提高网络的安全性和去中心化程度，而这种错误可能会导致整个以太坊网络崩溃。此外，多客户理念也有助于防止权力集中在一个开发团队或组织内，继而更好地实现网络去中心化。

针对上述提及的 ZK-EVm 多客户端问题，Vitalik Buterin 提出了三种可能的解决方案：

1、单一的 ZK-EVM：放弃多客户端范式，选择用来验证区块的单一 ZK-EVM。

2、封闭的多个 ZK-EVM：就一组特定的多个 ZK-EVM 达成一致并达成共识，并有一个共识层协议规则，即一个区块需要来自该集合中超过一半的 ZK-EVM 的证明才能被认为是有效的.

3、开放的多个 ZK-EVM：不同的客户端有不同的 ZK-EVM 实现，每个客户端在接受一个区块为有效之前等待与自己的实现兼容的证明。」

在 ZK-EVM 的背景下，Vitalik Buterin 支持第三种，也就是开放的多个客户端 ZK-EVM 生态系统的解决方案，他认为不同的客户端有不同的 ZK-EVM 实现，每个客户端在接受一个区块为有效之前等待与自己兼容的证明。

「对我来说，第三种解决方案似乎是理想的，至少直到并且除非我们的技术改进到可以正式证明所有 ZK-EVM 实现彼此等效的程度......」

不仅如此，一旦技术改进到 ZK-EVM 实现有些标准化的程度，Vitalik Buterin 认为解决方案将是选择最有效的选项，而他还觉得「第三种解决方案的挑战似乎小于其他两个选项的挑战，至少目前如此。」不过，Vitalik Buterin 提出开放的多个 ZK-EVM 可能会面临两大挑战：

**延迟挑战：**恶意攻击者可能会延迟发布一个区块，以及对一个客户端有效的证明。生成对其他客户端有效的证明实际上需要很长时间（即使例如 15 秒）。这段时间足够长，可能会创建一个临时分叉并中断几个插槽的链。

**数据效率低下：**ZK-SNARKs 的一个好处是可以从区块中删除仅与验证相关的数据（有时称为「见证数据」）。例如，一旦你验证了一个签名，就不需要将签名保存在一个区块中，你可以只存储一个表示签名有效的位，以及区块中确认所有签名的单个证明。但是，如果希望能够为一个区块生成多种类型的证明，则需要实际发布原始签名。