大多数二层扩展解决方案都带有一些不太理想的假设,而SDNARKs可以提供技术援助，但它们仍存在其他问题。V神认为他有办法绕过这些问题。

  大多数二层扩展解决方案都带有一些不太理想的假设,而SNARKs可以提供技术援助，但它们仍存在其他问题。V神认为他有办法绕过这些问题。

  上周，以太坊核心开发者Afri Schoedon提出，以太坊目前处于超负荷运作状态，Dapp开发者应该在其他链上搭建去中心化应用。V神对此表示不同意。他认为，大部分的Dapps并不是针对Gas进行优化的，而且行业竞争将会推动次优Dapps。同时，他也强调，二层解决方案（layer 2）的重要性和可观前景，并在Ethresear.ch论坛上发布了一个可能的解决方案以支持他的论点——使用SNARK技术解决二层扩展方案中的问题。

  他的方案试图解决目前二层解决方案面临的一些重大挑战。

  以太坊上绝大部分的二层解决方案都带有活跃度假设，而这就是V神试图通过SNARKs技术解决的第一个问题。

  可能会有人问道：“又要说这个吗？”

  活跃度，在一个去中心化的系统中，例如区块链，指最终共识的确定性。换句话说，如果区块链网络中的所有节点最终达成共识，那么，你可以说，你已经保证了活跃度。以以太坊为例。如果有两个或者以上的块是在几乎相同的时间内创建的，该怎么办？那必须有一种方法来决定哪个块是“真正的”块。（是有的）。如果没有，那么活跃度将无法得到保证。既定的工作量证明PoW（全称为Proof-of-Work）共识机制可以合理地保证活跃度。

  然而，二层解决方案（例如状态通道state channels和plasma）具有不同的共识机制，并且现有的保证活跃度的架构因为依赖交易方同时在线参与而无法维持。问题的根源在于共识机制，这些机制通常是各不相同的，但一般都是权威证明（PoA，全称为Proof-of-Authority）或者是实用拜占庭容错算法(PBFT，全称为practical Byzantine FaultTolerance)的某些变体，这些算法通常要求交易方在不同的交易时段监督不良行为甚至是停止交易。由此可见，这些达成共识的策略并不能兼顾活跃度。

  在9月22号星期六，V神在ethresear.ch论坛上表示潜在的链上扩展方案可以实现每秒完成500笔交易的速度。该概念是利用zk-SNARKs技术来实现块有效性的确定性。 zk-SNARKs中文名称为“零知识下简明的非交互知识论证”（全称是Zero-KnowledgeSuccinct Non-Interactive Argument of Knowledge）。这里的“零知识”是指，你不必向人们揭示某物的价值或者他们如何知道它的价值的情况下，证明其价值真实性的方式。“简明”意味着证明的部分非常短—最多只需要几百字节。

  这并不是第一次有人提议利用SNARKS解决第二层扩展方案中的问题。就在上周，ETHNews报道了一个项目，该项目旨在创建一个使用SNARK技术验证的plasma链，这也不是首个使用SNARK技术的项目。但是V神的解决方案并不是对现有项目的机械性重复。在他的框架下，必须有两种类型的用户：交易者和中继者（relayers）。交易者就是相互交易的个人或是实体。而中继者负责接收所有的事务信息，把这些信息记录下来，然后把它们发到主链上进行挖矿。在这样的架构下，中继者会接收所有的信息，接着把他们组合起来同时创建一个zk-SNARK。然后，中继者提交这个zk-SNARK到主链上挖矿。在zk-SNARK技术的监管下，中继者不可能耍欺诈伎俩，这意味着交易方无需经常在线监督是否有欺诈行为。

  这个基础框架并非新增的；上面提到的zk-SNARK plasma 链也有交易者和中继者。但是它们的具体情况有些不同。

  例如，很明显的是，它克服了SNARKs中的一个重大阻力。在SNARKS技术下，不可能对交易索赔的真实性作假，但有可能会遗漏必要的数据。这被称为“数据可用性问题”。例如，通过SNARK验证的plasma链，运营商（在V神的框架中类似于中继者的角色）将SNARK验证的块提交给主链。但是，这些块可能缺少EDCC（即智能合约）与块交互所必需的信息。 V神表示，这种机制可以避免这种困扰，“因为更新Merkle tree（默克尔树，通常也被称作Hash Tree，顾名思义，就是存储hash值的一棵树。）所需的所有数据都是在链上进行的。

  总的来说，V神的方案比一些典型的plasma解决方案要好，因为它并不需要交易方实时在线；并且它也优于现有的SNARK-plasma解决方案，因为它不会面临数据可用性问题。

  尽然，目前这个方案并不完美。当然，它也不可能会完美。方案所面临的重大挑战之一是减少证明时间。很多人认为，生成proof（证明）所耗的时间太长了。V神对此表示认同，但他对此持乐观态度，他觉得这个问题很快就会得到解决。在它悬而未解期间，这个方案仍然是一个可行的机制：

  现在大家都明白的一点是，优化SNARK / STARK provers非常重要，因此我相信随着时间的推移会有越来越多的软件工程工作。

  我赞同大家的观点，proof的生成速度应该要足够快，区块的确认共识达成的周期较长可能会是一个限制因素！尽管proof生成时间是一个阻力点，但是整个链通过ZK-SNARKs进行批量交易验证，仍然可以达到每秒完成500笔交易的速度。