aschoff小体 受托人与锻造的机制是什么样的?

手机客户端
BTC114手机客户端
扫描二维码下载手机APP
扫描二维码关注BTC114
微信公众号:btc114
 1 AC0.5与DPOS  我们之前分析过,DPOS的主要问题在于受托人的权力过高,而其他节点对区块的有效性验证过于简单,这就很容造成一个局面,即不同内容、但相同高度的区块共存于网络中的不同节点,也就是所谓的分叉,进而造成双重支付。  PBFT算法的本质则是让每一个节点都尽可能知道其他节点的决策,并以此来确定自己的决策。  因此,PBFT带来额外的流量消耗就可以理解了,其根源也找到了。在AC0.5算法中,这个额外的流量或者说“其他节点的决策”指的就是每个节点对下一个区块的投票信息,投票信息主要内容有4个部分,即区块高度、区块ID、签名、公钥,其中区块高度和区块ID的长度可以忽略不计,签名的长度为64字节,公钥的长度为32字节,一个区块达成共识需要全部受托人总数的2/3的投票,在系统中受托人总数为101人,也就是说需要至少67个投票。一个区块的大小大约是200字节,相当于2个投票的大小,因此AC0.5中流量消耗是原始DPOS的30多倍(在没有交易的空block情况下,如果有交易则交易不会消耗额外的流量)。  2 AC1.0做了哪些改进2.1 序列化方法  AC0.5中服务器之间的消息传递使用json格式,二进制字段则是转化为hex编码后再进行传输,投票中的二进制字段包括公钥和签名,之前我们算的是100字节,转化为hex编码后则翻1倍,变成200字节了。    另外json的字段信息和冗余的分隔符所占的字节数也不少。  AC1.0对这一点做了改进,使用了protobuf作为序列化方法,效果很不错,带宽降为原来的60[%]左右。  2.2 算法流程  AC0.5的流程为广播一个待确认区块收集选票(以广播的形式)收集确认信息(以广播的形式)确认区块  AC1.0的流程为propose (广播一个区块的元信息及当前generator的ip信息)collect votes (其他节点采用一对一的方式直接将选票发送给当前generator)commit and broadcast(广播一个已经确认的区块并携带投票信息)  通过对比可以发现,AC0.5需要三次广播,AC1.0仅需要两次广播,并且在propose环节,只广播了区块的元信息,不包括交易信息,只广播元信息有个好处,可以防止在区块无法达成共识的情况下白白浪费流量,因为如果连元信息都无法通过,那就没必要广播交易信息了。  2.3 广播协议  AC0.5使用的广播协议为最朴素也最粗暴的gossip算法,即随机选取一定数量的相邻节点然后将消息广播给它们, 这个一定数量固定为100. 任何一个节点在收到一条信息后,会计算这个消息的hash,如果发现没有收到过,就会继续广播给它的相邻节点。也就是说一轮广播需要进行100 * N次通讯,在N小于100的情况下,相当于复杂度为O(N^2), 在这里N为整个网络的节点个数。  AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点,每个节点只需要广播给10个相邻节点。  这个改动很小,但是参数的设置却是非常需要经验的,我们做过了大量的测试后,认为sqrt(N)可以达到比较理想的效果,一次广播需要的通讯次数略高于N * sqrt(N)。  除此之外,我们还实现了一个基于一致性哈希的广播算法,性能达到了极致,算法复杂度降低到了O(N), 但是这个算法需要更多的测试,其稳定性和可靠性也不如更简单的随机算法。  算法的demo版本在这里,有兴趣的可以研究下。    3 容错性  关于容错性,我认为可以从内因和外因两个方面来说。  从内因的角度来说,系统应该能容忍正常节点出错,这些错误主要是指服务器宕机、硬件错误、网络拥塞等。系统能够容忍最多1/3的受托人节点同时出错,假如某个受托人的节点出错了,那轮到该受托人生产区块的时候,就会缺失一个,并顺延到下一个10秒。假如超过1/3节点同时出错,那么系统将暂停工作,等到足够的节点恢复正常后,系统就可以立即恢复正常。  假如1/3以上的节点永远无法恢复(这种情况是存在的,比如他们的密钥丢了),那么系统必须要通过一次软件升级来恢复,并且这个升级不强制所有节点执行,只要部分节点升级,区块生产恢复正常后,通过受托人投票把那些不正常的节点撤销掉,系统就恢复如常了。  从外因的角度来说,系统应该能够容忍黑客攻击、受托人作弊的情况。这里的黑客攻击不是说DDOS,DDOS造成的后果最多是部分服务器宕机,我们已经归到内因里去了,这里的黑客攻击主要是指通过入侵拿到部分受托人密钥并获取权限,然后利用这些权限获利。获利的手段无非是广播多个版本的区块,在短时间内造成分叉,然后进行双重支付。在asch系统中,黑客必须要同时获得1/3以上节点的密钥,才能够发动连续攻击,使网络的分叉持续下去,否则系统将通过最长链同步算法迅速消除分叉,分叉之间的差距不会超过1个区块高度,也就是说2次确认以上的交易基本上不可能被回滚了。  从现有的使用DPOS算法的系统来看,包括bitshares、crypti、lisk在内,这些系统出现的分叉都是内因造成的,甚至大多数是算法实现上的bug所导致的。黑客攻击DPOS的案例还没有听说过,虽然存在理论上的漏洞,但要想真正的攻击,需要高超的技术和昂贵的资源,成本和收益不对等,因此也不会有人去攻击,当一个DPOS系统的市值慢慢增大,我们可以继续提高受托人节点的数量,进一步提高攻击的成本,因此外因的风险基本可以忽略。  最后,我想解释一下分叉这个词,分叉来源于英文的fork,fork根据上下文的不同,我认为可以翻译成两种意思,一个是分叉,另一个是分裂。  分叉指的是在社区成员团结一致的情况下系统因为bug或被攻击造成的不一致性,而分裂是指社区成员因观念分化造成软件走向不同的方向。  分叉强调的是系统的bug和不一致性,强调了物的因素,分叉后系统可能还是一个系统,并且是很可能被复原的;而分裂则是强调了人为的因素,一旦社区分裂,则系统一分为二,变成两个系统。  从这个角度来说,对于分叉可以做到事前的预防和事后的修复,但无法应对社区的分裂,任何一个区块链系统也无法解决分裂的问题,包括和任何一个声称可以避免分叉的PBFT系统。本内容由比特币资讯站整理提供,希望此技术贴:浅谈阿希币(asch)系统的共识机制与容错性信息能为您提供帮助,如果技术贴:浅谈阿希币(asch)系统的共识机制与容错性对您有益还请将我们比特币资讯站加入收藏,以便以后为您提供最新的技术贴:浅谈阿希币(asch)系统的共识机制与容错性信息。
*昵&&&&&称:
比特币热门标签会员 & 您好!
投资有风险 入市需谨慎
客服热线:8 /
技术贴:浅谈阿希币(asch)系统的共识机制与容错性
  我们之前分析过,DPOS的主要问题在于受托人的权力过高,而其他节点对区块的有效性验证过于简单,这就很容造成一个局面,即不同内容、但相同高度的区块共存于网络中的不同节点,也就是所谓的分叉,进而造成双重支付。  PBFT算法的本质则是让每一个节点都尽可能知道其他节点的决策,并以此来确定自己的决策。  因此,PBFT带来额外的流量消耗就可以理解了,其根源也找到了。在AC0.5算法中,这个额外的流量或者说“其他节点的决策”指的就是每个节点对下一个区块的投票信息,投票信息主要内容有4个部分,即区块高度、区块ID、签名、公钥,其中区块高度和区块ID的长度可以忽略不计,签名的长度为64字节,公钥的长度为32字节,一个区块达成共识需要全部受托人总数的2/3的投票,在asch系统中受托人总数为101人,也就是说需要至少67个投票。一个区块的大小大约是200字节,相当于2个投票的大小,因此AC0.5中流量消耗是原始DPOS的30多倍(在没有交易的空block情况下,如果有交易则交易不会消耗额外的流量)。2 AC1.0做了哪些改进2.1序列化方法  AC0.5中服务器之间的消息传递使用json格式,二进制字段则是转化为hex编码后再进行传输,投票中的二进制字段包括公钥和签名,之前我们算的是100字节,转化为hex编码后则翻1倍,变成200字节了。  另外json的字段信息和冗余的分隔符所占的字节数也不少。  AC1.0对这一点做了改进,使用了protobuf作为序列化方法,效果很不错,带宽降为原来的60[%]左右。2.2算法流程  AC0.5的流程为  广播一个待确认区块  收集选票(以广播的形式)  收集确认信息(以广播的形式)  确认区块  AC1.0的流程为  propose
(广播一个区块的元信息及当前generator的ip信息)  collect
votes (其他节点采用一对一的方式直接将选票发送给当前generator)  commit
and broadcast(广播一个已经确认的区块并携带投票信息)  通过对比可以发现,AC0.5需要三次广播,AC1.0仅需要两次广播,并且在propose环节,只广播了区块的元信息,不包括交易信息,只广播元信息有个好处,可以防止在区块无法达成共识的情况下白白浪费流量,因为如果连元信息都无法通过,那就没必要广播交易信息了。2.3广播协议  AC0.5使用的广播协议为最朴素也最粗暴的gossip算法,即随机选取一定数量的相邻节点然后将消息广播给它们, 这个一定数量固定为100. 任何一个节点在收到一条信息后,会计算这个消息的hash,如果发现没有收到过,就会继续广播给它的相邻节点。也就是说一轮广播需要进行100 * N次通讯,在N小于100的情况下,相当于复杂度为O(N^2), 在这里N为整个网络的节点个数。  AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点,每个节点只需要广播给10个相邻节点。  这个改动很小,但是参数的设置却是非常需要经验的,我们做过了大量的测试后,认为sqrt(N)可以达到比较理想的效果,一次广播需要的通讯次数略高于N * sqrt(N)。  除此之外,我们还实现了一个基于一致性哈希的广播算法,性能达到了极致,算法复杂度降低到了O(N), 但是这个算法需要更多的测试,其稳定性和可靠性也不如更简单的随机算法。  算法的demo版本在这里,有兴趣的可以研究下。3容错性  关于容错性,我认为可以从内因和外因两个方面来说。  从内因的角度来说,系统应该能容忍正常节点出错,这些错误主要是指服务器宕机、硬件错误、网络拥塞等。Asch系统能够容忍最多1/3的受托人节点同时出错,假如某个受托人的节点出错了,那轮到该受托人生产区块的时候,就会缺失一个,并顺延到下一个10秒。假如超过1/3节点同时出错,那么系统将暂停工作,等到足够的节点恢复正常后,系统就可以立即恢复正常。  假如1/3以上的节点永远无法恢复(这种情况是存在的,比如他们的密钥丢了),那么系统必须要通过一次软件升级来恢复,并且这个升级不强制所有节点执行,只要部分节点升级,区块生产恢复正常后,通过受托人投票把那些不正常的节点撤销掉,系统就恢复如常了。  从外因的角度来说,系统应该能够容忍黑客攻击、受托人作弊的情况。这里的黑客攻击不是说DDOS,DDOS造成的后果最多是部分服务器宕机,我们已经归到内因里去了,这里的黑客攻击主要是指通过入侵拿到部分受托人密钥并获取权限,然后利用这些权限获利。获利的手段无非是广播多个版本的区块,在短时间内造成分叉,然后进行双重支付。在asch系统中,黑客必须要同时获得1/3以上节点的密钥,才能够发动连续攻击,使网络的分叉持续下去,否则系统将通过最长链同步算法迅速消除分叉,分叉之间的差距不会超过1个区块高度,也就是说2次确认以上的交易基本上不可能被回滚了。  从现有的使用DPOS算法的系统来看,包括bitshares、crypti、lisk在内,这些系统出现的分叉都是内因造成的,甚至大多数是算法实现上的bug所导致的。黑客攻击DPOS的案例还没有听说过,虽然存在理论上的漏洞,但要想真正的攻击,需要高超的技术和昂贵的资源,成本和收益不对等,因此也不会有人去攻击,当一个DPOS系统的市值慢慢增大,我们可以继续提高受托人节点的数量,进一步提高攻击的成本,因此外因的风险基本可以忽略。  最后,我想解释一下分叉这个词,分叉来源于英文的fork,fork根据上下文的不同,我认为可以翻译成两种意思,一个是分叉,另一个是分裂。  分叉指的是在社区成员团结一致的情况下系统因为bug或被攻击造成的不一致性,而分裂是指社区成员因观念分化造成软件走向不同的方向。  分叉强调的是系统的bug和不一致性,强调了物的因素,分叉后系统可能还是一个系统,并且是很可能被复原的;而分裂则是强调了人为的因素,一旦社区分裂,则系统一分为二,变成两个系统。  从这个角度来说,asch对于分叉可以做到事前的预防和事后的修复,但无法应对社区的分裂,任何一个区块链系统也无法解决分裂的问题,包括比特币和任何一个声称可以避免分叉的PBFT系统。
本文内容仅供参考,并不构成投资建议!投资者据此操作,风险自担。
24小时热点阅读推荐
浙江国承信电子商务有限公司 浙ICP备号-1技术贴:浅谈阿希币asch系统的共识机制与容错性
1 AC0.5与DPOS
我们之前分析过,DPOS的主要问题在于受托人的权力过高,而其他节点对区块的有效性验证过于简单,这就很容造成一个局面,即不同内容、但相同高度的区块共存于网络中的不同节点,也就是所谓的分叉,进而造成双重支付。
PBFT算法的本质则是让每一个节点都尽可能知道其他节点的决策,并以此来确定自己的决策。
因此,PBFT带来额外的流量消耗就可以理解了,其根源也找到了。在AC0.5算法中,这个额外的流量或者说“其他节点的决策”指的就是每个节点对下一个区块的投票信息,投票信息主要内容有4个部分,即区块高度、区块ID、签名、公钥,其中区块高度和区块ID的长度可以忽略不计,签名的长度为64字节,公钥的长度为32字节,一个区块达成共识需要全部受托人总数的2/3的投票,在asch系统中受托人总数为101人,也就是说需要至少67个投票。一个区块的大小大约是200字节,相当于2个投票的大小,因此AC0.5中流量消耗是原始DPOS的30多倍(在没有交易的空block情况下,如果有交易则交易不会消耗额外的流量)。
2 AC1.0做了哪些改进2.1 序列化方法
AC0.5中服务器之间的消息传递使用json格式,二进制字段则是转化为hex编码后再进行传输,投票中的二进制字段包括公钥和签名,之前我们算的是100字节,转化为hex编码后则翻1倍,变成200字节了。
另外json的字段信息和冗余的分隔符所占的字节数也不少。
AC1.0对这一点做了改进,使用了protobuf作为序列化方法,效果很不错,带宽降为原来的60[%]左右。
2.2 算法流程
AC0.5的流程为
广播一个待确认区块
收集选票(以广播的形式)
收集确认信息(以广播的形式)
AC1.0的流程为
propose (广播一个区块的元信息及当前generator的ip信息)
collect votes (其他节点采用一对一的方式直接将选票发送给当前generator)
commit and broadcast(广播一个已经确认的区块并携带投票信息)
通过对比可以发现,AC0.5需要三次广播,AC1.0仅需要两次广播,并且在propose环节,只广播了区块的元信息,不包括交易信息,只广播元信息有个好处,可以防止在区块无法达成共识的情况下白白浪费流量,因为如果连元信息都无法通过,那就没必要广播交易信息了。
2.3 广播协议
AC0.5使用的广播协议为最朴素也最粗暴的gossip算法,即随机选取一定数量的相邻节点然后将消息广播给它们, 这个一定数量固定为100. 任何一个节点在收到一条信息后,会计算这个消息的hash,如果发现没有收到过,就会继续广播给它的相邻节点。也就是说一轮广播需要进行100 * N次通讯,在N小于100的情况下,相当于复杂度为O(N^2), 在这里N为整个网络的节点个数。
AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点,每个节点只需要广播给10个相邻节点。
这个改动很小,但是参数的设置却是非常需要经验的,我们做过了大量的测试后,认为sqrt(N)可以达到比较理想的效果,一次广播需要的通讯次数略高于N * sqrt(N)。
除此之外,我们还实现了一个基于一致性哈希的广播算法,性能达到了极致,算法复杂度降低到了O(N), 但是这个算法需要更多的测试,其稳定性和可靠性也不如更简单的随机算法。
算法的demo版本在这里,有兴趣的可以研究下。
关于容错性,我认为可以从内因和外因两个方面来说。
从内因的角度来说,系统应该能容忍正常节点出错,这些错误主要是指服务器宕机、硬件错误、网络拥塞等。Asch系统能够容忍最多1/3的受托人节点同时出错,假如某个受托人的节点出错了,那轮到该受托人生产区块的时候,就会缺失一个,并顺延到下一个10秒。假如超过1/3节点同时出错,那么系统将暂停工作,等到足够的节点恢复正常后,系统就可以立即恢复正常。
假如1/3以上的节点永远无法恢复(这种情况是存在的,比如他们的密钥丢了),那么系统必须要通过一次软件升级来恢复,并且这个升级不强制所有节点执行,只要部分节点升级,区块生产恢复正常后,通过受托人投票把那些不正常的节点撤销掉,系统就恢复如常了。
从外因的角度来说,系统应该能够容忍黑客攻击、受托人作弊的情况。这里的黑客攻击不是说DDOS,DDOS造成的后果最多是部分服务器宕机,我们已经归到内因里去了,这里的黑客攻击主要是指通过入侵拿到部分受托人密钥并获取权限,然后利用这些权限获利。获利的手段无非是广播多个版本的区块,在短时间内造成分叉,然后进行双重支付。在asch系统中,黑客必须要同时获得1/3以上节点的密钥,才能够发动连续攻击,使网络的分叉持续下去,否则系统将通过最长链同步算法迅速消除分叉,分叉之间的差距不会超过1个区块高度,也就是说2次确认以上的交易基本上不可能被回滚了。
从现有的使用DPOS算法的系统来看,包括bitshares、crypti、lisk在内,这些系统出现的分叉都是内因造成的,甚至大多数是算法实现上的bug所导致的。黑客攻击DPOS的案例还没有听说过,虽然存在理论上的漏洞,但要想真正的攻击,需要高超的技术和昂贵的资源,成本和收益不对等,因此也不会有人去攻击,当一个DPOS系统的市值慢慢增大,我们可以继续提高受托人节点的数量,进一步提高攻击的成本,因此外因的风险基本可以忽略。
最后,我想解释一下分叉这个词,分叉来源于英文的fork,fork根据上下文的不同,我认为可以翻译成两种意思,一个是分叉,另一个是分裂。
分叉指的是在社区成员团结一致的情况下系统因为bug或被攻击造成的不一致性,而分裂是指社区成员因观念分化造成软件走向不同的方向。
分叉强调的是系统的bug和不一致性,强调了物的因素,分叉后系统可能还是一个系统,并且是很可能被复原的;而分裂则是强调了人为的因素,一旦社区分裂,则系统一分为二,变成两个系统。
从这个角度来说,asch对于分叉可以做到事前的预防和事后的修复,但无法应对社区的分裂,任何一个区块链系统也无法解决分裂的问题,包括比特币和任何一个声称可以避免分叉的PBFT系统。
看过本文的人还看过
最新图文推荐
最新专栏文章
大家感兴趣的内容
&&<a rel="nofollow" class="red" href="" target="_blank" color="red新版网站排行榜
===全新上线===
网友热评的文章1 AC0.5与DPOS
我们之前分析过,DPOS的主要问题在于受托人的权力过高,而其他节点对区块的有效性验证过于简单,这就很容造成一个局面,即不同内容、但相同高度的区块共存于网络中的不同节点,也就是所谓的分叉,进而造成双重支付。
PBFT算法的本质则是让每一个节点都尽可能知道其他节点的决策,并以此来确定自己的决策。
因此,PBFT带来额外的流量消耗就可以理解了,其根源也找到了。在AC0.5算法中,这个额外的流量或者说“其他节点的决策”指的就是每个节点对下一个区块的投票信息,投票信息主要内容有4个部分,即区块高度、区块ID、签名、公钥,其中区块高度和区块ID的长度可以忽略不计,签名的长度为64字节,公钥的长度为32字节,一个区块达成共识需要全部受托人总数的2/3的投票,在asch系统中受托人总数为101人,也就是说需要至少67个投票。一个区块的大小大约是200字节,相当于2个投票的大小,因此AC0.5中流量消耗是原始DPOS的30多倍(在没有交易的空block情况下,如果有交易则交易不会消耗额外的流量)。
2 AC1.0做了哪些改进2.1 序列化方法
AC0.5中服务器之间的消息传递使用json格式,二进制字段则是转化为hex编码后再进行传输,投票中的二进制字段包括公钥和签名,之前我们算的是100字节,转化为hex编码后则翻1倍,变成200字节了。
另外json的字段信息和冗余的分隔符所占的字节数也不少。
AC1.0对这一点做了改进,使用了protobuf作为序列化方法,效果很不错,带宽降为原来的60[%]左右。
2.2 算法流程
AC0.5的流程为
广播一个待确认区块
收集选票(以广播的形式)
收集确认信息(以广播的形式)
AC1.0的流程为
propose (广播一个区块的元信息及当前generator的ip信息)
collect votes (其他节点采用一对一的方式直接将选票发送给当前generator)
commit and broadcast(广播一个已经确认的区块并携带投票信息)
通过对比可以发现,AC0.5需要三次广播,AC1.0仅需要两次广播,并且在propose环节,只广播了区块的元信息,不包括交易信息,只广播元信息有个好处,可以防止在区块无法达成共识的情况下白白浪费流量,因为如果连元信息都无法通过,那就没必要广播交易信息了。
2.3 广播协议
AC0.5使用的广播协议为最朴素也最粗暴的gossip算法,即随机选取一定数量的相邻节点然后将消息广播给它们, 这个一定数量固定为100. 任何一个节点在收到一条信息后,会计算这个消息的hash,如果发现没有收到过,就会继续广播给它的相邻节点。也就是说一轮广播需要进行100 * N次通讯,在N小于100的情况下,相当于复杂度为O(N^2), 在这里N为整个网络的节点个数。
AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点,每个节点只需要广播给10个相邻节点。
这个改动很小,但是参数的设置却是非常需要经验的,我们做过了大量的测试后,认为sqrt(N)可以达到比较理想的效果,一次广播需要的通讯次数略高于N * sqrt(N)。
除此之外,我们还实现了一个基于一致性哈希的广播算法,性能达到了极致,算法复杂度降低到了O(N), 但是这个算法需要更多的测试,其稳定性和可靠性也不如更简单的随机算法。
算法的demo版本在这里,有兴趣的可以研究下。
关于容错性,我认为可以从内因和外因两个方面来说。
从内因的角度来说,系统应该能容忍正常节点出错,这些错误主要是指服务器宕机、硬件错误、网络拥塞等。Asch系统能够容忍最多1/3的受托人节点同时出错,假如某个受托人的节点出错了,那轮到该受托人生产区块的时候,就会缺失一个,并顺延到下一个10秒。假如超过1/3节点同时出错,那么系统将暂停工作,等到足够的节点恢复正常后,系统就可以立即恢复正常。
假如1/3以上的节点永远无法恢复(这种情况是存在的,比如他们的密钥丢了),那么系统必须要通过一次软件升级来恢复,并且这个升级不强制所有节点执行,只要部分节点升级,区块生产恢复正常后,通过受托人投票把那些不正常的节点撤销掉,系统就恢复如常了。
从外因的角度来说,系统应该能够容忍黑客攻击、受托人作弊的情况。这里的黑客攻击不是说DDOS,DDOS造成的后果最多是部分服务器宕机,我们已经归到内因里去了,这里的黑客攻击主要是指通过入侵拿到部分受托人密钥并获取权限,然后利用这些权限获利。获利的手段无非是广播多个版本的区块,在短时间内造成分叉,然后进行双重支付。在asch系统中,黑客必须要同时获得1/3以上节点的密钥,才能够发动连续攻击,使网络的分叉持续下去,否则系统将通过最长链同步算法迅速消除分叉,分叉之间的差距不会超过1个区块高度,也就是说2次确认以上的交易基本上不可能被回滚了。
从现有的使用DPOS算法的系统来看,包括bitshares、crypti、lisk在内,这些系统出现的分叉都是内因造成的,甚至大多数是算法实现上的bug所导致的。黑客攻击DPOS的案例还没有听说过,虽然存在理论上的漏洞,但要想真正的攻击,需要高超的技术和昂贵的资源,成本和收益不对等,因此也不会有人去攻击,当一个DPOS系统的市值慢慢增大,我们可以继续提高受托人节点的数量,进一步提高攻击的成本,因此外因的风险基本可以忽略。
最后,我想解释一下分叉这个词,分叉来源于英文的fork,fork根据上下文的不同,我认为可以翻译成两种意思,一个是分叉,另一个是分裂。
分叉指的是在社区成员团结一致的情况下系统因为bug或被攻击造成的不一致性,而分裂是指社区成员因观念分化造成软件走向不同的方向。
分叉强调的是系统的bug和不一致性,强调了物的因素,分叉后系统可能还是一个系统,并且是很可能被复原的;而分裂则是强调了人为的因素,一旦社区分裂,则系统一分为二,变成两个系统。
从这个角度来说,asch对于分叉可以做到事前的预防和事后的修复,但无法应对社区的分裂,任何一个区块链系统也无法解决分裂的问题,包括比特币和任何一个声称可以避免分叉的PBFT系统。
欢迎关注,最新科技资讯、网站运营推广、搜索SEO优化、网上赚钱项目和创业信息分享。| 漏洞检测 |
| 隐藏捆绑 |
技术贴:浅谈阿希币asch系统的共识机制与容错性
1 AC0.5与DPOS我们之前分析过,DPOS的主要问题在于受托人的权力过高,而其他节点对区块的有效性验证过于简单,这就很容造成一个局面,即不同内容、但相同高度的
我们之前分析过,DPOS的主要问题在于受托人的权力过高,而其他节点对区块的有效性验证过于简单,这就很容造成一个局面,即不同内容、但相同高度的区块共存于网络中的不同节点,也就是所谓的分叉,进而造成双重支付。
PBFT算法的本质则是让每一个节点都尽可能知道其他节点的决策,并以此来确定自己的决策。
因此,PBFT带来额外的流量消耗就可以理解了,其根源也找到了。在AC0.5算法中,这个额外的流量或者说“其他节点的决策”指的就是每个节点对下一个区块的投票信息,投票信息主要内容有4个部分,即区块高度、区块ID、签名、公钥,其中区块高度和区块ID的长度可以忽略不计,签名的长度为64字节,公钥的长度为32字节,一个区块达成共识需要全部受托人总数的2/3的投票,在asch系统中受托人总数为101人,也就是说需要至少67个投票。一个区块的大小大约是200字节,相当于2个投票的大小,因此AC0.5中流量消耗是原始DPOS的30多倍(在没有交易的空block情况下,如果有交易则交易不会消耗额外的流量)。
2 AC1.0做了哪些改进2.1 序列化方法
AC0.5中服务器之间的消息传递使用json格式,二进制字段则是转化为hex编码后再进行传输,投票中的二进制字段包括公钥和签名,之前我们算的是100字节,转化为hex编码后则翻1倍,变成200字节了。
另外json的字段信息和冗余的分隔符所占的字节数也不少。
AC1.0对这一点做了改进,使用了protobuf作为序列化方法,效果很不错,带宽降为原来的60[%]左右。
2.2 算法流程
AC0.5的流程为
广播一个待确认区块
收集选票(以广播的形式)
收集确认信息(以广播的形式)
AC1.0的流程为
propose (广播一个区块的元信息及当前generator的ip信息)
collect votes (其他节点采用一对一的方式直接将选票发送给当前generator)
commit and broadcast(广播一个已经确认的区块并携带投票信息)
通过对比可以发现,AC0.5需要三次广播,AC1.0仅需要两次广播,并且在propose环节,只广播了区块的元信息,不包括交易信息,只广播元信息有个好处,可以防止在区块无法达成共识的情况下白白浪费流量,因为如果连元信息都无法通过,那就没必要广播交易信息了。
2.3 广播协议
AC0.5使用的广播协议为最朴素也最粗暴的gossip算法,即随机选取一定数量的相邻节点然后将消息广播给它们, 这个一定数量固定为100. 任何一个节点在收到一条信息后,会计算这个消息的hash,如果发现没有收到过,就会继续广播给它的相邻节点。也就是说一轮广播需要进行100 * N次通讯,在N小于100的情况下,相当于复杂度为O(N^2), 在这里N为整个网络的节点个数。
AC1.0把这个固定数量改为sqrt(N), 也就是说假如有100个节点,每个节点只需要广播给10个相邻节点。
这个改动很小,但是参数的设置却是非常需要经验的,我们做过了大量的测试后,认为sqrt(N)可以达到比较理想的效果,一次广播需要的通讯次数略高于N * sqrt(N)。
除此之外,我们还实现了一个基于一致性哈希的广播算法,性能达到了极致,算法复杂度降低到了O(N), 但是这个算法需要更多的测试,其稳定性和可靠性也不如更简单的随机算法。
算法的demo版本在这里,有兴趣的可以研究下。
关于容错性,我认为可以从内因和外因两个方面来说。
从内因的角度来说,系统应该能容忍正常节点出错,这些错误主要是指服务器宕机、硬件错误、网络拥塞等。Asch系统能够容忍最多1/3的受托人节点同时出错,假如某个受托人的节点出错了,那轮到该受托人生产区块的时候,就会缺失一个,并顺延到下一个10秒。假如超过1/3节点同时出错,那么系统将暂停工作,等到足够的节点恢复正常后,系统就可以立即恢复正常。
假如1/3以上的节点永远无法恢复(这种情况是存在的,比如他们的密钥丢了),那么系统必须要通过一次软件升级来恢复,并且这个升级不强制所有节点执行,只要部分节点升级,区块生产恢复正常后,通过受托人投票把那些不正常的节点撤销掉,系统就恢复如常了。
从外因的角度来说,系统应该能够容忍黑客攻击、受托人作弊的情况。这里的黑客攻击不是说DDOS,DDOS造成的后果最多是部分服务器宕机,我们已经归到内因里去了,这里的黑客攻击主要是指通过入侵拿到部分受托人密钥并获取权限,然后利用这些权限获利。获利的手段无非是广播多个版本的区块,在短时间内造成分叉,然后进行双重支付。在asch系统中,黑客必须要同时获得1/3以上节点的密钥,才能够发动连续攻击,使网络的分叉持续下去,否则系统将通过最长链同步算法迅速消除分叉,分叉之间的差距不会超过1个区块高度,也就是说2次确认以上的交易基本上不可能被回滚了。
从现有的使用DPOS算法的系统来看,包括bitshares、crypti、lisk在内,这些系统出现的分叉都是内因造成的,甚至大多数是算法实现上的bug所导致的。黑客攻击DPOS的案例还没有听说过,虽然存在理论上的漏洞,但要想真正的攻击,需要高超的技术和昂贵的资源,成本和收益不对等,因此也不会有人去攻击,当一个DPOS系统的市值慢慢增大,我们可以继续提高受托人节点的数量,进一步提高攻击的成本,因此外因的风险基本可以忽略。
最后,我想解释一下分叉这个词,分叉来源于英文的fork,fork根据上下文的不同,我认为可以翻译成两种意思,一个是分叉,另一个是分裂。
分叉指的是在社区成员团结一致的情况下系统因为bug或被攻击造成的不一致性,而分裂是指社区成员因观念分化造成软件走向不同的方向。
分叉强调的是系统的bug和不一致性,强调了物的因素,分叉后系统可能还是一个系统,并且是很可能被复原的;而分裂则是强调了人为的因素,一旦社区分裂,则系统一分为二,变成两个系统。
从这个角度来说,asch对于分叉可以做到事前的预防和事后的修复,但无法应对社区的分裂,任何一个区块链系统也无法解决分裂的问题,包括比特币和任何一个声称可以避免分叉的PBFT系统。
(责任编辑:幽灵学院)
------分隔线----------------------------
下一篇:没有了
【BangCamp】创业邦CEO南立新:天使期的创业者要怎样做?,赚...
揭开实木家具谜团 推进实木门窗企业发展-实木门窗,门窗,实木...
霸屏半年的万科股权之争并没有随着万科股票复牌而缓和,三国...
目前,电磁兼容技术已经发展成为专门的针对电子产品抗电磁干...
没有网络安全,就没有国家安全! 如果你的手机被病毒软件入侵...
南京师范大学生命科学学院院长杨光教授道出一个残酷事实:这...
工作日:9:00-21:00
周 六:9:00-18:00
&&扫一扫关注幽灵学院

我要回帖

更多关于 asch币 的文章

 

随机推荐