在本文中，我们试图详细研究由于隔离见证软叉更新而导致的比特币协议中的更改。 我们谈到了与事务可延展性，保持向后兼容性，增加吞吐量，新的事务序列化格式，新的脚本选项，Bech32地址格式及其优势，权重，大小和虚拟大小的概念有关的问题。 此外，以下是有关更新适应性的最重要统计信息，并提供了有关此更新主题的常见问题解答。
在继续详细描述此更新中的所有更改之前，我们建议您熟悉隔离见证的主要思想。 从字面上看，“隔离证人”从英语翻译为“独立证人”。 如图所示，比特币竞赛意味着硬币所有权的证据将与交易主数据分开存储。
如果我们考虑整个协议更新，则它包括许多其他改进。 SegWit允许您增加网络带宽，将硬币所有权的证据与其余交易数据分开，修复与在已签名交易中修改数据的能力（交易延展性）相关的交易格式中的缺陷，同时保持与协议先前版本的向后兼容性。 此更新的最大价值在于，它使您可以在比特币协议之上实施许多非常重要的脱链解决方案。
交易延展性问题和解决方案
最重要的是，在比特币中工作时，有机会更改交易，以使其在验证期间保持正确。 这些更改很小，它们不会影响发送者和接收者的地址，但是足以更改哈希结果。 换句话说，交易会将硬币转移到其先前的地址，但其更改的哈希值将不再与原始交易匹配。
显然，上述情况只能在尚未收到确认的交易中发生。 没有它的解决方案，就不可能实现链下协议的可靠运行，包括构建未确认交易链。 由于在编译事务时，并非所有数据都被签名（例如，您不能对scriptSig签名），因此存在几种类型的攻击的可能性：
- 更改签名格式 。 在比特币协议中，签名格式未经严格批准，并且取决于OpenSSL库的实现，在该库中也没有为签名定义严格格式。 第三方可能会修改被拦截的交易，这将导致哈希值发生变化。
- 直接影响scriptSig 。 如前所述，scriptSig包含一组操作，以验证特定用户是硬币所有者的证据。 但是除了这些操作之外，您还可以添加其他操作。 一些不影响任何内容的无害操作将导致事务的哈希值发生变化。
因此，您可以在不访问私钥的情况下更改事务的哈希值。 为什么更改哈希值如此不受欢迎？
首先，应该注意的是，可以创建原始交易的副本，对其进行添加而不会在验证过程中影响其正确性的更改，然后将其发送到网络。 具有不同哈希值的修改后副本与原始副本花费相同的硬币，因此它可以与原始交易竞争以进行确认。
链外协议已在上面提到。 为了实现它们，必须解决交易延展性问题。 他们工作的核心是建立未经确认的交易链。 更改第一个交易的哈希值将导致整个未确认交易链无效。
SegWit更新定义了用于填写字段的严格规则，因此可以认为与新格式交易的交易可塑性相关的问题已解决。 这使我们能够指定数据并明确地对它们进行序列化，从而消除了双重性。
通过网络分配块时的向后兼容性
根据旧规则，最大块大小为1 MB，其中包含带有内置证据的事务。 尽管新规则假定最大基本块大小为1 MB，但是另外还有一个带有证据的数据结构。 因此，新块的总大小超过1 MB。
为了向后兼容，协议规则允许旧节点使用新块，但是它们仅在基本配置中将接收块，最大大小为1 MB。 见证人结构不适用于他们。 新节点完全包含交易和证据。 下图将帮助您熟悉此问题。
左图是激活隔离见证之前比特币协议操作的示意图。 该块的最大大小为1 MB，并且以一种形式分布在不同的网络节点之间。
由于块大小受到限制，因此可以放置在其中的事务数也受到限制，并且系统容量取决于此。 当然，当出现增加吞吐量的问题时，他们开始寻找的第一件事就是增加最大块大小的方法。
增加吞吐量的方法
考虑解决增加系统吞吐量问题的两种主要方法。 任何报价均由比特币协议的开发团队仔细检查和测试。 如果社群达成协议并决定在协议中实施该提案，则会发布更新。
Hardfork更新。 更新最常见的是增加块的大小。 假定一个单元将容纳更多的事务，从而增加吞吐量。 但是，按照旧协议运行的节点将不接受这种单元，其规则规定最大块大小不能超过1 MV。 此类更改需要硬分叉，硬分叉在组织上比软分叉更复杂。
SoftFork更新。 隔离见证使我们可以使用软叉解决此问题。 到底如何 它允许我们将区块分为两部分，第一部分存储交易，第二部分包含证据。 同时，新的网络节点接收两个部分，而旧的网络节点仅接收一个1 MB的事务块。 旧节点无法接收有证据的数据块，因此无法验证其接收到的交易，但这使它们能够参与共识构建，而不必求助于硬叉，而是逐步切换到新软件。
创新隔离见证
请考虑隔离见证更新中包含的内容。 隔离见证的第一个也是最重要的创新是新的事务序列化格式。 除了已知字段外，新事务中还有三个新字段：标记，标志，它们用于版本控制，在这种情况下，它们是严格设置的，但是在以下协议中，它们以及见证字段都可以更改。 证人（证人数据）实际上是从交易主体中取出的一组硬币所有权证据。 从结构上看，它看起来像一组输入，每个见证人数据元素对应于具有特定编号的输入，这使您可以将证据与花费的特定硬币进行比较。
证人交易编号
要获取事务标识符（事务ID，txid），您需要以一种特殊的序列化格式将事务本身带到一个数据序列，然后从该数据序列中获取哈希值。 随着隔离见证的引入，分别出现了新的标识符，见证交易ID（wtxid）和新的序列化格式。 对于在不使用隔离见证的情况下花钱的较早交易，wtxid将与txid相同，因为它们不会在隔离见证中添加新字段。
需要Wtxid来构建备用Merkle树作为证据。 它的构建方式与普通事务相同，仅使用wtxid代替事务哈希。 因此，wtxid成对散列，并产生Merkle根。
重要的是要注意，Merkle根被插入到coinbase事务中，而不是块头中。 如果root位于块头中，则块的结构将发生变化。 支持旧协议的节点无法与此类模块一起使用。 保持向后兼容性的所有努力都将抵制这种不一致。 因此，将root插入coinbase事务的输出之一。 当所有节点都切换到隔离见证时，这种情况可能会改变，并且将考虑使用新方法。
证人计划，用于设定硬币消费条件
让我们看一下“隔离见证”交易脚本的构建方式，以及它如何使较旧的网络节点了解“隔离见证”交易是正确的，尽管它们没有收到硬币所有权的证据。
描述从新格式交易中花费硬币的规则的脚本包括两个部分。 第一部分是见证版本字节（指定见证程序版本的字节）。 现在可以使用0到0到16（OP0-OP16）的值。 将来，该协议的新版本可能会出现，并支持见证程序的其他版本。 第二部分是见证程序。 此部分的大小可以为2到40个字节。
见证程序是哈希见证脚本的结果。 见证脚本本身包含有关硬币消费条件的完整描述。 见证数据包含必须满足见证脚本中条件的硬币所有权证明。 因此，见证人数据始终由两部分组成：见证人脚本和硬币所有权证明。
值得注意的是，见证程序不包含任何操作（哈希值匹配，电子签名验证），并且脚本本身以OP0代码开头，因此，它对于所有旧节点均有效。 此外，尚未更新为SegWit的节点不会检查新格式输出的硬币所有权证据；它们认为这种浪费在任何情况下都是正确的。 严格来说，旧节点将接受新格式的交易，即使其发送者实际上并不拥有相应的硬币也是如此。 这就是为什么SegWit要求大多数比特币采矿能力的所有者接受此更新的原因。 另一个功能是，从新格式的输出中花费硬币的交易的scriptSig将为空。
设置硬币消费条件的新选项
随着SegWit的引入，提出了两种用于scriptPubKey的标准格式，它们成为在此更新出现之前用于设置硬币消费规则的两种最常用格式的替代。 让我们按顺序考虑它们。
见证密钥的支付 （P2WPKH）类似于标准密钥哈希的支付。 有什么区别？ 如前所述，未填充scriptSig并保持为空。 硬币所有权的所有证据都将转移到见证人数据结构中。
在这种情况下，将先前考虑的脚本，作为见证程序的公钥的版本和哈希插入到scriptPubKey中。 网络上的一个节点将这样的支出脚本与其他节点区分开来，因为它的版本为1，数据大小为20字节。 另一个版本和不同的大小具有不同的支出规则。
在这种情况下，scriptPubKey包含两个部分：见证人版本号为零和收件人的公钥的哈希值。 ScriptSig将为空，见证数据将包含电子签名和验证它的公共密钥。
见证脚本支付 （P2WSH）类似于脚本哈希的标准支付。 在这种情况下，可以使用自定义脚本来设置花费硬币的规则。 主机如何与上一个脚本区分开？ 在这种情况下，版本的值仍为1，见证程序占用32个字节，并且是见证脚本中的哈希值。 如果事务到达包含将具有第一个版本的脚本的主机的事务，但是其大小与20或32字节的值不同，则该主机将拒绝此事务，因为它将不知道如何使用它。
这里的见证数据分为两部分。 第一个包含一组硬币所有权的证据，即一组签名。 在第二部分中，放置了一个见证脚本，该脚本的内容仅设置了花费硬币的规则，但是在这种情况下，它在花费时指示，并且在发送硬币时指示其哈希值。
在这种情况下，scriptPubKey包含两个部分：版本的见证人编号为零，以及多重签名为1-of-2时见证人脚本的哈希值。 ScriptSig将为空，见证人数据将包含电子签名和明文形式的原始见证人脚本。
P2SH包装纸
新的脚本格式不同于旧的脚本格式。 因此，旧的服务和钱包将不知道如何使用此脚本格式以及如何编写它。 为了实现向后兼容性，使用P2SH的隔离见证交易使用特殊的“包装器”，它使您可以创建具有隔离见证交易属性的事务，但与外界通常使用的P2SH没有区别。
P2SH用于简化发送方的工作，而不会给接收方的赎回脚本的实现细节带来负担。 在这种情况下，接收者仅向发送者提供“赎回脚本”哈希值，并且脚本本身与证据一起传递给scriptSig。
在这种情况下，scriptPubKey包含一个哈希操作，一个赎回脚本哈希值和一个比较操作（与P2SH的旧版本一样）。 此处的ScriptSig将包含公钥的哈希值，见证人数据将包含电子签名和公钥。
这种方法允许未更新的数字钱包将交易发送到隔离见证地址，而无需了解设置硬币消费条件的新方法。
新的Bech32地址格式
值得一提的是被视为本机SegWit地址的Bech32地址。 在其历史的大部分时间里，比特币都使用Base58编码来添加地址和校验和，这是使用SHA-256哈希函数进行双重哈希的截断结果。 它们是原始软件的一部分，其范围在BIP13中扩展为P2SH。 但是字符集和校验和算法都有局限性：
- 由于不能使用字母数字表示模式，Base58中的地址占用了QR码更多的内存；
- base58非常不方便，无法可靠地书写纸张，通过移动键盘打字或朗读；
- 双重校验和散列很慢；
- base58解码很复杂并且相对较慢。
SegWit更新包括一类新的出口（见证程序）及其两种情况：P2WPKH和P2WSH。 通过使用P2SH，它们的功能可以间接地用于旧节点，但是直接使用它会更加优化和安全，为此，有必要引入一种新的地址格式。
Bech32地址规范
Bech32地址的长度不能超过90个字符，并且包含：
- 易于阅读的部分。 这包括可能需要传输的数据，或与地址所有者有关的数据，至少1个字符长。 例如，默认情况下，对于主网地址，字符为“ bc”，对于测试网，字符为“ tb”。
- 始终为1的定界符。 如果在人类可读的部分内允许使用“ 1”，则分隔符是字符“ 1”的最后一个。
- 数据部分的长度至少为6个字符，并且仅由字母数字字符组成，不包括“ 1”，“ b”，“ i”和“ o”。 这里，见证程序的版本和见证程序本身的数据（2到40字节）用作主要数据。
为什么在地址中包含分隔符？ 这使您可以清楚地将人类可读部分与数据可读部分分开，避免与使用该前缀的其他人类可读部分潜在的冲突。 它还避免了人类可读部分的字符集限制。 分隔符为1，因为使用非字母数字字符使复制地址变得很困难（无需在多个应用程序中双击）。 因此，在主字符集之外选择了字母数字字符。 同样，与基数58的数字系统相比，基数32的数字系统的使用会导致地址长度增加15％，但这与复制地址无关紧要。
校验和Bech32地址
地址的最后6个字符是校验和。 校验和是基于BCH代码构建的，它确保检测到影响不超过4个字符的任何错误，并且当出现4个以上的错误时校验和收敛的机会是109之一。
使用BCH代码的优点之一是可以将其用于更正错误。 如果地址中最多出现4个错误，它们将被自动纠正。 而且，如果出现更多错误，则很有可能会检测到它们，但无法自动纠正。
地址中的大小写
当校验和需要字符值时，使用小写字母。
该软件始终以小写形式显示整个Bech32地址字符串。
如果需要大写版本（例如，用于演示或在QR码中使用），则可以选择使用该版本。而且，该软件将不接受某些字符为大写字母而某些字符为小写字母的地址。通常，小写字母更适合显示，但是QR码应使用大写字母，因为它允许编码的字母数字表示形式比字节表示形式紧凑45％。重量和块大小的概念
隔离见证更新引入的另一个主要更改是引入了诸如交易权重和区块权重之类的概念。在隔离见证之前，他们通常只谈论交易规模和区块规模。但是，块大小限制为1 MB。激活更新后，有两种交易格式。因此，都需要进一步支持。为了解决这个问题，引入了交易权重和相应权重单位的概念。现在考虑到交易主体的大小，系数为3，见证人数据的大小，系数为1。您可能会猜到，见证人数据中包含的任何数据所需要的佣金比交易主体数据少3倍。这种方法允许验证者确定相对于区块中所占空间和所获得奖励的更有利可图的交易。重量使用特殊公式计算。块权重=碱基大小* 3总大小+块重量 -重量块（以重量为单位测量）的基础大小 -基本块的大小（以字节为单位）总大小-总块大小（以字节为单位）在此公式中，基本事务大小表示根据旧规则序列化的事务大小乘以3，然后将结果与根据新规则序列化的事务大小相加。结果，我们获得了交易的权重。无论旧式交易是根据新规则还是旧规则进行序列化，其大小始终将始终相同，权重将恰好大4倍。对于隔离见证交易，权重会稍小，因为交易规模中将不会包含硬币所有权的证据。连同权重一起，引入了虚拟大小的概念，它是通过将权重除以四来计算的。虚拟大小用于计算交易佣金，因此验证者可以了解使用常规记录价格（以spb单位（每字节聪数））将特定交易包含在区块中的好处。虚拟尺寸=重量单位/ 4由于非隔离见证的交易权重将是该大小的4倍，因此虚拟交易的大小将等于通常的大小。因此，对于旧交易，佣金的计算不会改变。对于新交易，它会稍小一些，因为签名是在单独的结构中提交的。因此，可以为他们支付较低的费用，但是当矿工包含在区块中时，它们具有相同的优先级。同时，不包含见证数据的最大块大小（基本大小）为1 MB，最大块权重为4 MB。这里可能会出现一个逻辑问题：“实际的块大小以及见证数据将是多少？”。绝对不可能回答。显然，此值的范围是1 MB到4 MB。但是可以进行更准确的理论评估。获取约1.8 MB。这个价值从何而来？当前，典型的事务块包含大约60％的未完成数据。如果我们计算一个1 MB的块的重量，该块包含40％的硬币所有权证据，我们将得到以下数据。400,000字节* 4 = 1,600,000常规重量单位600,000字节* 1 = 600,000常规重量单位1,600,000 + 600,000 = 2,200,000常规重量单位4,000,000 / 2,200,000 = 1.81 MB即，可以假定有效块大小将为约1.8MB。但是很明显，实际上，此值将完全取决于此区块中交易的组成。更新适应统计信息
截至2018年7月，隔离见证交易的数量已超过比特币网络总数的35％。同时，用于比特币和数字钱包的主要服务最近已经实现了对隔离见证的支持（例如，Electrum和Bitxfy）。
该图取自BitMex Research 研究，在激活更新后最终块大小的动态变化中，也可以注意到明显的变化。在新事务流增加的时刻，几乎所有块的可用空间都明显超过1 MB，有时甚至超过2 MB。此外，很明显，在激活SegWit之后，迫切需要解决低带宽问题的问题似乎不再那么尖锐。
根据分析，BitMex Research如果以新格式查看平均交易费用对交易次数的依赖性，则还可以看到这些值的变化之间存在非常强的相关性。而且，不要忘了隔离见证使在比特币协议之上开发脱链解决方案成为可能。当然，与SegWit相比，适应闪电网络要困难得多，但是，这方面的工作正在紧锣密鼓地进行，并且已经取得了重大成就。常见问题
-是否可以说RBF（按费用替换）不适用于隔离见证交易？不，按费用替换将适用于隔离见证交易，因为它不是基于您的支出规则，而是基于您使用相同硬币并指出交易条目的序列号的事实。如果您使用相同的硬币增加输入值，并指出拥有这些硬币的正确证据，则可以用相同的方法替换之前的交易。-如何更改未确认交易的哈希值？交易哈希是计算交易中存储的所有数据的哈希函数的结果。事务中包含的ScriptSig参与了哈希的计算，但是不能被签名。此字段中的较小更改（不需要更改签名验证规则）将导致事务哈希值的更改。这意味着签名保持有效，交易有效，但其哈希值将改变。-证人数据如何存储在交易中？如前所述，隔离见证交易引入了一种新的序列化格式。除了我们拥有一组输入和输出这一事实外，还添加了其他字节来存储证据。因此，该数据被存储在那里。用这种方式想象起来很简单：只有一个数据集，其中写入了两个事务输入（第一个输入字节和第二个输入字节），两个输出，然后是另外两个Witness数据集，它们以与字节相同的方式写入。实际上，硬币所有权的证据在序列化过程中转移到了另一个地方。-为什么不将现有的字符集（例如RFC3548或z-base-32）用于Bech32地址？选择字符集以使与其视觉相似性相关联的歧义最小化。选择该顺序以最小化少于一个数据位的字符对的数量。选择校验和以最大化检测少量错误的可能性，从而提高其针对典型错误的效率。