以太坊下次分叉重點 看這篇就夠了？

過去兩周，由於眾多的以太坊核心開發者奔赴多倫多參加以太坊擴展（scaling）會議，每周一次的電話會議被迫取消。本周五晚，以太坊核心開發者將繼續舉行電話會議，議題抓要圍繞伊斯坦布爾（Istanbul）硬分叉，並決定最終入選的提案（EIP）。

從設計層面來說，伊斯坦布爾（Istanbul）硬分叉是以太坊將走向 Serenity（寧靜）階段最後的分叉（不會產生新代幣）。同時，本次分叉的提案涉及問題眾多（Progpow、狀態租賃、chainID等）。如果一些問題在本次分叉中得不到解決，將對以太坊後續生態發展影響重大。另據以太坊2.0研究員Justin Drake所說，以太坊2.0階段0將於2020年1月3日發布。

推遲ProgPoW，聚焦「狀態租賃」

上個月17號，伊斯坦布爾硬分叉提案（EIP）徵集結束，共收集了29個提案。這些提案分別是：

EIP-615：EVM的子程序和靜態跳轉

EIP-663：無限制的SWAP和DUP指令

EIP-1057：ProgPoW，一種程序化的工作證明

EIP-1108：降低alt_bn128預編譯gas成本

EIP-1109：PRECOMPILEDCALL操作碼（刪除預編譯合同的CALL費用）

EIP-1283：沒有dirty maps，測量SSTORE的凈gas成本

EIP-1344：添加ChainID操作碼

EIP-1352：為預編譯/系統合同指定受限制的地址範圍

EIP-1380：減少自我呼叫的gas成本

EIP-1559：改變ETH 1.0鏈gas費用

EIP-1965：檢查chainID在特定塊號處是否有效的方法

EIP-1702：廣義帳戶版本控制方案

EIP-1706：當gas費用低下時，禁用SSTORE

EIP-1803：重命名操作碼

EIP-1829：橢圓曲線線性組合（ Elliptic Curve Linear Combinations）的預編譯

EIP-1884：重新定義依賴於trie-size的操作碼

EIP-1930：Gas呼叫標準嚴格化，如果沒有足夠的gas調用可以復原。

EIP-1985：某些EVM參數的合理極限

EIP-1959：新的操作碼，檢查chainID是否是chainID歷史的一部分

EIP-1962：EC算術和與運行時定義的配對（取代EIP-1829）

EIP-2014：擴展狀態Oracle

EIP-2026：狀態租賃H – 固定帳戶預付款

EIP-2027：狀態租賃C – 核算凈合同規模

EIP-2028：降低Calldata Gas成本

EIP-2029：狀態租賃A – 狀態櫃檯合約

EIP-2031：狀態租賃B–凈交易櫃檯

EIP-2035：無狀態客戶端 – 重新定價SLOAD和SSTORE以支付塊證明

EIP-2045：EVM操作碼粒子的gas成本

EIP-2046：降低對預編譯程序進行靜態調用的gas成本

此前的核心開發者電話會議，臨時批准的提案是EIP 1108——提議對以太坊網路的Gas費用進行了微小改動。不過，開發人員強調，該提案雖然獲得批准，但需要在之後的核心開發人員會議上提交基準數據。

另外，備受關注提案EIP-1057可能被推遲。EIP 1057提出了一種改進的PoW演算法，稱為「漸進式PoW」或ProgPoW，旨在更好地利用GPU特定的計算功能。

此前，開發人員通過開源賞金平台Gitcoin進行眾籌募集了5萬DAI（約合5萬美元），作為ProgPoW代碼審計資金。但由於該代碼至今並未找到第三方機構進行審計，因此在5月24日的開發者會議上被宣布推遲。

同樣被推遲的還有EIP-1559，該提案旨在改變以太坊交易費模式，但由於過於複雜，被開發者「拋棄」。

在這些提案中，「狀態租賃」顯得格外耀眼。

「狀態租賃」設計初衷是，以太坊的狀態大小當前已經是非常龐大了，如果其繼續以目前的速度增長，以太坊網路將變得異常臃腫。而我們正在低估存儲的長期成本，存儲成本可以近似地建模為：位元組*時間，因此，我們有必要對當前以太坊的狀態設計進行改動。

根據以太坊2.0的路線圖來看，狀態租賃也將在ETH 2.0（目前的計劃是在階段2）進行部署。到底要不要在ETH1.0重新耗時費力地開發，相信也會成為本周五電話會議的討論熱點。

刪減提案

上述提案也在社群中也引起廣泛討論，不少開發者質疑有些提案內容重複，應該進行刪減。

開發者Alex Beregszaszi 表示：「我很困惑。我認為那些提出相互衝突、相鄰、重複的EIP（有3到4個EIPs都是關於chainid、重新定價、SWAP和DUP的）的建議應該在再次提出之前達成一些共識。如果他們沒有明確規定，那麼爭論EIP就沒有什麼意義。」

直到目前，提案審計進程僅僅進行了一小段，核心開發者們能否在本周五給出最終答案，仍然懸而未決。

Alex認為，一些提案其實並不需要在硬分叉中進行，可以聯繫以太坊客戶端開發人員解決。「那些（EIP）作者不應該只是試圖自己解決它，而是要聯繫一些相關的開發人員，比如客戶端開發人員來審查他們的想法。如果每個人都等著核心開發者召開電話會議討論實施，我們將沒有足夠的時間討論所有這些提案。」

對於上面的EIP，開發者社群（點擊進入）目前也在討論進行縮減，以降低核心開發者工作量，提高效率。

硬分叉時間表

除了關注提案，關於伊斯坦布爾硬分叉的時間安排也同樣值得關注。

根據前硬分叉協調員 Afri Schoedon（已離開）制定的時間表，硬分叉過程分解為「一個固定的9個月周期」。伊斯坦布爾硬分叉時間表如下：

2019-05-17(星期五)：接受「伊斯坦布爾」提案截止日期

2019-07-19(星期五)：主要客戶端實現的截止日期

2019-08-14(星期三)：測試網（(Ropsten、Gorli或特設testnet)）升級時間

2019-10-16(星期三)：主網升級時間(「伊斯坦布爾」)

目前已經完成了第一階段提案收集，接下來要進行的則是「主要客戶端實現」。所謂的「主要客戶端實現」，即將已接受的EPI合併到以太坊現有客戶端中，這一步類似於將代碼組合在一起，這樣就可以對其進行全面測試。

不過，按照以太坊一貫的調性，這次硬分叉「按時」完成的可能性並不高。此前的君士坦丁堡分叉中，就出現了代碼漏洞，導致分叉延期。

以太坊基金會的受助人Alexey Akhunov在Gitter聊天室中說道，每個人都應該考慮「截止日期」，不應該為了截止而截至，一切以做好工作為前提。

「我自己也在思考這個截止日期的目的是什麼？」Akhunov說，「因為這是第一次（在分叉中）引入這麼多東西，所以我們來這裡是為了確保我們所做的事情是有原因的，而不是因為『有人這麼說』。」

來源：星球日報