Title: 区块链共识的确定性设计: 确定性的原理与PoW共识中的确定性设计 Post by: YeeToken on June 04, 2019, 12:34:35 PM 区块链共识的确定性设计 [/b]随着区块链技术的发展,特别是低延迟链,跨链等新技术的不断探索,确定性(Finality)越来越多的被讨论和研究。在开始本文的讨论之前,我们先理解下什么是确定性。 确定性字面意思是不可改变性,是比“去中心化”,“共识”更古老的概念。 从有账本开始,就可以探讨和定义其确定性,而此确定性不面临任何技术问题,因为那个时候的账本都是中心化的(有信任中介),确定性和正确性一样,都是信任中介意志的反映。 而只有在区块链技术引入了去中心化账本之后,共识和确定性才成为一个技术问题,我们可能面临确定性和共识无法同时达到的情况。 不同共识算法的确定性 [/b]根据目前的研究,大家对各类不同共识算法的确定性有了评估。 比如PoW不具有绝对确定性(Absolute Finality),只具有概率确定性(Probabilistic Finality),BFT具有绝对确定性,Casper FFG具有绝对确定性,YeeCo团队的Tetris共识具有绝对确定性。 为什么不同共识算法的确定性水平不同,是什么内在特性起作用呢? 确定性的原理 [/b]共识的本质是什么?共识是想要达成一致性(Consistency)的人达成一致性的过程,共识算法保证了想要达成一致性的人在有通信障碍或有人从中误导的情况下仍然可以达到一致性。 这里面有一个很好玩的点,有点文字游戏的意思,那就是“想要达成一致性的人”在某种共识机制中是作为前提条件出现的(先确定哪些人想达成一致,再寻求一致),而在某种其他共识机制中是作为共识结果出现的(达到一致但也注明范围,永远不承诺是所有人的共识) 举个例子,假设要为全公司组织一次聚餐,需要就去哪吃饭达成共识,第一种做法的思路是这事是公司“说的算的人”才能决定的,把这些人选定,投票,形成共识;第二种做法的思路是,公司水有多深,咱也不知道,咱也不敢问,到底是老板说的算,还是老板的小秘说的算,还是扫地僧说的算,姑且先形成一个不成熟的共识,然后公示出来,坐等有更大权力的人出来纠正,如果公示期足够长,就相信最终能达成一致,形成共识。 目前两种做法都算是达成了共识,但是他们在确定性上的表现如何呢?第一种做法的共识已经是公司“说的算的人”的决定,当时要么达成了一致,那就可以不修改了,要么就没达不成一致,悬而未决,总之不会出现先公布一个结果又修改的情况;第二种做法的共识是不断被纠正的,越往后被纠正的成本越高,概率越低,但理论上仍然可能被修改。 上述例子其实描述了BFT共识和PoW共识的不同,换成技术的语言说就是:BFT共识先假定一个稳定的共识范围,在此基础上选择一种强一致性但是低活性(Liveness)的机制,强一致性可以实现绝对确定性;PoW共识不假定稳定的共识范围,认为共识参与者可以随时进出,在此基础上只能采取一种高活性但是只具有最终一致性的机制,而最终一致性不能实现绝对确定性,只能实现概率确定性。 所以,决定确定性的本质特性是共识范围,这也符合大众的直觉观念,所谓共识范围就是“谁说的算”,“谁说的算”确定,你就会相信结果不会被修改,“谁说的算”不确定,你就不会相信结果不会被修改,这也就是大家口中说的:生意要跟“说的算的人”谈。 绝对确定性的必要性 因为区块链上的交易往往对应链下世界的权属转移(比如支付,充值等等),交易可被修改对这些经济活动的破坏是致命的,双花攻击实质就是利用了PoW不具有绝对确定性。 和链关联的应用在实践中还是基于某种确定性的标准在工作,比如大家熟知的比特币6个确认,以太坊12个确认。但这个确定性标准并不完整,大家可以回忆当发生分叉,算力战,攻击等情况下,钱包和交易所都会主动暂停交易,相当于这些应用评估PoW的确定性在这些特殊情况下减弱了,于是主动把n-confirm的标准调整到无穷大个确认。 跨链和多链分片也是和链关联的应用的一种表现形式,只不过链之间互为应用,他们对确定性的要求比链下应用更高,体现在两点: 区块链是一套按既定程序运行的系统,并不能像链下应用那样通过评估主动修改n-confirm的标准。 双花攻击中,链下应用很难找到足够大的交易物,收益不足而成本很高,双花实际很难被采用,但是跨链时链上很容易找到足够大的交易物,收益提升,双花变得有利可图。 所以,一方面从支撑应用的角度,链应该提供负责任的确定性,而不是把评估确定性的工作推给应用,另一方面从支持跨链的角度,确定性是其安全性的基石。 实现绝对确定性是必要的。 绝对确定性下共识参与者的博弈 [/b]单看共识的一致性,如果共识参与者还能做到认同“谁说了算”(BFT里是投票人集合,PoW里是算力),那么若共识结果符合自己的意愿,则皆大欢喜,若共识结果不符合自己的意愿也会选择“服从”;如果共识参与者已经不认同“谁说了算”了,则会选择硬分叉。 当引入了绝对确定性后,我们看一下对于强一致性共识和最终一致性共识分别意味着什么。 对于BFT这种强一致性共识,强一致性和绝对确定性是一体的,共识本身没有重铸链的情况,发生重铸链都是因为被干预,如果是部分投票人通过硬分叉分裂了链,老的链上的块的确定性仍然是得到保证的,只不过新分叉出一条链,这条新链只要有用户,这些用户也是认可这条新链上的块的确定性的; 如果是投票人集合合谋通过硬分叉重铸链,之前的链被废弃了,看起来依赖之前链的应用受到了区块被修改的影响,实际这种影响是因为老链死亡,而不是因为老链上的区块的确定性被破坏。 对于PoW这种最终一致性共识,链的可被重铸性是为了支持不稳定的共识范围而保留的,如果引入了绝对确定性,按前面的论述一定是额外引入了稳定的共识范围,那为了保证一个块的确定性,PoW的运行方式就不能仅仅是最长链原则,而只能是“包含被确定的块的最长链”原则,即大算力即使具备重铸链的能力,也要“服从”那个建立了确定性的稳定共识范围,而如果大算力不愿意服从,则只能发起硬分叉,老的链上的块的确定性仍然是得到保证的。大算力服从的意愿与“额外引入的稳定的共识范围”的权威性有关,如果不够权威,则大算力不服从的可能性就很大,应用是跟着确定性的共识范围走还是跟着大算力走就成了一个很复杂的情况了。 通过上诉的场景分析,我们可以理解到绝对确定性是不收敛的,是一致性的两个极端,一个极端是达成一致且不修改,一个极端是达不成一致就分裂成两个都不修改的部分,应用要在两个部分中做出选择,选择哪部分就认可哪部分的确定性。 既然有两个极端情况,我们设计确定性机制的时候,就要尽量让博弈结果能够均衡到不分裂的那种结果,后面会讨论PoW共识中确定性的设计。 总结来看,从应用的视角,绝对确定性的价值在于把区块可被改变的风险转化成了区块链分叉的风险,这种转变反过来又影响共识参与人的博弈行为,如果这种影响又进一步降低了分叉的可能性,则是一个成功的确定性机制,对应用来说是非常有价值的。 PoW共识中的确定性设计 [/b]经典的PoW共识坚持不稳定的共识范围这一设定,坚持最长链原则,保留了大算力进来重铸链而达到新的一致性的可能,如果我们仍然坚持这些,理论上是无法建立绝对确定性的,我们的设计上应该选择合理的突破这些限制。 PoW的绝对确定性机制应该包含下列要点: 稳定共识范围的建立 如前文所述,绝对最终确定性的本质要求是需要一个稳定共识范围,那如何引入,是直接改造PoW里那个不稳定共识范围,合二为一,还是额外引入一个新的,二者并列运行? 稳定共识范围对PoW的去中心化特性的影响有多大,会不会太削弱算力的权力,从而让这种PoW实际退化成一个投票机制? 确定性建立的时机 我们是要和一致性同时建立,还是可以分开?如果分开,确定性要延迟多久?理论上延迟要越小,就越需要那个建立一致性的不稳定共识范围(算力)服从于那个建立确定性的稳定共识范围,如何权衡? 稳定性共识范围如何做到激励相容 稳定性共识范围是某种机制选出来的,比如Staking,如果说对确定性进行投票决定了链的走向的话,投票人可以选择两边都投而没有任何损失,这就是无利害攻击(Nothing at stake),如何通过激励机制避免这种问题? 失败治理机制 确定性的建立,是通过牺牲活性换取了强一致性,那么就一定会遇到确定性的共识达不成的情况,这种情况好处是正好对外体现出了负责任的一面,达不成确定性,被确定的块的高度就不再增长了,链下活动也可以据此暂停,坏处是需要一套治理机制解决共识失败的情况。 对多链分片的支持 链外应用需要安全的获取的确定性信息,常规的方式是运行全节点,同步确定性共识结果并做验证,对于多链分片这种场景,每个分片一般是运行当前分片的全节点,运行其他所有分片的轻节点,这就涉及到一个问题,能否实现一个轻节点能安全的同步确定性共识结果,这是实现多链分片的一个重要问题。 另外,如果一个分片的链发生了分叉,如何让其他分片统一识别哪个是原有链,哪个是分叉链,并保证统一只跟其中一个链交互。 YeeCo的CRFG(Conditional Reward Finality Gadgets)提出了一套在PoW共识上建立绝对确定性的方案,后续的文章会做出详细介绍。 以上为YeeCo开发者的思考,不知大家有何见解,欢迎参与讨论。 Title: Re: 区块链共识的确定性设计: 确定性的原理与PoW共识中的确定性设计 Post by: YeeToken on June 05, 2019, 02:37:17 AM 原文链接:https://github.com/guoxbin/articles/blob/master/design_of_finality_in_blockchain_consensus.md
了解YeeCo公链的最新进展: https://github.com/yeeco/gyee |