ABC和BSV之争-吃瓜群众的你看懂了吗

2018-12-11 本文已影响1人 JouyPub

2018年8月，Bitcoin ABC提出了一种新的共识变更，以提高BCH节点的速度，并引入外链。该变更将在2018年11月15日上线。但Craig Wright拒绝这种变更，称其为垃圾，宣称应当坚持中本聪最初的设计（Satoshi's Vision），否定了ABC开发组，并在当前客户端版本上发布了自己的版本SV。由于ABC的共识变更会和原有共识不兼容，因此这将是一次硬分叉，而双方都拒绝增加防重放，这次和以往硬分叉生“仔”不同之处在于，以往更多是新的算力来维持一个新链；而本次是现有算力的分裂，与其说是硬分叉生“仔”，不如说成兄弟分家更贴切。

背景故事

Bitcoin ABC团队和NChain团队都是BCH社区比较重要的技术开发团队，NChain在2018年8月16日发布了Bitcoin SV (Satoshi’s Vision)客户端，这就是当前一直提到的BCH的ABC和BSV；其实还有一个大的开发组Bitcoin Unlimited，这位则保持中立。
BCH的技术升级一年两次，基本以ABC团队主导，本次计划定于网络中最近11个区块的中值时间大于或等于UNIX时间戳1542300000，即北京时间的2018年11月16日0:40。国外时间为11月15日，对我们而言是16日凌晨的事情。
BCH这次的分歧主要来自于两套技术方案，Nchain在之前就表达了自己的意见，打算回归到BCH最早的0.1版本，所以针对这次ABC既定的更新，BSV（Bitcoin SV）走的是回归路线，并移除了自动重放攻击保护；这样，在技术层面上，一旦更新完成就出现了两条有差异的ABC链和BSV链。
虽然ABC和BSV有差异，但是在最底层的交易格式上并无差别，而且BSV还主动移除了自动重放攻击保护，这就造成同样一笔交易能在两条链里进行有效广播；通俗一点就是，只要我们花了BCH，对方就可以伪造支取BSV，反之亦然，相当于BCH生的“仔”压根儿与你无关。
前面四条都是技术上的分歧，技术的背后也是需要矿工支持的，于是两技术的支持主人公吴忌寒和澳本聪Craig S Wright (CSW)就出场了，吴忌寒代表着比特大陆支持着Bitcoin ABC团队，CSW背后的Coingeek支持着NChain团队BSV；如此，一场技术的分裂造成了矿工的分裂，也就是算力的分裂；由于两大矿场及主人公都太出名了，所以该次事件才受到众多关注。
当前，ABC方在BCH链上约持有30%左右的算力，而SV方约持有50%算力（https://cash.coin.dance/blocks）但是双方在BCH上的算力均非主力，大部分的算力其实在BTC链上随时可能来支援，尤其是比特大陆控制着全球最大的比特币算力，在潜在算力上具有绝对优势，且据说吴忌寒已经奔赴新疆调整矿场部署。因此，胜负的结果并不是现在能预测的。

分歧点

战争爆发于ABC在BCH官网 https://www.bitcoincash.org 发布0.18版升级之后，CSW提出强烈批评，并且发布BSV版本，提出取消ABC的0.18版本升级，全网采纳BSV版本。此举遭到ABC团队和比特大陆等方面的反对，并对BSV版本提出反对。这次事件的主要矛盾点在于客户端采用的共识机制不同，两个版本的主要差别在于：

Bitcoin ABC方案

对区块内交易使用CTOR（顺序交易排序）交易排序规则替代了原有的TTOR（拓扑交易排序）交易排序规则。
设置了最小的交易大小（100bytes）防止对SPV的攻击。
增加了两个操作码OP_CHECKDATASIG和OP_CHECKDATASIGVERIFY，以便引入外链。
push-only规则。

Bitcoin SV方则十分简单：

区块大小上限从32M扩展到128M
启用加减乘除的操作码以便在未来支持链上智能合约
恢复中本聪早期版本设计了但被禁用的4个操作码

CSW对ABC 0.18版本的两个更新都提出反对，认为：

OP_CHECKDATASIG和OP_CHECKDATASIGVERIFY能够被用来设计赌博应用，因此会导致BCH主链被政府封杀。此逻辑因为两个原因在争论中淡出：[1] 没有这两个操作码，BCH也可以设计赌博应用，只不过更复杂一些；[2] 法律上缺乏对公共基础设施被用于犯罪用途而遭封禁的依据。
CTOR对BCH不是必要的改进，还会增加基础协议的复杂性。这一点争议较大，Rawpool研究报告支持上述反对CTOR的意见，而Markblundeberg提交在Reddit上的文章分析认为CTOR本身近期对BCH系统的改进不明显，长期也不确定，但目前升级能够为后续的石墨烯升级提供便利，后者有助于实现更大区块容量。ABC发布的BCH路线图也说明CTOR是后续石墨烯和大区块升级的先导升级。Jonald Fyookball则综合分析了CTOR的作用、优势和升级的必要性。

而Bitcoin ABC反对BSV的主要是将区块大小上限扩展到128M，主要理由为：
目前BCH每块实际容量在200k左右，现有32M区块上限是实际容量的160倍，没有扩容的市场需求。对此，CSW一方强调他们向大的银行和百货公司推荐使用BCH时，这些大公司强调BCH容量限制太小，无法满足它们的需求。因此，先升级128M然后取消区块容量上限是吸引大公司应用BCH的先决条件。
此外，BSV的128M扩容并不成熟，缺乏相应的测试数据。对此，CSW没有提供必要的测试数据。2018年9月初BCH对现有32M上限进行了一轮压力测试，测试中最大区块为21M，有一些节点掉线，目前没看到权威的测试报告。在8月曼谷会议上，ABC、比特大陆和Roger Ver等各方表示，在11月升级完成后，将投入力量测试128M扩容的可行性，如果通过，考虑在2019年5月的升级中部署。

根据以上梳理，实际上最终存在分歧的是ABC0.18版本的CTOR和新增的操作码（OP_CHECKDATASIG，OP_CHECKDATASIGVERIFY）

关于CTOR和TTOR的区别：
TTOR的交易排序规则仅要求任意一个交易必须排在它所引用的交易后面，而不要求具体顺序。CTOR则在TTOR基础上要求按照交易ID的顺序来打包请求，这样区块链就会形成一张依据ID排序的顺序表，从而可以支持分片存储，让交易查找可以在一次查找中完成而不必翻找整个链。（这导致硬分叉）

关于操作码的争论：
OP_CHECKDATASIG/OP_CHECKDATASIGVERIFY让区块链可以验证链外数据，从而提供了外链的接口。Bitcoin ABC认为比特币二层网络应该建立在链外，Craig Wright则反对这种做法，认为比特币的二层网络也应该在比特币的链内（但这才是主要矛盾）。有了这两个操作码，其实，不用再修改共识就能接入反洗钱系统了，直接来个公民身份核验的二层网络，对交易进行签名就好了，谁合法谁不合法立显。

其他的变化则并不是太重要，ABC也并不是死守32M，在BCH链中，区块大小其实是可配置的，只要节点改一个设置就行了，128M仅仅是一种象征意义。加减乘除也只是象征意义。

交易所如何站队

目前站队的交易所为数不多，三大交易所中 OKEx、币安倾向于中立态度，火币的态度尤不明朗。分叉事件后
OKEx交易所则宣布，由于Bitcoin Cash(BCH)的分叉已经完成，原BCH已不存在。故 OKEx已将原有的 BCH 兑换为 BCHABC 和 BCHSV，兑换比例为1 BCH=1 BCHABC+1 BCHSV；今日，OKEx 先后开放 BCHABC 和 BCHSV 提取和相关交易对交易。
币安也采取了类似操作，但目前仅开放了 BCH 分发和交易。等区块网络稳定后再开放充值提现，安全第一；目前没有计划时间。
而火币则基于最长链原则，将 BCH 币种的所指含义明确为“Bitcoin ABC”，不过这种定义是有问题的，因为随后Bitcoin SV 的区块高度也一度超过 Bitcoin ABC。所以火币又出了一则BCH充值延迟的公告

矿工如何看待这次纷争

整个故事的要点就在上面介绍完了，不难发现，本次BCH事件是技术分裂在矿工社区治理上的一次很好的尝试，不管分裂前矿工各大派系炒得如何凶残，人性都是逐利的，这将演变成一场博弈——金钱与面子之争，而不在漩涡之中的矿工会采用POS的nothing at stake的操作模式，要么两边都挖，要么我都不挖；
当然也可以有鹬蚌相争，渔人得利的操作模式出现，这就是最近热门的重放攻击，它的最大伤害是对交易所而不是我们吃瓜群众，只要我们不做任何操作便不会有啥影响，因为重放攻击只能是你操作了其中一个针对你没有操作的那个兄弟币进行窃取。所以显而易见，风险较大的会是交易所，只要有人提取BCH，交易所在重放攻击下会被窃取等额的BSV，所以所有交易所都会停止BCH的提现操作，直至其中一条链增加重放保护。目前，ABC的重放保护升级拟定计划在2019年5月15日。所以算力战如果真的一旦开启，BCH社区将进入内耗，不相关的矿工最后只会支持胜者链，而它也将成为真正的BCH，另一条链也不会死，但是价值将沦为子嗣链。
如此可以发现，炒得如此火热的BCH算力之争，本质上与99%的人没有太大关系；但是它确是一个很好的矿工社区治理和技术社区治理的实验，也暗示着在区块链的世界即使像BTC这样的老大哥，也可以出现技术造成的算力分裂，以往一直宣扬矿工不会以危害利益而去作恶，但是矿工却可以坚持自己不同的信仰而造成内耗，这样的信仰分裂一旦造成头部矿场分裂，后果还是挺严重的，还好BTC硬升级的改动一般不大，不会出现诸如BCH如此之大的意见分歧，不过这将会成为一个很好的Lesson learn。

这次事件的结局如何

2018年11月16日凌晨2点16分，BCH硬分叉算力战落下帷幕，以BCH ABC的算力胜利告终。在SVpool挖出分叉前最后一个区块后，BCH就此分裂成BCH ABC和BSV两条链，随后吴忌寒便转发了一条Twitter称：“ 祝贺！在这个新的区块之后，BCH社区中将不会再有捣乱分子了！”澳本聪则放话表示游戏仍在继续。
BCH的“分叉战”虽然结束，但此次分叉带来的影响并未结束，BCH的“保卫战”也才刚刚开始。在BCH成功分出两条链的几个小时后，有圈内人士对BCH ABC的稳定性提出了质疑。他表示：BCH分裂后，BSV出块稳定，一个小时保证在6个块；BCH ABC则出现了区块“抽风”，一个小时有7-17个块，论链的稳定性，BSV胜。
而在分叉后，PeckShield态势感知平台安全人员也发现：ABC和SV两个链上均存在一些容量为几千笔交易的异常区块。这样的情况被称为粉尘攻击，而这种攻击极有可能造成BCH网络阻塞，进而拉高交易费用。除粉尘攻击外，ABC还遭受了在相同地址间重复发送交易的垃圾交易攻击，在一段时间内，这种垃圾交易攻击可能会填充ABC的全部节点，从而影响ABC链的空间可用性。
徐明星也发布朋友圈表示：“BCH‘算力大战’的重点是看ABC和BSV能否稳定出块，以及两条链是否出现区块大量回撤，标志着两条链是否成功。”而初生的两条链目前都处于不稳定的状态，因此，两条链最后的结局一切都尚未能随意下定论。
在此次硬分叉之前，加密货币市场整体的行情在11月15日起出现大幅波动，比特币等主流币的暴跌引起了整个加密货币市场的恐慌，市值前百币种有90余个币种应声下跌。BCH投资人受到的影响或许更大。

题外话：这可能并不是一场简单的算力大战

这次分叉可能不会像当年BCH从BTC的分叉那样干脆。BCH从BTC分叉之所以干脆，是因为部署了重放保护，两条链直接产生了隔离。而这次则不然，双方都会以自己的方式在同一条链上处理交易，争夺主链的控制权，这必将伴随着大量惨烈的孤块与孤链，是一场成百上千万的美元的消耗战。
不过事情的发展可能和大家预期的不同。这场战争并不是公平对等的，并不是谁能够控制51%以上的算力谁就能胜利。
为什么这么说？主要是双方在共识上的主要不同点。我们可以看到，ABC方实际上是缩减了共识的范围，除了增加了新的操作码（一时半会也不会真有人用）。而SV方实际上未对原有共识做实质上的变更。换句话说，正如CTOR是TTOR的子集一样，ABC共识是SV共识的子集。这导致了一个有趣的情况，即：ABC链即是SV链，但SV链不是ABC链。这几乎让SV方成为了这场大战中打不死的小强，因为ABC方算力再强链再长，也不能在实质上孤立SV共识，因为ABC的最长链就是SV的最长链。ABC块对于SV共识来说只是长得奇怪了点。

但是对于ABC共识来说，劣势就会很明显。
对于ABC共识，在任何情况下，会存在两个情况。情况一，ABC链更长，但SV随时可能在下一个块后面重新接上SV链。情况二，SV链更长，此时ABC链被孤立，必须付出更大的算力来扭转情况使ABC链超过SV链。
然而，这也并不代表ABC方一定会输。只要ABC方持续用算力否定SV块，SV方就得不到任何的挖矿奖励，这可能会导致SV方矿工的逐步分化瓦解，最终放弃SV共识而采用ABC共识。
当然的当然，ABC方要做到这一点必须持续付出比SV方多得多的算力。换成我们喜闻乐见的语言就是：用钱砸死你。
我们相信比特大陆有足够的算力也有足够的钱，不过我们也相信Craig Wright代表的理想主义并不会太廉价（主要是也不用花很多钱）。

补充

1、什么是重放攻击
除了技术路线和理念不同之外，需要格外关注的还有重放攻击的危险。什么是重放攻击呢？重放攻击(Replay Attacks)又称重播攻击、回放攻击，不仅仅存在于区块链世界中，在传统网络中也有这种攻击方式。在传统网络中，重放攻击是指攻击者发送一个接收者已接收过的数据包，用于迷惑接收者。攻击者可以是最初的发送者，也可以是拦截并重发数据的第三者。在区块链网络中，尤其是在两条分叉链上，会容易出现这种问题。当时在以太坊和以太经典分叉时就出现了这样的问题。
由于以太坊和以太经典在刚刚分叉时，除了ETH回滚了在The DAO事件被盗的Token之外，没有任何系统差别。因此发布在ETH上的广播可以被拿到ETC网络上立即重播一次。在分叉过程中，同一个私钥对应的地址内既存着ETH，又存着ETC。因此在分叉后，攻击者就可以发出重放攻击了。举个例子，黑客Alice从B交易所提现100个ETH时，交易所B必须先向ETH矿工网络广播交易信息，这条交易信息中有交易所的私钥签名。这时如果Alice想要作恶，她可以立刻将此广播在ETC网络中再广播一次。由于广播中包含交易所B的私钥签名信息，而且交易所地址中既有100个ETH，又有100个ETC，那么黑客Alice可以不经交易所同意（因为ETC矿工也看到了交易所的私钥签名），把交易所B地址中的100个ETC也划给自己。这时虽然Alice只提现了ETH，但是她同时把交易所B的ETH和ETC都取走了。比如当时著名网站云币网就被重放攻击偷走了40000个ETC [20-22]。
但是后期的分叉中，各分叉链和持有者都对重放攻击有所准备，比如客户端有重放攻击保护，交易所暂停重提币等。比如说在比特币和比特币现金分叉时，比特币现金交易广播必须使用SIGHASH_FORKID，这样比特币和比特币现金相互之间就没有重放攻击的干扰了。
但是在本次分叉中，和过去分叉不同得是，由于SV版本主动移除了“重放攻击保护”，这就意味着两条链面临着巨大的重放攻击风险。作为持有者，在分叉竞争结束之前，如果担心风险，最好不要使用任何版本的BCH客户端发送交易给其他人，除非收发地址都是自己。不发送交易是没有被盗走的风险的，一旦发送广播就会面临着被恶意攻击者偷走两种资产中的一种的风险。

2、为什么会引发算力大战？
由于重放攻击的存在，持有者发送任何交易都有风险，交易需求会大大减少，因此两边系统都会出现半停滞的状态。因此和过去不同，两条链会保持强烈竞争的关系，而不是相对独立的关系，难以“共存”，直到一方先主动硬分叉，加入新的重放攻击保护机制。但是如果一方先行硬分叉，可能会被部分持有者认为是不成功的表现，而且开发需要一定时间，因此有可能短时间内两条链都不会再次主动进行硬分叉。
我们都知道比特币系的区块链系统有难度调整机制，比如说比特币是每2016个区块调整一次难度，以确保出块时间是10分钟左右。如果算力增长过快，就加大难度。如果算力降低过快，就减小难度。但是如果一个分叉币诞生后，算力相比比特币骤减，短时间内（因为难度调整必须等待完成2016个区块周期才行）会导致出块时间大大延长，减少矿工收益。矿工收益减少，矿工就会流失；矿工流失，算力就会减少；算力再次减少，则出块时间再次延长，于是就变成了恶性循环。最终分叉链就会因为难以算出下一个区块都消亡。这也正是比特币白皮书中所强调了最长链原则，算力低的链极难追上最长链[23]。
为了解决这一问题，比特币现金最开始引入了EDA机制，每当出块时间增长，就会降低挖矿的难度，最多执行6次。但是这种机制也带来了问题，比如说算力暴击。由于算力可以在比特币和比特币现金中自由切换，因此算力会等待BCH在EDA调整机制下，难度降低到最低点后集中切换到比特币现金上，来快速出块（因为难度很低，算力很高），从而获得超额收益。算力暴击造成了BCH的出块不稳定问题。因此在后期的更新中，Bitcoin ABC主导了一次DAA难度调整硬分叉升级，并移除了EDA。在DAA机制下，BCH难度动态调整，每144个区块调整一次，平均约1天[2]。但是目前双方版本的算力旗鼓相当，如果没有更多变化的话，那么双方出块速度都会大大降低，这也会加剧了两条链的竞争关系。
目前社区内也有关于两条链“共存”问题的讨论。正常来说，在比特币现金或者比特币区块链上，由于通讯不及时或同时挖出新区块等原因，有时也会产生意外分叉。这时会有算力竞争，然后由最长链原则决定哪条链是合法的链。得到算力认可较少的链，会因无法挖出新区块而真正消亡。换句话说两条链不能共存。在本次分叉之争中，ABC版本和SV版确实有也有算力竞争，但是考虑到BCH整体算力并不高，并且双方算力上没有数量级的差距，而且可以借力于BTC等sha256系的算力，那么短时间内双方不太会出现由于算力不足无法出块进而消亡的情况。然而，重放攻击会严重影响交易的收发，用户在很多场景下无法使用，实际上短期内两条链是不能“共存”的。这意味着必须有一方再主动硬分叉一次，加入新的重放攻击保护机制，然后BCH才能变成真正的互不干扰的两条链。

除此之外，本次算力大战还有两个点需要格外注意：
矿池的份额不一定代表算力持有者的真正的态度。比如说某矿池虽然支持某个版本的路线图，但这不代表在该矿池挖矿的所有矿工都支持这一路线图。但也有旗帜鲜明支持某一个路线图的矿池，比如SVpool，就是为了SV版本而建立的矿池。
比特币算力可能影响最终的结果。由于BCH和BTC都是属于双sha-256挖矿算法，那么比特币庞大的算力也可以随时切换过来。目前BTC算力约47.3 EH/s，BCH算力约4.65 EH/s，BTC是BCH的10倍之多（数据统计来源BTC.com，统计时间2018-11-12 12:00 UTC+8）。而且有很多网站都提供比特币算力的租借服务，因此比特币算力可能是影响这场算力大战的重要因素。

欢迎订阅「K叔区块链」 - 专注于区块链技术学习
博客地址：http://www.jouypub.com
简书主页：https://www.jianshu.com/u/756c9c8ae984
segmentfault主页：https://segmentfault.com/blog/jouypub
腾讯云主页：https://cloud.tencent.com/developer/column/72548