區塊客先前曾報導,以太坊網絡將在區塊高度 7,280,000 進行預定升級,目前預計會在 UTC 時間 2 月 28 日星期四晚上 8 點左右發生(台灣/香港時間 3 月 1 日周五凌晨 4 時左右),實際時間會有所不同,具體取決於平均區塊時間和挖掘難度。
原訂於 1 月 15 日 進行的君士坦丁堡硬分叉在正式啟動前的數小時遭喊停,以太坊開發團隊緊急要求延後啟動,理由是發現可讓駭客進行可重入(reentrancy)攻擊的安全漏洞。
2 月 22 日,官方在公告中確認,在區塊高度 7,280,000 將進行名為「君士坦丁堡和聖彼得堡」的網絡升級。根據官方說法,此網絡升級有兩個名稱的原因是因為最初的君士坦丁堡網絡升級被推遲,並且需要在同一區塊上進行兩次協議升級,以便修復各種以太坊測試網絡上的問題。而早前發現的潛在漏洞來自君士坦丁堡中的 EIP-1283 提案,而聖彼得堡升級旨在將該提案從測試網路中刪除。
君士坦丁堡升級除了將提高網絡效率、節省手續費成本外,還將延遲實施「難度炸彈」同時減少以太坊的區塊獎勵(從 3ETH 減至 2ETH)。
根據開發團隊的說法,延遲「難度炸彈(也稱為 “冰河時代”)」約 12 個月,「以確保我們不會在還沒準備好實施權益證明(PoS)前『凍結』了區塊鏈網絡」,這個過渡期是為了讓以太坊從當前的工作量證明 (PoW) 邁向採用更具效率的權益證明共識演算法。然而,由於權益證明一再被延遲,因此現階段需將難度炸彈延遲。
以太坊聯合創辦人 Vitalik Buterin 先前曾提到,雖然用戶不易察覺,但難度炸彈將對以太坊網路上的區塊時間產生影響,因此以太坊必須儘快進行升級。
另外,針對君士坦丁堡硬分叉中「Create2」將會產生負面安全隱患的指控, Buterin 已於 2 月 15 在核心開發人員電話會議期間否認此謠言。
君士坦丁堡升級引入潛在攻擊向量? Vitalik 出面闢謠
根據以太坊改進方案 EIP-1014,Create2 旨在提高用戶與合約進行交互的能力。現有的 Create 函數所創建的新合約地址是使用創建者的地址和隨機數生成的。而使用 Create2 和 Create 的唯一區別是 Create2 可以讓智能合約的地址由不同的當事人進行設定。
具體而言,Create2 允許交互使用「區塊鏈上尚未存在,但最終可能只包含代碼的地址」來執行。
據悉,就算智能合約已被落實部署,仍可再次通過編碼更改地址,而這過程中可能會將「潛在的攻擊媒介」引進網路。數名以太坊開發者為此感到擔憂,甚至有人質疑:「這是否意味著君士坦丁堡硬分叉後,Create2 新功能可以允許開發人員替換自毀契約,從而更改規則。這比以前更容易受到攻擊?」此次 Create2 屬於新引入的操作碼,被質疑在特定情形下可能引發一個 hijack 類安全問題。
Create2 opcode 和 Create opcode 目的都是用來產生新的合約並部署,但不同的地方在於,使用 Create2 可以自由地控制合約產生的地址,但是 Create 不支持。
開發人員 Jeff Coleman 強調說,「理論上而言,Create2 最有悖常理的地方在於,只要重新部署即可變更代碼,畢竟地址對初始化代碼僅能發揮保證的作用。要知道,初始化代碼是審計的一部分,而非確定性初始化代碼才是問題所在。」
Vitalik Buterin 在討論 Create2 時提出應以長遠的發展來看,「我們必須為將來著想,這種方式可以導致合約『處於或不處於』自毀操作的狀態。但在接下來幾週,這不是我們迫切需要關注的事情,但是當我們把以太坊 2.0 分片納入虛擬機規範中時,記住這一點仍然很有用。」
除了 Create2 之外,開發人員還表示已經找到一家獨立公司,對新算法「ProgPoW」進行基準測試,該新算法可以提高 GPU 挖礦的效率,而非著重於 ASIC 晶片挖礦。
開發團隊決議延遲實施 ProgPow
此前,以太坊核心開發團隊在 2 月 1 日的會議中,一致決議延遲實施 ProgPow,並交由第三方進行審核。
此前有開發人員透露,打算在以太坊君士坦丁堡硬分叉之前實施 ProgPow,以作為一個獨立但又適用於全系統的升級。
當天的電話會議中,以太坊核心開發人員 Hudson Jameson 宣稱「正在召集小組來對 ProgPoW 進行獨立審查」。他解釋說,此舉措旨在測試該算法在公平競爭中,用各種設備挖礦的有效程度,包括:GPU 、現場可程式化邏輯閘陣列(FPGA)和 ASIC 。
Jameson 預計將在 3 或 4 月完成審查,他表示,屆時所獲得的數據應該足以說服開發人員做出決定。
以太坊安全負責人 Martin Holst Swende 則提到,開發團隊已經在「是否應該實施 ProgPoW」的問題上糾結幾個月,他還想知道應該如何解決這個問題。 另一名開發人員 Greg Colvin 則回應,「我們必須作出決定,問題才能解決」。
開發團隊總體上已達成共識,即待審查工作完成,再決定是否實施 ProgPoW 。 Colvin 最後總結道,「我今天很樂意決定,但我不是專家。我可以等待審查結果出爐,但我不想等到 5 月才作決定。很多人都想盡快知道答案,因為這影響到他們的事業運作。」
Martin Holst Swende 先前曾經解釋過,對於 ASIC 和部分基於 GPU 設置的加速器而言,ProgPoW 更具抵抗力。「ProgPoW」基本上原理與 PoW 相同,但 ASIC 晶片並無法在此種算法下得到算力優勢,取得比非 ASIC 晶片更多的獲利。