Drivechain

作者:扎克-赫斯, Zack Hess

https://github.com/zack-bitcoin/amoveo-docs/blob/master/other_blockchains/drivechain.md

草稿版本6 驱动链的目标是允许多个不同的区块链被单一区块链上的PoW共识所保障。驱动链的目标是,比特币矿工不应该被要求考虑或参与到侧链中。

摘要 #

本文的目标是,不可能使用目前设计的drivechain来保护任何形式的侧链共识状态。对于攻击者来说,骚扰侧链的用户到侧链无法使用的地步总是很便宜的。比特币的PoW安全并不能很好地保护侧链的安全。

本文中的批评意见之前没有得到回应 #

我在这里提出的批评既不是本文的(1)也不是(2):http://www.drivechain.info/peer-review/peer-review-new/

  • 我不是在描述矿工窃取侧链资金的方法。
  • 我不是在描述一种可能导致池子开销或txn审查的方式。

http://www.truthcoin.info/blog/blind-merged-mining/ 里"Problem" “一节中,保罗描述了攻击者如何通过发送无效的区块数据来阻止侧:链的进展,以及为什么这不是一个安全问题,因为主链矿工可以暂时升级为侧链全节点,以了解哪个版本是有效的。

这个问题与我在本文中提出的批评不同。保罗解决的 “问题 “是如何防止side:chain硬更新。我所描述的问题与此有些关联。在我的评论中,攻击者正在进行侧面:软更新。

保罗的解决方案只是将矿工升级到side:full-node状态,对于防止side:hard更新很有效,但它没有解决软分叉的问题,因为软分叉的两边在side:full-node看来都有效。

在描述这一机制的数学中存在的错误 #

http://www.truthcoin.info/blog/drivechain/ 在 “Some Math (ie, Feel Free to Skip)” “一些数学(即随意跳过)“一节中 保罗做了一些数学计算,如果矿工审查侧链区块数据,他们的成本是多少,以试图证明驱动链确实有效。本节中的数学计算是基于一些错误的概念。

  • 在软分叉被合并后,根据新的规则集,无效的TXS与其他无效的TXS一样无效。假装有可能从因软分叉而无效的TXS中收到TXS费用,这就像假装有可能制造一个不知从何处创造出10k BTC的TXS,并向矿工支付9k BTC的费用让它发生。不管费用有多高,无效的TXS都不能被纳入。这个原则对于发生在侧链上的软分叉也是如此。
  • 对于审查侧:TXS来说,这并不是一个全有或全无的情况。例如,我们可以执行一个高的tx费用,支付给比特币矿工,审查所有不支付的侧:txs。这将是在完全窃取侧链价值和支持它的存在之间的一个妥协。根据拉弗曲线,以及这个侧链的竞争的存在,这个侧链:软分叉可以增加矿工的收入。在任何情况下,被破坏的价值将远远大于你需要支付给矿工的贿赂来实现它。
  • 在{ 2b }中计算的 “矿工总损失 “值,这是在所有矿工中分摊的成本。如果我只有1/10的算力,那么我只会感受到总损失的1/10,我只会造成与我的hashpower成比例的损失增加。总的来说,我参与的成本是TML*((我的算力)/(总算力))^2。这是一个公地悲剧的情况。个人的利益和集体的损失,但保罗后来把这个计算的结果当作个人利益和个人损失来应用。

破损机制的描述 #

drivechain中不起作用的部分是盲目合并挖矿。这里是保罗的描述:http://www.truthcoin.info/blog/blind-merged-mining/

我将用我自己的话来描述它。

为了使一个侧链区块有效,它的哈希值需要被记录到主链区块中。因此,侧链区块创建者需要向主链矿工付费,以便将这个哈希值纳入他们的区块中。由于任何人都可以创建侧边区块,侧边区块创建者需要将该侧边区块的几乎所有费用作为贿赂给主链矿工。

在 “处理重组 “部分,保罗解释了侧链的分叉选择规则。获得更多确认哈希值记录到主链上的侧链分叉版本获胜。

这意味着,得到更多确认的一方:链式分叉的一方是历史的有效版本。

侧链区块创建者为让他们的侧链区块被创建而支付的任何费用,如果他们的侧:区块成为孤儿,他们不会得到退款。如果侧:区块是孤儿,他们不会收到任何Tx费用。

因此,如果他们的区块被遗弃,对侧链区块创建者来说是非常昂贵的。

为什么导致侧块被遗弃的成本很低? #

主链矿工并不关心他们正在验证的一方:区块是否会成为孤儿区块。无论怎样,他们都会得到费用。 如果主链矿工经常允许边区块成为孤儿,这将间接损害他们,因为它使整个网络变得更糟。但是,主链矿工的这一成本是(他们所拥有的算力的百分比)。随着算力变得更加分散,他们越来越愿意允许边区块成为孤儿。

只要会导致孤儿发生的侧区块支付的费用高于矿工对前一个侧:区块进行孤儿化的成本,那么矿工就愿意去验证它。

尽管这样做对矿工的好处远远小于边区块成为孤儿对网络造成的损失。这就是公地的悲剧。

双重消费的攻击。最终性问题。 #

侧链孤儿与主链孤儿不同,因为侧链区块是以流动货币支付的,而主链区块是以非流动的算力支付的。

首先描述一下主:链采矿。如果你试图买起51%的算力,那么你买的越多就越贵。如果你拥有比整个网络多2倍的算力,你仍然只能每小时重写1小时。因此,如果你在10个小时内有2倍的算力,你可以改写10个小时的pow历史。所以要改写10小时的历史,你需要花费20小时之多的(区块奖励)。

有了烧毁证明(proof-of-burn), ,有了驱动链侧链,你只需要愿意接受与前一次创造10小时区块的人相比稍小的奖励。

撤销drivechain中的侧链区块类似于撤销proof-of-burn区块链中的区块。任何愿意接受较小奖励的侧块创建者都可以重写这些侧块。

这意味着驱动链侧链将有非常缓慢的最终性,无法确定一个TX是否能真正终结。

冻结攻击 Freeze Attacks #

如果你想造成驱动链侧链的延迟,你只需要愿意接受比前次在该历史上创造区块的人稍小的奖励。 由于导致侧链停止处理TXS的成本很低,而攻击者可以通过在其他市场上下注来冻结侧链获利,这意味着驱动链侧链的信任度为4级。 basics/trust_theory.md

如果你想造成比特币延迟,你需要支付超过相关时期的(所有费用)+(所有区块奖励)的费用,而且费用的价格会不断变高,因为稀缺性会推动需求。所以你要支付的是((区块奖励)+((额外的高费用价格)*(一个区块中能容纳的Tx数量)))*(攻击期间的区块数量)。

侧链区块创建griefing #

如果有人花99美元赚了100美元并创建了一个区块,而我花101美元赚了100美元并创建了同样的区块,导致他们的区块成为孤儿,那么这意味着我只损失了1美元,但我导致别人损失了100美元。由于与攻击的成本相比,有可能破坏别人更多的价值,这意味着Drivechain侧链的信任度为3级或更差。 basics/trust_theory.md

没有区块奖励的比特币 #

保罗说,他设计drivechain的一个基本假设是,只有当比特币有可能在没有区块奖励的情况下是安全的,drivechain才能发挥作用。

来自Drivechain Telegram的保罗–“我对Drivechain的一个论点是,我们可以用它来学习缺乏区块奖励的区块链的行为。”

看来,比特币确实将能够在没有区块奖励的情况下运作 https://twitter.com/fnietom/status/1037235118136602625?s=20

Drivechain使用的是与比特币不同的、安全性较低的共识机制,没有区块奖励。 #

在drivechain目前的设计中,侧链实际上与比特币没有区块奖励时的情况非常不同。 在没有区块奖励的比特币中,如果一个区块成为孤儿,矿工不会得到报酬。矿工以哈希值的形式承担损失。哈希值是一种非流动性的价值类型。如果一个攻击者积累哈希值来进行攻击,这意味着他需要51%的全球哈希值,这非常昂贵。

在驱动链中,如果一个侧:区块成为孤儿,矿工确实得到了报酬,而一个侧:区块的创造者,是与矿工不同的人,他以货币的形式承担了损失。货币是一种流动的价值类型。如果一个攻击者积累货币进行攻击,他只需要花费与攻击期间的所有费用一样多的钱。这相对来说是很便宜的。

造成孤儿的这种成本差异意味着,对其中一个系统的安全性作出的结论不一定能适用于另一个系统。

我们能否通过拆分区块奖励,让部分区块在侧链内创建来解决这个问题? #

如果侧:区块创建者因创建区块而获得区块奖励,那么实际上100%的区块奖励将归于包括该区块哈希值的主矿工,这与为什么费用归于主矿工的经济理由相同。如果该区块成为孤儿,区块奖励实际上使侧:创造者比原来更昂贵。现在,侧:创造者不仅仅是失去了费用,他们也失去了区块奖励。所以这是不可行的。

我们可以通过分割主链上的区块奖励来解决这个问题吗? #

想象一下,如果在主链中,任何验证侧边:区块的主链:区块奖励都会更高。问题是,主链矿工仍然没有动力去避免造成侧链的孤儿。

如果side:block是孤儿,我们能否通过取消对main:miner的付款来解决这个问题? #

我们可以使用prevSideBlock的参考号码来计算哪些块是孤儿,或者我们可以向BMMR添加更多的数据。

在这种情况下,侧链将等同于没有区块奖励的比特币。

  1. 这就解决了造成孤儿和伤害side:block创建者的很便宜的问题。
  2. 这就解决了最终性问题,因为攻击者必须重新挖所有这些区块奖励。
  3. 这就解决了冻结的问题,因为现在如果你想通过这种方式造成延迟,你就必须为延迟期间的所有侧:奖励付费。