区块链:望梅止渴的以太坊分片(Sharding)_nft币未来价格会不会到一美元

不久前Vitalik发了一篇题为《为什么分片棒棒哒:揭开技术属性的神秘面纱》的文章,从技术上深入浅出地讲解了以太坊分片提供的特定属性和付出的牺牲。

文中提到:“分片是以太坊可扩展性的未来,它将是帮助生态系统每秒支持数千笔交易并允许世界上大部分地区以可承受的成本定期使用该平台的关键。”文章是好文章,特别是通过定义以太坊分片的特定属性,与“流氓分片”划清了界限。虽然烤仔非常佩服V神画大饼的实力,也认同安全可靠的分片技术是未来区块链技术必然的发展方向,但是对于文中的若干错误仍然觉得不吐不快。文章的核心逻辑是V神认为通过“简单”技术无法同时让区块链获得可扩展性、去中心化、安全性三个属性,即所谓的“不可能三角”,而分片技术可以同时解决这些问题,所以“分片棒棒哒”。这个逻辑初看似乎有点道理,但是仔细想想却似是而非,主要有三个漏洞:“简单”技术、“不可能三角”、分片的必要性。

首先是关于“简单”技术无法同时获得三个属性的论断。文中没有定义到底什么样的技术能称为“简单”,实际讨论时偷换概念成了三种“容易的解决方案”:包括比特币以太坊在内的传统单链,由少数节点维护的高吞吐量区块链,以及多链生态系统。

这个论断的逻辑问题在于,“简单”不等于“容易”,偷换概念后的举例论证也因为没有穷尽所有可能性而更像是在挑软柿子捏。类似的逻辑烤仔之前曾经在一个笑话中见到过——“如何证明所有奇数都是素数?我们来看一下:3是素数,5是素数,7也是素数,证完了。”其中第二种方案吞吐量高的区块链,在V神的概念里似乎和节点数量少画上了等号,犯了循环论证的错误。总之,这里的论述肯定是没有考虑Conflux这样可以在几千个共识节点上实现几千TPS吞吐量的方案。或许V神在这里对于“简单”的定义可以直接按照效果划一条线,凡是能解决“不可能三角”的统统归为“不简单”技术,这样方可确保逻辑严谨立于不败之地。其次,所谓的“不可能三角”也是一个由来已久的错误概念。虽然常被拿来和分布式系统的CAP定理相提并论,但是实际上“区块链不可能三角”从来没有任何理论上的证明,最多只能算是一个“假说”或者“猜想”。这种把“自己做不到”等同于“不可能”的逻辑,颇有一种便秘了埋怨地球没有吸引力的即视感。好在V神似乎也意识到再提“不可能三角”以太坊分片的优点就说不通了,所以在这篇文章里偷偷加上了一个前提——“如果你坚持使用简单技术,那么将无法同时获得三种属性”。不知道啥时候能正式把“区块链不可能三角”的说法正式改为“区块链简单技术暂时做不到三角”以正视听,同时建议加一行小字“‘简单技术’指不能同时获得这三种属性的区块链技术”。最后,这篇文章也不足以支持分片技术的必要性和迫切性。分片固然可以打破“不可能三角”,解决以太坊面临的性能问题。但这只是一个充分性的条件,不能说明为什么一定要采用分片技术,甚至不能说明为什么一定要打破“不可能三角”。在“不可能三角”的描述中,可扩展性的要求是整个区块链共识系统的处理能力超过普通消费级PC或笔记本电脑作为单个节点的处理能力。从长远来看这个目标终归是要实现的,但是从目前以太坊的实际情况来看,这个目标属于好高骛远。以现在的电脑性能,单机足以每秒处理几千甚至上万笔交易,而以太坊只能处理不超过50笔,还远远没有达到瓶颈。基于以太坊现在的性能搞分片,就像是一个小学数学还没学明白的孩子非要学高等数学一样,事倍功半不说,将来还免不了从头再来一遍。

所以,即便分片可以解决以太坊面临的问题,也不意味着必须用分片来解决。与最初提出以太坊分片的概念时相比,如今已经有了包括Conflux等高性能共识算法和Rollup等第二层扩展方案在内的很多现成的解决方案。再抱残守缺地坚持做分片就有点一条道走到黑的意思了。

除了核心逻辑存有漏洞之外,分片本身在安全性、可靠性和性能方面的牺牲也是非常明显的,V神在文中已经说得比较详细,此处不再赘述。这里只纠正一点:分片必然降低用户体验,增加确认用户等待时间的问题无可避免,并非只存在于采用欺诈证明的方案。尽管ZK-SNARK等证明技术可以大幅提升交易的验证效率,确保交易上链后能被快速确认,但此类技术无一例外需要较长的时间用于生成证明。因此,从用户的视角来看,采用ZK-SNARK技术减少交易上链后等待时间的代价是增加了上链前等待生成证明的时间,总的体验未必有多少改善。寄希望于靠ZK-SNARK解决分片带来的延迟问题的人,应该再去复习一下朝三暮四的故事。综上所述,烤仔认为以太坊的分片技术就如同望梅止渴故事里的梅子,可以鼓舞人心但是没有多少实际意义。如果一直心心念念远方的梅子,而对身边的溪流视而不见,恐怕只会渴死在路上。

END

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

大币网

[0:15ms0-6:489ms