隔离见证是什么？详解隔离见证

来源：时间：2017-07-24 17:26:50

隔离见证是什么?详解隔离见证

本文第一次检查隔离见证(简写为SW)，并演示它是如何无法实现其设计目的，它是如何成为拖累比特币负担的不可逆的技术债务，以及它如何威胁货币的可互换性的。读了本文之后，矿工应该清楚为什么他们应该：1)拒绝激活隔离见证软分叉;2)尝试与Bitcoin Core 谈判，以达成新的协议，推动将隔离见证以硬分叉的方案来实施，以相应增加区块供应，或者转向支持坚持以市场驱动来实现增加区块供应的实施方案。

1. 问题是什么

比特别面临着许多挑战。在最高级别，这些挑战包括交易延展性和扩容。隔离见证声称可以解决交易延展性，并实现一次性增加容量，并为第二层扩展方案建立基础。在说明为什么这些声明不是真的之前，让我们回顾一下隔离见证试图解决的问题。

1.1 交易的延展性

用一句话说明什么是交易延展性?

交易延展性是为单个交易生成多个有效交易身份标识的能力。

它如何工作?

一个比特币交易由以下成分组成：

图1：比特币交易图解

为什么这是个问题?

攻击者可以通过以下方式欺骗用户。Alice需要来自Bob 的付款，Bod广播交易(txid-a)Alice 检测Bob的交易 (txid-a)，并通过无效的签名但是产生不同身份标识的方式修改它为：txid-b。 Alice 广播txid-b到网络，在那里txid-b可能被矿工接收和接受，而不是txid-a。如果这样的话，Alice就可以向Bob 声称交易没有成功，并要求再次付款。Bob 在区块链上检查txid-a，但无法看到最新的区块，断定发生了错误。如果Bob没有运行全节点，并没有留意自己的钱包，他就会被诱骗，向Alice支付更多的资金。Alice 则可以一次又一次地重放这个攻击，直到Bob意识到发生了什么。

这是解决闪电网络的一个特别重要的问题，在闪电网络中，人们需要不断地监控网络以确保他们的交易对手不会偷偷地发布旧的信道状态(实际上窃取应该转移给你的资金)。而一个一致的索引值将使这个过程变得更容易。

如何解决?

数字签名需要与用于生成索引值的数据分离或“隔离”。这意味着索引值将一直是相同的，并且不能在不使数字签名失效的情况下被修改，从而使攻击无效。

1.2 扩容

比特币当前链上扩容问题指的是，每10分钟生成的区块大小约束在最大1MB。因为这个限制，可以“纳入”区块的交易数量有限，这硬性地限制了支付网络上的链上交易量。

这种障碍已经成为问题，因为链上交易需求随着比特币的用户基数而增长(图2)。2016年，这种限制反复出现，导致了链上交易费用上升了213%(图3)，常规交易积压已经变得司空见惯。如果再不改变什么，这种趋势预计会变得更糟。这些工作积压的一个影响是对比特币的消费者服务产生严重的干扰。许多这些服务报告收到大量的用户服务工单都是同一个问题：交易进入区块失败。

增加链上交易的容量不仅仅是改变单个变量。对协议进行这样的更改需要网络的“分叉”，其中区块链历史在给定的点处分叉，并且旧规则的分支会被舍弃，支持新规则的分支会延续。

如果一些使用者从其他网络运行不同协议的软件版本，网络分叉可能会突然发生，或者他们可以提前计划允许整个网络从其他同行那里升级软件来避免被分叉。竞争性客户端例如：Bitcoin XT, Bitcoin Classic, 以及 Bitcoin Unlimited 在拥有多数算力支持后可以触发硬分叉。

二次签名哈希散列(译者注：这里的原文是：Quadratic Signature Hashing.)

无论这是什么方法，这有一个更显著的威胁链上扩容的问题：二次签名哈希散列。更清楚一些地说，这个问题是已经存在的1MB区块大小的问题，但是对更大的区块来说，可能是个严重问题。

一句话说明什么是二次签名哈希散列问题?

基于输入数量，此工作需要通过函数O(n²) 验证一个交易增加。(例如：二次方增长)

为什么这是一个问题?

某些交易可以被设计为包含的大量输入和输出，这些输入或输出要求矿工们和完整节点来消耗大量的CPU工作进行验证(图4)。对于矿工，这个验证时间可能会延迟他们在下一个区块上的工作，使他们处于劣势。最坏的一种情况是一个交易的验证时间超过挖掘下一个区块10分钟的目标。这可能被用于启动一种针对矿工和整个网络的拒绝服务攻击，因为完整节点不会在没有首先完成验证的情况下传播区块，除非他们在没有验证交易的情况下挖矿并破坏网络的共识规则。这种攻击会在更大区块下更加恶化，利用二次签名哈希散列，可以容纳更多或者更大的恶意交易。

它是如何工作的?

如果每次我们执行一次附加散列操作，散列的数据量都是相同的，则总散列时间将线性增加(表1)。

然而，如果每个附加一次的散列操作的数据量增加，那么即使散列操作的数量线性增加(表2)，总散列时间也会二次增加。(表2)

在比特币中，每个额外的输入需要(至少)一个额外的散列操作，但每个额外的输入也增加了交易量的整体大小，因此数据量每次都要被散列。

应该如何解决?