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. 這就解決了凍結的問題,因爲現在如果你想通過這種方式造成延遲,你就必須爲延遲期間的所有側:獎勵付費。