扩展块

层：共识层(软分叉)

标题：扩展块

作者：Christopher Jeffrey

Joseph Poon

Fed或Indutn成立于2017年3月17日

许可：公共域

摘要

本规范定义了一种在不改变当前共识规则的情况下提高比特币交易吞吐量的方法

目的

比特币的交易吞吐量与改变这条规则是不可能的。有许多方法可以显著提高事务吞吐量，但共识级别的解决方案可以证明自己是非常安全的。

历史

2013年，刘强森(Johnson Lau)首次提出了附加区块的方案，该方案提出了通过特殊的操作代码，让资金快速进出附蓑衣网小编2022 加生产区域的方法。

加长挡是另一个改进建议，也是刘强森在2017年提出的。新方案改变了原方案

规范

扩展块的许多思想。它是建立在权威块上的子层，矿工们将这个附加块的事务合并到梅克尔的根中。

扩展块方法使用来自BIP141、BIP143和BIP144的几个特性来实现事务的选择加入、序列化、验证和网络服务。这个规范应该考虑这个改进协议(BIPs)的扩展和修改。扩展块的当前版本与BIP141不兼容，需要附加一些额外的规则。

为了避免与尚未升级的UTXO节点集冲突，扩展块使用自己独立的UTXO集。这是一个非常聪明的努力，它要求在每个权威块的末尾有一个resolution事务。

该规范提供了一种方法来欺骗未升级的节点，使其相信这些现有的UTXO集仍然遵循它们预期的规则。不幸的是，这需要在升级的节点端进行额外的记账。

Commitment

升级的矿工将打包的扩展块包含余额为0的附加coinbase输出。这个输出脚本如下：

op _ return0x240xa21a9f [32字节-merkle-root]

特征值(译者注：此处原特征值为commitment，看完BIP141？这个词是一个加密的学术术语，意思是一个值保证与另一串数据的一一对应，它是通过计算hash得到的。BIP141的定义：承诺记录在？scriptPubKey？coinbase交易。也就是说，这个特征值被公钥脚本用来记录比特币基地交易？)序列化和搜索规则遵循BIP 141的规则。

用于计算梅克尔根的梅克尔树将所有扩展块和权威块的txids和wtxids作为叶子计数。

任何包含扩展块的块都必须包含扩展提交输出。扩展块的

opt-in(译者注：opt-in表示自愿接受，对应的反义词是opt-out，自愿拒绝)

输出可以使用witnesprogramscripts(bip 141定义)发送信号进入扩展块。如果脚本包含最小编码的P2PKH或P2SH脚本，这意味着输出信号退出扩展块。

除了witness、P2PKH或P2SH之外，输出的脚本代码在扩展块中将被视为无效。

Resolution

Resolution transaction是一种记账机制，维护扩展块之上设置的UTXO的所有值。它们以连续OP_TRUE输出的形式存在。它们处理进入和离开扩展块的UTXO集合。

第一个块包含传入或传出输出，并且必须包含最终解析事务。包含扩展块提交的每个块都必须包含最终解决事务。这个解析事务将消耗扩展块的所有输出。这个解析事务用完了所有打算进入扩展块的输出值。 解决事务必须作为块中的第一个事务出现。(这样，所有新创建的输出值都可以被正确擦除)。资金将被发送到一个任何人都可以花费的——输出。按照共识，这个产值是禁止花的，除非再有分析交易。

解析事务必须包含附加输出，作为离开扩展块的输出。

比特币基地输出不得包含见证过程。这是因为预先存在的共识规则，不能通过解决交易来消除。

resolution事务的第一个输入必须引用前一个resolution事务的输出。

手续费从扩展块向上传输，并进入决议交易。换句话说，解决交易的手续费必须等于扩展块中所有交易手续费的总和。

Bootstrap

为了引导扩展块的激活，必须首先从包含扩展块特征值的第一块连同进入扩展块的任何输出(激活块)中挖掘出创建解析事务。这是唯一一个不需要引用前一个分析事务的输出的分析事务。

创建分析事务还可以在第一输入脚本中包含1到100字节的pushdata，从而允许矿工在重新创建分析事务中添加特殊信息。推送数据必须能够转换成真正的布尔数。

解析规则

解析交易的第一个输出金额必须等于：

(前一个解析值输入值-现有值)-ext-block-fees

(前一个解析值输入的金额-左)。)

解析事务的版本必须设置为uint 32 max(2 ^ 32-1)。激活后，该版本号将被权威区块链(1M链)或其他扩展链上的共识规则交易所禁止。这一要求是为了解决在非上下文状态下识别事务的问题。

发现进入扩展块

的任何见证程序的输出包含包含扩展块的UTXO集合的keyhash或scripthash的输出， 将被视为选择加入

模板块

事务# 1 (coinbase):

输出# 0:

-脚本：p2pkh

-值：12.5 -脚本：OP _ RETURN0x aa 21 a9 ef[merkle-root]

-值：0

事务#2(扩展块资金事务):

输出# 0:

-脚本：p2wpkh(将进入扩展UTXO集将进入解析事务将赎回任何见证输出：

事务# 3(解析事务):

输入#0:

-输出点：

-哈希：上一个解析-txid

-索引：0

输入#1:

-输出点：

-哈希：事务# 2 txid

-索引：0

输出# 0:

-脚本：op _ true

-值：5.0

假设block)

-值：5.0

离开扩展block

为了保证现有区块链和扩展block中的货币汇率为1: 1，将有一个人离开扩展block。

在以后的交易中，交易#2的输出可能需要存在于他们的资金中的输出。

事务# 5(coin base):

输出#0:

-脚本：P2PKH

-值：12.5

输出#1:

-脚本：OP _ RETURN0x aa 21 a9 ef[merkle-root]

-值：0

事务#6(解析事务):

-输入# 0:

-Outpoint:

-Hash:previous-resolution-TXID

-索引：0block)

-Value:2.5

Output # 1:

-Script:P2PKH(注意这会导致anexit！)

-值：2.5

exit demoption]

]

根据上面的描述，扩展块中存在的输出通过解析事务将扩展块留给主链。在扩展块上创建的Outpoint不能被任何一方使用。相反，离开扩展块的事务的输出必须花费在解析事务中创建的输出点上。

离开(扩展块)交易

的到期要求与coinbase交易类似。在重组的前提下，有可能分析交易永远挖不出来。这将使所有传出(扩展块事务)输出无效，所有相关的支出事务不可靠，并使挖掘无法进行最佳链挖掘。出于这个原因，需要退出到期要求。基于以上原因，我们需要一个成熟期才能离开(延期大宗交易)。

请阅读：https://github.com/tothe moon-org/extension-blocks/issues/9

手续费

从扩展块内部收取的手续费向上传递到相应的决议交易。已解决交易的手续费必须等于扩展区块

中所有交易费用的累计总和。在费用政策制定层面，交易费用的计算方法可能会考虑交易成本，同时考虑进出输出导致的权威区块的交易规模/策略-签名数(size/legacy-sigops)。

在前面的计算示例中，交易#2的输出也可能增加额外的手续费。

事务# 5(coin base):

输出#0:

-脚本：P2PKH

-值：12.501(奖励费)

输出# 1:

-脚本：op _ return0x aa 21 a9 f[merkle-root]

-值：0

事务# 6(解析事务解析事务):

输入# 0:

-出点：

-哈希：上一次解析-txid [x input # 0:[-Outpoint:

-Hash:Transaction # 4 TXID

-Index:0

Output # 0:

-Script:P2WPKH(此输出将保留在ext . block)

-值：2.499(减去费用，this propagate up)

输出#1:

-脚本：P2PKH (note that this causes anexit!)

- Value: 2.5

验证

扩展区块内部交易验证规则应该被目的的软分叉强化，例如要比BIP-141的规则要额外强化。

在扩展交易里的交易矢量(transaction vector)可能包含一个使用BIP141交易系列化的见证矢量（witness vector）。（译者注：暂不理解这句话是什么意思，原文是：Transactions within the extended transactionvector MAY include a witness vector using BIP141 transaction serialization.）

扩展交易的验证工作将会使用VERIFY_WITNESS规则。

扩展交易不可以使用任何来自权威区块的UTXO集。

如果扩展区块，不能通过共识检查，已经升级的节点必须考虑将整个区块关定为无效（包括权威区块和扩展区块）。

BIP141规则改变

除了解析交易外，见证程序的输出必须只可以在扩展区块内被赎回。

见证交易可能只包含见证程序输入。

BIP141的P2SH嵌套特征将不在可用，并且它将不再是一个共识规则。

区块尺寸和交易尺寸（block weight and transaction weight）的概念被被删除。

sigop成本（sigops cost）的概念保留，以备将来可使用软分叉升级和和可升级限制DoS（DoS limits）。

DoS限制（DoSLimits）（译者注：这一部分描述的是扩展区块设计了一个算法，预判交易占多少计算量，分别包括对Inputs和Outputs的计算量计算方式，并且给出了垃圾交易的定义）

因为扩展区块定义的新的输入和输出计算量开销指标，所以DoS限制应该被加强。请留意在离开（扩展区块）交易输出对权威区块的DoS限制的影响，因为它们增长了交易尺寸和签名次数（sigops）。

MAX_BLOCK_SIZE:1000000 (unchanged)

MAX_BLOCK_SIGOPS:20000 (unchanged)

MAX_EXTENSION_SIZE:TBD

MAX_EXTENSION_COST:TBD

最大的扩展区块尺寸必须被故意设置得较高。平均真实区块的大小，事实上是被输入（签名数sigops）和输出的计算量开销所限制。

未来的（区块）尺寸和计算的可扩展性可以通过软分叉附加新的见证程序来实现。在未升级的节点，未知的见证程序的计算量开销被当成是1inputs/outputs来计算。更新过的节点，为了实现将来的DoS限制软分叉的变化可以使用低的计算量开销。

扩展交易计算量开销

扩展区块使用BIP141的升级脚本，也允许使用升级的DoS限制。

计算输入的计算量开销

见证关键哈希v0将按1分算，乘以一个系数8

见证脚本哈希v0的计算量预计数值将精确等于在可赎回脚本的签名次数（sigops）乘与一个系数8。

未知见证程序应该按1分计算，并且乘于系数1。

由于可赎回脚本允许在见证矢量中产生垃圾数据，因此为了减少使用可赎回脚本被使用的几率，每73bytes的序列见证矢量就计一分。

这样给未来的空间留下7分，用于软分叉升级DoS限制。

计算输出的计算量开销

当前定义的见证程序（v0）按8分计。未知的见证程序按1分计。任何现有的输出总是计为8分。

这样给未来的空间留下7分，用于软分叉升级DoS限制。

垃圾交易阈值

在扩展区块内，现在应该加强对垃圾交易的定义，使用一个共识阈值来定义。

在扩展区块中，任何包含500聪以下的交易真接判为垃圾交易。这种判断法的适应于进入扩展区块的交易，但不适应于离开扩展区块的交易。

为闪电网络安全而设定的规则（译者注：这一部分大体意思是关于外挂在扩展区块的闪电网络关闭通道，将通道状态广播到扩展区块时的成本预估，主要是通过收紧对广播交易的区块空间来惩罚非法广播，让攻击的手续费变的非常高）

在闪电网络白皮书中，已经定义了闪电网络所面临的系统性攻击。(旧状态的大规模关闭)

如果扩展区块的第二高位版本位（第30位）设定为1，另外700字节就被保留（注意：区块空间和签名操作的计算量开销未定义）

每笔交易的交易空间是预定了的，在同一区块内，会被两笔交易所消耗(每笔上限为350比特)，这一设定满足以下的约束要求。

初次分配只能被一笔交易花费，这笔交易要求其版本号里的第30位设为1的交易的输出中花费。

第二次分配只能从在过去2016个区块中任意拥有第30位设置的交易里的第一笔输出中花费。

如分配没有使用到任何交易，这些交易将使用这些额外的区块空间，700字节的可利用的区块空间将降低。

这一共识规则只在于扩展区块中，而并不是适用于主链区块。

以上规则是为了确保:在没有矿工互相协同的情况下，当系统受到攻击时，交易费用会异常的高。因为闪电网络交易是预订了区块空间的，并且双方在闪电网络的交易Commitment Transaction（译者注：Commitment Transaction是指闪电网络通道内的交易，没有在扩展区块里结算的交易）同意交易版本位来实施这一规则。这是一个在闪电网络里的opt-in（自愿接受）特性，使用高额手续费来做为可用性处罚。这是假定大多数使用场景是非法的广播，处罚将在同一个区块中包含在第二分配来完成，并且在第一次分配中给其他交易更多的区块空间。

迁移与采纳的影响

大头数比特币生态系统现在已经做好了升级到BIP141的准备

对于现在支持BIP的钱包，所需的迁移成本是很微小的。

对全节点来说，API可以修改为透明的为延展区块交易服务，就好像这些都是传统交易一样。当然这不会包含矿工用的API?（就是说矿工必须能够区分延展和非延展区块，而外接的程序则不一定需要区分）

钱包的影响与迁移

现在支持b1p141的钱包，必须做如下关键调整保证和扩展区块兼容。

当创建一笔交易时，钱包必须选择一条链来开始花费。(要么选择权威区块，要么选择扩展区块，但不能同时选两者)换句话说，交易必须要么包含所有现有的见证程序的输入，要么就两边都没有见证程序输入。对于支持两条链的钱包来说，如果用户没有定义使用哪条链的话，币选择器会自动选择一条链。钱包支持扩展区块，当看到解析交易的输入时，必须忽略掉。这可以非常简单的通过交易版本号来检查，就和钱包已经实现的忽略Coinbase交易的输入那样。这对阻止钱包，支持扩展区块的钱包，当看到解析交易但输入时，时必须加以忽略。这一点对防止钱包错误地判断双花很重要。同时支持权威区块和扩展区块资金的钱包必须忽略掉从扩展区块里离开的交易的输出。这是为了防止钱包错误地将同样的输入索引两次。

后两点只适合以下的钱包，这些钱包通过直接区块链监控来操作的。监控类全包通常关注区块链，并且索引他们自己的交易输出值。

内存池的影响

这个改动对于内存池实现来说是非常小的，尽管实现细节上可能略有不同，但是一个合规的内存池必须在追踪确认某输出的释出点的时候拒绝跨链花费（将输入在两条链上都合并），这些处于内存池的释出点可能不可被花费（因为它们必须在下一个实际生成的交易ID的同时被释放赎回）。

挖矿的影响

因（扩展区块数据）带来的附加体积大小和签名次数（sigops）计算：

节点在自行创建区块模板时，其在为权威区块留出保留空间的时候必须同时考虑到进入和离开（扩展区块）交易的输出尺寸，一个附带了进入输出或闻名于世输出的交易输出会增加标准区块的大小。

进入（扩展区块）交易输出将会以输入的形式增加解析交易的尺寸。

离开（扩展区块）交易的输出，会在解析交易中同时以签名次数（sigops）和输出的形式增加交易尺寸。

交易分类和选择算法，必须仔细考虑这些点。

getblocktemplate(BIP22)的扩展（译者注：这一部分是指在扩展区块里的广播区块用的模板，getblocktemplate是矿池挖出一个可用的值，要广播块时候用的模板。extblk下，这个模板要改）

除transactions数组外，兼容本协议的实现还必需包含一个extension数组。该extension数组包括了按照BIP22定义的交易，以及按BIP145定义的getblocktemplate的扩展区块。

兼容的实现必须包括解析交易作为其交易数组的一部分。这个解析交易必须有一个额外的属性被称为解析，是一个布尔值，设置为true。在交易数组里包含解析TX使得现有的扩容客户端可以向后兼容。

default_witness_commitment在扩展区块中被重命名为default_extension_commitment，并包含在扩展区块的commitment脚本里。

一个额外的可变字段被定义为“resolution”。如果交易现在是可变数组，resolution允许扩展区块可变，这让客户端可以正确更新解析交易。

沿着可变的解析字段，也定义了一个resolutioncapabilities字段，这是为了让客户端可以更新解析交易。

对于与老旧挖矿客户端交互的节点来说，可能需要在本地使用commitment-hash->ext. block的map容器，来存储扩展区块（并且还要在调用submitblock期间，完成一些重新序列化的工作）。

数据迁移的影响

每一个软件实现（implenmentations）都需要一个额外的位（bit）来存储是哪一条链的UTXO的标记。根据实现的的UTXO系列化/压缩格式，这可能需要一个数据库迁移。

激活

版本位（Version bit）: 2

分配名称: extblk (在GBT中以！extblk出现)

开始时间:?待定

超时时间:?待定

激活后失效（Deactivation）（译者注：这一部分是讲在扩展区块激活后，如果社区在往后达成共识可以将扩展区块废除掉，比如如果主链达成了扩容共识后，扩展区块变的没必要了就可以通过一个软分叉的形式将扩展区块里的交易只出不进，经过一定时间就可以清除掉里面的交易。这一功能也让扩展区块可以用于比特币的测试链。）

扩展区块激活后，矿工可以通过第28个BIP9软分叉位来实现将扩展区块失效。这个“失效”部署的开始时间应该在扩展区块激活后3年才可以，激活“失效”的算力阈值为95%。最小的锁定周期必须至少为26重定向周期（1年）。

通过这一点，将来扩展区块规则集可能会得到发展，它在功能集和可扩展性方面是非常优越的（另请阅读：根链和/或Mimblewimble）。这使得长期扩展解决方案可以以非常小的代价和包袱通过支持的将要丢弃的链上升级。

在失效后，社区肯定希望离开扩展区块的交易将以可选择的和安全的被设计好的软分叉进行，但进入（扩展区块）的交易和转移资金到扩展区块需要被禁止。

我们提出两个失效解决方案，本文档将选择其中之一作为最终方案。

失效方案#1

当在第28个位被激活后，解析交易输出将退回到一个被现在共识规则定义好的“任何人都可以花费”的输出。这个第28个BIP9位（或其他BIP9位连接）可以被过载以使得这个将来阻止这个“任何人都可以花费”将来被软分叉激活。这可以使得将来扩展区块特性不需要硬分叉。

社会共识是在扩展区块失效后里面的资金是可以被使用和赎回的。如果激活（失效）期间没有适当的和安全的取款条款，用户和交易所可以通过一个软分叉位来拒绝执行。

可以通过一个新的位来升级一个扩展区块，使用基于BIP9相同的联合（conjunction）第28个位，并使用新的规则（例如，在第27个位激活新的链，并有条件地激活第28位，创造一个直接迁移到新的在主链上没有交易的扩展区块）。

这个软分叉将强制执行取款/赎回资金，并将被过载，所以这要求脚本从语法上描述取款。

失效方案#2

当在第28个位被激活后，不再允许有交易打包进入扩展区块。只允许通过梅克尔树证明来提现到主链。

这要求今天详细说明并发布梅克尔树证明提现的代码和规范。

通过梅克尔树证明使其失效

从旧扩展区块到主链的交易赎回和新扩展区块可以通过以后设计梅克尔树证明的方式来转移。资金可以通过将UTXO梅克尔树根作为一种共识规则实现硬编码转入新扩展区块，并根据梅克尔树路径验证转入资金。

为了使资金转入，节点只需要一份失效扩展区块当前32字节梅克尔树根的副本。

全节点就没必要在磁盘上存储完整UTXO集合，在将来赎回时使用一个大的链上交易进行平衡，（译者注：暂时没明白这是什么意思his removes the necessity for full nodes to store acopy of the full UTXO set on disk, with a tradeoff of larger on-chaintransactions when redeeming in the future.）替代方案是为了为客户端保存UTXO集合的记录并在内存中保持完整的位字段。

基于新输出是无效的，TXO集是静态的（集只有花费或未花费的变化），这比目前提出的动态变化UTXOs的设计简单得多：https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011638.html

Motivation动机

虽然失效被看作是一个不利条件，但是本规范的主要优点不是一个使用BIP141规则集的扩展区块。相反，这个生态系统将奠定以操作扩展区块为基础。未来的比特币协议也许会包含几种不同的扩展区块和很多不同的规则集。

参考实现（正在开发）

https://github.com/bcoin-org/bcoin-extension-blocks

版权所有

本文件发布于公共域。

蓑衣网小编2022