[Coin] 0-confirmation, Avalanche, Coordicide

看板DigiCurrency (數位貨幣)作者 (達克鴨)時間5年前 (2019/06/07 01:23), 5年前編輯推噓27(27031)
留言58則, 23人參與, 5年前最新討論串1/1
這三個技術有個共通點,就是都很"快" 只是目的不太一樣,但因為剛好歷史上有部分技術互相傳承,就一起講吧。 Zero-confirmation是要讓使用者快速安全地完成一筆小額交易。 Avalanche則是要盡快形成不可逆的預共識,避免零確認交易可被雙花。 Coordicide則是要讓全網達成finality共識,移掉COO。 Zero-confirmation現在已經快要變成黑歷史了,不過在早期根本被當作理所當然。 而且是直接寫在bitcoin.org網站上 https://web.archive.org/web/20140122225824/http://bitcoin.org/en/ Instant peer-to-peer transactions 而且是早在中本聰還在的時候就已經被提出的技術。 https://bitcointalk.org/index.php?topic=423.0 我之前有講過Bitcoin交易的傳輸是flooding到整個P2P網路上。 但是假如有double spend交易發生,依照first seen規則,它是無法蓋過原本的交易的。 唯一的可能性就是在第一筆交易A發出後,確定對方收到後,再瞬間發出雙花交易B。 那麼就有可能發生網路中同時有交易A和交易B,一直要到區塊產生,才能產生共識。 Zero-confirmation技術就是先建立一個或多個連線非常良好的完整節點。 鄰居高達上百個節點,不斷監聽整個網路中的交易訊息。 只要發現網路中同時有交易A和交易B,那很顯然就是一個雙花交易。 交易立刻不成立,而且只需要額外等待不到五秒。 而這就是早期無論是bitpay還是coinbase的標準支付方式,零確認數秒內即可交易完成。 https://youtu.be/ZWcezOH06Ds?t=106
但是還不夠好,因為你要先建立一個連線非常良好的完整節點,耗費頻寬啊。 所以BCH現在有個機制是dobule spend alert 機制, 只要任何一個節點發現了衝突的雙花交易,立刻廣播全網dobule spend alert。 敢雙花還想逃,整個網路都知道了。任何利益關係人就可以立刻終止交易。 但是還不夠好,因為礦工可以全部偷偷自己來,我要雙花的交易幹嘛廣播。 等我挖出區塊後,再塞到新挖出的區塊就好了。 譬如我擁有30%的Bitcoin總算力,那我就有30%的機會成功雙花。 而且在我成功前不會有任何人知道,可以不斷嘗試。 這就是零確認最大的問題,惡意礦工可以自己嘗試雙花。 所以通常交易所都要等三個確認以上,也就是平均三十分鐘才會完成。 假如我們不想等確認,就會需要一個可以在極短時間內形成pre-consensus的機制。 也就是全網必須在極短時間內解決拜占庭問題,產生一個共識排除後來的雙花交易。 像是日本人好像都會很有共識地在公共場所做同一件事情,因為他們會讀"空氣" Avalanche這一系列的協定,其實基本概念就跟日本人讀空氣是一樣的。 https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV Avalanche只作用在衝突交易的共識形成,所以基本上並不影響後續PoW的運作。 礦工仍然可以自己選擇要讓那些交易進區塊,哪些不要。 就算不寫到consensus rule也是可以運作,就像是segwit那樣。 只要大部分的礦工節點遵循Avalanche,不符合pre-consensus的雙花交易區塊就會被丟棄。 接下來的例子假設網路上有個衝突的雙花交易A和交易B,需要網路凝聚共識決定。 下面有四個同樣都是用讀空氣法則的共識協定: 越前面的越簡單,但是越不安全。越後面的則比較複雜,但安全性較高。 Slush: 首先跟Bitcoin原來協定一樣,交易先到先贏。一個節點將會有交易A或交易B。 每個節點會去問k個鄰居節點你們是認定哪個交易?A或B交易? 假如鄰居節點認定某筆交易的比率大於0.5k,也就是超過一半都認定是某筆交易。 那就無論自己原來是什麼交易,都認定為該筆交易。 這個詢問動作只要不斷執行,在沒有惡意節點的狀態下,最後全網只會有一個共識交易。 但問題就是沒辦法防止惡意節點故意搗亂,沒辦法達到BFT。 一群惡意節點可以當變色龍,認定的交易亂跳導致最終共識無法確定。 Snowflake/Snowball: 為了避免共識亂跳的問題,這兩個改進版的協定加上了類似finality的概念。 就像是BCH超過十個確認後,區塊鏈不再reorg。deep reorg是不允許的。 Snowflake/Snowball加上了confidence值,當現在認定的交易被鄰居連續地確認。 那confidence就加一,當confidence到達預設的閥值,就進到finality狀態。 認定的交易就不再改變了。 Snowball則更難換認定的交易,不光是進到finality後不再改變認定的交易。 連進到finality狀態前要改變認定的交易都必須新交易的confidence值大於舊交易。 現在總算達到最後完整版的雪崩協定 Avalanche: 與其用Snowball的新交易的confidence值需大於舊交易才能夠改變。 其實還有讓交易更難以被任意改變的方式,那就是IOTA的DAG。 現在致敬IOTA用DAG串起所有收到的未確認交易,越早期的交易越不容易逆轉,權重越高。 這部份很類似於IOTA的tip selection algorithm 一樣會去算衝突交易的權重,並比較兩筆交易何者權重比較高。 鄰居節點用這個方式去回答最高權重的衝突交易。 然後此交易的confidence++ 跟之前方法一樣,一樣到達一個閥值後,進到early commitment。 這筆交易就是可以被接受的。 到這邊已經差不多講完整個雪崩協議家族了,但還是有個問題。 假如任何節點都可以進入pre-conseus,並且不用付出額外成本地執行雪崩協議, 那其實用Sybil attack產生大量惡意節點來摧毀整個Avalanche系統根本超簡單。 這也就是為什麼中本聰的共識機制根本不搞 1 IP 1 Vote的原因。 用Proof-of-Work來確保51%攻擊要需要非常高的成本。 並且將其導入到整個Bitcoin利益模型之中,到現在還是無可取代的完美傑作。 這就是為什麼我不認為一個完全沒有手續費也沒通膨加密貨幣有可能實現真正的去中心化。 因為形成一個去中心化的共識就是會需要付出額外的成本。 所以在BCH版本的Avalanche必須依照PoW特性做很多修改。 譬如在只有礦工節點才需要執行Avalanche,因為只有他們才會產生區塊。 你必須至少在前一百個區塊裡至少產生一個區塊才能參與Avalanche。 這已經可以產生非常高的女巫攻擊成本。 而且產出區塊越多,可以投越多票,更可以線性增加女巫攻擊的難度。 甚至交易的confidence也會和現在正在進行中的PoW nonce值有關。 這部分並沒有達到最終定案。不過BCHD目前很積極地要把Avalanche整合進來。 https://github.com/gcash/bchd/blob/avalanche/avalanche/spec.md 目前已經有些先期測試數據,只需要兩秒就可以達成雪崩協定的finality。 https://shanma.pro/news/23603.html 也就是在未來只要交易所願意,數秒內入賬是有可能性的。 比那個閃電網路搞到現在,還是沒什麼交易所願意接受這種風險。 LN甚至多Hop狀態下交易速度還比較慢,Avalanche使用體驗將會好很多。 https://twitter.com/haydenotto_/status/1135025360611844097 換到了IOTA的Coordicide,因為IOTA的Tangle並不具有共識達成finality的特性, Tangle是一直在亂長的,tip selection algorithm是局域的, 所以IOTA基金會才要搞個COO, 直接跟你講那些交易哪些tip給我優先挑,Tangle不要給我亂長。 直接milestone發出達成finality。 現在有了Avalanche這個概念,可以在極短時間內達成達成BFT的finality狀態。 這實在是太棒啦,只有一個問題,前面已經提過的女巫攻擊。 我不認為一個真正去中心化的共識可以在不耗費額外成本的狀態下產生。 BCH要解決這個問題太簡單了,直接把PoW拿來用,甚至可以直接帶入BCH的利益體系中。 但是IOTA就不要手續費,所以也不會有礦工,用PoS則會有其他問題。 因此就另外創出了Mana和KYC解決這個問題。 它類似於PoS用資金來當作共識參與門檻,Put your money where your mouth is 再來剩下的部分我覺得和Avalanche就大同小異而已。 只不過把名稱都改過而已。 把詢問鄰居節點的行為改成Cellular Consensus 為了讓整個架構在數學上更無懈可擊, 提出了加入了隨機參數的Fast Probabilistic Consensus 但整個理念和Avalanche系列裡的Snowflake/Snowball讀空氣達成共識是一致的。 -- simpleledger:qryeahexpqszdt9ffech6jhxu6wsfp0fnyhgd44ahf Bitcoin: 1GxtyprMfcxE366BDUsg1skQyuAnxktZjc https://www.blockchain.com/zh/btc/address/1GxtyprMfcxE366BDUsg1skQyuAnxktZjc Bitcoin Cash: bitcoincash:qp928h4q4xasa5wh2x88xhsxgc4vwj6g95uzq0ak97 https://goo.gl/2qNr43 Ethereum: 0x4A2B1e35eb64141bbad4C58cB7D79692bC5Dbbc2 https://etherscan.io/address/0x4A2B1e35eb64141bbad4C58cB7D79692bC5Dbbc2 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.255.217.155 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/DigiCurrency/M.1559841811.A.B10.html 2507字 * 10星 = 25070 PCH https://tinyurl.com/y4zuxbrf

06/07 01:34, 5年前 , 1F
禁止deep reorg好像是BTC就有的?只是我不太懂 這樣不會出
06/07 01:34, 1F

06/07 01:34, 5年前 , 2F
問題嗎
06/07 01:34, 2F

06/07 01:37, 5年前 , 3F
所以Avalanche是讓誠實礦工挑選的零確認交易更一致
06/07 01:37, 3F

06/07 01:38, 5年前 , 4F
最終的共識當然還是以區塊鏈裡的為準 是這個感覺對吧
06/07 01:38, 4F

06/07 01:40, 5年前 , 5F
最終共識的確是以區塊鏈裡最長鏈為準
06/07 01:40, 5F

06/07 01:41, 5年前 , 6F
礦工也可以完全不理Avalanche的共識
06/07 01:41, 6F

06/07 01:41, 5年前 , 7F
只是它產生的區塊會有很高的機會被orphan掉而已
06/07 01:41, 7F

06/07 01:51, 5年前 , 8F
意思是跟Avalanche唱反調的礦工挖出的區塊 即使已經領先一
06/07 01:51, 8F

06/07 01:52, 5年前 , 9F
個高度 也不會被Avalanche節點所接受嗎?
06/07 01:52, 9F

06/07 01:53, 5年前 , 10F
(設AB為一對雙花交易 Avalanche節點決定的是A 唱反調的是
06/07 01:53, 10F

06/07 01:53, 5年前 , 11F
B)
06/07 01:53, 11F

06/07 01:53, 5年前 , 12F
是的,這運作方式其實跟segwit一樣的
06/07 01:53, 12F

06/07 01:53, 5年前 , 13F
假如沒有硬分叉寫到consensus rule會這種狀態
06/07 01:53, 13F

06/07 01:54, 5年前 , 14F
含有不符合segwit規則的segwit交易其實是valid chain
06/07 01:54, 14F

06/07 01:55, 5年前 , 15F
但因為驗證segwit規則的算力佔絕大多數
06/07 01:55, 15F

06/07 01:55, 5年前 , 16F
所以不會有問題
06/07 01:55, 16F

06/07 01:56, 5年前 , 17F
任何敢不驗證segwit規則的礦工區塊只會被丟棄
06/07 01:56, 17F

06/07 01:56, 5年前 , 18F
可是這就不是以最長鏈為準了耶 還是說如果那條超過太多的話
06/07 01:56, 18F
所以你知道segwit的恐怖了吧,它其實偏離中本聰的想法非常多了

06/07 01:57, 5年前 , 19F
不過用在pre-consensus上就幾乎沒啥問題
06/07 01:57, 19F

06/07 01:57, 5年前 , 20F
最後Avalanche節點們還是會一起反悔?
06/07 01:57, 20F
這是預共識,若要讓Avalanche協定真正有效,不是約定好玩的話。 就是必須拋棄不遵守Avalanche預共識的區塊。 不過因為在BCH裡只處理conflict雙花交易, 所以影響比segwit被搞到會影響到所有segwit地址好太多。 一個能夠導致共識分裂的雙花交易其實並沒有常常產生。 就算礦工不鳥Avalanche,它的區塊也不一定就會被拋棄。 https://doublespend.cash/ 這邊有統計數據,我認為真的需要用到Avalanche去處理的衝突交易, 一天大約一個區塊而已。

06/07 01:58, 5年前 , 21F
只是如果Avalanche節點佔據多數算力的話 通常可以馬上再反
06/07 01:58, 21F

06/07 01:58, 5年前 , 22F
超而已
06/07 01:58, 22F
是的

06/07 02:08, 5年前 , 23F
我知道很不常發生~只是想確認一下極端情況下採取的對策
06/07 02:08, 23F

06/07 02:09, 5年前 , 24F
就是最長鏈跟Avalanche不一致的情況
06/07 02:09, 24F

06/07 02:11, 5年前 , 25F
不管那條最長的領先多少 Avalanche節點都不會鳥那一條嗎
06/07 02:11, 25F
這實作上我不知道怎麼做ㄝ 超過10個區塊高度BCH就不會reorg了, 所以應該是領先十個區塊就不應該再理Avalanche預共識。

06/07 02:20, 5年前 , 26F
「領先十個區塊就不應該再理Avalanche預共識」的意思
06/07 02:20, 26F

06/07 02:20, 5年前 , 27F
就是當Avalanche節點們發現最後輸太多 還是會往長的那條妥
06/07 02:20, 27F

06/07 02:20, 5年前 , 28F
協嗎
06/07 02:20, 28F

06/07 02:21, 5年前 , 29F
抱歉不是要鑽牛角尖 只是想確定板大的意思~
06/07 02:21, 29F
這我不知道啊,只是要這樣才合理,不然網路就分裂了。

06/07 02:22, 5年前 , 30F
了解了~我也覺得這樣才對
06/07 02:22, 30F

06/07 02:22, 5年前 , 31F
總之Avalanche節點佔據多數算力的情況下 最後輸掉的情況很
06/07 02:22, 31F

06/07 02:22, 5年前 , 32F
少 這樣就夠了
06/07 02:22, 32F

06/07 03:23, 5年前 , 33F
06/07 03:23, 33F
※ 編輯: DarkerDuck (111.255.217.155 臺灣), 06/07/2019 04:00:15 ※ 編輯: DarkerDuck (111.255.217.155 臺灣), 06/07/2019 04:27:42

06/07 05:36, 5年前 , 34F
好文大推
06/07 05:36, 34F

06/07 06:22, 5年前 , 35F
版主太猛了!
06/07 06:22, 35F

06/07 07:58, 5年前 , 36F
感謝版主,好文推薦
06/07 07:58, 36F

06/07 08:13, 5年前 , 37F
bch會不會發生多數節點不願意加入avalanche的狀況呢?
06/07 08:13, 37F
這個問題好解決,就跟當初segwit在BTC上啟動一樣就好。 avalanche會需要多數礦工在區塊鏈上投下同意票後才會啟動。

06/07 08:16, 5年前 , 38F
因為目前看起來並沒有經濟誘因去驅動節點,不知道會不
06/07 08:16, 38F

06/07 08:16, 5年前 , 39F
會形成之前segwit在bch的狀況
06/07 08:16, 39F
這個問題不錯,雖然礦工加上pre-consensus協定並沒有太大的短期好處。 但長期來說,這可大幅加強BCH的競爭力和使用者體驗。 那麼BCH上的使用者和交易就會更多,長期來說,礦工當然就可以收到更多交易手續費。 從很多礦工其實都支持BCH來看,這些礦工並非短視近利,而更在意長期的發展性。 ※ 編輯: DarkerDuck (111.255.217.155 臺灣), 06/07/2019 08:23:56

06/07 08:20, 5年前 , 40F
發現上面好像有類似回答,再推個><
06/07 08:20, 40F

06/07 08:23, 5年前 , 41F
覺得版主之前結合手續費的想法更能夠保護網路安全
06/07 08:23, 41F

06/07 09:02, 5年前 , 42F
不明覺厲推
06/07 09:02, 42F

06/07 09:09, 5年前 , 43F
推推推
06/07 09:09, 43F

06/07 10:31, 5年前 , 44F
黑鴉大真的是很強,對技術的了解令人敬佩不已
06/07 10:31, 44F

06/07 10:32, 5年前 , 45F
看來IOTA要達到願景真的不容易,還是期待,凸了木!
06/07 10:32, 45F

06/07 10:58, 5年前 , 46F
06/07 10:58, 46F

06/07 11:04, 5年前 , 47F
06/07 11:04, 47F

06/07 11:32, 5年前 , 48F
解說推。
06/07 11:32, 48F

06/07 12:18, 5年前 , 49F
推推
06/07 12:18, 49F

06/07 12:53, 5年前 , 50F
06/07 12:53, 50F

06/07 15:32, 5年前 , 51F
推技術文
06/07 15:32, 51F

06/07 15:45, 5年前 , 52F
06/07 15:45, 52F

06/07 16:17, 5年前 , 53F
06/07 16:17, 53F

06/07 18:58, 5年前 , 54F
謝謝版主解說
06/07 18:58, 54F
※ 編輯: DarkerDuck (36.237.86.113 臺灣), 06/07/2019 20:27:54

06/07 20:39, 5年前 , 55F
推推
06/07 20:39, 55F

06/07 22:48, 5年前 , 56F
06/07 22:48, 56F

06/07 23:29, 5年前 , 57F
06/07 23:29, 57F

06/08 21:55, 5年前 , 58F
06/08 21:55, 58F
※ 編輯: DarkerDuck (111.255.218.160 臺灣), 08/13/2019 09:09:38
文章代碼(AID): #1S-KmJiG (DigiCurrency)
文章代碼(AID): #1S-KmJiG (DigiCurrency)