作者:Paul Sztorc & CryptAxe
译者:Jack3.14
来源:https://github.com/bitcoin/BIPs/blob/master/BIP-0301.mediawiki
BIP: 301
Layer: Consensus (soft fork)
Title: Blind Merged Mining (Consensus layer)
Author: Paul Sztorc
CryptAxe
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/BIPs/wiki/Comments:BIP-0301
Status: Draft
Type: Standards Track
Created: 2019–07–23
License: BSD-2-Clause
摘要
盲合并挖矿(BMM)允许矿工在不运行其节点软件的情况下挖掘侧链/山寨币(即,不“看”它,因此“盲”)。
取而代之的是,一个单独的侧链用户运行他们的节点并构建区块,支付自己的交易费用。然后,他使用等量的资金从传统的layer1 Sha256d矿工那里“购买”找到这个区块的权利。
动机
合并挖矿(MM)允许矿工重用他们的哈希工作来保护其他链(例如,在Namecoin中)。
然而,传统MM有两个缺点:
矿工必须运行其他链的完整节点。(因此,他们必须运行可能存在错误的“非比特币”软件。)
矿工在另一条链上以替代货币获得报酬。(MMNamecoin的矿工将获得NMC。)
符号和示例
注意:我们在其他不明确的单词(例如“块”、“节点”或“链”)前面使用符号side:\*和main:\*,以将主链版本与其侧链对应物进行排序。我们将所有侧链用户命名为“Simon”,将所有主链矿工命名为“Mary”。
示例:假设一个侧链块包含20,000个txn,每个支付0.1美元的费用;因此,该块价值2000美元的费用收入。像往常一样:侧链的coinbase txn将向某人(在本例中为“Simon”)支付这2000美元。在BIP301下,Simon不进行散列,而是让一个layer1 txn向layer1矿工(“Mary”)支付1999美元。
BIP301使这种专业化的劳动在第一层变得不可信。如果 Mary 拿走了 Simon 的钱,那么她必须让 Simon 控制一边:块。
规格说明
BIP300由两条消息组成:“BMM接受”和“BMM请求”。这些管理称为“h*”的东西。
所以我们将讨论:
H* — 侧链的hashMerkleRoot,以及它的重要性。
“BMM Accep” — h*如何输入 main:coinbase。当Mary”接受”BMM请求时,Mary正在认可一个side:block。
“BMM请求” — — Simon 向 Mary 提供资金,如果(且仅当)她将认可一个特定的h*。当 Simon 广播BMM请求时,Simon 正在尝试一个 side:block。
h*
h*(”h star”)是侧链的Merkle根哈希。
在BIP301中,侧链的coinbase txn充当标头(它包含前一个side: block和前一个main:block的哈希)。因此,MerkleRoot包含所有重要的内容。
注意:在BIP301侧链中,“header”和“block hash”没有显著的共识意义,在设计中主要是为了帮助IBD。(相比之下,在主链中,header和block hash决定了难度调整和累积PoW。)
上图:h*位于main: coinbase中。h*包含所有side:txns,包括side:coinbase。side:coinbase包含许多“类似头”的字段,例如上一个side:block的哈希。
Mary控制main: coinbase,因此她可以选择任何h*。她的选择将决定哪个side:block被“找到”。
BMM接受
要“接受”BMM的提议(并接受 Simon 的钱),Mary 必须支持 Simon 的区块。
对于每一 side:block Mary希望背书,Mary将以下内容放入 main:coinbase OP_RETURN:
1字节-OP_RETURN(0x6a)
4字节-消息头(0xD1617368)
32字节-h*(从Simon获得)
代码详情在这里。
如果这些OP_RETURN输出不存在,则不接受任何请求。(而且,Mary 不会从请求中得到钱。)
Mary 和 Simon 有可能是同一个人。他们会完全信任对方,所以BMM过程就到此为止。只有接受;请求是不必要的。
当Simon和Mary是不同的人时,Simon将需要使用BMM请求。
BMM请求
Simon 将使用BMM请求从 Mary 那里购买查找侧链块的权利。
对于Simon想要尝试的每一 Side:Block ,他广播一个包含以下内容的txn:
3字节-消息头(0x00bf00)
32字节-h*(边:MerkleRoot)
1 byte-nSidechain(侧链ID)
4-bytes-prepreMainHeaderBytes(前一个main: block的最后四个字节)
我们使用扩展序列化格式。(SegWit使用ESF在txns中定位scriptWitness数据;我们在这里使用它来定位上面的五个字段。)
Message头将此txn标识为BMM事务。h*由Simon选择以对应于他的side: block。nSidechain是创建侧链时分配给侧链的编号。preSideBlockRef允许Simon在任何先前存在的side:block上构建(允许他绕过一个或多个无效块,详情如下)。MainpreHeaderBytes是前一个main:block的最后四个字节(详情如下)。
如果此txn未通过以下任何检查,则此txn无效:
每个“BMM请求”都必须匹配一个相应的“BMM接受”(上一节)。
每个main: block中每个侧链只允许一个BMM请求。换句话说,如果700个用户为侧链#4广播BMM请求,那么main:miner会挑出一个BMM请求来包含。
4个字节的 prevMainHeaderBytes 必须匹配前一个 main:block header的最后四个字节。因此,Simon的txns仅对当前块有效,在他知道的块历史中(因此,他知道的当前侧链历史)。
大多数BMM请求txns永远不会成为一个块。 Simon 会提出许多BMM请求,但只有一个会被接受。由于只有一个BMM请求可以成为真正的交易, Simon 可能会觉得整天都可以提出多个报价。这意味着 Mary 有许多报价可供选择,并且可以选择支付她最多的一个。
此BIP允许BMM请求通过 Lightning进行。一种方法在这里。(BMM接受不能超过LN,因为它们驻留在main: coinbase txns中。)
向后兼容
作为软分叉,旧软件将继续运行而无需修改。为了无信任地强制执行BMM,节点必须观察“成对”的交易,并使其受到额外规则的约束。未升级的节点会注意到区块链中存在此活动,但他们不会理解其中的任何一个。
就像P2SH或新的OP Code一样,这些老用户永远不会直接受到分叉的影响,因为他们不会期望收到这种付款。(事实上,这里唯一收到BTC的人都碰巧是矿工。所以比以往任何时候都没有理由期待兼容性问题。)
与所有以前的软分叉一样,未升级的用户会受到间接影响,因为他们不再执行完全验证。
部署
此BIP将通过 UASF-style 的块高度激活进行部署。块高度TBD。
参考实施
见:https://github.com/drivechain-project/mainchain
另外,有关兴趣,请参阅此处的示例侧链:https://github.com/drivechain-project/sidechains/tree/testchain
参考文献
http://www.drivechain.info/literature/index.html
http://www.truthcoin.info/blog/blind-merged-mining/
http://www.truthcoin.info/images/bmm-outline.txt
贡献者
感谢所有为讨论做出贡献的人,特别是:ZmnSCPxj, Adam Back, Peter Todd, Dan Anderson, Sergio Demian Lerner, Matt Corallo, Sjors Provoost, Tier Nolan, Erik Aronesty, Jason Dreyzehner, Joe Miyamoto, Chris Stewart, Ben Goldhaber。
版权
该BIP根据BSD2条款许可证获得许可。
来源:金色财经