問題唔只係將一個常數改大或改細。EIP-8037 會為建立新 state 嘅操作引入獨立嘅 state-gas 維度。按照拆分後嘅計價方式,向已存在帳戶轉 ETH 可以維持 21,000 execution gas;但如果收款地址尚未存在,交易就要額外支付 runtime state gas。
所以開發者唔應再假設:
錢包同相關服務應改用了解協議規則嘅估算方式,並喺 Platåberget 分別測試向已存在帳戶及新帳戶轉帳。Ethereum Foundation 已特別提醒,依賴硬編碼 gas cap 嘅工具可能會失效。
Enshrined proposer-builder separation(ePBS) 係 Glamsterdam 嘅主要協議改動之一,相關提案為 EIP-7732。佢會改變區塊構建同驗證責任喺協議入面嘅表達方式,因此 validator、builder、relay 同 node 基礎設施唔應只測試一般交易提交,亦要驗證完整出塊流程。
Block-level access lists 由 EIP-7928 規定,會向 client 同基礎設施提供一個區塊預期存取 state 嘅額外資料層。任何會讀取、解析或者模擬區塊內容嘅 execution tooling,都需要重新檢查相容性。
Glamsterdam 亦會提高部分大小限制:
合約部署工具、bytecode 驗證程式、開發框架同 indexing 系統,都應該直接測試新上限,而唔好當現行限制永遠不變。
比起記住升級個名,落手做嘅 checklist 更重要。維護 Ethereum 應用程式或基礎設施嘅團隊,至少應該:
Hegotá 係預計於 2027 年推出嘅升級,但範圍仍未定案。開發者目前審視緊 66 項提案;按現時流程,預計約於 8 月 27 日公布 proposed-for-inclusion 名單,而 client 團隊就要喺 9 月 10 日前提交偏好排名。呢啲係決策節點,唔代表 66 項提案會全部推出。
要分清楚提案所處嘅狀態:
現時 Hegotá 唯一正式排定嘅功能係 FOCIL,即 Fork-Choice Enforced Inclusion Lists(EIP-7805)。佢嘅目的係加強抗審查能力,透過 fork choice 強制執行指定交易清單,減少 block builder 排除符合條件交易嘅空間。
Frame Transactions(EIP-8141) 仍屬於 considered,而唔係已確認納入 Hegotá。呢項提案會引入一種新交易格式,將交易有效性、gas 支付同執行拆分成一連串 frame 及合約呼叫處理,理論上可以為 account abstraction 及更靈活嘅交易付款流程提供協議原生方案。
Ethereum 研究人員亦曾經將 Frame Transactions 同其他相關提案一齊討論,認為佢哋可能支援更原生嘅 privacy 功能;不過,呢個更大嘅組合目前仍未成為已批准嘅 Hegotá 功能清單。
Ethlabs 建議將 Quick Slots(EIP-8198) 納入一個範圍較集中嘅 Hegotá,方向包括加快出塊同 finality。不過,縮短 slot time 仍然只係提案,未係已確認嘅升級參數。
至於提高 gas limit、將 slot 縮短至 8 秒、post-quantum cryptography,以及其他 validator、privacy 同 execution-layer 提案,現階段都仍在考慮中,未確認屬於 Hegotá 範圍。
Glamsterdam 係眼前嘅工程期限。 Platåberget 畀團隊一個公開環境,及早搵出 gas repricing、state-gas 計算、ePBS、access list 同新大小上限造成嘅相容性問題,趕喺升級進入 Sepolia、Hoodi 同主網之前修正。
Hegotá 就係另一回事:佢仍然係優先次序同設計取捨。 目前只有 FOCIL 真正鎖定;Frame Transactions、Quick Slots、擴容工作及其他提案,仲要經過揀選、實作同測試先可以落實。對開發者而言,最穩妥嘅做法係將 Glamsterdam 當成即時相容性項目處理,而將 Hegotá 視為仍在演變中嘅路線圖,而唔係一張已經定稿嘅 2027 功能清單。