前世

**為什麼需要坎昆升級？ **

• 以太坊的願景為：在去中心化的前提下變得更具有可擴展性且更安全。當前以太坊的升級也致力於解決這個三難問題，但是一直面臨著很大的挑戰。
• 以太坊的問題：
• 目前出现了TPS 和性能较低，gas 费高且拥堵严重的情况，同时，运行一个以太坊客户端所需的磁盘空间也在快速增长，在底层，确保以太坊安全和去中心化的工作量共识算法对整个环境的影响也愈发显著。
• 所以，在去中心化的前提下，如何傳輸更多的數據並降低gas，來增強可拓展性，如何優化共識算法，來保障安全性，都是以太坊目前正在做的努力。
• 為了解決安全、去中心化和拓展性這個三難困境，以太坊曾利用PoW轉PoS 機制來進一步降低節點門檻，也準備利用信標鏈隨機分配驗證者來優化安全性，在可拓展性方面，以太坊考慮使用分片這個方式來減輕節點的工作量，這也能使以太坊可以同時創建多個區塊，增強其可拓展性。
• 當前以太坊每一個區塊的空間大概是200~300 KB，每個交易最小大約是100 個字節，約2000 筆交易，除以區塊時間12秒，以太坊的TPS 上限就被限制在100 左右。這個數據明顯無法滿足以太坊的需求。
• 因此，以太坊Layer2 關注如何能把大量數據放到block space裡去，通過欺詐證明和有效性證明保證安全，這也是為什麼DA 層決定了安全上限的原因，這也是坎昆升級的核心內容。
• 以太坊生態的迭代路線，無法構建對標Solana 的性能（在延遲和吞吐量方面），短期也看不到Near 的分片性能，也沒有Sui 和Aptos 的並行執行性能， 短期內以太坊只能構建以Rollup 為核心的多層結構，因此坎昆升級解決TPS 、 gas fee 和開發者體驗對於以太坊路線圖來說至關重要。

**以太坊路線圖怎麼規劃的？ **

最近幾次重要的升級及其目標

• 2020年12月1日 信標鏈正式發布，為POS**升級做了鋪墊
• 2021年8月5**日 倫敦升級，EIP1559改變了以太坊的經濟模型；
• 2022年9月15日 巴黎升級（The Merge），完成了POW切換POS*；*
• 2023年4月12**日 上海昇級，解決了質押提款問題；
• 完成了經濟模型和POS相關的升級，接下來幾次升級解決了以太坊的性能、TPS和開發者體驗的問題；
• 下一步重點是以太坊路線圖中的 The 湧 。
• 目標： Rollup 中實現10 萬+的TPS 。
• 主要有2個方案，鏈上和鏈下：
• 鏈下方案：指Layer2，包括rollup 等，
• 鏈上方案：指直接在L1 中進行更改，也就是熱門的分片方案，分片簡單理解就是將所有節點劃分成不同片區，完成每個片區的任務，這將有效提升速度；
• 分片方案解析：
• 分片（Sharding）方案的困境：曾經的Sharding 包括狀態分片，交易分片等，但是出現不同分片之間的同步是個難題，目前想要完成大範圍的網絡節點數據同步，技術難度大，不僅無法解決MEV 的情況，且可能需要大量補丁來彌補可能出現的各類問題，短期無法實現。
• Danksharding 是為以太坊提出的新分片設計， 其核心思想為中心化的出塊 + 去中心化的驗證 + **抗審查性，**這也與下文將要提到的數據可用性採樣（DAS）、出塊者-打包者分離（PBS）和抗審查清單（Crlist）有關。 Danksharding 核心思想的最大意義，在於把以太坊L1變成了一個統一的結算（settlement）和數據可用性（Data 可用性）層。

分片方案分為2步，目前看分為Proto- danksharding 和Fully-Rollup***。 ***

• 所以- 丹麥分片**：**
• 介紹： 通過引入blob 幫助L2 降費並增加吞吐量 ，同時作為danksharding 的前置方案為實現完全分片（sharding）鋪平道路。預期proto-danksharding 後， danksharing 的落地需2-5年時間。
• 內容：proto-danksharding 的主要特性是引入新的blob 交易類型，Blob 具有容量大且便宜的特點，給以太坊外接此類數據包，能讓rollup 的數據全部存入blob，大大緩解主鏈的存儲壓力，同時也能降低rollup 的費用。
• 完全匯總
• 介紹：rollup 全面擴容，重點在於數據可用性的利用。
• 內容：
• DAS 的P2P 設計：涉及數據分片網絡連接問題的一些工作以及研究；
• 數據可用性採樣客戶端：開發輕量級客戶端，可以通過對幾千字節的隨機採樣快速判斷數據是否可用；
• 有效的DA 自我恢復：能夠在最惡劣的網絡條件下有效地重建所有數據（比如，惡意驗證者攻擊、或者大塊節點的長時間停機）。

以太坊核心開發者會議

以太坊的每一次升級都依賴於核心開發者會議，通過核心貢獻者的共同討論，根據開發者們的一系列提案，決定未來的發展方向

• 定義：核心開發者會議是以太坊開發社區每週舉行的一次電話會議，來自不同組織的核心貢獻者共同討論技術問題並協調以太坊的未來工作。它們決定了以太坊協議的未來技術走向，同時也是真正進行以太坊升級決策的權力機構，負責決議，EIP 是否被納入升級，是否需要進行路線圖變更等重要事項。
• 核心流程：以EIP 為中心的升級流程大致如下，首先在核心開發者會議（簡稱ACD）上初步接納一個EIP，然後客戶端團隊無論該EIP 被納入升級與否，都對其進行測試，並在最終測試完後進行再一次回顧，再根據探討決定最終是否納入實際升級中。
• 會議分2類，分別是共識層會議和執行層會議，兩者隔週交替舉行：
• 共識層會議（All Core Developers Consensus - ACDC），關注以太坊共識層（權益證明、信標鍊等）；
• 執行層會議（ All Core Developers ution - ACDE**），後者關注以太坊的執行層（EVM、**Gas 時間表等）。
• 以太坊核心維護者有3 類，主要是一些討論提案的官方組織或者志願者論壇：
• AllCoreDevs：代碼維護者，負責ETH1網絡客戶端，升級，維護以太坊代碼和核心架構；
• “項目管理”部分：支持以太坊開發人員、協調硬分叉、監控EIP等，以及直接幫助AllCoreDevs 負責通信和運營；
• 以太坊 Magicians：一個希望圍繞EIP 和其他技術主題進行討論的“論壇”。

坎昆升級相關會議的時間線

按照討論內容劃分，本次坎昆升級可粗略分為5***個階段。 ***

第一個階段——引入升級主題

引出新任務proto-danksharding***、EOF和“selfdestruct” 操作碼，粗淺討論上海昇級內容*

• 以太坊在22年9月15日完成合併後，開發者會議暫停4週，為開發者留取一個月的時間查看後續升級所討論的EIP；
• 22年10月28日，合併後的第一次開發者會議，首次提出proto-danksharding、EOF 的實現和“selfdestruct”操作碼，此時， proto-danksharding 的具體範圍未確定，有開發者初步認為，可以將上海昇級分為幾步小型的升級，如先啟用質押的ETH 提款，然後再升級EIP 4844，但另外一部分開發者認為一步到位實施更大的升級更有意義。

第二個階段——確定時間範圍和KZG儀式的準備

2022年底，以太坊會議主要圍繞EOF和EIP 4844 進行討論，同時持續推進EIP 4844 所需的前期可信設置儀式——KZG儀式，開發者們將在23年1月正式確定4844將在哪個升級中露面

• 22年11月，在以太坊所有核心開發者電話會議#149中，已經提及EOF 或proto-danksharding，此時開發者們仍考慮將其放置在上海昇級中；
• 22年12月2日的共識層會議中，以太坊生態系統負責人Trent Van Epps 更新了EIP 4844 實施所需的可信設置儀式的進展情況，該儀式旨在生成一段將在EIP 4844 中使用的安全代碼。 Van Epps 希望該儀式將成為加密領域有史以來規模最大的儀式之一，收集8000 至10000 份contribution，該儀式的公眾貢獻期將持續大約2 個月，並於12 月的某個時候開始；
• 同日的核心開發者會議中，圍繞EOF 和停用selfdestruct 操作碼進行了一定的討論，以太坊基金會的某位開發人員反對將EOF 推遲到坎昆，認為如果代碼更改不包含在上海，它進入坎昆的可能性很小，關於selfdestruct 代碼，當時有開發人員主張推進EIP 4758，不過直接停用此操作碼將會破壞某些應用程序，開發人員認為在創建一個邊緣案例來保護此類型合約之前，該EIP 應再次權衡一段時間；
• 22年12月9日的核心開發者會議中，關於坎昆升級方面推進了KZG 儀式的實施，目前EIP 4844 所需的可信設置儀式已準備就緒；
• 22年12月16日的共識層會議中，關於EIP 4844 的主題，開發人員討論了將兩個不同的拉取請求(PR) 合併到proto-danksharding 的規範中，一個與節點如何處理數據修剪後超出特定點的數據可用性有關，一個是當某個塊上缺少關於blob 的信息時，將引入新的錯誤代碼來提醒節點；
• 23年1月5日的核心開發者會議中，開發者們就從上海昇級中移除與EOF 實現有關的代碼修改達成共識，Beiko 此時建議在兩週之後再決定是否應將EOF 包括在坎昆升級中；

第三個階段——初步討論提案的範圍

23年1月底，EOF在被從上海昇級移出後移入坎昆升級，此後2個月內主要圍繞除了EOF與EIP 4844 ***之外的其他提案進行討論，與此同時，EOF又被提議移出坎昆。這段時間主要在劃定坎昆升級的提案範圍。 ***

• 23年1月20日的核心開發者會議中，EOF 被移入坎昆升級；
• 23年3月6日的核心開發者會議中，關於坎昆升級的初步提案為：EIP 4788（公開信標鏈狀態根）、EIP 2537（高效執行BLS 簽名驗證和SNARKs 驗證等操作）、EIP-5920（引入新的操作碼PAY），以及EIP 6189（用於使SELFDESTRUCT 與Verkle 樹兼容）與EIP-6190（更改SELFDESTRUCT 函數以僅導致有限數量的狀態更改）的結合實施；
• 23年3月16日的核心開發人員會議裡，除了EOF 與EIP 4844 之外，下列提案被考慮納入坎昆：SSZ 格式、SELFDESTRUCT 刪除、EIP 2537、EVMMAX、EIP 1153、無限制的SWAP 和DUP 指令、引入PAY 代碼和EVM 中的信標狀態根；
• 23年3月30日的核心開發人員會議中，首次提出關於停用SELFDESTRUCT的提案EIP-6780，這也是坎昆最後確定使用的停用SELFDESTRUCT的提案。但是關於EOF 的實施，來自Erigon (EL) 客戶團隊的某位開發人員表示EOF “變化太大”，無法在即將到來的坎昆升級中與以太坊改進提案EIP 4844 相結合，有人提議在坎昆升級後不久在硬分叉中實施EOF；

第四個階段——確定明確的提案升級方向，刪除無關提案

23年4月，對於坎昆升級應覆蓋的提案有了清晰的方向，重點節點在4 月13日的開發者會議，此會議提出了9個*** EIP******，以及tim本人對於候補提案也有了較為深入的討論，在4月** 27日的會議中，EIP 6780、EIP 6475 和EIP 1153* 被確定納入坎昆，同時EOF和EVMMAX***（與EOF 實現相關的EIP子集）被從坎昆升級中刪除，EOF升級主要可以幫助EVM進行版本控制，並且可以同時運行多套合約規則，有助於以太坊後續的拓展性，但是考慮到整次升級的可實現度，*** EOF升級可能在後續隨著日常升級進行推進

• 23年4月12****日，以太坊上海昇級已完成；
• 23年4月13日的核心開發者會議中，開發人員討論了EIP 4844（用於在EL 中公開有關CL 狀態根的數據），除此之外，還有至少九個其他EIP被考慮納入升級，分別是**EIP 4844****、SELFDESTRUCT 移除（EIP-6780、EIP 第4758章 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、**EVMMAX EIP（EIP 6601和EIP 6690), SS 變化（EIP 6475、EIP 6493、EIP 6465、EIP 6404 和EIP 6466）、EIP 5656 和 EIP 6193；
• 23年4月27日的核心開發者會議裡，重點劃分了幾個的進度和取捨。首先，EIP4844 繼續確定納入坎昆升級，同時增加了以下EIP：EIP 6780（更改SELFDESTRUCT 操作碼的功能）、EIP 6475（一種新的簡單序列化（SSZ）類型來表示可選值）、EIP 1153（添加新的操作碼來操作status）；其次，正在考慮但尚未正式納入升級的EIP 為EIP 6913（引入SETCODE 指令）、EIP 6493（為SSZ 編碼交易定義簽名方案）、EIP 4788（在EL 塊頭中公開信標鏈塊根）、EIP 2537（添加BLS12-381 曲線作為預編譯）和EIP 5656（引入新的EVM 指令用於復制內存區域）；最後，EOF 和 EVMMAX**（與** EOF 實現相關的 * EIP* 子集）被從坎昆升級中刪除。 EOF **升級曾在2023年1月初的以太坊開發者大會中被移出上海昇級，後續從 23年1月底至4月初，都被默認將在坎昆升級中出現，但23年4月29****日的開發者會議中，**EOF **被再次移除。 **

第五個階段——最後的提案確定和細節完善

23年5月主要針對最後的提案細節進行精簡和完善，SSZ-> RLP 的變化將意味著不再需要坎昆的兩個SSZ EIPs***，因此EIPs 6475和6493將被移出坎昆升級。同時在26日的核心會議中，Tim Beiko 建議未來圍繞擴大坎昆範圍的對話僅限於以下五個EIP******：EIP-5920 、5656、7069、4788和******2530 ******。開發者目前已確定坎昆升級的全部範圍。 ***

• 23年5月5日的以太坊核心共識會議，討論了上次提及的EIP 4788，同時增加了對EIP 6987和EIP 6475的討論，這兩個提案分別有關驗證者和SSZ 交易；
• 23年5月11 日的第161 次以太坊執行層會議中，Tim Beiko 表示，未來幾週內仍然可以對坎昆升級範圍進行修改，但如果沒有來自開發者的明確建議，坎昆升級的範圍將保持「默認」狀態，且有關EIP-4844的討論中顯示，開發者同意將SSZ 從EIP-4844 的EL 實現中移除，但目前仍未影響到 6475 **的持續推進。 **除此之外，開發人員也簡要討論了兩個EIP 供坎昆考慮，分別是EIP 6969（電子IP 1559 的修改版本）和EIP 5656（用於復制內存區域的高效EVM 指令）；
• 23年5月18日的開發者共識會議中簡要討論了4844的進展，如允許EL 上的智能合約應用程序驗證CL 狀態的證明；
• 2023年5月25日，第162次以太坊核心會議中討論了停用SELFDESTRUCT、EIP-4844 規範更改、操作碼管理和潛在的最終Cancun 添加等內容。 Tim Beiko 建議未來圍繞擴大坎昆範圍的對話僅限於以下五個EIP：EIP-5920**、5656、7069、*** 4788* 和 2530**。開發者會在未來幾週內會確定** Dencun**（****Deneb

• Cancun****）的全部範圍；**

• 2023年6月1日第110 次以太坊共識層會議，以太坊基金會某位研究員介紹了一項關於以太坊主網節點傳播大量數據的能力的數據實驗結果，由此結果，該研究員建議將EIP 4844 規範從每個塊最多4 個blob 增加到6 個。同時開發者們正考慮將EIP 4788 納入坎昆升級；
• 2023年6月13日的核心開發者會議中，開發者們正式確認了升級範圍，包括EIP 4844、EIP 1153、EIP 5656、彈性IP 6780、EIP 4788；
• 2023年6月15日的共識會議中，討論了在Deneb中包含哪些以CL 為中心的EIP，其中，EIP-6988、EIP-7044、EIP-7045被提議加入，以及CL 客戶端團隊同意在下一個EIP-4844測試網Devnet6 上測試增加的blob 數量，並在兩週內就此事做出最終決定，同時以太坊基金會研究員Michael Neuder提出取消32枚ETH質押上限，以幫助減少活躍驗證者集的增長；
• 2023年6月22日的會議中，tim 提議將4844的預編譯地址移動到0xA，將他們打包並移動BLS到另一個地址，雖然該預編譯通過EIP 2537 引入，但在坎昆中不會考慮此方案；
• 2023年6月29日的共識會議中，開發人員繼續討論了blob 數量，將目標blob 限制 從2 上調到3，將最大blob 限制從4 上調到6，同時4844的測試網Devnet #7 即將上線。

今生

• 核心內容是EIP 4844，即原始丹麥分片
• 此次坎昆升級最終確定的EIP 範圍為：EIP 4844**、EIP 1153、EIP 5656、彈性IP 6780、EIP 4788。同時在6月19日的第111次以太坊ACDC 會議中，開發者們繼續討論了**EIP 6988**、** 彈性IP 7044**、**EIP 7045，以便在Deneb 中納入。開發者們表示，計劃在未來幾週內將上述三個EIP 合併到Deneb 規範中。

重點EIP的分析

電子工業園區 4844

• 簡介：
• EIP4844提案的名稱為Proto-Danksharding，是完整版分片擴容Danksharding的前置方案，整套分片方案其實就是圍繞著Rollup來進行鏈上擴容的。 方案目的是為了擴展第 2 層 **Rollup——通過幫助L2****降費並增加吞吐量 ，同時為實現完全分片（sharding）鋪平道路。 **
• 23年2月的電話會議中，以太坊開發人員將EIP 4844 升級命名為Deneb，這是天鵝座中的一顆一等星的名稱，即以後相關GitHub 版本上EIP 4844 的命名將更新為Deneb；在23年6月1日的會議中，以太坊的下一次升級規範有一些變化，在CL 端稱為Deneb，在EL 端稱為Cancun；
• 23年6月23日的開發者會議中，開發人員準備更新EIP 4844 的預編譯地址。目前，、核心開發人員已向EVM 添加了9 個預編譯，並將通過激活EIP 4844 和4788 分別在“0xA”和“0xB”地址下創建兩個預編譯。 6月29日的共識會議中，已經準備推出EIP 4844 的專用短期測試網絡Devnet #7。
• EIP-4844****引入了一種全新的交易類型——Blob 交易。
• Blob簡介：
• Blob ，類似一個外掛數據包，開始只有128 KB 的存儲空間，在該提案討論初期，Blob 的target 和limit 為2/4，在23年6月9日的開發者會議中，被調整為3/6。即目前以太坊中每一筆交易可以最多攜帶三個Blob交易，即384 KB，每一個區塊的target Blob 容量為6 個，即768 KB，最大可承載16 個Blob，即2MB；
• 可能會對網絡穩定性產生一定影響，但是以太坊開發團隊仍決定先行測試，避免後續需要硬分叉來拓展blob 塊。
• Blob 以 KZG commit Hash 作為 Hash**，用於數據驗證，作用和** Merkle 類似；
• 節點同步鏈上的Blob Transaction 後，Blob 部分會在一段時間後過期刪除，存儲時間為三週。
• Blob作用——提高以太坊的TPS，同時降低成本
• 目前整個以太坊總數據量大小只有1TB左右，而Blob可以給以太坊每年帶來2.5～5TB的額外數據量，直接遠超賬本本身好幾倍；
• 對於節點來說，一個區塊多下載1MB～2MB左右的Blob數據並不會造成帶寬負擔，在存儲空間上也僅僅是增加了固定的200~400GB左右一個月的Blob數據量，這些並不會影響到整個以太坊節點的去中心化，但圍繞著Rollup實現的擴容是極大的提高；
• 且節點本身其實是不需要去存儲全部的Blob數據的，因為Blob其實是個臨時的數據包，那麼其實對於節點來說只需要下載固定三週的數據量即可。
• EIP-4844的作用——開啟Danksharding****敘事的前章
• **高擴容：**目前EIP-4844可以初步擴容L2，完整版Danksharding可以將EIP-4844中的Blob數據量從1MB～2MB擴展至了16MB～32MB，在確保了去中心化和安全性的同時實現了更高的擴容；
• **低費用：**bernstein分析師表明，Proto-dank-sharding可以將第2層網絡的費用降低到當前水平的10-100倍；
• 實際數據：
• Opside 測試網部署了4844，目前觀察可以降低rollup 的50%成本；
• EigenLayer 的DA 技術方案沒有披露太多，無法評估其數據；
• Celestia 嚴格意義上來說和以太坊關係不大，其DA 花費現在也無法評估，取決於其具體技術方案；
• Ethstorage 的方案是上傳其Layer2存儲證明，其DA 成本可能會降低至原先的5%；
• Topia 預期降低100~1000倍成本，因為主網Danksharding 還要兼顧安全性和兼容Layer1 層面的P2P 網絡廣播。
• DA****解決方案：Danksharding（以太坊擴容的分片解決方案）目前若繼續擴容可能會節點負擔過大（16mb以上）和數據可用性不足（30天有效期）的問題。解決方式：
• 數據可用性採樣（Data Availability Sampling）——降低了節點負擔
• 將Blob 中的數據切割成數據碎片，並且讓節點由下載Blob 數據轉變為隨機抽查Blob 數據碎片，讓Blob 的數據碎片分散在以太坊的每個節點中，但是完整的Blob 數據卻保存在整個以太坊賬本中，前提是節點需要足夠多且去中心化；
• DAS採用了兩個技術：糾刪碼（Erasure Coding）和KZG 多項式承諾（KZG 承諾）;
• 提議者-打包者分離（PBS）——解決了節點的工作分工問題，讓性能配置高的節點負責下載全部數據進行編碼分發，讓性能配置低的節點來負責抽查驗證。
• 性能配置高的節點可以成為打包者（Builder），打包者只需要負責下載Blob 數據進行編碼並創建區塊（Block），然後廣播給其他的節點來進行抽查，對於打包者（Builder）來說，因為同步數據量和帶寬要求較高，所以會相對中心化；
• 性能配置較低的節點可以成為提議者（Proposer），提議者只需要驗證數據的有效性並創建和廣播區塊頭（Block Header），但對於提議者（Proposer）來說，同步數據量和帶寬要求較低，所以會去中心化。
• 抗審查清單（crList）——解決了對於打包者而言因其審查權力過大，就可以故意忽略掉某些交易並且隨意排序並插入自己想插入的交易去獲取MEV的問題。
• 在打包者（Builder）打包區塊交易之前，提議者（Proposer）會先公佈一個抗審查清單（crList），這個crList 中包含著mempool 中的所有交易；
• 打包者（Builder）只能選擇打包並對crList 裡的交易進行排序，這意味著打包者不能插入自己的私有交易去獲取MEV，也不能去故意拒絕某個交易（除非Gas limit 滿了）；
• 打包者（Builder）打包好之後將最終版本的交易列表Hash 廣播給提議者（Proposer），提議者選擇其中一個交易列表生成區塊頭（Block Header）並廣播；
• 節點同步數據時會從提議者（Proposer）那獲取區塊頭，然後從打包者（Builder）那獲取區塊Body，確保區塊Body 是最終選擇的版本。
• 雙槽PBS——解決了中心化的打包者通過獲取MEV 越來越中心化的問題
• 用競標的模式來決定出塊：
• 打包者（Builder）拿到crList 後創建交易列表的區塊頭並出價；
• 提議者（Proposer）選擇最終競標成功的區塊頭和打包者（Builder），提議者無條件獲得中標費（不管是否生成有效區塊）；
• 驗證委員會（Committees）確認中標的區塊頭；
• 打包者（Builder）披露中標的區塊Body；
• 驗證委員會（Committees）確認中標的區塊Body 並進行驗証投票（通過則出塊，如果打包者故意不給區塊Body 則視為區塊不存在）。
• 意義：
• 首先，打包者（Builder）擁有更大權力打包交易，但是上文提到的crList 首先就限制了其臨時插入交易的可能，其次，若打包者（Builder）想通過更改交易順序獲利，則其需要在一開始就付出很大的競標成本來保證自己可以獲得區塊頭資格，那麼其獲得的MEV利潤就進一步被縮小，整體下來對於其獲得MEV的手段和實際價值都有所影響；
• 但是，初期可能會導致僅有少部分人成為打包者（考慮到節點性能問題），而大部分人僅成為提議者，這有可能導致進一步中心化，同時，在打包者數量本身就很少的情況下，某些具有MEV 能力的經驗豐富的礦工將更有可能競標成功，這將更加影響實際的MEV解決效果；
• 對於某些採用MEV 拍賣方式的MEV 解決方案來說有一定影響。
• 意義：
• EIP 4844 實際上是一個超級簡化版的 Danksharding**：**它提供了一個跟Danksharding 一樣的應用接口，包括一個新的opcode 叫Data Hash；以及新的一個數據對象叫Binary Large Objects，也就是Blob；
• proto-danksharding 是用來實現完整 Danksharding 規範的“支架” *(即交易格式和驗證規則) * 提案：不過目前還沒實現任何分片，所有驗證者和用戶仍需要直接對完整數據的可用性進行直接驗證；
• 為什麼長期角度選擇 proto-danksharding 而非 EIP 4488 的直接讓 layer2 降費，因為這樣未來升級成完整分片時僅需小幅調整：
• 電子工業園區 4488 與proto-danksharding 的主要實際區別在於，EIP-4488 試圖將今天以太坊所需做出的變更降到最低，而proto-danksharding 則對今天以太坊做出更多的變更，以便在未來升級到完整版分片時只需做出很少的變更；
• 雖然實現完整分片(有數據可用性採樣等) 是一項很複雜的任務，而且實現proto-danksharding 後還有很複雜的工作，但這些複雜性都會控制在共識層上。一旦proto-danksharding 部署了，執行層客戶端團隊、rollup 開發者和用戶在過渡到完整分片時都不需要做任何額外的工作了。
• 要實現完整分片，需要完成 PBS**、委託證明和數據可用性採樣的實際實現，不過此類修改都將集中於** CL 層，無需開發者進行再調整：目前4844 實現了一種新的交易類型，與完整分片裡需要的交易格式、共識交叉驗證邏輯和執行層邏輯等完全相同，也衍生出了用於blob 的、自我調整的獨立gas 定價，未來要實現完整分片，需要完成PBS、委託證明和數據可用性採樣的實際實現，不過這些修改僅在CL 層，不需要EL 層或rollup 開發者進行修改，便利開發者。

其次是SELFDESTRUCT removal***，EIP-6780最終被確定為最適合的方案，但26日的開發者會議中tim提議在此提案中增加另一個操作碼SETCODE，以允許程序性賬戶仍然可以更新***

自我毀滅 移除 EIP-6780**：**X

• 背景：
• 在21年3月，Vitalik 就提出SELFDESTRUCT 對以太坊生態弊大於利，主要原因在於它是唯一一個能在單個區塊中變更無限個狀態對象、導致合約代碼變動、能未經賬戶同意就能修改賬戶餘額的操作碼，對於以太坊安全中有很大隱患；
• 在鏈上唯一移除一個合約的辦法就是SELFDESTRUCT。如果在合約裡面調用：selfdestruct 函數即可自毀合約。存在合約中的以太坊將會發送到設計好的地址裡。剩下的代碼和存儲變量將會在狀態機中被移除。其實合約銷毀這個動作理論上聽上去是個好主義，但實際上是很危險的。 **selfdestruct****函數雖然能在緊急情況下幫助開發人員刪除智能合約並將合約內的餘額轉移到指定的地址，但這一特性也被不法分子利用，使它成為了攻擊手段。 **
• 23年4月13日的核心開發者會議中，引入了四個有關SELFDESTRUCT 的提案參與討論，分別是6780、4758、6046和6190，後續EIP 6780被定為最終提案。
• 簡介：selfdestruct是智能合約的緊急按鈕，銷毀合約並將剩餘ETH轉移到指定賬戶。
• 電子工業園區 6780：停用SELFDESTRUCT，除非他們在合約裡的同一交易中。
• 更新：5月26日，tim 提議除了刪除SELFDESTRUCT 之外，還要增加另一個操作碼—— SETCODE，以允許程序性賬戶仍然可以更新。 （即加入了更新功能，通過更新/升級的方式將智能合約內的財產等進行update），此處是吸取了EIP 4758 的優勢，其可以讓dapp 有升級空間。

• 原因：原先操作SELFDESTRUCT碼需要對帳戶狀態進行大量更改，如刪除所有代碼和存儲。這在未來對使用Verkle 樹帶來了困難：每個帳戶將存儲在許多不同的帳戶密鑰中，這些密鑰不會明確連接到root 帳戶。
• 更改：此EIP 實現了更改，刪除SELFDESTRUCT，以下兩種情況除外
• 僅用於SELFDESTRUCT取回資金的應用程序仍然可以使用；
• 在合約裡的同一交易中使用的SELFDESTRUCT也無需更改。
• 意義：提高安全性
• 之前主網上存在有合約存在用SELFDESTRUCT限制誰可以通過合約發起交易的情況；
• 防止用戶在SELFDESTRUCT 一個金庫後繼續往其中存入款項並交易，那麼這個金庫在反複利用中可能導致任何人都可以竊取金庫中的代幣。

下方三個提案為後續刪除的有關SELFDESTRUCT的提案，在23年4 月28的核心開發者會議中正式選擇6780***，其餘三個提案被棄用，原因為以太坊開發團隊最終想完全刪除SELFDESTRUCT操作碼，而下列三個提案更多是採用替換的方式進行修正。 ***

• EIP-4758**（棄用）**：通過將SELFDESTRUCT 更改為SENDALL 來停用SELFDESTRUCT，這可以向調用者恢復所有資金（將帳戶中的所有以太幣發送給調用者），但不會刪除任何代碼或存儲。
• 原因：同上，原先操作SELFDESTRUCT碼需要對帳戶狀態進行大量更改，如刪除所有代碼和存儲。這在未來對使用Verkle 樹帶來了困難：每個帳戶將存儲在許多不同的帳戶密鑰中，這些密鑰不會明確連接到root 帳戶。
• 更改：
• 操作碼SELFDESTRUCT重命名為SENDALL，現在只將賬戶中的所有ETH 移動到調用者方，該方案不再破壞代碼和存儲，或改變隨機數；
• 相關的所有退款SELFDESTRUCT均已刪除
• 意義：
• 相較於EIP-6780保存了原先的功能，因為有的應用程序仍在/需要使用SELFDESTRUCT碼。
• EIP-6046**（棄用）**：將SELFDESTRUCT 替換為DEACTIVATE。將SELFDESTRUCT 更改為不刪除存儲密鑰，並在帳戶隨機數中使用特殊值來表示停用
• 原因：同上，使用Verkle 樹，帳戶將以不同方式組織：帳戶屬性（包括存儲）將具有單獨的密鑰，但是不可能遍歷並找到所有使用過的密鑰。而原先操作SELFDESTRUCT碼需要對帳戶狀態進行大量更改，這使得SELFDESTRUCT在Verkle 樹中繼續使用非常困難。
• 更改：
• 改變EIP-2681引入的規則，使常規的nonce增加受到2^64-2而不是2^64-1的約束；
• SELFDESTRUCT被更改為：
• 不刪除任何存儲密鑰並將帳戶保留在原處；
• 將賬戶餘額轉移到target **，**設置賬戶餘額為0.
• 將帳戶隨機數設置為2^64-1。
• 自EIP-3529以來不予退款；
• EIP-2929的相關規則SELFDESTRUCT保持不變。
• 意義：
• 該提案相比於其他的直接刪除SELFDESTRUCT的行為擁有了更多靈活性。
• EIP-6190**（棄用）**：改變SELFDESTRUCT，與Verkle 兼容，使其只引起有限數量的狀態變化
• 原因：同上，使用Verkle 樹，帳戶將以不同方式組織：帳戶屬性（包括存儲）將具有單獨的密鑰，但是不可能遍歷並找到所有使用過的密鑰。而原先操作SELFDESTRUCT碼需要對帳戶狀態進行大量更改，這使得SELFDESTRUCT在Verkle 樹中繼續使用非常困難。
• 更改：不是在交易結束時銷毀合約，而是在調用它的交易結束時發生以下情況：
• 合約代碼設置為0x1，隨機數設置為2^64-1。
• 合約的0第th 個存儲槽設置為合約使用CREATE操作碼( keccak256(contractAddress, nonce)) 時將發布的地址。隨機數始終為2^64-1。
• 如果調用被一個或多個別名合約轉發後合約自毀，則將別名合約的第0th 個存儲槽設置為步驟2 中計算的地址；
• 合約的餘額將全部轉移到堆棧頂部的地址；
• 堆棧的頂部被彈出。
• 意義：
• 旨在讓SELFDESTRUCT可以後續形成Verkle 樹，同時進行最少的更改；
• 應用了EIP-2929的gas 成本增加。

接著是EIP 1153***，節省gas的同時，為未來的存儲設計鋪路***

電子工業園區 1153X

• 簡介：瞬態存儲操作碼，添加用於操作與存儲行為相同但在每次交易後丟棄的狀態的操作碼。
• 原因：
• 在以太坊中運行交易可以生成多個嵌套的執行框架，每個框架由CALL（或類似的）指令創建。可以在同一筆交易中重新輸入合約，在這種情況下，不止一個框架屬於一個合約。
• 目前，這些框架可以通過兩種方式進行通信：通過CALL指令傳遞的輸入/輸出，以及通過存儲更新。如果存在屬於另一個不受信任的合約的中間框架，則通過輸入/輸出進行的通信是不安全的。
• 以reentrancy lock 為例，它不能依賴中間幀來傳遞鎖的狀態：SSTORE通過存儲的通信SLOAD很昂貴，而瞬態存儲是解決幀間通信問題的專用且gas 高效的方案。
• 改變：EVM 中添加了兩個新的操作碼，TLOAD( 0xb3) 和TSTORE( 0xb4)。
• 瞬時存儲對於擁有它的合約來說是私有的，就像持久存儲一樣，只有擁有合同框架才能訪問其臨時存儲。當訪問存儲時，所有幀都會訪問同一個臨時存儲，其方式與持久存儲相同，但與內存不同。
• 潛在用例：
• 可重入 鎖;
• 鏈上可計算CREATE2 地址：構造函數參數從工廠合約中讀取，而不是作為初始化代碼哈希的一部分傳遞；
• 單筆交易EIP-20批准，例如#temporaryApprove(address 支出者，uint256金額）；
• 轉賬費用合約：向代幣合約支付費用以在交易期間解鎖轉賬；
• “Till”模式：允許用戶執行所有操作作為回調的一部分，並在最後檢查“till”是否平衡；
• 代理調用元數據：在不使用調用數據的情況下將額外的元數據傳遞給實現合約，例如不可變代理構造函數參數的值。
• 意義：
• 節省 gas**，擁有更簡單的** gas 計費規則；
• 解決幀間通信問題；
• 不改變現有操作的語義；
• 使用後無需清除存儲槽；
• 未來的存儲設計（例如 Verkle **樹）不需要考慮瞬時存儲的退款問題。 **

接著是4788***，能減少對質押池的信任假設***

電子工業園區 4788**：**X

• 簡介：EVM 中的信標塊根。
• 更新：在23年6月15日的開發者會議中，開發者提出進行代碼更改以改善質押者體驗，該EIP 將公開信標鏈區塊的根，其中包含EVM 內部鏈狀態信息，供DApp 開發者的信任最小化訪問。
• 改變：在相應的執行負載頭中提交每個信標鏈塊的哈希根，同時將這些根存儲在一個處於執行狀態的合約中，並添加一個讀取該合約的新操作碼。
• 意義：這是一項代碼修改提案，提議修改以太坊虛擬機（EVM）以使其能夠公開合約層（CL）狀態根在執行層（EL）的數據，可以使以太坊網絡中不同協議和應用程序之間的通信更加高效和安全**。 **允許質押池、橋接和restaking 協議有更多無需信任的設計。

最後是5656***，提供了一種高效的新的內存複製操作碼，但是考慮到其測試帶寬，目前處於暫時被包括進升級的狀態** *

電子工業園區 5656X

• 簡介：MCOPY

• 內存複製指令。

• 更新：23年6月9日，開發團隊表示最初對MCOPY 存在分歧，因為雖然其解決了安全問題，但仍擔心將它添加到升級所需的實施+ 測試帶寬，但是最後仍同意包含該EIP ，但是如果開發者在測試或客戶端遇到容量問題，就會考慮將其刪除。因此，**MCOPY****處於暫時被包括進坎昆升級中的狀態。 **
• 更改：提供了一種高效的EVM 指令來複製內存區域。
• 意義：內存複製是一個基本操作，但在EVM上實現它需要成本。
• 隨著MCOPY 指令的可用性實現，可以更精確地複制代碼詞句，將提高約10.5% 的內存副本性能，對於各種計算量大的操作非常有用；
• 對編譯器生成更有效和更小的字節碼也將會很有用；
• 可以節省一定的身份預編譯的gas 費用，但是並不能起到實際推進此部分實現的作用。

候選名單****EIP

23年6月15日，開發者共識會議討論了在 Deneb中包含哪些以CL為中心的EIP***，其中，**** EIP 6988****、EIP 7044、***EIP 7045 ***被提議加入。 ***

電子工業園區 6988**：**X

• 簡介：防止被罰沒的驗證者被選為區塊提議者。
• 意義：加大了違規節點的懲罰，將利好DVT。

電子工業園區 7044**：**X

• 簡介：確保簽名的驗證器退出永久有效。
• 意義：可以一定程度上改善質押者體驗。

電子工業園區 7045**：**X

• 簡介：將attestation slot 包含範圍從一個epoch 的滾動窗口擴展到兩個epoch。
• 意義：加強網絡安全性。

刪除EIP的分析

在23年4月29日的第 160次以太坊ACDE會議中，EVMMAX和***** EOF被確認移出本次升級，與EOF***相關的改動可能會在後續的日常升級中引入

EVM 最大值 彈性IP**：**

• 簡介：EVMMAX 旨在為以太坊上的算術運算和簽名方案帶來更大的靈活性。目前，有兩種EVMMAX 提案，一種帶有EOF，另一種不帶EOF。
• 電子工業園區 6601：EVM 模塊化算術擴展(EVMMAX)
• 改變：是EIP 5843的迭代，與EIP 5843的區別在：
• 6601引入了一個新的EOF部分類型，存儲模數、預計算的Montgomery參數、將被使用的值的數量（仍然支持運行時可配置的模數）；
• 6601為EVMMAX值使用一個單獨的內存空間，用新的加載/存儲操作碼在EVM<->EVMMAX內存之間移動值；
• 6601支持對高達4096位的模數的操作（EIP中提到的暫定限制）。
• 意義：EIP-5843 為以太坊虛擬機引入高效模塊化加法、減法和乘法，EIP-6601在此基礎上進一步升級，通過引入設置部分、單獨的內存空間和新的操作碼，為模塊化算術運算提供更好的組織和靈活性，同時支持更大的模數，提高EVM 的性能。
• 作為EVM 合約，在各種曲線（包括BLS12-381）上啟用橢圓曲線算術運算；
• MULMOD與現有操作碼相比，將對高達256 位的值進行操作的gas 成本降低90-95% ADDMOD；
• 允許將modexp 預編譯實現為EVM 合約；
• 顯著降低代數哈希函數（例如MiMC/Poseidon）和EVM 中的ZKP 驗證的成本。
• 電子工業園區 6690：
• 改變：EIP-6990是從EIP-6601 改編而來的提案，旨在不依賴EOF 向EVM 引入優化的模塊化算術運算。雖然EIP-6601 需要EIP-4750 和EIP-3670 作為依賴項，但EIP-6990 提供了一個更獨立的解決方案。它通過消除對EOF 的依賴提供了一種更簡化的方法。
• 意義：它保留了EIP-6601 的核心功能，可以對高達4096 位的奇數模數進行優化的模塊化算術運算，這種簡化允許更有效的實施和採用，同時仍然提供與EIP-6601 相關的好處。

EOF 變化**：**

• 簡介：EOF 是對EVM 的升級，引入了新的合約標準和一些新的操作碼，傳統的EVM 字節碼（bytecode）是非結構化的指令序列（unstructured sequence of instructions）字節碼。 EOF 引入了容器（container）的概念，它實現了結構化的字節碼。容器由一個header 和幾個section 組成，來實現字節碼的結構化。升級後EVM 將可以進行版本控制，並且同時運行多套合約規則。
• 電子工業園區 663：
• 簡介：無限制的SWAP 和DUP 指令
• 意義：通過引入了兩個新指令：SWAPN 和DUPN，它們與SWAP 和DUP 的區別在於堆棧深度從16 個元素增加到256 個元素
• 電子工業園區 3540：
• 簡介：
• 從前鏈上部署的EVM 字節碼都是沒有一種預先定義的同一結構的，代碼只有在客戶端中被運行前才會被驗證，這既是一種間接成本，也會阻礙開發者引入新功能或棄用老功能。
• 此EIP 為EVM 引入一種可以拓展和版本控制的container，並且聲明了EOF 合約的格式，以此為基礎就可以實現在部署EOF 合約的時候對代碼進行驗證，即creation time validation，意味著可以防止不符合EOF 格式的合約被部署，這種改動實現了EOF 版本控制，會有助於未來停用EVM 已有的指令或者引入大型功能（如賬戶抽象）
• 意義：
• 版本控制有利於以後實現引入或棄用新功能（例如引入賬號抽象）；
• 合約代碼和數據的分離對於L2的驗證(op)有益，減少L2驗證器的gas成本，同時合約代碼和數據的分離也更加方便鏈上數據分析工具的工作。
• 電子工業園區 第3670章
• 簡介：基於EIP-3540 ，目的是確保EOF 合約的代碼是符合格式有效的，對於不符合格式的合約會阻止其部署，不會影響Legacy 字節碼。
• 意義：在由3540 引入的container 基礎上，EIP-3670 確保EOF 合約中的代碼是有效的，或者防止它被部署。這意味著未定義的操作碼不能被部署在EOF 合約中，這有一個額外的好處，即減少所需增加的EOF 版本數量。
• 電子工業園區 4200：
• 簡介：
• 引入了第一個EOF 專用的opcode：RJUMP、RJUMPI 和RJUMPV，它們encode destinations as signed immediate values。編譯器可以使用這些新的JUMP 操作碼來優化部署和執行JUMP 時的gas 成本，因為它們消除了現有JUMP 和JUMPI 操作碼在做jumpdest analysis 時所需的運行時間。這個EIP 是對dynamic jump 的補充。
• 和傳統的JUMP 操作比，區別在於RJUMP 等操作不是指定一個具體的offset 位置，而是指定一個相對的offset 位置（從dynamic jumps -> static jumps），因為很多時候static jumps 就夠了。
• 意義：優化網絡和降低成本。
• 電子工業園區 4750：
• 將4200 的功能更進一步：通過引入CALLF and RETF兩個新的opcode，為無法用RJUMP、RJUMPI 和RJUMPV 代替的情況實現了替代方案，以此實現了在EOF 合約中再也不需要JUMPDEST 了，也就因此禁止了dynamic 跳。
• 意義：優化代碼，方式是通過將代碼劃分為幾個部分來實現的。
• 電子工業園區 5450：
• 背景：背景仍然是以太坊的合約現在在部署的時候是不檢查的，只有在運行的時候才會進行一系列的檢查，棧有沒有溢出（上限1024），gas 夠不夠之類的。
• 內容：為EOF 合約添加了另一個有效性檢查，這次是圍繞堆棧（stack）。這個EIP 可防止EOF 合約部署可能導致堆棧下溢或溢出的情況（stack underflows / overflows）。這樣，客戶端可以減少他們在執行EOF 合約期間進行的有效性檢查的數量。
• 意義：一大改進就是讓這些執行的時候才發生的檢查盡可能的少，更多的檢查都在合約部署的時候就發生。

5月26日開發者會議更新後，與EIP 4844有關的交易類型從SSZ到RLP的變化意味著不再需要坎昆的兩個SSZ EIPs***，因此EIPs 6475和6493被移出坎昆升級***

電子工業園區 6475X

• 簡介：EIP 4844 的配套提案。 Proto-danksharding 引入一個使用SSZ 編碼的新交易類型，而不是其他交易類型所使用的RLP 編碼方式。
• 更新：在第161 次以太坊執行層核心開發者會議中，關於EIP 4844 的SSZ 序列化格式的討論顯示，最初開發者傾向於通過blob 事務向EL 引入SSZ 格式的早期迭代，最終開發者計劃將所有交易類型從RLP 升級至SSZ，但鑑於其路徑不明確且肯定無法在坎昆升級上實施，開發者一直在權衡從EIP-4844 中刪除SSZ。經過多次討論，開發者同意將SSZ 從EIP-4844 的EL 實現中移除，**但目前並未對EIP6475做出移除的行為。 5月26日更新後，SSZ-> RLP 的變化將意味著不再需要坎昆的兩個 SSZ EIPs: 因此 **EIPs 6475和6493**將被移出坎昆升級。 **

電子工業園區 6493X

• 簡介：SSZ交易簽名方案。該EIP 為簡單序列化(SSZ)編碼交易定義了簽名方案，將解決節點應如何處理在CL上以SSZ格式進行格式化但在EL上編碼不同的blob交易類型。這個EIP是更新以太坊序列化格式以實現跨層一致性內容的一部分；
• 背景：SSZ 變化
• 簡介：Simple SerialiZe，是信標鏈上使用的序列化方法。
• 不銹鋼 changes還包括另外三種配套提案，此次只引入了6465.
• 電子工業園區 6465：SSZ 取款根，定義了現有Merkle-Patricia Trie (MPT) 承諾向簡單序列化(SSZ)提款的遷移過程；
• 電子工業園區 6404 / 電子工業園區 6466：
• 二者均定義了一個將現有的Merkle-Patricia Trie (MPT) 承諾遷移到簡單序列化(SSZ)的過程。
• EIP-6404 — SSZ 交易根
• EIP-6466 — SSZ 收據根

蒂姆 Beiko 在5月26日的核心開發者會議中建議未來圍繞擴大坎昆範圍的對話僅限於以下五個EIP***：EIP 5920、5656、7069、4788和2537，後續提案將在此範圍中產生。後續EIP 5656和EIP 4788被確認為正式升級的提案，5920、7069和2537 被移出，其中EIP 5920 是由於開發者擔心轉移ETH******的方式可能存在的潛在副作用，以及暫未完成的推理、測試和安全工作，所以從升級中移除。 ***

電子工業園區 5920**：**X

• 簡介：支付操作碼。引入新的操作碼PAY用於以太坊傳輸，無需調用其任何函數即可將以太幣發送到地址。
• 原因：目前，向一個地址發送以太需要用戶調用該地址的一個函數，這有幾個問題：
• 首先，它打開了一個重入攻擊的載體，因為接收者可以回調到發送者那裡；
• 其次，它打開了一個DoS向量，所以父函數必須認識到接收者可能會耗盡gas 或回調；
• 最後，CALL操作碼對於簡單的以太傳輸來說是不必要的昂貴，因為它需要擴展內存和堆棧，加載接收者的全部數據，包括代碼和內存，最後需要執行一個調用，可能會做其他無意的操作。
• 更改：
• 引入了一個新的操作碼：( PAY) PAY_OPCODE，其中：
• 從堆棧中彈出兩個值：addrthen val。
• 將wei 從執行地址轉移val到地址addr。如果addr是零地址，valwei 則從執行地址燒錄。
• 潛在隱患：現有合約被使用時將不依賴於他們錢包的實際餘額，因為已經可以在不調用它的情況下將以太幣發送到一個地址。
• 意義：節省 gas**。 **
• 更新：23年6月9日，由於擔心轉移ETH 的方式可能存在的潛在副作用，以及通過提案需要進行的推理、測試和安全工作，PAY 從升級中移除。

電子工業園區 7069X

• 簡介：修改後的CALL 指令
• 更改：引入三個新的調用指令，CALL2、DELEGATECALL2和STATICCALL2，具有簡化語義的作用。旨在從新指令中刪除gas可觀察性，並為不受重定價影響的新類別合約打開大門。
• 背景：
• 63/64th 規則：限制call 深度且確保調用者在被調用者返回後有剩餘的gas來進行狀態改變；
• 在引入第63/64條規則之前，需要稍微準確地計算呼叫方的可用gas。 Solidity有一個複雜的規則，它試圖估計調用者一方執行調用本身的成本，以便設置一個合理的gas值。
• 目前引入****63/64th 規則：
• 刪除了call 深度檢查；
• 確保在執行被調用行為之前，至少保留5000個gas；
• 確保至少有2300個gas可供被調用行為使用。
• 津貼規則：如知名的2300津貼，當一個合約調用另一個合約時，被調用的合約會得到2300 gas 用於執行非常有限的操作（足夠做一點計算和生成一條日誌，但不夠寫滿一個存儲槽），由於它設置的是固定的gas 數量，因此只要gas 價格可以調整，人們就沒有辦法確定這些gas 到底能支持什麼類型的計算。
• 意義：為未來引入 EOF **鋪路，同時更加便捷大型合約的運行。 **
• 移除gas 可選性：新指令不允許指定gas limit，而是依賴“63/64th 規則”（主要指EIP-150 中用於大量IO 操作的Gas 重定價，提高了特定操作的Gas 消耗量）來限制gas，這個重要的改進是簡化了圍繞“津貼”的規則，無論是否發送該value，調用者都不需要執行有關gas 的計算；
• 引入新提案後，用戶始終可以通過在交易中發送更多gas（當然，會受區塊gas 限制）來克服Out of Gas 錯誤。
• 以前在提高存儲成本時(如EIP-1884 增加某些操作碼的gas) 一些只向他們的調用發送有限數量的gas 的合約被新的成本核算機制所打破。之前一些合約有一個gas 上限，永久地限制了他們可以花費的氣體數量，哪怕他們將其發送到他們的子調用中也無法解決，無論多少額外的gas 都不能解決，因為call 會限制發送的數量。
• 為引入EOF 鋪路：一旦引入EVM 對象格式(EOF)，就可以在EOF 合約中拒絕舊的調用指令，確保它們基本上不受gas 價格變化的影響。由於這些操作是消除氣體可觀察性所必需的，因此EOF 將需要它們來代替現有指令；
• 更加便利的狀態返回碼：引入了返回更詳細狀態代碼的便利功能：成功(0)、還原(1)、失敗(2)，且在未來可擴展。

電子工業園區 2537**：**X

• 簡介：BLS12-381 曲線操作的預編譯。
• 改變：將BLS12-381 曲線上的操作作為預編譯添加到有效執行BLS 簽名驗證和執行SNARKs 驗證等操作所必需的集合中。
• 意義：以太坊可以創建更安全的密碼證明，並允許與信標鏈更好的互操作性**。 **

公關 3175 曾被提及過，但未曾放入候選名單中，後續無討論

**公關 第3175章：**X

• 簡介：該提案將防止被懲罰的驗證者在退出隊列時提出區塊。如果有超過50％的驗證者因惡意行為而被懲罰，在被強制從網絡中驅逐的同時，這些驗證者仍然能夠提出區塊。開發者表示，更改此邏輯是一個相對較小的CL層更改，可以提供對“高故障模式”的保護。
• 根據5 月4 日的第108 次以太坊核心開發者共識會議，PR 3175 處在格式化為EIP 的過程中，將改為EIP-6987，即出於安全考慮，防止罰沒（slashed）驗證節點被選為區塊提議者。

未來

基於以上信息，我們得到了以下結論：

1.坎昆升級的主要目標按照優先級排序為，擴容，安全，省gas****和互操作性：

• 擴容毫無疑問，是第一優先級（4844）；
• 安全和省gas 為第二要義（6780、1153、5656 和7045），同時兼顧一定的開發者體驗；
• 第三為互操作性，如優化dapp之間的聯結、通信和互操作性（4788、7044 和6988）；
• 預期數據：測試網4844 可降低opside rollup 的50%成本；EigenLayer 和Celestia 的技術方案沒有披露太多，無法評估其數據；Ethstorage 預估DA 成本降至原先的5%；Topia 預期降低100~1000倍成本。

2.坎昆升級 到 **Danksharding的未來2~5年，是DA**層項目的黃金發展期

• 層 2 的安全上限取決於其採用的DA 層，Proto-Danksharding 通過更便宜的狀態數據存儲，將利好存儲協議、模塊化協議和L1 存儲擴展網絡。
• **首先，**Danksharding 回歸到以太坊狀態機的本質。 V神提到，以太坊共識協議的目的不是保證所有歷史數據的永久存儲。相反，目的是提供一個高度安全的實時公告板，並為其他去中心化協議留出空間進行更長期的存儲 （這 以太坊共識協議的目的不是保證 永久存儲所有歷史數據。相反，目的是 提供高度安全的實時公告板，並留出空間 其他去中心化協議來進行長期存儲。 ）；
• 其次，Danksharding **降低了**DA **成本，但實際落地時間和數據可用性問題也需要解決。 **
• **DA****成本降低：**在此次更新之前，將數據從rollup 發佈到以太坊主鏈需要調用calldata，而調用此代碼的gas 費非常昂貴，是layer 2 中最大的一筆支出，EIP 4844 通過引入數據blob，作為rollups 獨有的額外數據空間，將大大減少存儲成本，進而使DA 成本降低。
• 實際落地時間長，且能夠提升的 TPS 和降低的 gas 仍有限，所以利好 DA 層項目在後續的持續發展：
• 在polynya有關danksharding 的iable security data sharding 文章中，表明其落地需要2-5年；
• 即使落地，其能夠提高的 TPS 和降低的 gas 量級仍有限：
• 電子工業園區 4844 目前支持6個Blob，未來擴容問題依靠Danksharding 才能解決；
• 當前以太坊區塊空間大概是200 KB。到了Danksharding 之後，在規範中計劃的大小是32 兆，約為是100 倍的提升。目前以太坊的TPS 為15左右，理想化狀態下提升100倍後為1500左右，量級上並非有很大提升。
• 因此，落地時間長 + 實際改變有限將利好 DA 層項目，一些如Celestia、** Eigenda** 的 DA 項目仍可以在後續通過更便宜的成本和更快的 TPS 與 Danksharding *競爭 ，ETHstorage topia **等新DA*項目也能填補落地前的市場空白。 **
• 技術問題，如數據存儲和數據可用性問題也需要解決：
• DA 主要的成本有兩個，一個是網絡帶寬的成本，另一個是存儲成本，而4844 本身並不解決存儲問題和區塊上鍊的帶寬問題
• blob 會在以太坊共識層上存儲約3 週後被刪除，若想達成存儲完整歷史記錄和全部數據可用，目前的解決方案有：dapp 自身存儲與自己相關的數據、以太坊門戶網絡（目前正在開發中）或區塊瀏覽器等第三方協議進行存儲、在BitTorrent 中存儲歷史數據或個人用戶的自發存儲。
• 因此，Proto-Danksharding 將利好存儲協議、模塊化協議和L1 存儲擴展網絡：
• 對於歷史數據的調用需求使去中心化存儲協議或第三方索引協議等將會多一條新的發展渠道；
• 後續模塊化協議可以通過高速的Rollup 執行交易，安全的結算層負責結算，低費用大容量的數據可用性層用負責保障；
• 利好L1 存儲擴展網絡，如Eth storage，其能以更低的存儲成本提供可編程存儲的二層解決方案。

3.坎昆升級利好L2****多樣性、L3、RAAS和 數據可用性等賽道

• L2 賽道分析：
• 頭部Layer2，如Arbitrum 軌道、OP 堆棧、Polygon2.0、分形 Scaling（StarkWare 旗下）和HyperChain（zkSync 旗下）等5個項目會受益。 blob 帶來的存儲減費會使之前一系列限制layer 2 發展的成本和可拓展性問題得到大幅改善，大大增強數據吞吐量，解決費用問題後，頭部layer 2 將有機會繼續部署針對特定功能、高度自定義化的多鏈並發的L3 生態；
• 二線Layer2 與主流Layer2 在運營成本上的差距會被縮小，將給予一些小型項目更多的發展機會，如Aztec、Metis、Boba、ZKspace、layer2.finance等；
• 雖然模塊化區塊鏈項目的真實需求仍然有待驗證，但多樣化的編程語言仍然成為可能，比如Starkware的Cario 、Move系語言、Wasm 支持的C、c++、C# 和Go系列語言，這樣可以引入更多的web2 開發者。
• Raas 賽道分析：
• Raas 本身優勢在於高度定制化，定制化需求> 單純成本和效率，所以費用降低是定制化Rollup 的一個較大利好。
• 但是RAAS 賽道的問題是可能被OverHype 了，甚至有對RAAS 賽道本身的質疑。 面對 5 個頭部 layer2 的競爭，各種新的 DA **的出現，新項目能否構成一個賽道我們是要打一個問號的。 **
• 首先，頭部layer 2 應用鏈的部署優勢在於網絡框架的完整度和鏈間生態的安全性， RAAS 的優勢在於其定制性和自由度；
• 但是目前OP 和ZK 系的RAAS 技術壁壘不強，且短期內仍處於測試網階段，無實際產品交互，考慮到RAAS 的實際進展、技術形式和未來layer3 的生態優勢，RAAS 的實際需求存疑。
• OP 系：雖然OP stack 的bedrock 升級+ 4844 上線從成本和效率上帶來了一定的⼩幅提升，但是該提升帶來的吸引力不強；
• ZK系：目前龍頭項目走ZKEVM 路線的較多，更加在意與以太坊的兼容性，所以電路設計就會犧牲一定的效率，在針對性上不如OP 系。但是目前市面上的ZK RAAS 大多依舊是使用龍頭項目（如ZkSync）去Fork 鏈，壁壘仍不強。
• 所以，短期內 OP RAAS 在 layer3 落地前仍有一定的發展空間，長期看來 ZK RAAS 和 layer3 **可能是未來趨勢。 ** *ZK RAAS 在4844 後的成本劣勢更大，其消耗的算力比OP 要大很多，雖然其上傳到L1 的成本相較於OP 更少，但這相比於證明過程的花費僅僅是杯水車薪，而OP就優勢在於能在短期內快速搭建生態，在layer3 落地前仍有一定的發展空間；
• 對於常規defi 應用，NFT市場，轉型rollup 並非是一個硬性需求，僅對效率要求高的支付應用或遊戲才對rollup 有更強的需求。未來可能defi 類項目會在l2，social 類可能日常行為在l3 或者鏈下，最後核心數據和關係放在l2 上，gaming 類的項目有需求去l3 或rollup，但考慮到目前鏈遊大多實質為資金盤，且代幣無法對外流通帶來了發展瓶頸，加上全鏈上游戲的萌發，l3 本身的生態吸引力要遠遠大於rollup。

**4.**坎昆升級改善了開發者和用戶體驗

• 坎昆升級第二個重要提案SELFDESTRUCT removal 將進一步提高以太坊安全性，同時對於刪除後可能存在的程序性賬戶更新問題，準備引入新操作碼SETCODE 來改善此類情況；
• 坎昆升級的第三個提案EIP 1153 增加了瞬態存儲操作碼，首先可以節省gas，其次能解決幀間通信問題，最後為未來的存儲設計鋪路，如Verkle 樹將不需要考慮瞬時存儲的退款問題；
• 坎昆升級的第四個提案EIP 5656 引入了MCOPY 內存複製指令，可以更精確地複制代碼詞句，將提高約10% 的內存副本性能；
• 坎昆升級的第五個提案為EIP 4788可以使以太坊網絡中不同協議和應用程序之間的通信更加高效和安全，也允許質押池、橋接和restaking 協議有更多無需信任的設計；
• 坎昆升級最新（23年6月15日）提議加入的以CL為中心的EIP升級還有：EIP 6988、EIP 7044、EIP 7045，分別在細節方面提升了以太坊的安全性和使用性，如改善質押者體驗和提升網絡安全性等。
• 被刪除的提案中，SSZ-> RLP 的轉變使兩個SSZ 電子工業園區（EIP） 6475 和EIP 6493）被移出坎昆升級；EOF 相關提案在被從上海昇級中移出後再次從坎昆升級中移除，目前考慮可能直接在後期的日常升級中實現；EVMMAX 由於是一些與EOF 實現相關的EIP子集，所以也和EOF一起被移出坎昆升級；考慮到轉移ETH 的方式可能存在的潛在副作用，以及通過提案需要進行的推理、測試和安全工作，EIP 5920從升級中移除。

5.與zkml****和賬戶抽象的關係

對zkml影響不大

• ZKML 即零知識證明（Zero Knowledge）和機器學習（Machine Learning）的結合；區塊鏈與 ML 模型的結合解決了機器學習的隱私保護及可驗證性問題：
• 隱私保護：輸入數據的保密，如使用大量個人信息作為數據餵給機器進行訓練時，個人信息的保密就是一大需求；或模型參數作為項目的核心競爭力，也需要進行加密來維持競爭壁壘。諸如此類的信任問題存在時，ML 模型要想獲得更大規模的數據和應用就會存在阻礙。
• 可驗證性：零知識證明技術應用範圍廣泛，ZKP 可以讓用戶無需驗證即可得知信息正確性。且由於機器學習模型需要大量計算，而ML 模型可以通過ZK-SNARK 生成證明，減少證明大小，緩解ML的算力需求問題。
• ZKML 的存儲需求和 DA **關係不大：**需要類似Space and Time 這種單獨的存儲結構，其核心技術是“SQL 證明”新安全協議，簡單來說就是一個位於區塊鏈旁邊的數據倉庫，能讓開發者以簡單的SQL 格式連接鏈上和鏈下數據並將結果直接加載到智能合約中；
• ZK-SNARKs 是 ZKML 中 ZK 的主要形式，能適配 ML 的鏈上算力需求，隨著密碼學的發展，尤其是遞歸的****SNARK 證明會利好 ZKML 在鏈上的落地：
• ZK-SNARKs 具有高度緊湊性的特點，使用ZK-SNARKs 能讓證明者生成一個短證明，而驗證者無需交互，只需進行少量的計算即可驗證其有效性，這種僅需一次有證明者向驗證者交互的性質，使ZK-SNARKs 在實際應用中具有高效性和實用性，更加適配ML 的鏈上算力需求。
• 目前不可能進行鏈上訓練，鏈上僅能存儲鏈外計算的結果：
• 當前ML 的問題更多在於算力需求無法滿足和算法限制（無法並行計算）導致的低性能，大模型ZK 證明需要更高算力，鏈上無法支持，當下流行的ZK-SNARKs 也僅支持小規模、較小計算量的ML 零知識證明，即算力局限是影響ZKML 區塊鏈應用發展的關鍵因素，鏈上僅能做到存儲鏈外計算的結果。

利好賬戶抽象

• 首先，坎昆升級能一定程度減少 ZK rollup 證明的費用：
• 當前zkSync 的交易費取決於3 方面：
• 驗證者生成SNARK 證明和進行驗證所消耗的固定資源成本，該部分成本較高；
• 驗證者將SNARK 證明提交到以太坊主網時的gas 費，這部分費用會因主網擁堵而相應增加；
• 用戶支付給驗證者的服務費用，包括交易確認、消息廣播等。
• 所以，若引入4844，主網擁堵導致的gas 費增加問題將得到緩解，能一定程度減少ZKP 證明的費用，雖然相較於生成證明的費用不多，但是考慮到目前ZK 仍處於出初期，未來ZK 係發展趨勢仍不容小覷。
• 其次，賬戶抽象將傳統的 tx 交易轉變為 useroperation**，再將** useroperations 用 *ECDSA * 打包成塊，對鏈上存儲佔用相比於之前更多，所以對於存儲的要求更高；
• 接著，賬戶抽象與 ZK rollup 可以相輔相成：
• 目前賬戶抽象的問題一是Gas Fee 貴，由於步驟過多，且牽扯到智能合約，所以數據多，進而導致Gas Fee 貴，而ZK Rollup 優勢就在於能減少數據；
• 賬戶抽象導致安全性難以保證：由於AA 涉及多個合約，安全性是問題，但是未來L2 逐步成型後，共識層將不再改動，智能合約會有更多用武之地，賬戶抽象的安全性也可得到保障，借助ZK rollup 的可信驗證，安全性將會有更大提升。
• 最後，考慮到 AI 技術的崛起，能幫助增強鏈上合約的安全性和優化鏈上交易或活動步驟：
• AI 與安全性：AI 技術可以用於增強鏈上交易的安全性和隱私保護。例如Web3安全平台SeQure 就利用AI檢測和防止惡意攻擊、欺詐行為和數據洩露，並提供實時監控和警報機制，確保鏈上交易的安全性和穩定性；
• AI 與鏈上活動優化：區塊鏈上的活動包括交易、合約執行和數據存儲等。通過AI的智能分析和預測能力，可以更好地優化鏈上活動，提高整體效率和性能。 AI可以通過數據分析和模型訓練，幫助識別交易模式、檢測異常活動，並提供實時建議以優化區塊鍊網絡的資源分配。
• 因此，坎昆升級將從存儲空間的擴大，到與 ZK rollup 的相輔相成，再到與 AI **技術的結合，逐步利好賬戶抽象未來的發展。 **

**6.**回看以太坊路線圖，接下來是什麼

• **目前來看，**Layer2 還沒有類似於 Solana 的性能（在延遲和吞吐量方面），也沒有像 Near 這樣的分片性能，也沒有像 Sui 和 Aptos **這樣的並行執行性能，坎昆升級提升了以太坊作為領導者的領先地位； **
• 坎昆升級之後，預估幾個重大的開發時間 Fully-Danksharding**（2~5年），MEV * 和 **PBS***落地（1~3年），賬戶抽象（1~2年），***ZK * **一切（3~6年），EOF和開發者體驗（看延期幾次？）。 **

這 天災

• 目標：重點是解決MEV 問題。
• 方案：通過「提議者構建者分離（PBS）」來達成應用層的MEV 最小化，此時可能會對blob 做出優化，並引入預確認服務或搶跑保護等。
• PBS即出塊者和排序者分離。排序者只負責排序不管上鍊，出塊者不管交易，直接選排序者打好的包上鍊。這個流程會讓整個過程更加流程正義，緩解MEV問題，是MEV 外部化的思路。
• PBS目前完成度仍然很低，比較成熟的是 外部MEV 解決方案合作——flashbots 的mevboost。
• 進階版的「Enshrined Proposer-Builder Separation（ePBS）」完成度更低週期更長，估計短期內無法見到落地，另外還有漸進版本的PEPC 和Optimistic Relaying ，增強了PBS 框架的靈活性和適應性

這 邊緣

• 目標：利用Verkel 樹取代Merkle ，引入信任最小化的解決方案，使輕節點獲得與全節點一樣的安全保障，讓區塊驗證盡可能簡單和輕便。
• 同時，L1 的ZK 化明確地加入Verge 路線圖之中ZK 將是未來擴容和提速的大勢所趨；
• 方案：引入zk-SNARKs ，代替舊的證明系統，包括基於SNARK 的輕客戶端；共識狀態變化的SNARKs；Enshrined 匯總。
• Verkle 樹是一種專門針對狀態的Merkle 樹的更有效的替代方法，它不需要提供每個姐妹節點（共享同一個父節點的節點）到所選節點的路徑，而只是提供路徑本身作為證明的一部分，Verkle 證明的效率比Merkle 證明高3 倍。
• 供奉 Rollup 是指在L1 上擁有某種共識集成的Rollup，優點在於繼承了L1 的共識，無需治理代幣來執行rollup 升級，同時通過在鏈外進行計算並只將結果發佈到區塊鏈上，可以提升交易數量，不過實現的技術難度較大。未來這些rollup 組合在一起，將能滿足未來幾十年區塊鏈生態系統中的大部分需求。

這 清除

• 這 Purge 指的是通過降低參與驗證網絡的存儲要求來簡化協議的目標。這主要是通過對歷史和狀態的休眠和管理來實現的。歷史數據休眠（EIP-4444）允許客戶端修剪超過一年的歷史數據，並停止在P2P 層面提供服務。
• 狀態休眠。當涉及到處理狀態增長時，有兩個主要目標：弱無狀態，指的是只使用狀態來建立區塊，但不驗證它的目標；狀態休眠，指刪除在規定時間內（1 年）未被訪問的狀態。狀態休眠應該使節點需要存儲的狀態總共減少20-50 國標。
• 在第五個階段Purge中，EIP 4444 被明確寫入Roadmap，EIP-4444 要求客戶端清除超過1 年的數據，同時該階段還有一些EVM 優化的工作，如簡化GAS 的機制和EVM 預編譯等；

這 揮霍

• 最後的第六階段Splurge 中，EIP 4337 也被提及，作為錢包生態的長期佈局提案，賬戶抽象未來將會進一步提高錢包易用性，包括使用穩定幣支付gas、社交恢復錢包等；

參考資料：

• 以太坊核心開發者會議更新：
• 以太坊 所有核心開發人員致電 #148 寫上去
• 以太坊 所有核心開發人員致電 #149 Writeup
• 以太坊 共識層通話 #99 寫上去
• 以太坊 所有核心開發人員致電#150 寫上去
• 以太坊 所有核心開發人員致電#151 寫上去
• 以太坊 共識層通話 #100 寫上去
• 以太坊 所有核心開發人員都提出電話#152 寫上去
• 以太坊 所有核心開發人員都提出電話#153 寫上去
• 以太坊 Magicians 論壇討論原文：
• 以太坊 所有核心開發人員都提出電話#156 寫上去
• 以太坊 所有核心開發人員都提出電話#157 寫上去
• 以太坊 所有核心開發人員都提出電話#158 寫上去
• 以太坊 所有核心開發人員都提出呼籲#159 寫上去
• 以太坊 所有核心開發人員都提出電話#160 寫上去
• 以太坊 所有核心開發人員達成共識#108 寫上去
• 以太坊 所有核心開發人員都提出電話#161 寫上去
• 以太坊 所有核心開發人員達成共識#109 寫上去
• 以太坊 所有核心開發人員都提出電話#162 寫上去
• 以太坊 所有核心開發人員達成共識#110 寫上去
• Tim 關於最新的以太坊坎昆升級推文（23年6月9日）：
• 以太坊所有核心開發者共識電話會議#111 寫上去
• 以太坊 所有核心開發人員達成共識#112 寫上去
• 以太坊升級相關內容：
• 自毀代碼的簡介：
• 探索EVMMAX 提案和BLS12-381
• 除了EIP-4844 坎昆升級還會包含哪些內容？速覽以太坊最新共識電話會議
• 以太坊上海昇級，又增加了哪些新內容？
• 推文：
• 好的 Ventures:以太坊上海昇級後，坎昆升級潛在投資機會- 前瞻新聞
• 除了備受矚目的EIP-4844，坎昆升級還會包含哪些提案？
• V神：值得考慮刪除的EVM 功能
• 原始 Danksharding 常問問題
• V 神推薦丨深入了解以太坊的分片路線圖，看這一份報告就足夠
• 一文讀懂以太坊新升級方案Danksharding
• 解讀Ethereum 最新路線圖中的有趣事實和隱含密碼
• Vitalik：為什麼說SELFDESTRUCT對以太坊的生態弊大於利
• 以太坊願景：
• 砌塊工程 Research 研究員Brrr ： Proto-Danksharding 如何加速以太坊的L1 Rollup 可擴展性
• 第111次以太坊ACDC會議：討論Deneb升級最終範圍以及EIP-7044等三項提案
• 網紅 Stacy Muur 速覽以太坊擴展解決方案演變：OP 堆棧、任意 軌道、多邊形 2.0
• 三類Rollups橫向對比：經典Rollups（Optimistic/ZK 匯總）、供奉 Rollups、主權 匯總
• [AMA] 我們是 EF Research（第 8 部分：7 月 7 日， 2022）：
• 2023值得重新思考的3大熱門賽道
• 黑山EDCON 2023 結束後的思考：基礎設施和應用趨勢前瞻
• AI 與Web3 結合可能性的無限遐想
• AI+Web3：探索人工智能和區塊鏈的融合之路
• 對比zk-rollup 和op-rollup：從驗證方式分析為何當前zkSync Gas 費偏高
• “卷上加卷”：Rollup時代的賬戶抽象解決方案
• 深度解讀ZKML：技術原理、應用場景、優勢和挑戰
• ZKML：將AI和區塊鏈融合，實現隱私保護的模型部署技術
• 可以 安全數據 分片
• 對話EthStorage 創始人Qi Zhou | 數據可用性和去中心化存儲
• 一文讀懂最新版以太坊發展路線圖
• 關於Space 和 Time的簡單介紹
• 提案原文：
• 電子工業園區 4844：
• 電子工業園區 6780：
• 電子工業園區 1153：
• 電子工業園區 5920：
• 電子工業園區 5656：
• 電子工業園區 7069：
• 電子工業園區 4788：
• 電子工業園區 2537：
• EVM 最大值 生態IP：
• 電子工業園區 6601：
• 電子工業園區 6990：
• 結束符 變化：
• 電子工業園區 663：
• 電子工業園區 3540：
• 電子工業園區 第3670章
• 電子工業園區 4200：
• 電子工業園區 4750：
• 電子工業園區 5450：
• 電子工業園區 6475：
• 電子工業園區 6493：
• 公關 第3175章