注：本文作者为软件工程师Steve Sokolowski。文章内容为作者个人观点，不代表本站立场。
Core即将发布的隔离验证（SegWit）代码是比特币行业的一大转折点。虽然区块容量问题拖了比特币将近一年的后腿，但人们却迟迟没有给出推翻Core发展路线图的具体时间。而这一切都将被隔离验证改变，因为它代表着比特币未来发展的重大转折。
隔离验证的软分叉承诺现有节点不会被网络淘汰，可以继续运行。虽然这种承诺听起来很棒，但事实上每个程序员都经常会给出肯定的言论，同时还伴随着明确的免责声明，以防将来出什么差错。最坏的情况就是软件运作出现偏差、被滥用，因为根本没人注意到其中存在的问题。
通过软分叉来执行隔离验证代码会破坏大部分现有的软件。另外，这种额外的复杂性将来还会降低开发者的效率。在本篇文章中，我会详细说明隔离验证的主要缺点，以及以软分叉方式来实施隔离验证对普通用户带来的不利影响。 我建议社区反对Core的软分叉决定，应该将软分叉升级为硬分叉，把最终决定权从矿工手中转移到用户和投资者手中。而执行此硬分叉的最佳时机已经减少到数周或者几个月。
隔离验证是对比特币协议的补充，将数据格式一分为二：现有的区块和“验证”分段。现有区块中的交易可以作为验证分段中详细数据的指引。举个例子，一笔涉及多个收款方的交易可能在现有区块中占据较小空间，因为现有区块中的签名不必涵盖所有交易信息。
隔离验证的支持者指出了该计划的多个优势。其中一点就是隔离验证能够解决交易延展性（）问题。该问题导致用交易哈希来跟踪未经确认的交易难上加难。同时，支持者
不幸的是，我认为隔离验证的缺点远远大于其优点。首先我会列明一些技术缺陷，然后讲述其最致命的缺点——部署方式。
首先，检查区块中不断上涨的交易有效性是很重要的。虽然隔离验证有效提高了1MB的区块空间应用率，但所有的交易数据还是会在区块链中接收并存储。在隔离验证中，验证数据是分开接收的，因此1MB的区块中会包括100KB的额外交易验证数据，一共就是1.1MB。但事实上并没有那么简单：就算区块容量只简单增加了0.1MB，交易所需带宽也会比想象中更多。
可以把这种情况看成了两个Excel表格。这两个表格包含了不同的汽车数据，而车牌号则需要同时记录在意外事故报告和检测报告中。如果将两个报告的表格合二为一，那么车牌号就只用记录一遍。而隔离验证的交易标识符的重复会产生额外的数据。
另外，3月份的时候我说过，隔离验证只会在比特币交易比较复杂以及人们选择使用的时候才会增加小部分交易空间。隔离验证不会为那些只有一次输入输出的简单交易提高区块容量。而且，人们只会在看到潜在利益的前提下才会去使用隔离验证，因此软分叉升级可能会很慢或者根本不会进行。
其次，隔离验证会破坏加密货币领域的现有软件部署模式。区块浏览器的损失可能最大。一旦首笔隔离验证交易完成，很多浏览器就会掉线。我为200多个币创建过区块浏览器，因此我敢断言，处理这种非标准化的交易是极其复杂的任务。货币客户端不会跟踪所有地址的余额，因此你就只能改写自己的软件来适应新的数据格式，然后为整个区块链重建索引。
我们曾遇到过类似情况，当时一共花了我们3个月的时间才使得我们的区块浏览器代码在没有产生数学错误或丢失交易的前提下顺利运行。因为交易一开始就进行计算了，漏洞在数日变址之后才产生。但是计算出错的步骤不太明显，整个调试过程大部分都靠猜测来进行。验证新代码有效性的唯一方法就是删除数据库和再次重建索引，前提还要了解计算总值。我们手中的区块浏览器数据多达1.1TB，是比特币区块数据的两倍多，这就意味着要不断为500GB串联的汇总数据重建索引。很多数据分析服务最终都会宣告失败（或者更糟，反馈错误数据），因为开发者通常没有大量的时间进行更新升级，这就造成了大量重要的比特币代码的中心化。
但不只是区块浏览器会遭受劫难。拥有定制比特币客户端的交易所也不得不修改产品代码，重点是这些代码运行多年，从未有过任何问题。经营有方的公司不会在没有经过大量测试的前提下轻易修改产品代码，毕竟这关系着一大笔资金。这种升级的代价很大，因此我反对采用Core的计划激活隔离验证代码。需要处理大量交易的公司（这类公司通常对隔离验证有利）恐怕会认为支付高额交易手续费的风险比雇人重新编写代码的风险更小，因为重新编写代码可能会导致巨大的损失。
第三，就算所有服务机构都成功进行了升级，社区还是需要面临交易高度复杂性，最终阻碍比特币的发展。之前开发者只要理解和管理单一简化的区块链，而隔离验证实施之后，开发者就必须同时处理主链和验证数据事务。加密货币本来就是一个相对复杂的领域，开发者的能力是很重要的。目前比特币系统已经越来越复杂，几乎没有人能完全理解。隔离验证实施之后，系统会变得更加复杂，开发者的培训时间肯定会增加，我们很可能会失去大部分潜在人才。比特币社区本来就面临人才紧缺问题，特别是有道德的开发者，隔离验证反而会在复杂化系统的同时减少人才输入。
第四，即使每个开发者都认为系统复杂度提高不是什么大事，但是一旦隔离验证执行之后，就会永远存在。这就意味着，之后每个客户端的每次修改都要同时在现有的区块链代码和验证数据中测试。为了一些相对次要的改进而永久放慢发展的脚步真的值得吗？Core预计，隔离验证的稳定性需要3300多条线路的附加测试。所有测试都必须随着每一次修改来运行和更新，过程中可能会发现一些目前尚不存在但需要补充测试的问题。
第五，隔离验证的确能解决比特币的部分“历史遗留问题”，比如说交易延展性（transaction malleability）。不过隔离验证的解决方案未免过于复杂。数月以前，Bitcoin Unlimited推出了极瘦区块（Xtreme Thinblocks），能在接受大量数据时大大避免区块处理延迟的现象。相比之下，这种方式更加简单。
隔离验证提出的这一解决方案还有“画蛇添足”的嫌疑。大量的加密货币运行延展性交易都已经7年多了，从未出过什么差错。只要处理得当，延展性问题不会导致资金损失。Core认为解决交易延展性问题可以让智能合约和比特币系统的契合度更高。这种说法没错，但现在已经有一种和智能合约契合度很高的币了。Core应该把重点放在比特币的优势上，即货币交易。
Core急着解决交易延展性问题还是为了推动闪电网络（Lightning Network）正式落地。但闪电网络是永远不可能部署成功的。Theymos（曾是r/bitcoin版主）早就说过闪电网络在一开始的时候就在走向灭亡。因为他在比特币社区区块扩容问题上引发的战争肯定会殃及闪电网络。
Core随着客户端0.12版开始就不断添加各种新功能，却未事先了解过用户的需求。他们的新版本更新率很低，因为其中并没有任何引人注目的功能。Core不应该再继续召开一周一次的发展大会，这类会议从不涉及区块容量问题。他们更应该关注成本效益分析。他们添加任何新功能之前必须先考虑问题：这个新功能真的有人用吗？新功能是不是浪费时间，拖延了我们解决区块容量问题的进度？至于隔离验证试图解决的问题是否代表着用户需求，那就不得而知了。
最后，对于隔离验证最需要担心的一点同时也是其最具灾难性的影响就是：Core试图通过软分叉的方式激活隔离验证代码。软分叉是懦夫的行为，他们用这种方式将人们不想要的改变强加给他们。在软分叉投票中，矿工很可能会作出对自己影响最少的经济决策。他们不用向开发者支付任何改进软件的费用；他们不用担心运行多年仍功能完好的代码改变后造成的资金损失的风险；他们不用担心是否有人使用隔离验证更新；他们更不用担心要怎么和那些不常上论坛的人互通消息。其实他们根本无权作决定，那些必须承担代码更新后果的人才享有这个权利。还有另一个解决方案：硬分叉，可以让社区内的每一个人掌握决定权。这也是我呼吁用硬分叉的方式执行隔离验证的主要原因。至少有一家交易所要支持目前“简单的”区块链。最大的挑战就是找到拥有充足时间的合适人选来对Bitcoin Core或Bitcoin Unlimited进行小小的改进，在隔离验证激活时分叉网络。这个人不能参与有关分叉无休无止的讨论。这种改变可以是一道简单的指令，使用隔离验证代码来拒绝包含验证数据的区块。Btcfork（Reddit）就是一个反面教材，因为解决方案是明摆着的，根本用不着过多的讨论。
在隔离验证问题上坚持自己的立场显然要比在区块容量问题上站队要好得多，因为人们可以就此问题发起不信任投票[1]。无论是对隔离验证分叉的反对，还是为分叉而奋斗的持久战都能让Core感受到他们自0.12版添加的各种功能都是不必要的。这样他们才能把重点放在研究一个长期或短期有效的解决方案，用于解决普及比特币的阻碍：区块容量限制。这样Core才会意识到，一味地添加使用率不高的功能是不能改善软件情况的。Core必须了解：矿工和开发者是为软件用户服务的。要么就追随社区的选择，要么就自动出局。
总之，隔离验证的确存在优势。很多人都因此劳心劳力。也许在其他加密货币领域它会有用武之地。隔离验证硬分叉可能会得到大部分社区成员的支持。如果大多数用户都希望维持原状，那么支持隔离验证的Core开发者很可能会在价值较少的一方继续运行。就像当初以太坊硬分叉一样。
软分叉将决定权分配给了矿工，实际上他们根本不会受到最终结果的影响。因此用户才应该是决策人。如果在软分叉之前都没有人挺身而出，那到底就都会陷入困境。即使未来真的实现了无限制的区块容量，那也躲不过要处理隔离验证交易的命运。如果有人想要告诉社区，比特币是因用户而存在的，不是因开发者或矿工存在的，那么它们应该让隔离验证以硬分叉的方式进行。
注释 (? returns to text)
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：http://www.longfuchaju.com//chanye/jieneng/4947.html
