本文章由火币区块链研究院出品，本报告发布时间2018年11月13日，作者：袁煜明，马天元。
摘要
BCH社区最知名的开发团队之一Bitcoin ABC提出了比特币现金0.18版客户端提案，并预计在18年11月15日进行一次“硬分叉式”的客户端升级。0.18版最重要的特性包括：1. 用规范交易排序（CTOR）替代拓扑交易排序（TTOR）2.激活OP_CHECKDATASIG和OP_CHECKDATASIGVERIFY（DSV）两个操作码。
然而BCH社区另一知名开发团队NChain却提出了另一提案，即Bitcoin SV。Bitcoin SV主张：1.将版本退回到0.1版并永久锁定，同时将区块扩容到128 MB。2.激活OP_MUL，OP_INVERT，OP_LSHIFT和OP_RSHIFT四个操作码。
本次分叉同以往的硬分叉有所不同，短期内两条链无法“共存”。由于客户端没有重放攻击保护，区块链有遭遇重放攻击的危险。在ABC版本链上的交易，也可以在SV版本链上重新广播并打包，部分持有者可能会出现Token被故意取走的情况。这意味着两条链关系会趋向于激烈竞争而非各自独立，直到一方加入新的重放攻击保护机制才能结束。不过值得关注得是，算力多少既需要考虑各个比特币现金矿池的份额，也需要考虑矿池中不同矿工的实际想法，同时比特币的算力持有者和租借者也会增加这次“算力战争”的变数。
报告正文
1. 背景介绍
Bitcoin ABC一直是BCH社区最知名的开发团队之一，得到社区内众多矿池的支持，包括蚂蚁矿池，BTC.com，Bitcoin.com，ViaBTC矿池等。其主导了比特币现金的多次升级。比如18年5月的比特币现金32 MB扩容（0.17版本）[1]，17年11月的DAA难度算法调整（0.16版本）等[2]。比特币现金最早的扩容方案也是由Bitcoin ABC提出的。在18年8月，Bitcoin ABC又提出了比特币现金0.18版本的方案[3]，并且是一次按照既定规划执行的升级[4]。
然而，BCH社区另一开发团队NChain团队反对这次升级，认为升级过于频繁，升级内容不利于BCH发展，并提出了Bitcoin SV方案，主张将BCH回到最早的0.1版本并永久锁定。本次支持Bitcoin SV的阵营包括：NChain、Coingeek矿池、SV pool、BMGpool等。
NChain团队包括社区知名人物Craig S Wright。Craig S Wright来自澳洲，此前曾自称是中本聪，并得到当时Bitcoin核心开发者Gavin Andresen的认可[5]。但是Craig S Wright一直未能出示有效的决定性证据（如签名等）。后来他加入NChain团队，并成为BCH首席科学家，也得到了BCH社区一定程度的认可。此外，Bitcoin SV方案还得到了目前BCH算力最高的矿池之一Coingeek的支持，Coingeek目前占BCH全网算力约32.6%，而且同时Coingeek也是一家知名的区块链行业媒体，Coingeek的核心人物是Calvin Ayre。另外SV Pool是由于Bitcoin SV方案而组建的矿池，目前是BCH算力第二高的矿池，算力占比约18.7%左右。BMG Pool是BCH算力第三高的矿池，占比约14.5%（24小时出块占比，数据统计来源coin.dance，统计时间2018-11-12 12:00 UTC+8）。
2. Bitcoin ABC方案技术分析
本次Bitcoin ABC提出的升级方案预计在2018年11月15日16:40 UTC正式部署[6]。新增的特性如下[3]：
1）引入新的操作码OP_CHECKDATASIG，可以改进BCH的脚本语言来进行对区块链外部信息的验证。这将会允许使用oracle预言机和跨链原子交换；
2）引入规范交易排序（CTOR，canonical transaction ordering），这种排序方式可以支持未来大规模的扩容；
3）完成几个小的技术修复和改进。
我们都知道无论是比特币还是比特币现金都是图灵不完备的区块链。当时中本聪等开发者认为过多的特性会降低比特币系统的安全性，因此比特币被设计成是图灵不完备的，并不能支持智能合约，但是却能够使用一些比较简单的脚本语言。
OP_CHECKDATASIG就是这样一种操作码，它最核心的用途是和区块链外部的世界进行通信，即oracle预言机。很多预测竞彩类项目都有对预言机的涉及。那什么是预言机呢?假如Alice和Bob想对世界杯冠军的归属进行对赌，Alice认为法国能够获胜，Bob则认为克罗地亚能够夺冠，那么Alice和Bob就要按照商量好的赔率锁定一些资金，一旦比赛结束，就把这些资金给猜对的人。为了安全起见，过去Alice和Bob都要找一个可信的第三人来保管，博彩公司也就应运而生。而区块链能够去中介化，双方可以把资金Token锁在区块链中，就不需要第三方可信的人了。虽然锁定这笔资金很容易，但是区块链如何按照比赛结果进行赔付呢？这就需要oracle预言机了。
支持智能合约的区块链可以很容易地完成这个操作，只要将外界的比赛结果输入，然后合约向赢家支付奖金即可。（注：不过判断结果信息的真假并不在区块链能够处理事务的范畴之中。永远也不能排除有人恶意将例如“克罗地亚夺得冠军”这种结果上传的行为。但是可以通过机制设计来大幅减少假信息的上传可能性。如多人共同输入，仲裁、错误惩罚等，而且例如世界杯比赛、下周某时某分某股票的价格等结果是一个完全客观、公开、公允的信息，没有任何争议。一旦输入结果错误全网的所有节点都可以看到，假信息骗过大多数人的可能性几乎为0）
但是像比特币现金和比特币的区块链，它们没有智能合约，是无法支持oracle预言机的。其实，预言机判断谁是赢家，本质上就是一个验证过程。过去比特币现金只能支持交易信息的验证，不能对外部信息进行验证。比如说，Alice可以用自己的私钥对交易进行签名操作，来确认这条交易时她本人发出的，即通过现有的OP_CHECKSIG操作码。那是不是可以模仿OP_CHECKSIG操作码，设计另一种操作码让它可以验证除了交易之外的其他信息的签名呢?因此，于是社区就设计了一种新的操作码OP_CHECKDATASIG，让它也能验证其他信息的签名，做出二元选择并支付。该提案最早由Bitcoin Unlimited的Andrew Stone提出[7]。
这个操作码的引入可以让BCH实现预言机的简单脚本操作，理论上可被用于竞彩和赌博。可以在一定程度扩大比特币现金的使用范围，但同时也会增加其合规风险。
Bitcoin ABC的0.18版本的第二个重要改动就是移除拓扑交易排序（TTOR，topological transaction order，并改为规范交易排序（CTOR，canonical transaction ordering）。交易排序指得就是在一个区块内的多笔交易的顺序。之所以交易需要排序，是因为比特币现金（或比特币）中会有这种类型的交易：Tx2交易需要依赖Tx1才能发生，这种情况下，Tx2交易使用了Tx1交易的交易输出。
在以前的TTOR结构下，一个区块内的交易顺序是：
1. 区块头（coinbase）交易；
2. 在一个区块内，当Tx2使用Tx1交易的交易输出时，Tx2交易必须排在Tx1交易后；
3. 其他所有的交易（不排序）。
如果改为CTOR结构之后，一个区块内的交易顺序变成了：
1. 区块头（coinbase）交易；
2. 按照交易ID排序的所有交易。
将TTOR改为CTOR的话，属于修改共识规则的范畴，必须通过硬分叉来完成。那为什么要修改TTOR呢？因为过去比特币现金区块较小，约为32MB，无论是哪种排序影响都不大。但是如果希望比特币现金能够扩容到100MB、1GB甚至1TB，而且满负荷交易的时候，那么排序就至关重要了。支持者认为采用CTOR比TTOR逻辑更简化，可以有效地加快超大区块打包时间和传输效率，简化软件应用，并且认为TTOR作用并不大[8]。除此之外，社区部分成员认为采用CTOR还可以让比特币现金采用分片技术（Sharding）[9]和采用石墨烯协议（The Graphene protocol）更为容易[10-11]。
但是也存在反对意见，大部分反对意见认为基于目前的TTOR，并不会让分片和石墨烯的实施更为复杂，也很难显著提高效率，而且CTOR没有经过长时间的实践。而TTOR不会拖累系统，也经过长时间的检验，而且能够保留交易之间的父子关系，因此没必要通过硬分叉来更换[12-16]。
3. Bitcoin SV方案技术分析
Bitcoin SV方案同样选择在11月15日进行部署0.1版本，其新增的特性如下[17]：
1）重新启用操作码 OP_MUL, OP_INVERT, OP_LSHIFT, 和OP_RSHIFT (18年11月升级后生效)；
2）增加每个脚本操作码的字节数到500（18年11月升级后生效）；
3）将区块扩容到128MB（18年11月升级后生效）；
4）将P2P信息降低到接近excessiveblocksize；
5）移除自动重放攻击保护；
6）移除18年5月的升级；
7）移除 GUI；
8）将 excessiveblocksize 作为一个标准参数；
9）将excessiveblocksize 和maxblocksize 加入到RPC getinfo；
10）修复CVE-2018-17144。
Bitcoin SV的全称是Bitcoin Satoshi Vision，即“中本聪愿景比特币‘。其核心理念就是回到中本聪客户端0.1版本，并永远锁定，不再做任何升级。同时将区块大小扩容，分两步走，第一步是将区块大小扩充到128 MB，第二步是将区块大小的控制权交还给矿工，由矿工投票设定合适的区块大小以适应比特币现金的发展。之所以SV想要永远锁定在0.1版本，是因为它认为过去BCH升级更新过于频繁，而且也不认可ABC版本BCH的路线图（比如虫洞协议等），它认为频繁改动不利于形成稳定的共识和长久的信任。因此它希望将客户端永远锁定在0.1版本，并不再更新。
关于BCH社区的发展路线图问题，目前Bitcoin ABC确实是最有影响力的开发团队，ABC团队主导的BCH开发路线图也确实有最广泛的共识。但是很难说一定是ABC团队“掌控”了BCH，因为仍然有Bitcoin Unlimited等其他竞争开发团队，包括NChain也是非常知名的BCH开发团队。ABC团队主要依靠捐赠，主体上也是一个非盈利的团队。不过另一方面，如果将BCH锁定0.1版本，确实可以增强BCH的去中心程度，因为没有团队可以对BCH的发展路线进行“主导”了，但也确实可能会牺牲掉未来BCH顺应时代发展的一些机会，可以说锁定0.1版本是一把双刃剑。
同时，我们可以注意到Bitcoin SV的版本还重新启用了4个曾被中本聪等早期开发者禁用的四个操作码。这四个操作码的功能分别是：
我们可以看出Bitcoin SV重新启用的操作码主要是用于进行简单运算类内容。这些操作码均是早年被开发者禁用掉的操作码。比如说OP__LSHIFT，当时的比特币客户端在处理包含OP_LSHIFT的事务时，会导致客户端在某些机器上崩溃，于是在0.3.5版本这个操作码就被禁用掉了[18]。
有评论指出如果直接启用这些操作码，可能会令Bitcoin SV版本的BCH和0.1版本的“中本聪客户端”有不兼容的情况。作为回应，NChain开发者表示本次重启会改变这些操作码的定义，比如说过去OP_LSHIFT和OP_RSHIFT是对数字进行移位操作，Bitcoin SV版本会让这两个操作码的对象改为字符，它们可以对最高520 bytes的字符串进行操作[19]。
另外在扩容方面，SV版本认为目前的32 MB区块体积仍然不够，而且难以商用，虽然目前BCH区块实际使用率并不高（以这篇文章完成时最近的20个区块为例，从556256高度到556275高度，区块平均体积约57KB，折合0.057 MB，占总32 MB区块大小约0.17%）。SV版本希望将区块扩充到128MB，并且在后期的更新中逐渐把区块大小确定的权力交还给矿工，未来由矿工算力投票确定区块的大小以符合未来BCH的商用。
4. 什么是重放攻击
除了技术路线和理念不同之外，需要格外关注的还有重放攻击的危险。什么是重放攻击呢？重放攻击(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客户端发送交易给其他人，除非收发地址都是自己。不发送交易是没有被盗走的风险的，一旦发送广播就会面临着被恶意攻击者偷走两种资产中的一种的风险。
5. 为什么会引发算力大战？
由于重放攻击的存在，持有者发送任何交易都有风险，交易需求会大大减少，因此两边系统都会出现半停滞的状态。因此和过去不同，两条链会保持强烈竞争的关系，而不是相对独立的关系，难以“共存”，直到一方先主动硬分叉，加入新的重放攻击保护机制。但是如果一方先行硬分叉，可能会被部分持有者认为是不成功的表现，而且开发需要一定时间，因此有可能短时间内两条链都不会再次主动进行硬分叉。
我们都知道比特币系的区块链系统有难度调整机制，比如说比特币是每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）。而且有很多网站都提供比特币算力的租借服务，因此比特币算力可能是影响这场算力大战的重要因素。
因此，目前社区内的一些评论认为“某版本有多少算力支持”只是估算，并不准确，而且变数较多。因此本报告不对双方版本的算力多少进行统计和评估。另外某非常知名网站提前开始了对双方路线的价格预估。根据价格反映的结果，SV版本每个BCH约为0.0177 BTC，ABC版本每个BCH约为0.0639 BTC。这意味着目前该网站上Bitcoin ABC版本的BCH路线图更受资金支持（统计时间2018-11-12 12:00 UTC+8）[24]。这也是目前市场对双方支持情况的一瞥。
6. 总结
Bitcoin ABC和Bitcoin SV提出的BCH路线图，都分别拥有各自的支持者。ABC版本的路线图更强调定期对BCH进行更新和完善，并且支持更复杂的脚本和通过多层网络实现智能合约等。而SV版本的路线图更希望BCH稳定在一个协议上不再变化，回到比特币早期的版本，且不支持智能合约。除此之外，和过去的分叉不同，本次分叉有重放攻击的风险，而且由于算力的分配情况，双方阵营可能会维持一定时间的激烈竞争关系。直到一方主动硬分叉加入新的重放攻击保护机制之后，两条链才能“共存”。不过，虽然比特币现金社区内部现在正在经历着激烈的斗争，甚至还带来一些安全隐患，但也正是加密社区的魅力所在。在这样的加密社区内，没有一个绝对的权威能够控制路线图的走向，社区成员们可以自由选择自己的发展路线并进行尝试。因此这肯定是一次有意义的探索。
7. 附录
[1] November hardfork changes to be completed by August 15th https://www.bitcoinabc.org/2018-08-08-nov-code-complete-reminder/
[2] Difficulty Adjustment Algorithm Update https://www.bitcoinabc.org/2017-11-01-DAA/
[3] Announcing Bitcoin ABC 0.18.0 https://www.bitcoinabc.org/2018-08-20-announcing-bitcoin-abc-0-18-0/
[4] Medium Term Development Plan https://www.bitcoinabc.org/2017-12-01-dev-plan/
[5] Satoshi http://gavinandresen.ninja/satoshi
[6] Next Scheduled Bitcoin Cash Network Upgrade https://cash.coin.dance/
[7] Enable oracle-based data import via OP_DATASIGVERIFY https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/bucash1.3.0.0/doc/opdatasigverify.md
[8] Canonical Transaction Ordering for Bitcoin https://blog.vermorel.com/pdf/canonical-tx-ordering-2018-06-12.pdf
[9] Sharding Bitcoin Cash https://medium.com/@Bitcoin_ABC/sharding-bitcoin-cash-35d46b55ecfb
[10] Benefits of Canonical Transaction Order https://medium.com/@Bitcoin_ABC/benefits-of-canonical-transaction-order-ec30ae62d955
[11] Graphene: A New Protocol for Block Propagation Using Set Reconciliation http://forensics.cs.umass.edu/graphene/graphene-short.pdf
[12] Canonical Transaction Ordering for Bitcoin: A Critical Evaluation https://nchain.com/app/uploads/2018/09/Canonical-Transaction-Ordering-A-Critical-Evaluation-Final.pdf
[13] Private vs trustless sharding https://www.yours.org/content/private-vs-trustless-sharding-12d00d1fd865
[14] Research on CTOR and TTOR of Bitcoin https://medium.com/@Maylee0508/research-on-ctor-and-ttor-of-bitcoin-447ffde49a91
[15] Why ABC’s CTOR Will Not Scale https://medium.com/@g.andrew.stone/why-abcs-ctor-will-not-scale-8a6c6cf4a441
[16] A technical dive into CTOR https://www.reddit.com/r/btc/comments/9ehll3/a_technical_dive_into_ctor/
[17] Bitcoin SV version 0.1.0 Release Notes https://github.com/bitcoin-sv/bitcoin-sv/releases
[18] CVE-2010-5137 Detail Description https://nvd.nist.gov/vuln/detail/CVE-2010-5137
[19] BSV's new OP_LSHIFT and OP_RSHIFT are not compatible with Satoshi's Bitcoin v0.1.0 https://www.reddit.com/r/btc/comments/9ce492/bsvs_new_op_lshift_and_op_rshift_are_not/e5b9vpe/
[20] How to deal with the Ethereum Replay Attack https://medium.com/@timonrapp/how-to-deal-with-the-ethereum-replay-attack-3fd44074a6d8
[21] OKcoin的重放攻击解读 http://8btc.com/thread-67367-1-1.html
[22] 关于云币网用户 ETC 快照分配的详细说明https://weibo.com/ttarticle/p/show?id=2309404001976231797438&mod=zwenzhang&sudaref=www.google.com&display=0&retcode=6102
[23] Bitcoin: A Peer-to-Peer Electronic Cash System https://bitcoin.org/bitcoin.pdf
[24] Pre-Fork Trading for Upcoming Bitcoin Cash Hard Fork rk https://poloniex.freshdesk.com/support/solutions/articles/1000270700-update-on-the-upcoming-bitcoin-cash-hard-fork
火币区块链应用研究院
关于我们：
火币区块链应用研究院（简称“火币研究院”）成立于2016年4月，于2018年3月起全面拓展区块链各领域的研究与探索，主要研究内容包括区块链领域的技术研究、行业分析、应用创新、模式探索等。我们希望搭建涵盖区块链完整产业链的研究平台，为区块链产业人士提供坚实的理论基础与趋势判断，推动整个区块链行业的发展。
火线视点是火币研究院推出的区块链市场热点类研究报告。该系列聚焦区块链行业最新热点新闻事件、热门话题事件，以专业、客观的视角解读事件的本质，为广大读者提供及时且通俗易懂的分析。
联系我们：
咨询邮箱：[email protected]
公众号：火币区块链研究院
Twitter:Huobi_Research
Medium:Huobi Research
Facebook:Huobi Research
免责声明：
1. 火币区块链研究院与本报告中所涉及的数字资产或其他第三方不存在任何影响报告客观性、独立性、公正性的关联关系。
2. 本报告所引用的资料及数据均来自合规渠道，资料及数据的出处皆被火币区块链研究院认为可靠，且已对其真实性、准确性及完整性进行了必要的核查，但火币区块链研究院不对其真实性、准确性或完整性做出任何保证。
3. 报告的内容仅供参考，报告中的事实和观点不构成相关数字资产的任何投资建议。火币区块链研究院不对因使用本报告内容而导致的损失承担任何责任，除非法律法规有明确规定。读者不应仅依据本报告作出投资决策，也不应依据本报告丧失独立判断的能力。
4. 本报告所载资料、意见及推测仅反映研究人员于定稿本报告当日的判断，未来基于行业变化和数据信息的更新，存在观点与判断更新的可能性。
5. 本报告版权仅为火币区块链研究院所有，如需引用本报告内容，请注明出处。如需大幅引用请事先告知，并在允许的范围内使用。在任何情况下不得对本报告进行任何有悖原意的引用、删节和修改。