博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
【图学院】区块链与密码学全民课堂第1-6讲:分叉大战
阅读量:2145 次
发布时间:2019-04-30

本文共 3209 字,大约阅读时间需要 10 分钟。

导语:本课堂用通俗易懂的系列内容为大家呈现区块链与密码学领域相关知识。这里有知识也有故事,从感兴趣到有乐趣,全民课堂等你来学。

这个系列中的课程内容首先从比特币着手进行入门介绍,再延伸至区块链的相关技术原理与发展趋势,然后深入浅出地依次介绍在区块链中应用的各类密码学技术。欢迎大家订阅本公众号,持续进行学习。

【本课堂内容全部选编自PlatON首席密码学家、武汉大学国家网络安全学院教授、博士生导师何德彪教授的《区块链与密码学》授课讲义、教材及互联网,版权归属其原作者所有,如有侵权请立即与我们联系,我们将及时处理。】

关注PlatON公众号获取最新区块链资讯

在这里插入图片描述
1.6 比特币的分叉
我们日常在用的手机APP,系统更新犹如家常便饭,偶尔还会上几个新功能。而这看似简单的更新在比特币系统中却是难上加难,为什么呢?
在这里插入图片描述
软件由于方案优化、BUG修复等原因进行升级是一种非常常见的现象。如手机应用等传统软件,升级非常简单,只需厂商发布,用户接受升级即可。

但是对于比特币这种去中心化的系统,升级是非常困难的,需要协调网络中每个参与者。软件升级意味着运行逻辑的改变,但是在比特币中,升级必然会导致不同节点在一定时间内运行不同的版本,于是就会产生分叉。

分叉主要包含软分叉和硬分叉两种。如果比特币升级后,新的代码逻辑向前兼容,即新规则产生的区块仍然会被旧节点接受,则为软分叉;如果新的代码逻辑无法向前兼容,即新产生的规则产生的区块无法被旧节点接受,则为硬分叉。

在这里插入图片描述
下面我们就来看看什么是软分叉和硬分叉。

1.6.1 软分叉

软分叉由于向前兼容,新旧节点仍然运行在同一条区块链上,并不会产生两条链,对整个系统影响相对较小。到目前为止,比特币发生过多次软分叉,BIP-34,BIP-65,BIP-66,BIP-9。

在这里插入图片描述
此处以BIP-34为例,简单说明软分叉的过程。在旧版本中,存在一个无意义的字段"coinbase data”,矿工不会去验证该字段的内容。BIP-34升级的新版本则要求该字段必须包含区块高度,同时将版本信息由“1”修改为“2”。该升级共包含三个阶段。

第一阶段-矿工将版本号修改为“2”,此时所有矿工验证区块时,按照旧的规则验证,即不关心“coinbase data”字段内容,所有矿工不论以新规则还是旧规则打包区块,均可以被整个网络接受。

第二阶段-如果最新产生的1000个区块中,版本号为“2”的区块个数超过75%时,则要求版本号为“2”的矿工必须按照新的规则打包区块,升级的矿工收到版本号为“2”的区块时,只会接受“coinbase data”字段包含区块高度的区块,对于版本号为“1”的区块,仍然不校验该字段并接受。

第三阶段-如果最新产生的1000个区块中,版本号为“2”的区块个数超过95%,则升级的矿工只接受版本号为“2”的区块,并会对“coinbase data”字段进行校验,版本号为“1”的区块则不被接受,以此来逼迫剩余少量矿工进行升级。

软分叉虽然对系统的影响较小,但是为了保证向前兼容,不能新增字段,只能在现有数据结构下修改,即可升级的内容非常有限。同时,因为这些限制,软分叉一般升级方案比较复杂,复杂的方案往往更容易产生BUG,并且可维护性很差。

- 比特币科普之“第一次”分叉-

凡是都有第一次,让我们看看比特币第一次分叉是怎么回事儿呢?

第一次软分叉

比特币的第一个软分叉协议升级后禁用了协议特性的OP_RETURN。从技术上讲,这是一个UASF,但在早期,实际上只是中本聪在制定协议规则。升级没有导致区块链分叉。

第一次硬分叉

比特币的第一次硬叉协议升级增加了一个新功能OP_NOP,而且也是由中本聪指定的。然而,并不是所有人都认为这次升级实际上是一个硬分叉。从结果来看,它没有导致区块链分叉。

1.6.2 硬分叉

硬分叉就像议会表决一样,会出现“吵翻天”的情况。

在这里插入图片描述
硬分叉相比软分叉则会“暴力”很多,由于不向前兼容,旧版本矿工无法验证新版本的区块而拒绝接受,仍然按照旧的逻辑只接受旧版本矿工打包的区块。而新版本产生的区块则会被新版本矿工接受,因此新版本矿工保存的区块会和旧版本矿工保存的区块产生差别,即会形成两条链。

硬分叉修改余地很大,方案设计比较简单,但是如果整个网络中有两种不同的意见,就会导致整个生态的分裂。

当前比特币影响最广泛的硬分叉事件即为2017年8月1日的硬分叉,比特币由一条链分叉产生一条新的链“比特现金(Bitcoin Cash,BCH)“。这是一场开发者与矿工之间没有硝烟的战争!

在这里插入图片描述
下面我们就来还原这次事件的原委。

这次硬分叉的起因是开发者与矿工在比特币扩容方案上的分歧。比特币区块大小为1MB,按照每10分钟一个区块的速度,全球每秒只能完成大约7笔交易。比特币发展初期,1MB的区块足够打包出块间隔内产生的所有交易,但是在比特币如此火爆的今天,这种处理速度显然达不到要求。

为了解决以上问题,经过社区讨论,最终形成了两个改进方案,分别是扩容方案和隔离见证方案。

扩容方案的想法比较直接,既然现在因为区块太小而导致交易处理速度低下,那就直接扩大区块的容量,使其能容纳更多的交易。原来1MB不够用,那么就扩成2MB、8MB,甚至直接扩到32MB.

隔离见证方案的想法是,将交易分为两部分,一部分是交易信息,另一部分是见证信息,这两部分信息分开进行处理。好比一辆车太小,要搭车的人太多,于是让车上所有人将背包和行李放在另一辆跟着的货车上,这样原来的车就可以容纳更多的人了。

支持扩容方案的主要是矿工们。采用扩容方案,矿工可以在每个区块中包含更多的交易,从而获取更多的手续费,然而若使用隔离见证的扩容方案,小额的交易将不通过区块确认,矿工的手续费收益会大幅降低,因此矿工更倾向于支持扩容方案。

隔离见证方案的支持者主要是比特币开发团队的部分核心成员。他们认为,扩容方案是一个“扬汤止沸”的方案,毕竟不可能无限制地对区块的容量进行扩大。同时,区块的变大会使得挖矿的门槛提高,从而降低普通矿工的参与度,导致比特币系统的去中心化程度减弱。

在这里插入图片描述
2016年2月和2017年3月,争议双方两次进行商讨,希望双方“握手言和”,接受一个折中的方案。该方案中,区块容量将会被扩大到2MB,同时也对比特币部署隔离见证的方案。但是,由于期间有参与方反悔或者反对,导致最终没有达成共识,这也给“硬分叉”埋下了导火索。

在2017年8月1日,比特大陆投资的矿池ViaBTC团队,采用比特大陆提出的UAHF(用户激活的硬分叉)方案,挖出了第一个区块,对比特币区块链进行了硬分叉。自此,与比特币竞争的分叉币比特币现金诞生。比特币现金区块链的区块容量达到了8MB,且没有采用隔离见证方案。可以说这是一次矿工的胜利。

在这里插入图片描述
硬分叉后称为比特币现金(BCH),随后比特币黄金(BTG)、比特币钻石(BCD)、超级比特币(SBTC)等密码货币出现。

全民课堂第1-6讲今天就上到这里啦,下一期我们将聊聊比特币的后继者们,盘点其他密码货币的来龙去脉,敬请期待!

在这里插入图片描述

- 了解PlatON更多动态  -

PlatON Official Website

https://www.platon.network/

PlatON·GitHub

https://github.com/PlatONnetwork

PlatON·Forum

https://forum.latticex.foundation/c/PlatON-CN

PlatON·Telegram

https://t.me/PlatONNetworkCN

PlatON·Twitter

https://twitter.com/PlatON_Network

PlatON·LinkedIn

https://linkedin.com/company/platonnetwork
在这里插入图片描述
在这里插入图片描述

转载地址:http://vgegf.baihongyu.com/

你可能感兴趣的文章
source insight使用方法简介
查看>>
<stdarg.h>头文件的使用
查看>>
C++/C 宏定义(define)中# ## 的含义 宏拼接
查看>>
Git安装配置
查看>>
linux中fork()函数详解
查看>>
C语言字符、字符串操作偏僻函数总结
查看>>
Git的Patch功能
查看>>
分析C语言的声明
查看>>
TCP为什么是三次握手,为什么不是两次或者四次 && TCP四次挥手
查看>>
C结构体、C++结构体、C++类的区别
查看>>
进程和线程的概念、区别和联系
查看>>
CMake 入门实战
查看>>
绑定CPU逻辑核心的利器——taskset
查看>>
Linux下perf性能测试火焰图只显示函数地址不显示函数名的问题
查看>>
c结构体、c++结构体和c++类的区别以及错误纠正
查看>>
Linux下查看根目录各文件内存占用情况
查看>>
A星算法详解(个人认为最详细,最通俗易懂的一个版本)
查看>>
利用栈实现DFS
查看>>
逆序对的数量(递归+归并思想)
查看>>
数的范围(二分查找上下界)
查看>>