专栏首页Fractal 区块链Fractal CTO 范磊:PoS 能不能实现真正去中心化?
原创

Fractal CTO 范磊:PoS 能不能实现真正去中心化?

2019年9月6日,Fractal Platform CTO 范磊在Fractal社区,进行了主题为《PoS能不能实现真正去中心化?》的在线直播。文章比较长,约5000字,但都是硬核干货,希望大家能看到最后。

以下是部分直播内容整理: 大家好,这是我们第一次在比较公开的环境下进行分享,今天会从六个方面来讲,主要围绕区块链的一些基本原理设计、Fractal之前做的工作,以及我们对行业的一些看法。

为什么使用PoS共识算法

我们先讨论有关PoS集中化的话题,这可以从两个角度去理解,一是技术造成的集中化,当共识协议无法容纳大量节点时,开发者迫于无奈将节点数缩减到很少,这就产生了集中化现象,这块具体内容我们在后面PoS协议分析的时候会讲到。 另一个是经济模型造成的集中化,PoS 系统的收益与持有的stake数量相关,这会造成stake持有量大的人会有更多的stake,而持有量少的人无法参与挖矿。这种担心是非常合理的,不过即便是在最开放、最公平的系统中,财富的集中化在整个人类社会中也是不可避免的。 那么在经济系统中产生了集中化后,我们看看PoS会不会带来一些负面影响?人类社会发展了这么多年,虽然产生了很多资本家和金融大鳄,但是并没有影响社会稳定,因此可以说明这个事不可怕。我们只要能保证财富的正常流通,以及再分配的机制就可以了。有人认为它有投资价值,自然会相对高价的购买stake,反之则会被抛售,在这之间自然会形成一个动态平衡,所以我们认为只要有一个正常的流通机制,那么PoS的经济集中化不是问题。 如果不用担心这个问题的话,其实PoS成为大多数公链的选择有一定的必然性,因为它的优点是显而易见的。除了节能之外,尤其对于新公链来说,PoS系统会更加友好。 PoW是完全开放的,其算力也是标准化的,那么对于恶意攻击者来说,会较容易搜集到足够多的算力来对新公链发动攻击。在PoS系统中算力跟stake相关, 如果要发动攻击,你唯一能做的就是从二级市场去获取,这个操作自然会推高stake的价格,那么一方面就保护已有投资者的利益,另一方面也提高了攻击者的成本。所以对于新公链来说,被恶意攻击的概率会更低一点。 所以我们采用了PoS共识算法,我们这个项目本身学术背景非常浓,我们从16年就考虑设计纯的PoS共识算法,直到17年,算法就大概成型了,所以我们也自然地把PoS作为我们努力的方向。但是PoS的设计是非常困难的,我们看到市面上有大量雷同的设计,我后面也会详细讲。

PoS共识协议设计难点

其实PoW的成功是有一定代价的,即能源消耗,但其带来的好处是限制了攻击者的能力。在这种分布式系统里面,我们想要得到一个有序的结果,有两个需要面临的挑战,第一,谁是合法的参与者?在早期的分布式系统里是靠设备注册,如果没有注册过程,谁都可以进去,那么坏人就可能占大多数。 也就是形成了所谓的女巫攻击(sybil attack),二是发言的无序性。如果用户在系统中发很多垃圾信息,会导致实现共识非常困难。而PoW巧妙地运用了硬件资源的限制,解决了这两个攻击的问题。 在PoS系统中,即便没有硬件资源的约束,但stake相当于用户的准入门槛,所以女巫攻击的问题我们不用担心。我们将关注点放在第二个问题上,如何排除噪音最终形成确定性的大家一致认可的结果?这里面有个很重要的概念,也是是密码学或分布式算法中研究了很多年的协议,我们叫交互式协议。交互式协议的过程就是把坏人筛除掉,最终形成一个结果,目前类PoS的协议基本上都是使用这种交互式协议来完成的。 但交互式协议有个问题,如果要达成一个结果,需要网络上很多人参与交互,并且是多轮交互,这时候交互的过程非常耗时,即便带宽很大都不行,因为网络会有延迟,延迟和带宽是两个概念,所以交互式协议通常延迟比较大,网络性能不好。尤其是参与者增多之后,网络的延迟或整个的协议复杂性,不是呈线性变化的,它至少是平方或者更高次方的变化。那么在这种情况下,PoS的设计就变得十分困难。 我们必须要找到一个新的设计方法或者思路。在找到新思路前,我们来看看古典的算法是怎么做的?

PoS发展史

PoS共识协议可能近两年大家听到的会比较多,但其实它的相关技术发展大概已有30多年了。比较广泛的是PBFT或者BFT这个名词,就是拜占庭类协议。这里有个学术研究的图,总结了BFT类协议的发展历程。

在80年代就开始有Dolve-Strong等人设计的一些协议,最上面一行的第二个圆圈中的Katz,就是Fractal的首席科学家Jonathan Katz,他在在早期的拜占庭协议里做了非常多的贡献,可以说是教科书级的人物。

我们重点看图中最下面一行的右边三块,其中PBFT是两个分布式计算的学者在约20年前左右提出的,它改进了传统的BFT,使得算法的复杂度降低了。但PBFT类协议是存在效率问题的,另外,它对网络延迟条件的假设也非常高。PBFT协议非常适合用在分布式系统里面,如果我们从区块链的角度看,它更适合私有链或者联盟链,如果我们硬要把它搬到公有链上,这是勉为其难的。所以,我们现在看到的大多是折中方案,比如只限定几十或一百的节点来参加共识,这也是为什么我们会认为PoS系统有非常强的中心化趋势。之后我们也会讨论PoS中心化的趋势是不是一定会存在?

为了改善上述存在的问题,尤其是降低通讯的复杂度,近年来还出现了SBFT,它的想法很简单,就是采用聚合签名算法。有了聚合签名之后,节点再发签名,只需要发给一个leader或者叫collector,他把签名聚合到一起后再发给其他人。从总量上来说,这确实降低了通讯的复杂度,但这种设计把压力都给了leader这个节点,如果这个节点坏了,整个系统就坏了,所以SBFT的中心化趋势更加严重,它是一个有限的改进。

今年出现的项目Libra采用的是Hotstuff算法,Hotstuff是SBFT上更进一步的优化,其主要对上述所说的当leader节点变坏之后的问题做出了改进。其做法在每一轮中更换leader,把共识和更换leader的过程合二为一,这里面也存在代价,就是每一轮都依赖于时间同步,否则工作不能继续,且集中化的趋势并没有降低。

除了BFT类协议之外,在PoS中还有更直接的共识协议,比如Algorand 。Algorand 用到的是另一种解决争议的交互式协议BA*,其扩展性本质上与PBFT类似。所以整体来讲,目前大多数PoS协议都有这些特征。

我们不想在类BFT协议上继续做小幅度的改进,包括Libra也在白皮书中明确说了,在当前基于Hotstuff的这个项目中,做的是许可链(Permissioned Blockchain),但Libra最终还是会向非许可链的方向发展,不需要许可,谁都可以参加,这样是我们的共识协议所支持的方向。

Fractal设计的新型PoS共识协议——iChing

iChing 是易经的音译,这个协议最初的版本在2017年就有了,后面一直在做一些改进。回到PoS协议设计的初衷,我们发现会面临两个问题,一个是准入机制,这个由stake来决定,另一个是当发生不同意见是,如何裁决? 在去掉交互式协议后,我们会面临PoS中的Nothing at stake攻击。因为持有stake就能挖矿,且不会浪费任何资源,大家会在多个地方进行挖矿,那么必然会产生大量分叉。很显然,分叉就会影响共识,我们现在来讲讲怎样不通过交互式协议去达成共识。 大家看下面这张图片,这是我们最核心的算法构造,这个哈希不等式将PoW的算力竞争转化为了PoS的stake的竞争。即便有了这个公式,系统中还是会出现很多分叉。但我们通过严格的数学分析,证明了这个分叉并不可怕,有兴趣的朋友可以点击查看这篇论文,里面会有详细的分析。我们得出的结论是,如果坏人尝试在所有的地方挖矿,那么他挖出的链会以2.7倍的速度往前涨,显然这时系统不能容忍的49%的坏人和51%的好人,因为49*2.7倍则会超过好人。 针对这个问题,我们有个greedy策略,也是iChing协议设计中最精妙的地方。我们鼓励好人也在分叉的地方挖矿,即时不是链最长的地方,从下图中可以看到,有1greedy,2 greedy或full greedy几种策略,当然,对好人来说不会用full greedy,坏人有可能在所有地方尝试。

我们鼓励好人做2或3 greedy,得到的结果是好人能让诚实链的增长速度达到原来的2.2倍左右,以此来抵抗坏人的链的增长速度,也就是说Nothing at stake攻击带来的影响并不可怕。我们通过鼓励好人使用greedy策略,来抵消坏人的优势,这样我们就不需要使用交互式协议来排除分叉。 所以基于以上分析,在我们的iChing协议中,所有的矿工只需要像Bitcoin一样,找最长的链产生区块然后发出去,当然,我们除了最长的还有次长的等等,这按照算法要求来做就可以了。iChing可以支持类似Bitcoin这种规模的参与者,我们不要时间同步的假设,也不需要交互式协议。所以说iChing的系统可扩展性,或者说是去中心化特性跟Bitcoin是一样的。

基于iChing共识的公链Fractal Platform

基于上述研究结果,我们在18年上半年开始,筹划做一个全新的公链系统——Fractal Platform,为什么叫Fractal?刚刚讲到我们的链会有很多分叉,Fractal就是分叉的意思。 我下面讲一下,基于iChing我们所做的Fractal公链。iChing本质上只是一个共识协议,如果我们把它当做支持未来区块链落地应用的架构来说,那么还有很多问题要解决。我们解决了PoS去中心化共识问题,还要提高性能或者说吞吐率。这涉及到Fractal另一个重要的技术点。 我们经过严谨的计算分析,得出了区块链系统性能的瓶颈在哪,一个是共识,比如说交互式的共识,它本身就会把网络卡住;另外一个瓶颈就是网络层,现在所谓的1万甚至10万TPS的项目,远远不是我们家用或普通商用的网络带宽能承受的,并且在区块链系统中还有额外的开销,就是交易数据。交易数据通常是小包,大其在网络中传输的效率很低。 举个栗子, 比如船运货,如果货物都是散装的,各种各样的货物,它的运输效率会很低,而现在海运为了提高效率,会采用集装箱的方式。我们在网络层(Layer 0)上有一个创新的优化,叫作Backpacker。它的机制就是把小包通过packer打成一个标准的集装箱,这样我们就可以有效的提高网络对于小包的处理的能力。我们这里数据的集装箱,也就是 packer打出来的小包叫作 pseudo-block,然后将其传给所有的共识节点。这里利用了PoS一个天然的好处,就是将区块打包放在共识区块之后,节点产生共识块后,我们再把pseudo-block组成新的真正交易区块。但这时候真正的交易区块已经不用传了,因为pseudo-block已经传遍全网了,我们只要传输很小的meta-block,也就是这个block头部就可以了。 所以Fractal会提供一个非常平稳的网络流量,使得带宽利用率很高,因为既没有小交易数据包的消耗,又没有大共识块的冲击,所以整个网络的性能优化非常好。 Fractal基于iChing和Backpacker这两点创新,就可以在跨大洋跨洲的真实网络环境下,实现超过3000TPS的完全分布式的去中心化PoS系统。

Fractal当前开发进展及未来规划

Fractal经过一年的开发,我刚才讲的所有的特点和协议都已经完全实现,从核心网络共识、钱包接口、智能合约已经DApp的demo,也已经全部具备。我们的共识节点已经在跑了,目前主要节点部署在亚马逊上,当然我们也尝试过在阿里云等其他多种不同的云上同时部署节点。 下面是我们配套的区块链浏览器总览图,包括block数量、时间数量,当前的TPS等等,这是我们跑的一个小的背景流量,大概一二百TPS。我们在压力测试的时候,会做到一两千甚至三千的TPS。

下图是block的交易信息,大家可以看到里面的区块信息、交易信息以及地址信息等等,按地址查询余额、交易等等区块链浏览器应该具有的功能,我们也都已经开发完成。

下面的界面是有关钱包的,大家可以看到,这是一个全功能钱包,从发交易到部署智能合约、调用智能合约以及等待交易确认等等功能都已实现。

我们的钱包目前是以chrome插件的形式来提供的,因为它可以很自然的和DApp的开发结合在一起。同时,我们也做了一个DApp的demo,从下图可以看到这是一个掷骰子的游戏。我们通过智能合约以及钱包接口,来实现了在浏览器中DApp开发。

这个DApp的特点是接受交易双方的随机数输入来实现绝对的公平,整个的过程是完全开源的,不是依赖于单独一方产生随机数,右上角的彩色小点都是鼠标移动的时候产生的随机数种子。 所以大家可以看到Fractal目前的完成度是非常高的,也非常欢迎对这个项目有兴趣的各路英雄,以各种形式来参加我们的项目。我下面就稍微说一下Fractal未来的规划。当然,一方面是完善目前的系统,我们还有非常多的细节需要去改进优化。另一方面,也是跟社区关联最大的,就是如何来参与这个系统。 我们将Fractal定位成一个基础的功能平台,希望上面会承载不同的应用,我们也会做一些技术上的储备和支持来使得它真正成为一个生态系统。比如内置的去中心化兑换机制,大家在上面做应用可以发行自己的token,发行后,开发者不需要去考虑用交易所来兑换,我们内置的机制就可以跟其它主流数字货币进行兑换,这样一来就保证生态开发者的利益,平台是不会侵犯和抢占这部分利益的。另外,像随机数的产生,以及链下信息上链的oracle(预言机)机制等,我们都会提供内生的支持,所以也非常欢迎大家来参与Fractal整个生态的建设。 以上就是我今天的分享,谢谢大家。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 一文读懂Fractal共识协议:iChing之精妙

    在过去的十年里,PoW 共识协议一直安全地支撑着区块链系统稳定运行,而其存在的能源浪费和算力集中的问题也显而易见,因此,Fractal 在 2017 年设计之初...

    Fractal
  • 【Fractal】Layer0 加速协议BackPackers:突破公有链吞吐效率瓶颈

    BackPackers引入了一种新的网络模式来解决网络层(layer 0)的一些低效率问题,包括交易广播瓶颈、源广播瓶颈和P2P网络中节点间的负载不均衡。

    Fractal
  • ETH2.0 都要来了你还不知道 Casper 吗?(二)

    在上篇文章中,我们介绍了Vitalik原始论文中的Casper FFG,其借助PoS对PoW产生的区块进行确认来提高系统的安全性,但这只是一种过渡的方案,在以太...

    Fractal
  • iOS性能优化系列篇之“列表流畅度优化”

    这一篇文章是iOS性能优化系列文章的的第二篇,主要内容是关于列表流畅度的优化。在具体内容的阐述过程中会结合性能优化的总体原则进行阐述,所以建议大家在阅读这篇文章...

    iOSSir
  • PHP验证手机号码和归属地 PHP函数代码

    一个实用的PHP函数代码,正则表达式验证手机号码的正确性和查询手机号码归属地,下面来看这个函数的具体代码: <?php // 手机号码验证 function c...

    joshua317
  • 妈妈再也不用担心我没有壁纸啦!

    近期准备参加一个隐写分析的比赛,unsplash是比赛训练数据集来源之一。Unsplash 是一个完全免费的、无版权的高清图片资源网站,里面的图片也是各式各样,...

    老肥码码码
  • 机器之心论文解读:可用于十亿级实时检索的循环二分嵌入模型(RBE)

    论文链接:https://arxiv.org/pdf/1802.06466.pdf

    机器之心
  • python将红色玫瑰转化为蓝色妖姬

    步骤: 1.将图片进行导入 2.将图片使用numpy包变成矩阵格式 3.遍历numpy中的像素点,对红色的像素点进行处理,变成蓝色 4.将处理完的矩阵变...

    崔笑颜
  • Python学习笔记(一)

    张树臣
  • K 近邻法(K-Nearest Neighbor, K-NN)

    树相当于不断地用垂直于坐标轴的超平面将 k 维空间切分,构成一系列的k维超矩形区域。

    Michael阿明

扫码关注云+社区

领取腾讯云代金券