坎昆升級解決TPS、gasfee 和開發者體驗對於以太坊路線圖來說至關重要。
原文作者：胖鳥財經、原文來源：胖鳥財經
轉載來源：PANews
前世
為什麼需要坎昆升級？
以太坊的願景為：在去中心化的前提下變得更具有可擴展性且更安全。當前以太坊的升級也致力於解決這個三難問題，但是一直面臨著很大的挑戰。
以太坊的問題：
目前出現了TPS和性能較低，gas費高且擁堵嚴重的情況，同時，運行一個以太坊客戶端所需的記憶體空間也在快速增長，在底層，確保以太坊安全和去中心化的工作量共識算法對整個環境的影響也愈發顯著。
所以，在去中心化的前提下，如何傳輸更多的數據並降低gas，來增強可拓展性，如何優化共識算法，來保障安全性，都是以太坊目前正在做的努力。
為了解決安全、去中心化和拓展性這個三難困境，以太坊曾利用PoW轉PoS機制來進一步降低節點門檻，也準備利用信標鏈隨機分配驗證者來優化安全性，在可拓展性方面，以太坊考慮使用分片這個方式來減輕節點的工作量，這也能使以太坊可以同時創建多個區塊，增強其可拓展性。
當前以太坊每一個區塊的空間大概是200~300KB，每個交易最小大約是100個字節，約2000筆交易，除以區塊時間12秒，以太坊的TPS上限就被限制在100左右。這個數據明顯無法滿足以太坊的需求。
因此，以太坊Layer2關注如何能把大量數據放到blockspace裡去，通過欺詐證明和有效性證明保證安全，這也是為什麼DA層決定了安全上限的原因，這也是坎昆升級的核心內容。
以太坊生態的迭代路線，無法構建對標Solana的性能（在延遲和吞吐量方面），短期也看不到Near的分片性能，也沒有Sui和Aptos的並行執行性能，短期內以太坊只能構建以Rollup為核心的多層結構，因此坎昆升級解決TPS、gasfee 和開發者體驗對於以太坊路線圖來說至關重要。
以太坊路線圖怎麼規劃的？
最近幾次重要的升級及其目標
- 2020年12月1日信標鏈正式發布，為POS升級做了鋪墊
- 2021年8月5日倫敦升級，EIP1559改變了以太坊的經濟模型；
- 2022年9月15日巴黎升級（TheMerge），完成了POW切換POS；
- 2023年4月12日上海升級，解決了質押提款問題；
完成了經濟模型和POS相關的升級，接下來幾次升級解決了以太坊的性能、TPS和開發者體驗的問題；
下一步重點是以太坊路線圖中的TheSurge 。
- 目標：Rollup中實現10萬+的TPS。
主要有2個方案，鏈上和鏈下：
- 鏈下方案：指Layer2，包括rollup等，
- 鏈上方案：指直接在L1中進行更改，也就是熱門的分片方案，分片簡單理解就是將所有節點劃分成不同片區，完成每個片區的任務，這將有效提升速度；
分片方案解析：
分片（Sharding）方案的困境：曾經的Sharding包括狀態分片，交易分片等，但是出現不同分片之間的同步是個難題，目前想要完成大範圍的網路節點數據同步，技術難度大，不僅無法解決MEV的情況，且可能需要大量補丁來彌補可能出現的各類問題，短期無法實現。
Danksharding是為以太坊提出的新分片設計，其核心思想為中心化的出塊+去中心化的驗證+抗審查性，這也與下文將要提到的數據可用性採樣（DAS）、出塊者-打包者分離（PBS）和抗審查清單（Crlist）有關。Danksharding核心思想的最大意義，在於把以太坊L1變成了一個統一的結算（settlement）和數據可用性（DataAvailability）層。
分片方案分為2步，目前看分為Proto-danksharding 和Fully-Rollup。
Proto-danksharding：
- 介紹：通過引入blob幫助L2降費並增加吞吐量，同時作為danksharding的前置方案為實現完全分片（sharding）鋪平道路。預期proto-danksharding後，danksharing的落地需2-5年時間。
- 內容：proto-danksharding的主要特性是引入新的blob交易類型，Blob具有容量大且便宜的特點，給以太坊外接此類數據包，能讓rollup的數據全部存入blob，大大緩解主鏈的存儲壓力，同時也能降低rollup的費用。
Fully-Rollup
- 介紹：rollup全面擴容，重點在於數據可用性的利用。
- 內容：DAS的P2P設計：涉及數據分片網路連接問題的一些工作以及研究；
數據可用性採樣客戶端：開發輕量級客戶端，可以通過對幾千字節的隨機採樣快速判斷數據是否可用；
有效的DA自我恢復：能夠在最惡劣的網路條件下有效地重建所有數據（比如，惡意驗證者攻擊、或者大塊節點的長時間停機）。
以太坊核心開發者會議
以太坊的每一次升級都依賴於核心開發者會議，通過核心貢獻者的共同討論，根據開發者們的一系列提案，決定未來的發展方向
定義：核心開發者會議是以太坊開發社區每週舉行的一次電話會議，來自不同組織的核心貢獻者共同討論技術問題並協調以太坊的未來工作。它們決定了以太坊協議的未來技術走向，同時也是真正進行以太坊升級決策的權力機構，負責決議，EIP是否被納入升級，是否需要進行路線圖變更等重要事項。
核心流程：以EIP為中心的升級流程大致如下，首先在核心開發者會議（簡稱ACD）上初步接納一個EIP，然後客戶端團隊無論該EIP被納入升級與否，都對其進行測試，並在最終測試完後進行再一次回顧，再根據探討決定最終是否納入實際升級中。
會議分2類，分別是共識層會議和執行層會議，兩者隔週交替舉行：
- 共識層會議（AllCore Developers Consensus – ACDC），關注以太坊共識層（權益證明、信標鏈等）；
- 執行層會議（AllCore Developers Execution – ACDE），後者關注以太坊的執行層（EVM、Gas時間表等）。
以太坊核心維護者有3類，主要是一些討論提案的官方組織或者志願者論壇：
- AllCoreDevs：代碼維護者，負責ETH1網路客戶端，升級，維護以太坊代碼和核心架構；
- “項目管理”部分：支持以太坊開發人員、協調硬分叉、監控EIP等，以及直接幫助AllCoreDevs負責通訊和運營；
- EthereumMagicians：一個希望圍繞EIP和其他技術主題進行討論的“論壇”。
坎昆升級相關會議的時間線
按照討論內容劃分，本次坎昆升級可粗略分為5個階段。
第一個階段——引入升級主題
引出新任務proto-danksharding、EOF和“selfdestruct”操作碼，粗淺討論上海升級內容
以太坊在22年9月15日完成合併後，開發者會議暫停4週，為開發者留取一個月的時間查看後續升級所討論的EIP；
22年10月28日，合併後的第一次開發者會議，首次提出proto-danksharding、EOF的實現和“selfdestruct”操作碼，此時，proto-danksharding的具體範圍未確定，有開發者初步認為，可以將上海升級分為幾步小型的升級，如先啟用質押的ETH提款，然後再升級EIP4844，但另外一部分開發者認為一步到位實施更大的升級更有意義。
第二個階段——確定時間範圍和KZG儀式的準備
2022年底，以太坊會議主要圍繞EOF和EIP4844 進行討論，同時持續推進EIP4844 所需的前期可信設置儀式——KZG儀式，開發者們將在23年1月正式確定4844將在哪個升級中露面
22年11月，在以太坊所有核心開發者電話會議#149中，已經提及EOF或proto-danksharding，此時開發者們仍考慮將其放置在上海升級中；
22年12月2日的共識層會議中，以太坊生態系統負責人TrentVan Epps 更新了EIP4844 實施所需的可信設置儀式的進展情況，該儀式旨在生成一段將在EIP4844 中使用的安全代碼。VanEpps 希望該儀式將成為加密領域有史以來規模最大的儀式之一，收集8000至10000份contribution，該儀式的公眾貢獻期將持續大約2個月，並於12月的某個時候開始；
同日的核心開發者會議中，圍繞EOF和停用selfdestruct操作碼進行了一定的討論，以太坊基金會的某位開發人員反對將EOF推遲到坎昆，認為如果代碼更改不包含在上海，它進入坎昆的可能性很小，關於selfdestruct代碼，當時有開發人員主張推進EIP4758，不過直接停用此操作碼將會破壞某些應用程式，開發人員認為在創建一個邊緣案例來保護此類型合約之前，該EIP應再次權衡一段時間；
22年12月9日的核心開發者會議中，關於坎昆升級方面推進了KZG儀式的實施，目前EIP4844 所需的可信設置儀式已準備就緒；
22年12月16日的共識層會議中，關於EIP4844 的主題，開發人員討論了將兩個不同的拉取請求(PR)合併到proto-danksharding的規範中，一個與節點如何處理數據修剪後超出特定點的數據可用性有關，一個是當某個塊上缺少關於blob的訊息時，將引入新的錯誤代碼來提醒節點；
23年1月5日的核心開發者會議中，開發者們就從上海升級中移除與EOF實現有關的代碼修改達成共識，Beiko此時建議在兩週之後再決定是否應將EOF包括在坎昆升級中；
第三個階段——初步討論提案的範圍
23年1月底，EOF在被從上海升級移出後移入坎昆升級，此後2個月內主要圍繞除了EOF與EIP4844 之外的其他提案進行討論，與此同時，EOF又被提議移出坎昆。這段時間主要在劃定坎昆升級的提案範圍。
23年1月20日的核心開發者會議中，EOF被移入坎昆升級；
23年3月6日的核心開發者會議中，關於坎昆升級的初步提案為：EIP4788（公開信標鏈狀態根）、EIP2537（高效執行BLS簽名驗證和SNARKs驗證等操作）、EIP-5920（引入新的操作碼PAY），以及EIP6189（用於使SELFDESTRUCT與Verkle樹兼容）與EIP-6190（更改SELFDESTRUCT函數以僅導致有限數量的狀態更改）的結合實施；
23年3月16日的核心開發人員會議裡，除了EOF與EIP4844 之外，下列提案被考慮納入坎昆：SSZ格式、SELFDESTRUCT刪除、EIP2537、EVMMAX、EIP1153、無限制的SWAP和DUP指令、引入PAY代碼和EVM中的信標狀態根；
23年3月30日的核心開發人員會議中，首次提出關於停用SELFDESTRUCT的提案EIP-6780，這也是坎昆最後確定使用的停用SELFDESTRUCT的提案。但是關於EOF的實施，來自Erigon(EL) 客戶團隊的某位開發人員表示EOF“變化太大”，無法在即將到來的坎昆升級中與以太坊改進提案EIP4844 相結合，有人提議在坎昆升級後不久在硬分叉中實施EOF；
第四個階段——確定明確的提案升級方向，刪除無關提案
23年4月，對於坎昆升級應覆蓋的提案有了清晰的方向，重點節點在4月13日的開發者會議，此會議提出了9個EIP，以及tim本人對於候補提案也有了較為深入的討論，在4月27日的會議中，EIP6780、EIP6475 和EIP1153 被確定納入坎昆，同時EOF和EVMMAX（與EOF實現相關的EIP子集）被從坎昆升級中刪除，EOF升級主要可以幫助EVM進行版本控制，並且可以同時運行多套合約規則，有助於以太坊後續的拓展性，但是考慮到整次升級的可實現度，EOF升級可能在後續隨著日常升級進行推進
23年4月12日，以太坊上海升級已完成；
23年4月13日的核心開發者會議中，開發人員討論了EIP4844（用於在EL中公開有關CL狀態根的數據），除此之外，還有至少九個其他EIP被考慮納入升級，分別是EIP4844、SELFDESTRUCT移除（EIP-6780、EIP4758、EIP6046、EIP6190）、EIP5920、EIP1153、EIP2537、EIP4788、EVMMAXEIPs（EIP6601和EIP6690）、SSZchanges（EIP6475、EIP6493、EIP6465、EIP6404 和EIP6466 ）、EIP5656 和EIP6193 ；
23年4月27日的核心開發者會議裡，重點劃分了幾個的進度和取捨。首先，EIP4844繼續確定納入坎昆升級，同時增加了以下EIP：EIP6780（更改SELFDESTRUCT操作碼的功能）、EIP6475（一種新的簡單序列化（SSZ）類型來表示可選值）、EIP1153（添加新的操作碼來操作status）；其次，正在考慮但尚未正式納入升級的EIP為EIP6913（引入SETCODE指令）、EIP6493（為SSZ編碼交易定義簽名方案）、EIP4788（在EL塊頭中公開信標鏈塊根）、 EIP2537（添加BLS12-381曲線作為預編譯）和EIP5656（引入新的EVM指令用於復制內存區域）；最後，EOF和EVMMAX（與EOF實現相關的EIP子集）被從坎昆升級中刪除。EOF升級曾在2023年1月初的以太坊開發者大會中被移出上海升級，後續從23年1月底至4月初，都被默認將在坎昆升級中出現，但23年4月29日的開發者會議中，EOF被再次移除。
第五個階段——最後的提案確定和細節完善
23年5月主要針對最後的提案細節進行精簡和完善，SSZ->RLP 的變化將意味著不再需要坎昆的兩個SSZEIPs，因此EIPs6475和6493將被移出坎昆升級。同時在26日的核心會議中，TimBeiko 建議未來圍繞擴大坎昆範圍的對話僅限於以下五個EIP：EIP-5920、5656、7069、4788和2530。開發者目前已確定坎昆升級的全部範圍。
23年5月5日的以太坊核心共識會議，討論了上次提及的EIP4788，同時增加了對EIP6987和EIP6475的討論，這兩個提案分別有關驗證者和SSZ交易；
23年5月11日的第161次以太坊執行層會議中，TimBeiko 表示，未來幾週內仍然可以對坎昆升級範圍進行修改，但如果沒有來自開發者的明確建議，坎昆升級的範圍將保持「默認」狀態，且有關EIP-4844的討論中顯示，開發者同意將SSZ從EIP-4844的EL實現中移除，但目前仍未影響到6475的持續推進。除此之外，開發人員也簡要討論了兩個EIP供坎昆考慮，分別是EIP6969（EIP1559 的修改版本）和EIP5656（用於復制內存區域的高效EVM指令）；
23年5月18日的開發者共識會議中簡要討論了4844的進展，如允許EL上的智能合約應用程式驗證CL狀態的證明；
2023年5月25日，第162次以太坊核心會議中討論了停用SELFDESTRUCT、EIP-4844規範更改、操作碼管理和潛在的最終Cancun添加等內容。TimBeiko 建議未來圍繞擴大坎昆範圍的對話僅限於以下五個EIP：EIP-5920、5656、7069、4788和2530。開發者會在未來幾週內會確定Dencun（Deneb+ Cancun）的全部範圍；
2023年6月1日第110次以太坊共識層會議，以太坊基金會某位研究員介紹了一項關於以太坊主網節點傳播大量數據的能力的數據實驗結果，由此結果，該研究員建議將EIP4844規範從每個塊最多4個blob增加到6個。同時開發者們正考慮將EIP4788 納入坎昆升級；
2023年6月13日的核心開發者會議中，開發者們正式確認了升級範圍，包括EIP4844、EIP1153、EIP5656、EIP6780、EIP4788；
2023年6月15日的共識會議中，討論了在Deneb中包含哪些以CL為中心的EIP，其中，EIP-6988、EIP-7044、EIP-7045被提議加入，以及CL客戶端團隊同意在下一個EIP-4844測試網Devnet6上測試增加的blob數量，並在兩週內就此事做出最終決定，同時以太坊基金會研究員MichaelNeuder提出取消32枚ETH質押上限，以幫助減少活躍驗證者集的增長；
2023年6月22日的會議中，tim提議將4844的預編譯地址移動到0xA，將他們打包並移動BLS到另一個地址，雖然該預編譯通過EIP2537 引入，但在坎昆中不會考慮此方案；
2023年6月29日的共識會議中，開發人員繼續討論了blob數量，將目標blob限制從2上調到3，將最大blob限制從4上調到6，同時4844的測試網Devnet#7 即將上線。
今生
核心內容是EIP4844，即Proto-Danksharding
此次坎昆升級最終確定的EIP範圍為：EIP4844、EIP1153、EIP5656、EIP6780、EIP4788。同時在6月19日的第111次以太坊ACDC會議中，開發者們繼續討論了EIP6988、EIP7044、EIP7045，以便在Deneb中納入。開發者們表示，計劃在未來幾週內將上述三個EIP合併到Deneb規範中。
重點EIP的分析
EIP4844
簡介：
EIP4844提案的名稱為Proto-Danksharding，是完整版分片擴容Danksharding的前置方案，整套分片方案其實就是圍繞著Rollup來進行鏈上擴容的。方案目的是為了擴展第2層Rollup——通過幫助L2降費並增加吞吐量，同時為實現完全分片（sharding）鋪平道路。
23年2月的電話會議中，以太坊開發人員將EIP4844 升級命名為Deneb，這是天鵝座中的一顆一等星的名稱，即以後相關GitHub版本上EIP4844 的命名將更新為Deneb；在23年6月1日的會議中，以太坊的下一次升級規範有一些變化，在CL端稱為Deneb，在EL端稱為Cancun；
23年6月23日的開發者會議中，開發人員準備更新EIP4844 的預編譯地址。目前，、核心開發人員已向EVM添加了9個預編譯，並將通過激活EIP4844 和4788分別在“0xA”和“0xB”地址下創建兩個預編譯。6月29日的共識會議中，已經準備推出EIP4844 的專用短期測試網路Devnet#7。
EIP-4844引入了一種全新的交易類型——BlobTranscation。
Blob簡介：
Blob，類似一個外掛數據包，開始只有128KB 的存儲空間，在該提案討論初期，Blob的target和limit為2/4，在23年6月9日的開發者會議中，被調整為3/6 。即目前以太坊中每一筆交易可以最多攜帶三個Blob交易，即384KB，每一個區塊的targetBlob 容量為6個，即768KB，最大可承載16個Blob，即2MB；
可能會對網路穩定性產生一定影響，但是以太坊開發團隊仍決定先行測試，避免後續需要硬分叉來拓展blob塊。
- Blob以KZGcommit Hash 作為Hash，用於數據驗證，作用和Merkle類似；
- 節點同步鏈上的BlobTransaction 後，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天有效期）的問題。解決方式：
- 數據可用性採樣（DataAvailability Sampling）——降低了節點負擔
將Blob中的數據切割成數據碎片，並且讓節點由下載Blob數據轉變為隨機抽查Blob數據碎片，讓Blob的數據碎片分散在以太坊的每個節點中，但是完整的Blob數據卻保存在整個以太坊帳本中，前提是節點需要足夠多且去中心化；
DAS採用了兩個技術：糾刪碼（ErasureCoding）和KZG多項式承諾（KZGCommitment）；
提議者-打包者分離（PBS）——解決了節點的工作分工問題，讓性能配置高的節點負責下載全部數據進行編碼分發，讓性能配置低的節點來負責抽查驗證。
性能配置高的節點可以成為打包者（Builder），打包者只需要負責下載Blob數據進行編碼並創建區塊（Block），然後廣播給其他的節點來進行抽查，對於打包者（Builder）來說，因為同步數據量和帶寬要求較高，所以會相對中心化；
性能配置較低的節點可以成為提議者（Proposer），提議者只需要驗證數據的有效性並創建和廣播區塊頭（BlockHeader），但對於提議者（Proposer）來說，同步數據量和帶寬要求較低，所以會去中心化。
抗審查清單（crList）——解決了對於打包者而言因其審查權力過大，就可以故意忽略掉某些交易並且隨意排序並插入自己想插入的交易去獲取MEV的問題。
在打包者（Builder）打包區塊交易之前，提議者（Proposer）會先公佈一個抗審查清單（crList），這個crList中包含著mempool中的所有交易；
打包者（Builder）只能選擇打包並對crList裡的交易進行排序，這意味著打包者不能插入自己的私有交易去獲取MEV，也不能去故意拒絕某個交易（除非Gaslimit 滿了）；
打包者（Builder）打包好之後將最終版本的交易列表Hash廣播給提議者（Proposer），提議者選擇其中一個交易列表生成區塊頭（BlockHeader）並廣播；
節點同步數據時會從提議者（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解決方案來說有一定影響。
意義：
EIP4844 實際上是一個超級簡化版的Danksharding：它提供了一個跟Danksharding一樣的應用接口，包括一個新的opcode叫DataHash；以及新的一個數據對象叫BinaryLarge Objects，也就是Blob；
proto-danksharding是用來實現完整Danksharding規範的“支架”(即交易格式和驗證規則)提案：不過目前還沒實現任何分片，所有驗證者和用戶仍需要直接對完整數據的可用性進行直接驗證；
為什麼長期角度選擇proto-danksharding而非EIP4488 的直接讓layer2降費，因為這樣未來升級成完整分片時僅需小幅調整：
EIP4488 與proto-danksharding的主要實際區別在於，EIP-4488試圖將今天以太坊所需做出的變更降到最低，而proto-danksharding則對今天以太坊做出更多的變更，以便在未來升級到完整版分片時只需做出很少的變更；
雖然實現完整分片(有數據可用性採樣等)是一項很複雜的任務，而且實現proto-danksharding後還有很複雜的工作，但這些複雜性都會控制在共識層上。一旦proto-danksharding部署了，執行層客戶端團隊、rollup開發者和用戶在過渡到完整分片時都不需要做任何額外的工作了。
要實現完整分片，需要完成PBS、委託證明和數據可用性採樣的實際實現，不過此類修改都將集中於CL層，無需開發者進行再調整：目前4844實現了一種新的交易類型，與完整分片裡需要的交易格式、共識交叉驗證邏輯和執行層邏輯等完全相同，也衍生出了用於blob的、自我調整的獨立gas定價，未來要實現完整分片，需要完成PBS、委託證明和數據可用性採樣的實際實現，不過這些修改僅在CL層，不需要EL層或rollup開發者進行修改，便利開發者。
其次是SELFDESTRUCTremoval，EIP-6780最終被確定為最適合的方案，但26日的開發者會議中tim提議在此提案中增加另一個操作碼SETCODE，以允許程式性帳戶仍然可以更新
SELFDESTRUCTremoval EIP-6780：X
背景：
在21年3月，Vitalik就提出SELFDESTRUCT對以太坊生態弊大於利，主要原因在於它是唯一一個能在單個區塊中變更無限個狀態對象、導致合約代碼變動、能未經帳戶同意就能修改帳戶餘額的操作碼，對於以太坊安全中有很大隱患；
在鏈上唯一移除一個合約的辦法就是SELFDESTRUCT。如果在合約裡面調用：selfdestruct函數即可自毀合約。存在合約中的以太坊將會發送到設計好的地址裡。剩下的代碼和存儲變量將會在狀態機中被移除。其實合約銷毀這個動作理論上聽上去是個好主義，但實際上是很危險的。selfdestruct函數雖然能在緊急情況下幫助開發人員刪除智能合約並將合約內的餘額轉移到指定的地址，但這一特性也被不法分子利用，使它成為了攻擊手段。
23年4月13日的核心開發者會議中，引入了四個有關SELFDESTRUCT的提案參與討論，分別是6780、4758、6046和6190，後續EIP6780被定為最終提案。
簡介：selfdestruct是智能合約的緊急按鈕，銷毀合約並將剩餘ETH轉移到指定帳戶。
EIP6780：停用SELFDESTRUCT，除非他們在合約裡的同一交易中。
更新：5月26日，tim提議除了刪除SELFDESTRUCT之外，還要增加另一個操作碼——SETCODE，以允許程式性帳戶仍然可以更新。（即加入了更新功能，通過更新/升級的方式將智能合約內的財產等進行update），此處是吸取了EIP4758 的優勢，其可以讓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成本增加。
接著是EIP1153，節省gas的同時，為未來的存儲設計鋪路
EIP1153X
簡介：瞬態存儲操作碼，添加用於操作與存儲行為相同但在每次交易後丟棄的狀態的操作碼。
原因：
在以太坊中運行交易可以生成多個嵌套的執行框架，每個框架由CALL（或類似的）指令創建。可以在同一筆交易中重新輸入合約，在這種情況下，不止一個框架屬於一個合約。
目前，這些框架可以通過兩種方式進行通訊：通過CALL指令傳遞的輸入/輸出，以及通過存儲更新。如果存在屬於另一個不受信任的合約的中間框架，則通過輸入/輸出進行的通訊是不安全的。
以reentrancylock 為例，它不能依賴中間幀來傳遞鎖的狀態：SSTORE通過存儲的通訊SLOAD很昂貴，而瞬態存儲是解決幀間通訊問題的專用且gas高效的方案。
改變：EVM中添加了兩個新的操作碼，TLOAD(0xb3)和TSTORE(0xb4)。
瞬時存儲對於擁有它的合約來說是私有的，就像持久存儲一樣，只有擁有合同框架才能訪問其臨時存儲。當訪問存儲時，所有幀都會訪問同一個臨時存儲，其方式與持久存儲相同，但與內存不同。
潛在用例：
reentrancylock；
鏈上可計算CREATE2地址：構造函數參數從工廠合約中讀取，而不是作為初始化代碼哈希的一部分傳遞；
單筆交易EIP-20批准，例如#temporaryApprove(addressspender, uint256 amount)；
轉帳費用合約：向代幣合約支付費用以在交易期間解鎖轉帳；
“Till”模式：允許用戶執行所有操作作為回調的一部分，並在最後檢查“till”是否平衡；
代理調用元數據：在不使用調用數據的情況下將額外的元數據傳遞給實現合約，例如不可變代理構造函數參數的值。
意義：
節省gas，擁有更簡單的gas計費規則；
解決幀間通訊問題；
不改變現有操作的語義；
使用後無需清除存儲槽；
未來的存儲設計（例如Verkle樹）不需要考慮瞬時存儲的退款問題。
接著是4788，能減少對質押池的信任假設
EIP4788：X
簡介：EVM中的信標塊根。
更新：在23年6月15日的開發者會議中，開發者提出進行代碼更改以改善質押者體驗，該EIP將公開信標鏈區塊的根，其中包含EVM內部鏈狀態訊息，供DApp開發者的信任最小化訪問。
改變：在相應的執行負載頭中提交每個信標鏈塊的哈希根，同時將這些根存儲在一個處於執行狀態的合約中，並添加一個讀取該合約的新操作碼。
意義：這是一項代碼修改提案，提議修改以太坊虛擬機（EVM）以使其能夠公開合約層（CL）狀態根在執行層（EL）的數據，可以使以太坊網路中不同協議和應用程式之間的通訊更加高效和安全。允許質押池、橋接和restaking協議有更多無需信任的設計。
最後是5656，提供了一種高效的新的內存複製操作碼，但是考慮到其測試帶寬，目前處於暫時被包括進升級的狀態
EIP5656X
簡介：MCOPY- 內存複製指令。
更新：23年6月9日，開發團隊表示最初對MCOPY存在分歧，因為雖然其解決了安全問題，但仍擔心將它添加到升級所需的實施+測試帶寬，但是最後仍同意包含該EIP，但是如果開發者在測試或客戶端遇到容量問題，就會考慮將其刪除。因此，MCOPY處於暫時被包括進坎昆升級中的狀態。
更改：提供了一種高效的EVM指令來複製內存區域。
意義：內存複製是一個基本操作，但在EVM上實現它需要成本。
隨著MCOPY指令的可用性實現，可以更精確地複製代碼詞句，將提高約10.5%的內存副本性能，對於各種計算量大的操作非常有用；
對編譯器生成更有效和更小的字節碼也將會很有用；
可以節省一定的身份預編譯的gas費用，但是並不能起到實際推進此部分實現的作用。
候選名單EIP
23年6月15日，開發者共識會議討論了在Deneb中包含哪些以CL為中心的EIP，其中，EIP6988、EIP7044、EIP7045 被提議加入。
EIP6988：X
- 簡介：防止被罰沒的驗證者被選為區塊提議者。
- 意義：加大了違規節點的懲罰，將利好DVT。
EIP7044：X
- 簡介：確保簽名的驗證器退出永久有效。
- 意義：可以一定程度上改善質押者體驗。
EIP7045：X
- 簡介：將attestationslot 包含範圍從一個epoch的滾動窗口擴展到兩個epoch。
- 意義：加強網路安全性。
刪除EIP的分析
在23年4月29日的第160次以太坊ACDE會議中，EVMMAX和EOF被確認移出本次升級，與EOF相關的改動可能會在後續的日常升級中引入
EVMMAXEIPs：
簡介：EVMMAX旨在為以太坊上的算術運算和簽名方案帶來更大的靈活性。目前，有兩種EVMMAX提案，一種帶有EOF，另一種不帶EOF。
EIP6601：EVM模塊化算術擴展(EVMMAX)
改變：是EIP5843的迭代，與EIP5843的區別在：
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驗證的成本。
EIP6690：
改變：EIP-6990是從EIP-6601改編而來的提案，旨在不依賴EOF向EVM引入優化的模塊化算術運算。雖然EIP-6601需要EIP-4750和EIP-3670作為依賴項，但EIP-6990提供了一個更獨立的解決方案。它通過消除對EOF的依賴提供了一種更簡化的方法。
意義：它保留了EIP-6601的核心功能，可以對高達4096位的奇數模數進行優化的模塊化算術運算，這種簡化允許更有效的實施和採用，同時仍然提供與EIP-6601相關的好處。
EOFchanges：
簡介：EOF是對EVM的升級，引入了新的合約標準和一些新的操作碼，傳統的EVM字節碼（bytecode）是非結構化的指令序列（unstructuredsequence of instructions）字節碼。EOF引入了容器（container）的概念，它實現了結構化的字節碼。容器由一個header和幾個section組成，來實現字節碼的結構化。升級後EVM將可以進行版本控制，並且同時運行多套合約規則。
EIP663：
簡介：無限制的SWAP和DUP指令
意義：通過引入了兩個新指令：SWAPN和DUPN，它們與SWAP和DUP的區別在於堆棧深度從16個元素增加到256個元素
EIP3540：
簡介：
從前鏈上部署的EVM字節碼都是沒有一種預先定義的同一結構的，代碼只有在客戶端中被運行前才會被驗證，這既是一種間接成本，也會阻礙開發者引入新功能或棄用老功能。
此EIP為EVM引入一種可以拓展和版本控制的container，並且聲明了EOF合約的格式，以此為基礎就可以實現在部署EOF合約的時候對代碼進行驗證，即creationtime validation，意味著可以防止不符合EOF格式的合約被部署，這種改動實現了EOF版本控制，會有助於未來停用EVM已有的指令或者引入大型功能（如帳戶抽象）
意義：
版本控制有利於以後實現引入或棄用新功能（例如引入帳號抽象）；
合約代碼和數據的分離對於L2的驗證(op)有益，減少L2驗證器的gas成本，同時合約代碼和數據的分離也更加方便鏈上數據分析工具的工作。
EIP3670：
簡介：基於EIP-3540，目的是確保EOF合約的代碼是符合格式有效的，對於不符合格式的合約會阻止其部署，不會影響Legacybytecode。
意義：在由3540引入的container基礎上，EIP-3670確保EOF合約中的代碼是有效的，或者防止它被部署。這意味著未定義的操作碼不能被部署在EOF合約中，這有一個額外的好處，即減少所需增加的EOF版本數量。
EIP4200：
簡介：
引入了第一個EOF專用的opcode：RJUMP、RJUMPI和RJUMPV，它們encodedestinations as signed immediate values。編譯器可以使用這些新的JUMP操作碼來優化部署和執行JUMP時的gas成本，因為它們消除了現有JUMP和JUMPI操作碼在做jumpdestanalysis 時所需的運行時間。這個EIP是對dynamicjump 的補充。
和傳統的JUMP操作比，區別在於RJUMP等操作不是指定一個具體的offset位置，而是指定一個相對的offset位置（從dynamicjumps -> static jumps），因為很多時候staticjumps 就夠了。
意義：優化網路和降低成本。
EIP4750：
將4200的功能更進一步：通過引入CALLFand RETF兩個新的opcode，為無法用RJUMP、RJUMPI和RJUMPV代替的情況實現了替代方案，以此實現了在EOF合約中再也不需要JUMPDEST了，也就因此禁止了dynamicjump。
意義：優化代碼，方式是通過將代碼劃分為幾個部分來實現的。
EIP5450：
背景：背景仍然是以太坊的合約現在在部署的時候是不檢查的，只有在運行的時候才會進行一系列的檢查，棧有沒有溢出（上限1024），gas夠不夠之類的。
內容：為EOF合約添加了另一個有效性檢查，這次是圍繞堆棧（stack）。這個EIP可防止EOF合約部署可能導致堆棧下溢或溢出的情況（stackunderflows / overflows）。這樣，客戶端可以減少他們在執行EOF合約期間進行的有效性檢查的數量。
意義：一大改進就是讓這些執行的時候才發生的檢查盡可能的少，更多的檢查都在合約部署的時候就發生。
5月26日開發者會議更新後，與EIP4844有關的交易類型從SSZ到RLP的變化意味著不再需要坎昆的兩個SSZEIPs，因此EIPs6475和6493被移出坎昆升級
EIP6475X
簡介：EIP4844 的配套提案。Proto-danksharding引入一個使用SSZ編碼的新交易類型，而不是其他交易類型所使用的RLP編碼方式。
更新：在第161次以太坊執行層核心開發者會議中，關於EIP4844 的SSZ序列化格式的討論顯示，最初開發者傾向於通過blob事務向EL引入SSZ格式的早期迭代，最終開發者計劃將所有交易類型從RLP升級至SSZ，但鑑於其路徑不明確且肯定無法在坎昆升級上實施，開發者一直在權衡從EIP-4844中刪除SSZ。經過多次討論，開發者同意將SSZ從EIP-4844的EL實現中移除，但目前並未對EIP6475做出移除的行為。5月26日更新後，SSZ->RLP 的變化將意味著不再需要坎昆的兩個SSZEIPs: 因此EIPs6475和6493將被移出坎昆升級。
EIP6493X
簡介：SSZ交易簽名方案。該EIP為簡單序列化(SSZ)編碼交易定義了簽名方案，將解決節點應如何處理在CL上以SSZ格式進行格式化但在EL上編碼不同的blob交易類型。這個EIP是更新以太坊序列化格式以實現跨層一致性內容的一部分；
- 背景：SSZchanges
- 簡介：SimpleSerialiZe，是信標鏈上使用的序列化方法。
SSZchanges還包括另外三種配套提案，此次只引入了6465.
EIP6465：SSZ取款根，定義了現有Merkle-PatriciaTrie (MPT) 承諾向簡單序列化(SSZ)提款的遷移過程；
EIP6404/ EIP6466：
二者均定義了一個將現有的Merkle-PatriciaTrie (MPT) 承諾遷移到簡單序列化(SSZ)的過程。
EIP-6404— SSZ 交易根
EIP-6466— SSZ 收據根
TimBeiko 在5月26日的核心開發者會議中建議未來圍繞擴大坎昆範圍的對話僅限於以下五個EIP：EIP5920、5656、7069、4788和2537，後續提案將在此範圍中產生。後續EIP5656和EIP4788被確認為正式升級的提案，5920、7069和2537被移出，其中EIP5920 是由於開發者擔心轉移ETH的方式可能存在的潛在副作用，以及暫未完成的推理、測試和安全工作，所以從升級中移除。
EIP5920：X
簡介：支付操作碼。引入新的操作碼PAY用於以太坊傳輸，無需調用其任何函數即可將以太幣發送到地址。
原因：目前，向一個地址發送以太需要用戶調用該地址的一個函數，這有幾個問題：
首先，它打開了一個重入攻擊的載體，因為接收者可以回調到發送者那裡；
其次，它打開了一個DoS向量，所以父函數必須認識到接收者可能會耗盡gas或回調；
最後，CALL操作碼對於簡單的以太傳輸來說是不必要的昂貴，因為它需要擴展內存和堆棧，加載接收者的全部數據，包括代碼和內存，最後需要執行一個調用，可能會做其他無意的操作。
更改：
引入了一個新的操作碼：(PAY)PAY_OPCODE，其中：
從堆棧中彈出兩個值：addrthenval。
將wei從執行地址轉移val到地址addr。如果addr是零地址，valwei則從執行地址燒錄。
潛在隱患：現有合約被使用時將不依賴於他們錢包的實際餘額，因為已經可以在不調用它的情況下將以太幣發送到一個地址。
意義：節省gas。
更新：23年6月9日，由於擔心轉移ETH的方式可能存在的潛在副作用，以及通過提案需要進行的推理、測試和安全工作，PAY從升級中移除。
EIP7069X
簡介：修改後的CALL指令
更改：引入三個新的調用指令，CALL2、DELEGATECALL2和STATICCALL2，具有簡化語義的作用。旨在從新指令中刪除gas可觀察性，並為不受重定價影響的新類別合約打開大門。
背景：
63/64th規則：限制call深度且確保調用者在被調用者返回後有剩餘的gas來進行狀態改變；
在引入第63/64條規則之前，需要稍微準確地計算呼叫方的可用gas。Solidity有一個複雜的規則，它試圖估計調用者一方執行調用本身的成本，以便設置一個合理的gas值。
目前引入63/64th規則：
刪除了call深度檢查；
確保在執行被調用行為之前，至少保留5000個gas；
確保至少有2300個gas可供被調用行為使用。
津貼規則：如知名的2300津貼，當一個合約調用另一個合約時，被調用的合約會得到2300gas 用於執行非常有限的操作（足夠做一點計算和生成一條日誌，但不夠寫滿一個存儲槽） ，由於它設置的是固定的gas數量，因此只要gas價格可以調整，人們就沒有辦法確定這些gas到底能支持什麼類型的計算。
意義：為未來引入EOF鋪路，同時更加便捷大型合約的運行。
移除gas可選性：新指令不允許指定gaslimit，而是依賴“63/64th規則”（主要指EIP-150中用於大量IO操作的Gas重定價，提高了特定操作的Gas消耗量）來限制gas，這個重要的改進是簡化了圍繞“津貼”的規則，無論是否發送該value，調用者都不需要執行有關gas的計算；
引入新提案後，用戶始終可以通過在交易中發送更多gas（當然，會受區塊gas限制）來克服Outof Gas 錯誤。
以前在提高存儲成本時(如EIP-1884增加某些操作碼的gas)一些只向他們的調用發送有限數量的gas的合約被新的成本核算機制所打破。之前一些合約有一個gas上限，永久地限制了他們可以花費的氣體數量，哪怕他們將其發送到他們的子調用中也無法解決，無論多少額外的gas都不能解決，因為call會限制發送的數量。
為引入EOF鋪路：一旦引入EVM對象格式(EOF)，就可以在EOF合約中拒絕舊的調用指令，確保它們基本上不受gas價格變化的影響。由於這些操作是消除氣體可觀察性所必需的，因此EOF將需要它們來代替現有指令；
更加便利的狀態返回碼：引入了返回更詳細狀態代碼的便利功能：成功(0)、還原(1)、失敗(2)，且在未來可擴展。
EIP2537：X
簡介：BLS12-381曲線操作的預編譯。
改變：將BLS12-381曲線上的操作作為預編譯添加到有效執行BLS簽名驗證和執行SNARKs驗證等操作所必需的集合中。
意義：以太坊可以創建更安全的密碼證明，並允許與信標鏈更好的互操作性。
PR3175 曾被提及過，但未曾放入候選名單中，後續無討論
PR3175：X
簡介：該提案將防止被懲罰的驗證者在退出隊列時提出區塊。如果有超過50％的驗證者因惡意行為而被懲罰，在被強制從網路中驅逐的同時，這些驗證者仍然能夠提出區塊。開發者表示，更改此邏輯是一個相對較小的CL層更改，可以提供對“高故障模式”的保護。
根據5月4日的第108次以太坊核心開發者共識會議，PR3175 處在格式化為EIP的過程中，將改為EIP-6987，即出於安全考慮，防止罰沒（slashed）驗證節點被選為區塊提議者。
未來
基於以上訊息，我們得到了以下結論：
1.坎昆升級的主要目標按照優先級排序為，擴容，安全，省gas和互操作性：
擴容毫無疑問，是第一優先級（4844）；
安全和省gas為第二要義（6780、1153、5656和7045），同時兼顧一定的開發者體驗；
第三為互操作性，如優化dapp之間的聯結、通訊和互操作性（4788、7044和6988）；
預期數據：測試網4844可降低opsiderollup 的50%成本；EigenLayer和Celestia的技術方案沒有披露太多，無法評估其數據；Ethstorage預估DA成本降至原先的5%；Topia預期降低100~1000倍成本。
2.坎昆升級到Danksharding的未來2~5年，是DA層項目的黃金發展期
Layer2 的安全上限取決於其採用的DA層，Proto-Danksharding通過更便宜的狀態數據存儲，將利好存儲協議、模塊化協議和L1存儲擴展網路。
首先，Danksharding回歸到以太坊狀態機的本質。V神提到，以太坊共識協議的目的不是保證所有歷史數據的永久存儲。相反，目的是提供一個高度安全的實時公告板，並為其他去中心化協議留出空間進行更長期的存儲（Thepurpose of the Ethereum consensus protocol is not to guaranteestorage of all historical data forever. Rather, the purpose is toprovide a highly secure real-time bulletin board, and leave room forother decentralized protocols to do longer-term storage. ）；
其次，Danksharding降低了DA成本，但實際落地時間和數據可用性問題也需要解決。
DA成本降低：在此次更新之前，將數據從rollup發佈到以太坊主鏈需要調用calldata，而調用此代碼的gas費非常昂貴，是layer2 中最大的一筆支出，EIP4844 通過引入數據blob，作為rollups獨有的額外數據空間，將大大減少存儲成本，進而使DA成本降低。
實際落地時間長，且能夠提升的TPS和降低的gas仍有限，所以利好DA層項目在後續的持續發展：
在polynya有關danksharding的Variablesecurity data sharding 文章中，表明其落地需要2-5年；
即使落地，其能夠提高的TPS和降低的gas量級仍有限：
EIP4844 目前支持6個Blob，未來擴容問題依靠Danksharding才能解決；
當前以太坊區塊空間大概是200KB。到了Danksharding之後，在規範中計劃的大小是32兆，約為是100倍的提升。目前以太坊的TPS為15左右，理想化狀態下提升100倍後為1500左右，量級上並非有很大提升。
因此，落地時間長+實際改變有限將利好DA層項目，一些如Celestia、Eigenda的DA項目仍可以在後續通過更便宜的成本和更快的TPS與Danksharding競爭，ETHstoragetopia 等新DA項目也能填補落地前的市場空白。
技術問題，如數據存儲和數據可用性問題也需要解決：
DA主要的成本有兩個，一個是網路帶寬的成本，另一個是存儲成本，而4844本身並不解決存儲問題和區塊上鏈的帶寬問題
blob會在以太坊共識層上存儲約3週後被刪除，若想達成存儲完整歷史記錄和全部數據可用，目前的解決方案有：dapp自身存儲與自己相關的數據、以太坊門戶網路（目前正在開發中）或區塊瀏覽器等第三方協議進行存儲、在BitTorrent中存儲歷史數據或個人用戶的自發存儲。
因此，Proto-Danksharding將利好存儲協議、模塊化協議和L1存儲擴展網路：
對於歷史數據的調用需求使去中心化存儲協議或第三方索引協議等將會多一條新的發展渠道；
後續模塊化協議可以通過高速的Rollup執行交易，安全的結算層負責結算，低費用大容量的數據可用性層用負責保障；
利好L1存儲擴展網路，如Ethstorage，其能以更低的存儲成本提供可編程存儲的二層解決方案。
3.坎昆升級利好L2多樣性、L3、RAAS和數據可用性等賽道
L2賽道分析：
頭部Layer2，如ArbitrumOrbit、OPStack、Polygon2.0、FractalScaling（StarkWare旗下）和HyperChain（zkSync旗下）等5個項目會受益。blob帶來的存儲減費會使之前一系列限制layer2 發展的成本和可拓展性問題得到大幅改善，大大增強數據吞吐量，解決費用問題後，頭部layer2 將有機會繼續部署針對特定功能、高度自定義化的多鏈並發的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的出現，新項目能否構成一個賽道我們是要打一個問號的。
首先，頭部layer2 應用鏈的部署優勢在於網路框架的完整度和鏈間生態的安全性，RAAS的優勢在於其訂製性和自由度；
但是目前OP和ZK系的RAAS技術壁壘不強，且短期內仍處於測試網階段，無實際產品交互，考慮到RAAS的實際進展、技術形式和未來layer3的生態優勢，RAAS的實際需求存疑。
OP系：雖然OP stack 的bedrock升級+4844 上線從成本和效率上帶來了一定的⼩幅提升，但是該提升帶來的吸引力不強；
ZK系：目前龍頭項目走ZKEVM路線的較多，更加在意與以太坊的兼容性，所以電路設計就會犧牲一定的效率，在針對性上不如OP系。但是目前市面上的ZKRAAS 大多依舊是使用龍頭項目（如ZkSync）去Fork鏈，壁壘仍不強。
所以，短期內OPRAAS 在layer3落地前仍有一定的發展空間，長期看來ZKRAAS 和layer3可能是未來趨勢。
ZKRAAS 在4844後的成本劣勢更大，其消耗的算力比OP要大很多，雖然其上傳到L1的成本相較於OP更少，但這相比於證明過程的花費僅僅是杯水車薪，而OP就優勢在於能在短期內快速搭建生態，在layer3落地前仍有一定的發展空間；
對於常規defi應用，NFT市場，轉型rollup並非是一個硬性需求，僅對效率要求高的支付應用或遊戲才對rollup有更強的需求。未來可能defi類項目會在l2，social類可能日常行為在l3或者鏈下，最後核心數據和關係放在l2上，gaming類的項目有需求去l3或rollup，但考慮到目前鏈遊大多實質為資金盤，且代幣無法對外流通帶來了發展瓶頸，加上全鏈上游戲的萌發，l3本身的生態吸引力要遠遠大於rollup。
4.坎昆升級改善了開發者和用戶體驗
坎昆升級第二個重要提案SELFDESTRUCTremoval 將進一步提高以太坊安全性，同時對於刪除後可能存在的程式性帳戶更新問題，準備引入新操作碼SETCODE來改善此類情況；
坎昆升級的第三個提案EIP1153 增加了瞬態存儲操作碼，首先可以節省gas，其次能解決幀間通訊問題，最後為未來的存儲設計鋪路，如Verkle樹將不需要考慮瞬時存儲的退款問題；
坎昆升級的第四個提案EIP5656 引入了MCOPY內存複製指令，可以更精確地複製代碼詞句，將提高約10%的內存副本性能；
坎昆升級的第五個提案為EIP4788可以使以太坊網路中不同協議和應用程式之間的通訊更加高效和安全，也允許質押池、橋接和restaking協議有更多無需信任的設計；
坎昆升級最新（23年6月15日）提議加入的以CL為中心的EIP升級還有：EIP6988、EIP7044、EIP7045，分別在細節方面提升了以太坊的安全性和使用性，如改善質押者體驗和提升網路安全性等。
被刪除的提案中，SSZ->RLP 的轉變使兩個SSZEIP（EIP6475 和EIP6493）被移出坎昆升級；EOF相關提案在被從上海升級中移出後再次從坎昆升級中移除，目前考慮可能直接在後期的日常升級中實現；EVMMAX由於是一些與EOF實現相關的EIP子集，所以也和EOF一起被移出坎昆升級；考慮到轉移ETH的方式可能存在的潛在副作用，以及通過提案需要進行的推理、測試和安全工作，EIP5920從升級中移除。
5.與zkml和帳戶抽象的關係
對zkml影響不大
ZKML即零知識證明（ZeroKnowledge）和機器學習（MachineLearning）的結合；區塊鏈與ML模型的結合解決了機器學習的隱私保護及可驗證性問題：
隱私保護：輸入數據的保密，如使用大量個人訊息作為數據餵給機器進行訓練時，個人訊息的保密就是一大需求；或模型參數作為項目的核心競爭力，也需要進行加密來維持競爭壁壘。諸如此類的信任問題存在時，ML模型要想獲得更大規模的數據和應用就會存在阻礙。
可驗證性：零知識證明技術應用範圍廣泛，ZKP可以讓用戶無需驗證即可得知訊息正確性。且由於機器學習模型需要大量計算，而ML模型可以通過ZK-SNARK生成證明，減少證明大小，緩解ML的算力需求問題。
ZKML的存儲需求和DA關係不大：需要類似Spaceand Time 這種單獨的存儲結構，其核心技術是“SQL證明”新安全協議，簡單來說就是一個位於區塊鏈旁邊的數據倉庫，能讓開發者以簡單的SQL格式連接鏈上和鏈下數據並將結果直接加載到智能合約中；
ZK-SNARKs是ZKML中ZK的主要形式，能適配ML的鏈上算力需求，隨著密碼學的發展，尤其是遞歸的SNARK證明會利好ZKML在鏈上的落地：
ZK-SNARKs具有高度緊湊性的特點，使用ZK-SNARKs能讓證明者生成一個短證明，而驗證者無需交互，只需進行少量的計算即可驗證其有效性，這種僅需一次有證明者向驗證者交互的性質，使ZK-SNARKs在實際應用中具有高效性和實用性，更加適配ML的鏈上算力需求。
目前不可能進行鏈上訓練，鏈上僅能存儲鏈外計算的結果：
當前ML的問題更多在於算力需求無法滿足和算法限制（無法並行計算）導致的低性能，大模型ZK證明需要更高算力，鏈上無法支持，當下流行的ZK-SNARKs也僅支持小規模、較小計算量的ML零知識證明，即算力局限是影響ZKML區塊鏈應用發展的關鍵因素，鏈上僅能做到存儲鏈外計算的結果。
利好帳戶抽象
首先，坎昆升級能一定程度減少ZKrollup 證明的費用：
當前zkSync的交易費取決於3方面：
驗證者生成SNARK證明和進行驗證所消耗的固定資源成本，該部分成本較高；
驗證者將SNARK證明提交到以太坊主網時的gas費，這部分費用會因主網擁堵而相應增加；
用戶支付給驗證者的服務費用，包括交易確認、消息廣播等。
所以，若引入4844，主網擁堵導致的gas費增加問題將得到緩解，能一定程度減少ZKP證明的費用，雖然相較於生成證明的費用不多，但是考慮到目前ZK仍處於出初期，未來ZK係發展趨勢仍不容小覷。
其次，帳戶抽象將傳統的tx交易轉變為useroperation，再將useroperations用ECDSA打包成塊，對鏈上存儲佔用相比於之前更多，所以對於存儲的要求更高；
接著，帳戶抽象與ZKrollup 可以相輔相成：
目前帳戶抽象的問題一是GasFee 貴，由於步驟過多，且牽扯到智能合約，所以數據多，進而導致GasFee 貴，而ZKRollup 優勢就在於能減少數據；
帳戶抽象導致安全性難以保證：由於AA涉及多個合約，安全性是問題，但是未來L2逐步成型後，共識層將不再改動，智能合約會有更多用武之地，帳戶抽象的安全性也可得到保障，借助ZKrollup 的可信驗證，安全性將會有更大提升。
最後，考慮到AI技術的崛起，能幫助增強鏈上合約的安全性和優化鏈上交易或活動步驟：
AI與安全性：AI技術可以用於增強鏈上交易的安全性和隱私保護。例如Web3安全平台SeQure就利用AI檢測和防止惡意攻擊、欺詐行為和數據洩露，並提供實時監控和警報機制，確保鏈上交易的安全性和穩定性；
AI與鏈上活動優化：區塊鏈上的活動包括交易、合約執行和數據存儲等。通過AI的智能分析和預測能力，可以更好地優化鏈上活動，提高整體效率和性能。AI可以通過數據分析和模型訓練，幫助識別交易模式、檢測異常活動，並提供實時建議以優化區塊鏈網路的資源分配。
因此，坎昆升級將從存儲空間的擴大，到與ZKrollup 的相輔相成，再到與AI技術的結合，逐步利好帳戶抽象未來的發展。
6.回看以太坊路線圖，接下來是什麼
目前來看，Layer2還沒有類似於Solana的性能（在延遲和吞吐量方面），也沒有像Near這樣的分片性能，也沒有像Sui和Aptos這樣的並行執行性能，坎昆升級提升了以太坊作為領導者的領先地位；
坎昆升級之後，預估幾個重大的開發時間Fully-Danksharding（2~5年），MEV和PBS落地（1~3年），帳戶抽象（1~2年），ZK一切（3~6年），EOF和開發者體驗（看延期幾次？）。
TheScourge
目標：重點是解決MEV問題。
方案：通過「提議者構建者分離（PBS）」來達成應用層的MEV最小化，此時可能會對blob做出優化，並引入預確認服務或搶跑保護等。
PBS即出塊者和排序者分離。排序者只負責排序不管上鏈，出塊者不管交易，直接選排序者打好的包上鏈。這個流程會讓整個過程更加流程正義，緩解MEV問題，是MEV外部化的思路。
PBS目前完成度仍然很低，比較成熟的是外部MEV解決方案合作——flashbots的mevboost。
進階版的「EnshrinedProposer-Builder Separation（ePBS）」完成度更低週期更長，估計短期內無法見到落地，另外還有漸進版本的PEPC和OptimisticRelaying ，增強了PBS框架的靈活性和適應性
TheVerge
目標：利用Verkel樹取代Merkle，引入信任最小化的解決方案，使輕節點獲得與全節點一樣的安全保障，讓區塊驗證盡可能簡單和輕便。
同時，L1的ZK化明確地加入Verge路線圖之中ZK將是未來擴容和提速的大勢所趨；
方案：引入zk-SNARKs，代替舊的證明系統，包括基於SNARK的輕客戶端；共識狀態變化的SNARKs；EnshrinedRollups。
Verkle樹是一種專門針對狀態的Merkle樹的更有效的替代方法，它不需要提供每個姐妹節點（共享同一個父節點的節點）到所選節點的路徑，而只是提供路徑本身作為證明的一部分，Verkle證明的效率比Merkle證明高3倍。
EnshrinedRollup 是指在L1上擁有某種共識集成的Rollup，優點在於繼承了L1的共識，無需治理代幣來執行rollup升級，同時通過在鏈外進行計算並只將結果發佈到區塊鏈上，可以提升交易數量，不過實現的技術難度較大。未來這些rollup組合在一起，將能滿足未來幾十年區塊鏈生態系統中的大部分需求。
Thepurge
ThePurge指的是通過降低參與驗證網路的存儲要求來簡化協議的目標。這主要是通過對歷史和狀態的休眠和管理來實現的。歷史數據休眠（EIP-4444）允許客戶端修剪超過一年的歷史數據，並停止在P2P層面提供服務。
狀態休眠。當涉及到處理狀態增長時，有兩個主要目標：弱無狀態，指的是只使用狀態來建立區塊，但不驗證它的目標；狀態休眠，指刪除在規定時間內（1年）未被訪問的狀態。狀態休眠應該使節點需要存儲的狀態總共減少20-50GB。
在第五個階段Purge中，EIP4444 被明確寫入Roadmap，EIP-4444要求客戶端清除超過1年的數據，同時該階段還有一些EVM優化的工作，如簡化GAS的機制和EVM預編譯等；
TheSplurge
最後的第六階段Splurge中，EIP4337 也被提及，作為錢包生態的長期佈局提案，帳戶抽象未來將會進一步提高錢包易用性，包括使用穩定幣支付gas、社交恢復錢包等；
加密貨幣屬於高風險投資，本網站內容均不構成任何投資建議與責任。
掌握虛擬貨幣、區塊鏈大小事
