作者：汪海波
原文：
http://www.jianshu.com/p/6f7d31a699a8SegWit2x是基于纽约共识(New York Agreement)的比特币升级方案，主要包括了两个功能升级：隔离见证激活和2MB区块升级，目前已经发布了Beta版。
为了更清楚地解释SegWit2x是如何工作的，我们先从比特币现有的升级方案说起：
矿工激活软分叉 —— MASF(Miner Activated Soft Fork)
在MASF出现之前，比特币的技术升级往往是由开发者决定一个激活时间，在激活时间之后，只有升级的区块才能被全网接受。比如中本聪就曾以此方法针对丢币漏洞、区块大小和Sigops限制、交易额溢出等问题进行过升级修复。
还有一个例子是P2SH的激活，激活时间是由Gavin Anderson指定的。与之前稍有不同的是，P2SH是经过了一段时间对两个不同P2SH技术方案(BIP16和BIP17)的算力投票后，然后在某一确定时间进行激活的。
这样的激活方式优点是简单粗暴、见效快；缺点是对于旧节点不够友好，一旦新功能被激活，未升级节点产生的区块会被立刻拒绝。随着比特币用户增加、价值变大，这样的升级方式显得落后，随之也就有了第一个MASF方案 —— IsSuperMajority，简称ISM，它的规则是这样的：
在对比特币协议进行升级时，对新版本区块的nVersion值进行简单+1操作；
升级开始后，如果在过去1000个区块(6~7天)内，有750个区块的nVersion为新版本号（也就是说75%的算力已升级），那么新功能会被激活。所有新版本软件产生的区块会按照新规则进行验证，未验证通过会被拒绝。而旧版本软件产生的区块依然按照旧规则进行验证，只要合格同样可被网络接受。
如果标识为新版本的区块继续增加，达到在过去1000个区块内有950个区块的nVersion为新版本号，那么所有由旧版本软件产生的旧版本号区块会被拒绝，这样软分叉激活就完成了。
使用ISM进行升级的功能包括了BIP34(nVersion为2)、BIP66(nVersion为3)和BIP65(nVersion为4)。ISM较之以前的方案为新功能的验证和旧节点的安全升级预留了充裕的时间窗口，同样问题也是存在的。ISM每次升级nVersion值+1，一次只能激活一种新功能，想要激活另一种新功能就需要等待上次新功能完全升级完毕再进行。这样的限制对同时为多个功能进行算力投票造成了障碍，于是有了新的MASF方案——BIP9.
BIP9定义了一种新的升级方案，使用nVersion的0~28bits中的某一bit来表示激活某一种特性，规定新功能升级流程的起始时间和过期时间，并清晰定义了升级流程中的不同状态和状态迁移条件。
当MTP(表示一个区块和它之前10个区块的时间戳中位数)大于起始时间后，进入STARTED状态，这时矿工可以开始对该功能进行Signal(将对应的bit设置为1)；
如果在STARTED状态中的一个完整难度调整周期内(2016个区块)，有1916个区块将对应bit设置为1（表示95%的算力已经激活该功能），那么在下一个周期内进入LOCKED_IN状态；
LOCKED_IN状态将会持续一个难度调整周期，目的是为尚未设置对应功能bit的矿工留出缓冲时间，在这个周期内，未设置bit的区块依然可被接受；
LOCKED_IN周期结束后，会自动进入ACTIVATED状态，这时未升级新功能的区块都将被拒绝，同时，用于升级的bit也会被释放；
如果在过期时间前仍未完成激活，那么升级失败。
第一个使用BIP9进行升级的功能是CHECKSEQUENCEVERIFY opcode，这是一个由BIP68/BIP112和BIP113共同定义的升级，使用bit0做为标识位。这次BIP9升级自UTC时间2016年5月1日开始，在417312区块进入锁定状态，随着新功能在419328区块被激活，bit0被重新释放。BIP9定义的升级方式，为比特币升级提供了更加灵活的方式，在nVersion不同的bit上标识的新功能，可以同时进入激活流程且不会互相干扰。
SegWit(BIP141/BIP143/BIP147)同样使用BIP9进行功能激活，使用bit1做为标识位，定义起始时间为UTC时间2016年11月15日凌晨，过期时间为UTC时间2017年11月15日凌晨。但由于比特币社区各方对于扩容方案持有不同意见，到目前为止，SegWit区块仍然没有达到LOCKED_IN的阈值。为了在过期时间前激活SegWit，社区内出现了一种充满争议的升级方案 —— BIP148。
用户激活软分叉 —— UASF(User Activated Soft Fork)
BIP148是为了激活SegWit而被提出的，它制定一种强制激活规则：在2017年8月1日到2017年11月15日这段时间内，如果SegWit没有被激活且没有被锁定(依然处在投票阶段)，那么在这段时间内没有将SegWit标识位bit1置位的区块都会被拒绝。那么在BIP148的区块链上，将只会有SegWit区块存在，在一个完整的难度调整周期后，SegWit将会进入BIP9的激活状态。
严格来讲，这不是一个由用户投票来激活的方案，BIP148强制指定了一个时间来要求全部算力必须标记SegWit，否则会被BIP148拒绝，并随时面临reorg的风险。同时，这也不是一个直接激活SegWit的方案，这是一个通过软分叉来帮助SegWit进入LOCKED_IN阶段的方法，起到了间接激活的作用。
在算力意见不统一的前提下，执行BIP148-UASF是危险的。BIP148节点会只接受SegWit区块而拒绝非SegWit区块，非BIP148节点会同时接受SegWit和非SegWit区块，所以在UTC时间2017年8月1日后，会有很大概率分裂成两条链，对于非BIP148链来说，一旦区块高度被BIP148链超过，那么就会面临着reorg，之前挖到的区块全部作废，矿工承担了巨大的损失。同时，非BIP148链为了保护自己不被reorg，也会发起防御性的硬分叉来拒绝激活了SegWit的区块，整个局面会十分混乱。同时，经济因素也会是分叉过程中的决定因素，不在本文的讨论范围内，就不做多说了。
SegWit2x —— SegWit、BIP91和BIP102的合体
SegWit2x版本中除了会实现全部的SegWit功能外，还实现了BIP91和BIP
102。BIP91的目标是更加缓和地间接激活SegWit，防止BIP148-UASF造成的混乱局面。BIP91基本沿用了BIP9的MASF激活步骤，设置起始时间为UTC时间2017年6月1日，过期时间为2017年11月15日（同SegWit一样），使用bit4做为标识位，但是在进入LOCKED_IN状态的数值有所调整，从『2016个区块中的1916』更改为『336个区块中的269』(将激活周期从大约2周降低到了2.3天左右，同时将激活阈值从95%降低到了80%)。
了解了BIP91的机制，我们对照着SegWit2x工作组发布的时间表来看，一个关键的时间点是2017年7月21日，这是矿工部署节点并激活bit4和bit1的时间。同时我们来看一下未来最近几次难度调整的的时间：假设在未来一段时间内算力没有大幅波动，一个难度调整周期近似看做13.5天，那么可以估算出：区块473760会在7月2日左右被挖出，区块475776会在7月15日左右被挖出，区块477792会在7月28日左右被挖出，区块479808在8月10日左右被挖出。由此进一步推测：
7月21日签署NYA的矿池开始部署SegWit2x节点，如果立刻得到80%以上算力支持，激活bit4和bit1，那么在2.3天后的7月23日左右，BIP91会进入LOCKED_IN状态。应该是出于快速激活的考虑，BIP91在进入LOCKED_IN状态后就不再接受未激活SegWit标识位的区块。所以BIP91的软分叉是发生在LOCKED_IN阶段的，这时所有未激活SegWit标识位bit1的区块都将被拒绝，又因为SegWit2x算力占据绝对优势，小算跟随的概率较大，所以届时全网的区块会全部为标识bit1的区块；
再经过2.3天至7月25日左右，BIP91被激活；
时至难度调整的7月28日，由于SegWit2x仅部署后半个难度调整周期，前半个周期(7月15日~7月21日)未进行部署，且因为Segwit基于BIP9激活，需要整个周期内95%的算力支持，所以在这个时间点SegWit不大可能进入LOCKED_IN状态；
那么紧接着的时间点是8月1日的BIP148-UASF，由于BIP91的激活，整个网络已经完成了软分叉，此时网络上已经全部都是激活SegWit标识的区块了，所以BIP148也就不再起作用了；
8月10日的难度调整时，上一个周期的SegWit算力支持已达到了95%以上，这时便进入LOCKED_IN状态，随后在8月23日左右的难度调整时，SegWit全面激活。
另一个SegWit2x实现的是BIP102，也就是将原有1MB大小的区块容量扩展到2MB。与通过指定时间和指定算力阈值进行分叉的方法不同，SegWit2x的BIP102实现要求在SegWit功能激活高度后的第144*90个区块开始接受2MB大小的区块(按照之前的推算，SegWit激活大约发生在8月23日，那么2MB的硬分叉会发生在11月20日左右）。除了将区块大小增大到2MB，BIP102还将包含Witness数据的区块大小从4MB提升到了8MB、单个TX的Sigops限制从16000提升到了32000等。
总结
SegWit2x的Beta版已经发布，涉及到软分叉的部分已基本完成，同时testnet5也已上线。由于2MB区块的硬分叉要到11月20日左右才会发生，所以部分关于硬分叉的细节仍然在讨论和实现中。SegWit2x的快速发布，以及矿工对NYA的签署，降低了8月1日BIP148-UASF到来时的风险，同时为2MB分叉预留了时间，在当前是值得社区进行广泛测试和评估的。
