解讀區塊鏈,軟分叉和硬分叉__區塊鏈

來源:互聯網
上載者:User
解讀區塊鏈,軟分叉和硬分叉
最近在交流群和論壇中經常聽到軟分叉和硬分叉,起初對這個概念只是簡單認為是區塊鏈軟體升級後新舊協議造成新舊節點對新的區塊認可時的一種分歧,軟分叉一般不會產生永久性分叉的鏈,而硬分叉則會產生兩條鏈,如果大多數節點升級到新版本,則舊鏈存活就看算力的大小的。
查詢了些資料,再次明確下軟硬分叉的概念。
軟硬分叉涉及的問題是去中心化節點軟體、協議、版本升級的問題,所有在區塊鏈中啟動並執行節點有一樣的軟體,遵守一樣的共識機制、維護同一條鏈,但是一旦軟體、協議、版本升級後,所有節點不可能同一時間都更新到同一版本,這就造成了一部分節點擁有新的共識協議機制,這時候會網路中出現新、老、兩種節點。那麼在區塊產生的時候,新節點產生的區塊,老節點就會認為合法或者不合法,老節點產生的區塊,新節點也會認為合法或者不合法。在區塊鏈中一直有一個51%算力的臨界點,那麼我們這裡認為新節點的算力是大於50%的。

首先再對軟硬分叉做一個解釋:
軟分叉:官方定義:A temporary fork in the block chain which commonly occurs when miners using non-upgraded nodes violate a new consensus rule their nodes don’t know about.(當新共識規則發布後,沒有升級的節點會因為不知道新共識規則下,而生產不合法的區塊,就會產生臨時性分叉。)說實話官方定義感覺有點模糊。
當整個區塊鏈網路中,系統版本或協議升級後,且和老版本協議不相容,那麼升級後的新節點就無法接受老節點挖出來的全部或者部分區塊,因為新節點的算力較大,所以老的節點挖出來的區塊沒有機會得到認可,老節點產生的區塊最終會被認為是短鏈而被放棄,新老節點始終還是在同一條鏈上工作,這種情況稱作軟分叉。新節點要求比老節點嚴格多。
硬分叉:官方定義:A permanent divergence in the the block chain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.(區塊鏈發生永久性分歧,在新共識規則發布後,部分沒有升級的節點無法驗證已經升級的節點生產的區塊,通常硬分叉就會發生。)
當整個區塊鏈網路中,系統版本或協議升級後,且和老版本協議不相容,未升級的老節點無法接受新節點挖出的全部或者部分區塊,導致出現了兩條鏈,假設新節點的算力較大,新節點們在維護一條鏈,老節點也始終在維護一條他認可的鏈,如果這時候大多數的節點都開始升級為新版本,那麼老節點維護的鏈能不能存活就看算力有多少了,這就稱作硬分叉。
很明顯,最粗淺的理解就是軟分叉還是一條鏈,硬分叉就會分成兩條鏈。
以太坊和比特幣中都出現過分叉的問題,針對現實應用,軟分叉和硬分叉在實際應用中有什麼優缺點:
軟分叉只有一條鏈(最簡單明了),開始不要求區塊鏈中所有節點統一時間升級,可以允許逐步升級,並且在軟分叉過程中不影響系統的穩定性和有效性。但是軟分叉又有個前提就是老的未升級節點要能接受新節點產生的區塊,這就要求系統要向前相容(forward compatible,這個和一般我們在用的軟體向下相容是相反的方式,要求新出現的區塊對老系統留一個餘地,確保相容),其實讓老節點承認新的區塊,實際是一種欺騙,讓老節點沒法察覺實際上發生的變化,這也違背了單點完整性驗證。
以太坊和比特幣中都曾出現過軟硬分叉的事件:
The DAO在2016年駭客通過splitDAO函數遞迴發送模式上的漏洞曾經竊取了360萬個以太幣,splitDAO函數在執行時最後才修改使用者的結餘和交易額,如果能夠在返回splitDAO處理運算之前,進行多次以太幣的操作調用,那麼多次遞迴來持續轉移以太幣到別的賬戶。(具體程式碼分析查看鄒均大神的區塊鏈技術指南P210或者網上http://blog.csdn.net/sportshark/article/details/51820008),由於代碼漏洞發布後無法修改,DAO求助以太坊,以太坊最初採用軟分叉的方式,鎖定the DAO帳號,不允許發生交易,凍結以太幣,這裡可以發現軟分叉實際上是在以太坊軟體上加了約束規則,使得駭客的以太幣無法交易,這樣不影響以太坊其餘的正常交易,不要復原區塊鏈的資料(復原影響之大難以想象)。在實施軟分叉方案時,在以太坊的每個交易上都會檢查DAO相關的地址,如果和DAO有關聯就拒絕這個交易,從而鎖定所有資金,但是這個方案沒有收取交易GAS費用,攻擊者一旦以零成本發起大量無效交易,那麼這個網路就面臨癱瘓,最終各個節點回退了軟體版本,軟分叉失敗,隨後實施了硬分叉,下圖:

硬分叉方案在1880000區塊把DAO的合約歸在另外一個L列表中,在1920000區塊,設計一個非常規的狀態變更,強行把L所有地址餘額轉到一個退款地址中,這樣眾籌的DAO幣就可以換回以太幣,最終硬分叉成功,上圖中1920000區塊後面,左邊為區塊編號,右邊為hash值,直線代表新鏈,節點升級後都在新鏈上記賬,沒有升級的節點在舊鏈記賬。

現在以太坊上為了區分新鏈-ETH,舊鏈ETC,兩個鏈除了DAO涉及部分軟體代碼相同,曆史帳號分叉前相同,地址和私密金鑰也相同,故都為合法。(當然還有重放攻擊,同樣參考鄒均大神P216)。
同樣在比特幣中,出現過軟分叉(http://ns2.btckan.com/news/topic/29027 談國鵬,這位大神還有視頻講解,youku和巴位元都有,可以搜尋下。這個文章中寫的很詳細明,筆者就直接拷貝過來了。)P2SH軟分叉升級,P2SH包含在BIP16中,通過軟分叉進行升級比特幣系統,讓比特幣在支援P2PKH基礎上,再支援一種叫P2SH的標準交易類型。在此之前,比特幣已經支援如下的指令碼:”OP_HASH160 [20-byte-hash-value] OP_EQUAL”。要花費這樣的指令碼你只需要把hash值的原資料(preimage)推到(push data)棧上即可。
P2SH是對以上條件的一種更嚴格限制,在P2SH模式(新節點)下,你不但需要提供該hash值的原資料,還要保證:
該原資料是一個可執行檔指令碼;
該指令碼執行結果返回:true;
該指令碼中不能含有”push data”的操作;
以及其它的一些限制;
當支援P2SH的新節點被部署時,新節點的算力>50%(P2SH升級時要求>=55%),系統將處於下面的運行狀態中:P2SH交易被轉寄到老節點時,會被老節點認定為非標準交易(有了新的,或不能理解的OP_CODE),老節點不接受、不打包、不轉寄;當包含有P2SH交易的區塊廣播到老節點時,老節點接受區塊,並按原有規則驗證該P2SH交易,結果通過,因為老的規則只要驗證原資料的hash是否相等(顯然是相等的);老的節點建立了一個原資料為:123456的指令碼輸出,並花費該輸出。老節點們能夠接受。但是廣播到新節點時,按新規則(必須是指令碼…)則不通過,新節點拒絕接受,認定為非法,不會打包該交易。即使該交易被老節點打包,也會被新節點拒絕。因為新節點控制多數算力,這樣的交易將永遠無法生效;系統同時維護一條鏈。
P2SH的升級細節:
要求支援P2SH的礦工在其coinbase交易裡包含“/P2SH/” 字樣;
2012年2月1日檢查之前1個星期內的所有區塊(約1000個),如果超過550個包含(約55%)則啟用P2SH。
SegWit軟分叉升級
SegWit主要包含在BIP141-144中,通過軟分叉進行升級比特幣系統,讓比特幣支援一系列SegWit的功能集。關於隔離見證的具體內容詳見《談談區塊連(21):比特幣之隔離見證》。
通過軟分叉升級需要讓老的節點認定新的交易為非標準交易,但同時是合法的。隔離見證是如何做到的呢。答案是:anyone-can-spend的輸出交易。
anyone-can-spend:
下面是一個anyone-can-spend的例子:
scriptPubKey: (empty)
要花費這樣的輸出,你只需要提供這樣的簽名指令碼:
scriptSig: OP_TRUE
隔離見證中將指令碼版本(script versioning)和anyone-can-spend完美結合。一個標準的P2WPKH的輸出如下:
scriptPubKey: 0 <20-byte-key-hash> (0x0014{20-byte-key-hash})
這開頭的0在新節點中將是指令碼的版本號碼,在老節點中是一個anyone-can-spend的輸出。
當支援SegWit的新節點被部署時,新節點的算力>50%(SegWit升級時要求>=95%),系統將處於下面的運行狀態中:
SegWit交易被轉寄到老節點時,會被老節點認定為非標準交易(anyone-can-spend),老節點不接受、不打包、不轉寄;
當包含有SegWit交易的區塊廣播到老節點時,老節點接受區塊,並按原有規則驗證該SegWit交易,結果通過(因為它是誰都可以花費的);
老的節點嘗試花費SegWit交易,因為它是誰都可以花費的。老節點們能夠接受。但是廣播到新節點時,按新規則(隔離見證的驗證規則)則不通過,新節點拒絕接受,認定為非法,不會打包該交易。即使該交易被老節點打包,也會被新節點拒絕。因為新節點控制多數算力,這樣的交易將永遠無法生效;
系統同時維護一條鏈。
SegWit的升級細節:
升級到core 0.13.1及以上的支援SegWit;
2017年11月如果95%算力支援,則啟用SegWit。

參考網路和區塊鏈技術指南上的講解,分析了軟分叉和硬分叉,期間也看到另外一篇文章,http://www.8btc.com/tan90d97有興趣的讀者可以瞭解下,這個具體對亂硬分叉交易資料結構作了分析。 

轉載來自:https://blog.csdn.net/sxjinmingjie/article/details/77621311

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.