当前位置:首页-NFT-正文

比特币最近更新(p币最近更新)

最近比特币圈子可真是热闹,最让人激动的就是BIP91成功激活了,BIP91的激活也意味着BIP141隔离见证的激活进入倒计时,折磨比特币开发者数年的签名地狱就要解决了,一定程度上也可以增加网络容量。

比特币最近更新(p币最近更新)_第1张比特币最近更新(p币最近更新)_第1张
比特币最近更新(p币最近更新)_第3张比特币最近更新(p币最近更新)_第3张

看看之前部署了隔离见证的莱特币,已经疯长超过10倍,就可以知道这项技术有多么重要了。

比特币最近更新(p币最近更新)_第5张比特币最近更新(p币最近更新)_第5张

听起来很简单的事情,其实是比特币社区各方博弈数年后做出的妥协。抛开利益问题,我们来谈谈这些新特性部署背后的技术和原理。

机智的中本聪

中本聪在设计区块链的结构时,就想到了一个问题,如果有一天比特币壮大了,想增加新的功能怎么办呢?于是,他机智的在区块中加了个小标记,叫做nVersion,也就是标记这个区块的版本,有了什么新功能要增加,可以对应的在版本号上体现出来。我相信中本聪对比特币那是相当的有信心,他给这个用来放版本号的nVersion预留了4个字节,最大值达到2147483647,可以用到宇宙毁灭了。创世区块0的版本号是1。(程序员们对此表示很不满,从1开始计算的东西真是太可恶了)

比特币最近更新(p币最近更新)_第7张比特币最近更新(p币最近更新)_第7张

第一次升级

从2009年发布,比特币一直在默默无闻的运行着,一直到2013年。一个小缺陷被大家发现了,中本聪在设计比特币时,没有在区块中加上高度这个数据,也就是说,当你收到一个区块时,如果你没有它之前的所有区块,你根本不知道它到底高度是多少。对PC机来说这不是问题,只要下载了全部区块链就可以解决,可是手机这种移动设备表示,存储所有几十G的区块链,我压力山大啊。

于是,最早的升级探索开始了。

这次升级被记录在BIP34文档中,大致内容如下:

  • 开始时,所有nVersion=1的区块使用老共识进行验证
  • 之后,所有nVersion>1的区块都当作非标准的,只要能通过新共识或老共识验证,都认为合法。
  • 当连续的1000个区块中有750个区块是nVersion=2的,以后所有nVersion=2的区块只使用新共识进行验证
  • 当连续的1000个区块中有950个区块是nVersion=2的,所有nVersion=1的区块将被认为非法

这次升级非常的成功,从227836区块开始,nVersion=2统一了天下。

比特币最近更新(p币最近更新)_第9张比特币最近更新(p币最近更新)_第9张

在此之后使用类似的方式,比特币进行了另外两次nVersion=3和nVersion=4的升级。

故事如果这么结束了,那就太无聊了。

不知道你有没有发现这种升级方式有两点问题:

  1. 同时只能进行一种更新
  2. 更新一旦开始,如果不成功,就永远不能停止

是不是觉得前几次的更新都是在走钢丝,稍不留神,上一个更新迟迟得不到足够的节点支持,永远僵死在那里,堵死以后所有更新的道路。细思恐极。

更加牛逼的更新方法BIP9

还记得前面说的中本聪给nVersion留了整整4个字节的空间么,现在这4个字节将派上大用场。

比特币最近更新(p币最近更新)_第11张比特币最近更新(p币最近更新)_第11张

这4个字节被拆成了32个二进制位,并规定最高的3个位必须为001(好奇为什么一定要是001的小伙伴先等等,先说正事儿,文末会告诉大家为什么要这么规定),剩下的29个位用来标记是否投票支持某项升级提案,1为支持,0为反对。上图就表示投票同意bit1代表的更新提案,这个提案记录在BIP148文档中,也就是我们常听说的隔离见证。这下就解决了同一时间只能对一个提案进行投票的问题,现在最多可以同时有29个了。

BIP9定义了一套非常精巧的更新方案,将一个更新提案分为五个状态:

  • DEFINED 是提案的初始状态,也就是一个提案被提出,但是还没有开始投票
  • STARTED 提案进入投票时间,投票开始
  • LOCKED_IN 在投票时间内达成投票成功的条件,提案进入锁定期
  • ACTIVE 进入锁定期之后一段时间,提案正式开始生效,投票结束,更新完成
  • FAILED 在投票时间内没有达成投票成功的条件,投票结束,不进行任何升级

如果用有限状态机图来表示就是这个样子的,图中的MTP可以理解为当前的时间。

比特币最近更新(p币最近更新)_第13张比特币最近更新(p币最近更新)_第13张

为什么一定要有LOCKED_IN阶段而不是直接进入ACTIVE是为了给还没有升级的节点一些时间来更新。就像一项新法律通过后也要等到一个特定的日期再生效是一个道理。

有限状态机的引入也就保证了一个投票过程只能处于某个确定的状态,一旦过了timeout指定的时间,提案投票一定会有通过或者不通过之中一种确定的结果,再也不用担心僵死不结束的情况了。

好了,现在来填刚才挖的坑,为什么最高三位一定是001。BIP9的文档中没有具体提及为什么,我第一次被人问及这个问题时也很困惑,细细思考后找到了原因:因为比特币要尽可能做到向前兼容,也就是说,新版本软件产生的数据,老版本最好也能识别验证和认可,这是相当不容易的,要做出很多妥协。在BIP9更新方法出现之前,区块的版本已经升级到nVersion=4了,nVersion<4的区块将被认为是无效的,nVersion的数据类型是Int。这就给nVersion的值提出了一个要求:如果想保证向前兼容,nVersion必须作为Int被解释,同时必须满足nVersion>=4

在这个限制下,让我们一位一位的讨论:

最高第一位:一定是0,如果是1,根据Int的补码表示规则,nVersion将解释成负数,不能满足nVersion>=4

最高第二位:不能是0,如果是0,仅仅只有bit1这一个提案在投票,就会出现如下情况:

比特币最近更新(p币最近更新)_第15张比特币最近更新(p币最近更新)_第15张

此时表示的数字是2,不能满足nVersion>=4

就目前来看,只要限制最高位是01就可以满足要求了,为什么要限制前三位呢?这是因为BIP9的作者考虑到未来可能有别的类型的投票,为了保证可拓展性,又加了一位。最高位的可选项其实有三种(001、010、011),只是010和011还没有被使用而已。

如果你也关注比特币的发展,可以在这里找到所有的BIP文档。