ETC遭受的廉價51%攻擊迷局
編者按：本文來自金色財經，Odaily經授權轉載。
編者按：本文來自
金色財經
此次攻擊由一個獨立礦工“0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e”發起。該礦工悄悄產出了3594個區塊，隨後一併廣播給其他礦工，由於這些區塊數量眾多，區塊順序比其他礦工所建立的鏈佔有更大權重，致使其他礦工不得不接受這一系列區塊，最終攻擊者區塊成功取代了原有區塊，從區塊高度10904146到10907740區塊發生重組。
，Odaily經授權轉載。
編者按：本文來自
金色財經
此次攻擊由一個獨立礦工“0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e”發起。該礦工悄悄產出了3594個區塊，隨後一併廣播給其他礦工，由於這些區塊數量眾多，區塊順序比其他礦工所建立的鏈佔有更大權重，致使其他礦工不得不接受這一系列區塊，最終攻擊者區塊成功取代了原有區塊，從區塊高度10904146到10907740區塊發生重組。
，Odaily經授權轉載。
編者按：本文來自
金色財經
此次攻擊由一個獨立礦工“0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e”發起。該礦工悄悄產出了3594個區塊，隨後一併廣播給其他礦工，由於這些區塊數量眾多，區塊順序比其他礦工所建立的鏈佔有更大權重，致使其他礦工不得不接受這一系列區塊，最終攻擊者區塊成功取代了原有區塊，從區塊高度10904146到10907740區塊發生重組。
，Odaily經授權轉載。
8月3日，ETC官方推特公佈了區塊鏈數據分析公司Bitquery針對ETC遭受51%攻擊事件的調查報告。
報告顯示，8月1日0:30-8月2日11:30，ETC遭受51%攻擊。
此次攻擊由一個獨立礦工“0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e”發起。該礦工悄悄產出了3594個區塊，隨後一併廣播給其他礦工，由於這些區塊數量眾多，區塊順序比其他礦工所建立的鏈佔有更大權重，致使其他礦工不得不接受這一系列區塊，最終攻擊者區塊成功取代了原有區塊，從區塊高度10904146到10907740區塊發生重組。
而鏈上數據表明，該名礦工故意從外部購買了哈希算力以發起攻擊，且該礦工地址自7月29日才顯示為活躍狀態，連續3天每天生成30個區塊。最終該攻擊者僅花費了17.5 BTC（約合17萬美元）欺騙整個ETC網絡12個小時，成功實施攻擊。
此外，由於在ETC網絡中，並非所有由節點和礦工運行的軟件都具有相同的行為，節點版本和軟件的多樣性使得此次攻擊更加嚴重：
基於Geth和Hyperledger Besu兩個客戶端的節點接受攻擊者的區塊並選擇最長的分叉鏈；
基於Open Ethereum客戶端的節點仍保留舊的鏈。而這些都導致有些礦工基於舊鏈轉賬，但在主要的ETC鏈（分叉鏈）上並未反映，而基於不同客戶端的節點可能面臨雙花。
據相關機構的調查，其具體過程如下：
1. 惡意礦工（ETC地址：0x75d1e5477f1fdaad6e0e3d433ab69b08c482f14e）挖掘了約3000個區塊。
2. 2Miners礦池由於Multi-geth結束對Ethereum classic的支持而短暫下線進行維護。
3. 當2Miners礦池維護的這段時間內，2Miners礦池並沒有產生新的區塊。在2Miners礦池結束維護上線後，約3000個區塊同時被插入到2Miners礦池中。
4. 由於Ethereum Classic上所有的Parity或者OpenEthereum節點都無法處理這3693個來自Core-Geth節點的區塊，因此就出現了鏈分叉：
所有的Parity或者OpenEthereum節點上的礦工都依舊在原始主鏈上進行挖掘，但是在Core-Geth節點的礦工就在被插入約3000個區塊的新鏈上挖掘。
5. 根據工作證明（POW）共識，在新鏈上的工作量會逐漸超過原始主鏈，在原始主鏈上Parity節點的一些礦工根據會“選擇在更多工作量的鏈上進行挖掘”的準則，轉移到新鏈上進行挖掘。
最終，在區塊高度10904146處，總共3693個區塊被通過重組（reorgnization）的方式被加入到區塊鏈中。
通過兩個機構的調查和信息公佈，很明顯的原因有2個，一是因為近期的客戶端支持問題，二是攻擊者恰恰利用了這一點。
不同的客戶端代表著不同的接入角色，礦工既是網絡維護方，也是數據的產生者，這意味著，如果在客戶端提供一些不正確的數據時，被其他節點同步，也就是攻擊的開始。
上文中的攻擊者利用礦池節點的重新上線時機，將準備好的區塊數據讓礦池誤以為是正確記賬數據而繼續廣播。而因為Parity、OpenEthereum、Core-Geth客戶端礦工的“不和”，對不同數據的同步不一致，因此，將導致分叉。
此次的攻擊的源頭是客戶端的混亂，而這件事的成因已醞釀久矣。
據金色財經此前報導，2020年1月25日，ETC Cooperative執行董事Bob Summerwill近期宣布擴展對ECIP-0001提案的支持，提案中一些變化包括，剔除Rust開發者Wei Tang。
Bob Summerwill指控稱，Wei Tang作為ECIP編輯者和ECIP-1000作者，多次濫用職權，威脅要軟分叉或是離開ETC生態系統。
此外，由於在ECIP-1000的編輯器列表中使用soc1c的真實姓名代替了soc1c，ETC社區中還有聲音指責稱Wei Tang對社區另一位ECIP編輯soc1c人肉搜索。
對此，Wei Tang於博客中解釋事件緣由，並回應稱，對於所涉及的提案要求作出更改等是出於避免ETC過於集中化的考慮。不過後期爭議實際轉移到了自己身上。同時Wei Tang表示並沒有所謂的人肉soc1c事實。因為此前合併編輯者列表時，soc1c本人已同意，且soc1c真實姓名在社區中廣為人知，且其本人也經常使用自己的真實姓名。
據悉，該爭議事件起於ECBP-1076提案。由於覺得首次在ETC會議上提出並一次性接受ECBP-1076提案，以及ECIP編輯將ECBP-1065提案狀態更改為“活動”的做法不謹慎，因此Wei Tang要求進行更多討論，但遭soc1c拒絕（ soc1c執行了撤銷審查），此後soc1c提交請求要求將Wei Tang從ECIP流程中剔除。此後，Aztlan硬叉過程中，又出現ECIP-1061和ECIP-1072的爭議（該爭議中也出現了“撤銷”操作）。 Wei Tang認為，提案過程中soc1c的“撤銷”操作實際上是很大的集中化風險，並創建了新請求，認為“撤銷”操作違反流程，不應被當做規範。
對於ETC Aztlán硬分叉時間推遲一事Wei Tang與社區也有不同觀點，他認為此前已經由於Aztlán規範的錯誤導致Mordor和Kotti測試網已產生無法消除的損害，現在只希望損害不會波及到主網。 Wei Tang稱“不負責任地硬分叉會破壞網絡安全，每天高喊代碼就是法律是沒用的。”
Bob Summerwill回應稱，分叉時間推遲是因為不可預測的區塊時間因素導致，而非社區更改了此前選定的硬分叉的區塊號。而區塊時間預測出現誤差是常有的事情。針對社區不健康的指責，Bob Summerwill回應ETC社區非常健康。
交鋒反反复复，而不能確認統一。
6月14日，Wei Tang就宣布了，其個人將停止支持ETC，原因為在Phoenix硬分叉後，ETC網絡打破了以太坊一致性的邏輯，特別是在不變性方面。
