從 0 到 1：瞭解以太坊上海升級

上海升級的主要內容是開放質押提款和 EOF，不包含 EIP-4844。

撰文：Shiqi

TL;DR

  • 上海升級的主要內容是 Withdrawal 和 EOF，EIP-4844 不會包含在上海升級
  • Withdrawal
  • 提款無需主動發起，是全自動實現的，每天可以為 115,200 個 Validators 執行取款
  • 有「部分提款」和「全部提款」兩種規則，分別對應不同的條件，大部分提款都將會是「部分提款」
  • 「部分提款」提取的是 Validators 的收益部分，由於長達兩年的質押，信標鏈上已經累計了不少收益，因此在解鎖剛開的前四天，解鎖量最大；「全部提款」則是收益 + 質押的 32 ETH 同時取走
  • 理想狀態下，預計升級後第一天解鎖 400k ETH 左右，第二天 300K 左右，第三天 180K 左右，第四天 60K 左右，前四天解鎖量大部分來源都是「部分提款」，從第五天開始由於所有的 Validators 基本都經歷過了一次提款，大部分節點的收益已經提取完了，因此第五天開始提款的主要來源將「全部提款」，這個數字會間接受到流動限制係數的限制
  • 準確來說，流動限制係數限制的不是每天能處理的「全部提款」數量，而是每天能達成「全部提款」條件的數量，也就是說即如果在上海升級之前，有大量的 Validator 滿足了「全部提款」的規則，那仍然有可能發生遠超預期的大量 ETH 解除質押的情況
  • EOF
  • EOF 是對 EVM 的升級，引入了新的合約標準和一些新的操作碼，升級後 EVM 將可以進行版本控制，並且同時運行多套合約規則
  • 有了 EOF 後，EVM 來說在進行迭代的時候，就不再受限於向前兼容的需求，升級難度變低了可能會導致未來以太坊 EVM 的升級可能更頻繁
  •  EVM 迭代頻繁可能會導致對 EVM 兼容的虛擬機有更高的要求，如 zkEVM，要想保持始終能跟上版本，可能需要其他 EVM 兼容的 VM 有自動轉化 EOF 更新到自己的 VM 的能力

瞭解以太坊上海升級

什麼是上海升級

上海升級是以太坊執行層的下一次硬分叉，此前已經經歷了君士坦丁堡升級、伊斯坦布爾升級、柏林升級、倫敦升級、巴黎升級（Merge），每次升級都意味著以太坊有了一些重大的更新，比如 EIP-1559 改變了礦工的收入結構，Merge 改變了以太坊的運行機制等等。

Beacon 鏈（信標鏈）—— 長達兩年的共識層練習生

2020 年 12 月以太坊引入了 Beacon 鏈，從此以太坊從執行層和共識層由一條鏈負責，開始向執行層共識層由兩條平行的鏈分開負責的方向轉變，也是從 PoW 向 PoS 轉變。

轉變後，共識層由 Beacon 鏈負責，執行層由曾經的以太坊主網負責，也就是大家平時和以太坊上的用戶交互會用到的那一個，Beacon 鏈和主網在合併前，只能通過執行層上的 Deposit Contract 進行通信，簡而言之就是用戶在執行層的 Deposit Contract 上面存入 ETH，就把 ETH 存入了信標鏈，但是從此信標鏈上的 ETH 沒有辦法回到執行層，Deposit Contract 裡的 ETH 也無法取出。

注：Deposit contract，簡而言之 Deposit Contract 是一個部署在 ETH 主網上的智能合約，它會接受任何包含至少 1 ETH 和一個有效 input data 的交易，信標鏈上的節點則會監聽這個合約，並且使用監聽到的交易中的輸入數據來在信標鏈建立相對應的 Validator。

但是 Beacon 鏈並不是一上線就出道的，它經過了長達兩年的共識練習生階段，直到 2022 年 9 月才正式和以太坊主網完成合並。中間 Beacon 鏈經過了多次升級，從最初的 Phase 0，到 Altair upgrade，再到 Bellatrix（又稱 The Merge），終於順利出道，從此 Beacon 鏈和以太坊主網合二為一共同組成一個新的 Ethereum，二者通過 Engine API 進行通信。

在 Beacon 鏈長達兩年的共識練習生的過程中，積累了許多 ETH 在 Beacon 鏈上，至今仍然無法被取出，而用戶平時在以太坊網絡上進行操作的時候，用的都是自己在執行層上的 ETH 餘額。因此信標鏈 ETH 的提款功能必須被實現，就等來了本次 Shanghai Upgrade（上海升級）。

事實上，上海升級指的是執行層的升級，而除了上海升級外，同時進行的還有共識層信標鏈的升級，叫做 Capella 升級，Beacon 鏈上的 ETH 提款到執行層上的功能，是由上海升級和 Capella 升級共同完成的。

上海升級的重點

上海升級的首要目標是實現信標鏈的取款功能。除了信標鏈取款外，EOF（EVM Object Format） 同樣也是一個重大升級，但是恰恰由於他重大所以會需要更多的測試時間，為了不拖延信標鏈取款功能的實現，EOF 的升級可能會推遲，主要取決於他的進度。

EIP-4844 是另一個備受關注的重要升級，由於他對於以太坊意義十分重大且同樣可能推遲信標鏈取款功能的實現，因此 EIP-4844 已經確認會放在下一次的 Cancun Upgrade 中（Shanghai Upgrade 的下一次）。

上海升級的進度

預計 2023 年 1 月進行影子分叉，3 月進行上海升級硬分叉，本次升級實際除了執行層的 Shanghai Upgrade 外，還會進行共識層的 Capella Upgrade，執行層和共識層的共同升級來完成信標鏈的取款功能，除了信標鏈上質押的 ETH 取款功能外，同時還會實現 EOF 以及一些其他的小升級，預期共計實現 9 個 EIP。另一方面根據 2023 年 1 月 5 日舉辦的下一次 All Core Developers 會議，會決定是否推遲 EOP 的實現到 2023 年秋季，以免影響取款功能實現的進度。同時備受期待的 EIP-4844 將於 2023 年秋季執行。

注：影子分叉，簡單來說，影子分叉就是一種壓力測試的方法，用主網的數據，在小範圍的節點內進行測試。通過運行少量 config 更新了的節點來對以太坊網絡進行分叉得到影子分叉的網絡，這樣影子分叉可以繼承原來網絡的狀態和歷史，同時又不影響原來網絡中的大部分節點的狀態，也就不會影響分叉前網絡的運行。這樣做的好處是，主網的數據量和交易都是最複雜的，可以幫助節點模擬真實的情況。

升級的具體內容

提款

可能涉及的概念

首先要了解提款，大致需要對什麼是 Validator，什麼是 ETH 2.0，The Merge 發生了什麼有一個模糊的概念，如果下面提到的這些概念很熟悉可以跳過。

如果沒有概念的話，也可以閱讀 Ethereum 2.0 Knowledge base，也可以對現狀做一個這樣的簡單理解：Ethereum 現在分為共識層和執行層，共識層有一堆稱之為 Validators 的打工仔，他們在共識層（信標鏈）質押了 32 ETH 作為他們作為他們打工幹活的擔保，靠這個擔保，Validators 可以為 Ethereum 出工出力同時互相監督，以此來換取一些收益，目前這些用於擔保和收益的資金，Validators 都是取不出來的。

Validator 的職責

Validator 職責主要有三個：

（1）Propose block，繼承了之前礦工的職責，但是目前大部分的 Validator 都選擇了安裝 mev-boost，來間接實現 Proposer builder separation，如果想了解更多關於 MEV 和 MEV-boost 的事情，可以閱讀 A&T View：以太坊質押可提取價值中的投資機會

（2）Sign Attestation，指 Validator 投票來確認其他 Validator propose 的 block 的有效性，Attestation 每個 Epoch 進行一次，是職責 1 的補充

（3）監控其他 Validators 有沒有 Slashable offenses（監控有沒有違規行為），常見的違規行為有 Attestaion Violation

Slot 和 Epoch

可以把 Slot 和 Epoch 理解成一種時間的單位，它代表了一個時間區間，一個窗口期，他們對應了一段時間的長度，12s / slot，32 Slots = 1 Epoch，6.4mins / Epoch，因此每 12s 一個 slot，每 6.4 分鐘一個 Epoch，而每天又有 225 個 Epoch。

Slot 和 Epoch 在理解提款時有重大作用，因為 Validators 是以 Slot 或者 Epoch 為單位活動的，也正因為此，提款也是以 Slot 或者 Epoch 來統計的。

圖片來自：https://eth2book.info/altair/part2/building_blocks/aggregator

通常每個 Slot 會有一個 Validators 被隨機選中，這個 Validator 可以 propose 一個 block（一個 Slot 只會有一個有效的 block，但是每個 Slot 裡並不是一定有 block，比如被選中在這個 slot propose block 的 validator 離線了）。同時所有的 Validators 會被分成許多個委員會（committees），每個委員會里至少 128 個至多 2048 個 Validators，這些委員會會獨立負責 attest 每一個 slot，attest 時會從每個委員會中隨機選擇一些 Validators 作為 Aggregator，每個委員會中 Aggregators 數量目前是 16，Aggregators 負責聚合 Validators 的 Attestation 投票並廣播給下一個 block proposer。再每個 Epoch 之後，committees 會解散後重組。

Validator 的狀態

Validator 有幾種常見的狀態，根據狀態的不同，會滿足 Validator 不同的提款條件，所以要正確瞭解提款會怎麼發生，知道 Validator 的幾種主要狀態也是有必要的。顯然並不是所有的 Validator 都是 Active 狀態，而只有狀態為 Active 和 Withdrawable 的 Validator 滿足提款條件。

1. 存款

首先用於成為 Validator 的 32ETH 要先被存入主網的存款合約（Deposit Contract）中，並且這個狀態要保持 7 個小時左右才會進入 Pending 狀態，每個 Validator 創建成功後，都會有一個對應的編號（index），這個編號是單調遞增的，也就是說你越晚成為 Validator 你的 index 就越大

2. Pending

Validator 完成存款，就成了一個正式 Validator 預備軍，需要等待其他活躍（Active）狀態的 Validator 投票才能進入 Pending 狀態，這種投票每 4 個小時進行一次。

進入 Pending 狀態後，Validator 會進入一個隊列等待被徹底激活，每個 Epoch 能激活的 Validators 數量受到「流失限制係數（CHURN_LIMIT_QUOTIENT）」的限制，計算方式是

max(MIN_PER_EPOCH_CHURN_LIMIT, n // CHURN_LIMIT_QUOTIENT)

其中 MIN_PER_EPOCH_CHURN_LIMIT= 4，n 是 active validators 的數量，CHURN_LIMIT_QUOTIENT = 65536。

因此以 2022 年 12 月 29 日的數據為例，目前網絡中有 492,975 個 Active Validators，那麼目前每個 Epoch 能激活的新 Validators 數量是 7 個，以一天 225 個 Epoch 計算，每天能激活的新增 Validators 數量是 1575 個。

3. Active

Active 狀態的 Validator 可以參與 Attestation 和 propose block（開始打工），直到 Validator 的餘額降低到 16ETH 以下，自願退出或被 Slashed 為止。

如果有 Validators 錯過了 Block Proposed 或者參與 Attestation，這個狀態就叫離線（曠工了），如果至少 2 個 Epoch 沒有參與 Attestation，Validator 就會被扣錢，通常來說一個 Validator 至少要有 50% 的時間在線才能獲得正收益。但是離線狀態的 Validator 仍然保持 Active 狀態，只有遭到了 Slash（被發現違紀），才會被強制退出網絡，並且至少沒收餘額的 1/32

4. Exit & Withdrawable

非活躍狀態的 Validator 都會被強制離開網絡（Exit）並且無法重新加入，同時另一方面，Validator 離開網絡的速度也是被嚴格限制的。事實上，在 Pending 部分提過的 Validator 激活速度的限制其實也是對整個網絡驗證者離開的限制。這個限制的目的是為了防止驗證者（Validator）的數量變化太快引起的對網絡的不穩定。同時另一方面，對於退出網絡的 Validator （Exit 狀態）也需要大約 27 個小時才能提款（Exit -> Withdrawable），同時對於因為違規被懲罰而強制退出的 Validator 來說，還需要額外 36 天才能變為 Withdrawable 狀態。目前信標鏈上主動退出的 Validators 有 867 個，被 Slashed 而退出的 Validator 有 223 個，他們目前全都是 Withdrawable 的狀態。想要主動退出網絡可以參考 Exit your validator | Prysm

Validators 數量和以太坊發行量以及 APR 的關係

詳細可見：Upgrading Ethereum

N 是驗證者的數量，225 是每天能運行的 Epoch 數量

圖源

APR 和 N 的增長是一種負相關關係，這麼設計有幾個原因，首先是保證 APR 是一個和 N 相關的函數，這樣可以避免理性的驗證者在成本明顯高於收益時果斷退出，同時可以避免支出過高的成本來保證安全性。

另一方面，讓 APR 和 N 是一種負相關關係會激勵 Validators 去審查其他人的工作成果，來想辦法讓那些有不正當行為的 Validators 被從網絡中趕出去。

圖源

0x01 Credential 和 0x00 Credential

0x01 和 0x00 都是一種存款時 Validator 收到的證明，對於提款這件事來說，只需要知道只有持有 0x01 Credential 的 Validators 才可以順利提款，因為 0x01 包含了這個 Validators 收益的目標地址，而目前絕大部分的 Validators 持有的都是 0x00 Credential，因此對他們來說需要在上海升級後升級到 0x01 Credential，具體想了解怎麼升級到 0x01 Credential 可以看 [Tim 的推特](https://twitter.com/TimBeiko/status/1600939567523037184)。這種轉變是由於提款方案的變化。

現在信標鏈有多少 Validators 和 ETH？

根據 Beaconcha.in 的數據，截止 12 月 29 日，Beacon 鏈上上有效質押的 ETH 為 15,775,062 ETH（這個數據統計的是用於計算 Stake 收益和懲罰的 ETH 數量），活躍（Active）的驗證者數量為 492,975，總共有 494,096 個驗證者，當前每個驗證者平均質押的 ETH 為 33.93 ETH（也就是說 Beacon 鏈上 ETH 的總數為 16,764,677 ETH）。目前質押獲取收益最高的 Validator 地址上有 36.9690 ETH，質押時間超過 700 天。

Withdrawal 會如何實現

Withdrawal 會由執行層和共識層共同升級實現，執行層主要是通過引入 EIP-4895 協助共識層執行提款的過程。具體來說，EIP-4895 是基於「Push」的思路架構而非「Pull」的思路完成提款，即用戶無需主動發起提款請求，而是會根據 Validators 在信標鏈中的狀態產生一個對應「收據」，這個收據包含了完成提款所需要的細節，收據們會進入一個取款隊列，每個區塊打包的時候會執行一部分的收據，而且在固定時間內能執行的取款請求數量是被嚴格限制的。

注：1）這些取款請求將是一種「系統級」的操作類型，不會獨立進行也不會進入用戶正常交易的 mempool 中，換言之，提款會在交易結束後進行，因此不會和用戶去競爭區塊空間。只有當執行客戶端通過 Engine API 進行同步時，才會進入到執行區塊中。因此提款行為不會提高以太坊的 gas 或者讓以太坊更擁堵

 2）Payload 用於告訴合約用戶想要調用的函數及這個函數用到的參數的值。System-level operation 意味著將會定義一種新的 payload object `withdrawal` 來將提款行為和用戶正常的 Transaction 行為區分開來，而不是將提款定義為一種新的 Transactions 類型，這種方法雖然更復雜但是實現起來更易於測試也更安全。更多關於 Payload 可以看

 What-is-the-use-of-the-payload-field-in-the-ethereum-transaction-reciept
 Understanding-data-payloads-in-ethereum-transactions
  
3）Capella Upgrade 的內容
     
Capella is a consensus-layer upgrade containing a number of features related to validator withdrawals. Including:

Automatic withdrawals of `withdrawable` validators.
Partial withdrawals sweep for validators with 0x01 withdrawal credentials and balances in excess of `MAX_EFFECTIVE_BALANCE`（32ETH）.
Operation to change from `BLS_WITHDRAWAL_PREFIX`（0x00） to `ETH1_ADDRESS_WITHDRAWAL_PREFIX`（0x01） versioned withdrawal credentials to enable withdrawals for a validator.

Withdrawal 的條件

Withdrawal 分兩種。「部分提款（Partial Withdrawal）」和「全部提款（Fully Withdrawal）」，對應不同的條件，部分取款和完全取款不會有優先級上的區別，因為提款是全自動進行的，也就是說只需要滿足必要條件然後等著就行了。

  • 必要條件：Validator 具備 0x01 Credential
  • 部分提款條件：Validator 是 Active 狀態，同時 Validator 的餘額大於 32ETH
  • 全部提款條件：Validator 是 Withdrawable 狀態（這通常意味著 Validator 已經退出網絡）

提款具體會如何進行

可以直接看 https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md#has_eth1_withdrawal_credential

Validator propose 區塊的時候，會按 Validator 的 index 去線性掃描所有 Validators，找到的前 16 個滿足 Withdrawal 條件的 Validators 會組成一個集合被包含在 ExecutionPayload 中，等待取款執行。

也就是說，每個 Epoch 會有 512 個 Validator 可以取款（因為一個 Epoch 有 32 個 Slot，而一個 Slot 一個區塊），一天有 115,200 個 Validators 會被執行取款（一個 Epoch 6.4 分鐘，一天大概有 225 個 Epoch），5 天之內所有 Validator 現有的所有 Validators 都會被遍歷一邊。

理想狀態下，如果這 115,200 個取款都是 Partial Withdrawal，那麼根據 index 從低到高，index 前 115,200 個 Validator 的可供提取的餘額在 3 - 4 ETH（根據 beaconcha 數據質押最早的 Validator 餘額大概是 36.3 ETH，第 115,200 個 Validators 的餘額大概是 35 ETH），以中間數 3.5 ETH 來計算，第一天因為取款功能解鎖的 ETH 大概是 403,200 個 ETH（115200 * 3.5）。同樣的計算方式，升級第二天大概解鎖 2.5 * 115,200 = 288,000 ETH，第三天大概解鎖 1.5*115200 = 172,800。第四天大概解鎖 0.5*115200 = 57,600 ETH，從第五天開始，已經有大部分 Validators 進行過提幣了，因此不會在產生像前幾天那麼大的拋壓。

注：ETH 開質押的時候是 2020 年 12 月，此時 ETH 的價格在 $1,000 左右，因此此後參與質押的 ETH 大部分和當下的價格相比都是虧損的。

圖片來自：Cryptorank

但是事實上，提款並不可能總是如預期那麼順利，總會有一些意外情況讓實際的提款金額高於或低於理想值。

  • 讓解鎖金額低於理想值的情況
  • 並不是所有 Validators 都是 0x01 Credential，也並不是所有 Active 的 Validators 都有 32 ETH。因此有一部的 Validators 是不滿足提款條件的（原因千奇百怪），這些不符合規則的 Validator 會在遍歷的時候被 Pass，由於這個 Pass 機制的存在，Validator 在遍歷（Sweep）的時候的時候是有上限的，這個上限是`MAX_VALIDATORS_PER_WITHDRAWALS_SWEEP` = 16384（2**14）
  • 讓解鎖金額高於理想值
  • 會有 Validators 選擇全部取款的選項。理論上如果前 115,200 個 Validators 全部選擇全部取款，那麼第一天的解鎖金額就是 3,686,400 ETH。但是想要全部提款的前提是退出網絡，而每天能退出網絡的 Validators 數量嚴格受到「流失限制係數」限制，目前每天能退出網絡的 Validators 數量上限是 1,575。

提款可能的影響

注：以下都只是個人做的時候想到的一些問題和自己的看法，不是投資建議

Q1：解鎖的 ETH 是否會在市場上大量拋售

很大概率不會，雖然在升級的前幾天，解鎖的 ETH 量很大，但是解鎖並不意味著會出售。這批解鎖 ETH 的質押者的成本以目前 ETH 的價格來說並不低，作為在不知道解鎖何時會發生就加入了 ETH 質押的用戶來說，相信大部分都是 long ETH 的（沒有證據純猜測），沒有足夠獲利的情況下個人認為並不會選擇出售 ETH 反而可能會選擇再質押。同時由於開放提款後，質押 ETH 有了更明確的解鎖時間和解鎖期限，也就意味著更低的風險，相信也會吸引更多的用戶參與質押。

Q2：會對流動性質押服務產生什麼樣的影響

在此處以 Lido 為例，進行一個猜測。

根據提款的流程，大部分的提款都將會是通過「部分提款」的方式，也就是說對於流動性質押服務商來說，實際能解鎖的 ETH 只有平臺運行的 Validator 的利潤部分，除非平臺主動去讓 Validator 進行退出來，然而顯然從各種角度來說，平臺都沒有動力這麼做。

那麼會導致一個極端情況出現，就是如果 stETH 在解除質押後可以立即 1:1 兌換成 ETH，那麼一旦大量 stETH 的持有人去申請兌換，且這個總量超過了當時 Lido 通過 ETH 提款得到的 ETH 的總量的時候，就會發生 stETH 沒有 ETH 可以兌換的情況（因為實際上還鎖著呢），所以即使開放解鎖後，stETH 和 ETH 的 1:1 兌換仍然會需要一段緩衝期，讓平臺有時間去解除 Validator 的質押，也正因為這個時間差的存在，stETH 為代表的質押衍生品在上海升級後，將仍然會以一個略低於 1:1 的匯率和 ETH 組池。

延遲提款有一個好處是，降低了擠兌造成的恐慌和風險。此外還有另一個潛在的好處，就是 Lido 遇到的困境所有流動性質押服務商都會遇到，因此 ETH 質押延遲取款將很有可能成為流動性質押服務商的一種通用模式。為什麼這是件好事呢？因為 stETH 的護城河之一是其良好的流動性和可組合性，但有一種擔憂是，在解除質押後，stETH 的流動性優勢由於質押衍生品都可以 1:1 兌換 ETH 而消失了，但是由於延遲取款的機制存在，stETH 將仍然保存他的流動性優勢。

想了解更多關於取款的事情，可以看下面幾個資料：

  • https://www.youtube.com/watch?v=CcL9RJBljUs
  • https://notes.ethereum.org/@ralexstokes/validator-withdrawals-meta-spec

EOF

可能涉及的概念

EVM

以太坊和比特幣最重要的區別之一就是加入了智能合約，而 EVM 可以被理解為運行智能合約的操作系統。推薦閱讀：https://noxx.substack.com/p/evm-deep-dives-the-path-to-shadowy?s=r

Byte code

通常開發者可以用名為 Solidity 的高級編程語言編寫智能合約，但是 Solidity 編寫出來的智能合約人類讀得懂計算機卻讀不懂，因此需要交由 EVM 解釋（interpret）成 EVM bytecode 再交由計算機運行，把人類能讀懂的高級語言（Solidity）變成只有計算機能讀懂的語言（bytecode）。

下圖中，上面這串不明所以的十六進制代碼就是 bytecode，他們有個明顯的特徵就是 0x 開頭的，0x 開頭會讓 EVM 把接下來的一連串當作十六進制來讀；下面是編譯前由 Solidity 所寫的合約代碼

圖片來自：Etherscan 隨便找了一筆交易截圖

opcode 操作碼

opcode a.k.a operation code，簡單來講 bytecode 通常就是一連串 opcode 與其輸入值。opcode 代表了 EVM 的一些相對可讀的操作指令，這些指令都有嚴格對應的十六進制代碼，如 `ADD` 對應 0x01。每個 opcode 都是要 gas 的。

圖片來自 https://ethervm.io/

Stack Machine

EVM 是一種 Stack Machine，採用 LIFO（Last in，First Out）的方式進行讀取，簡單理解就是 EVM 操作碼的輸入值都會進入棧裡，並且由按照棧。以太坊理論上最多有 256 個操作碼，每個操作碼都會將棧頂的元素出棧，將結果入棧。瞭解更多可以看深入簡出棧

Process flow operations

Process flow operations 主要是指以下幾個 opcode

圖片來自：https://ethereum.github.io/execution-specs/autoapi/ethereum/dao_fork/vm/instructions/control_flow/index.html

  • Stop：停止 EVM 代碼的運行
  • PC：程序計數器，用於指定當前讀取字節碼的字段，會確認字節碼下一個要執行的指令在哪裡，然後可以通過 JUMP 跳轉到需要執行的函數。
  • JUMP：改變下一個要執行的指令
  • JUMPI：有條件的 JUMP
  • JUMPDEST：JUMP 的目的地
  • offset：偏移量，用來表示每個指令的所在位置，以字節作為單位。位、字節、字是計算機數據存儲的單位。位是最小的存儲單位，每一個位存儲一個 1 位的二進制碼，一個字節由 8 位組成。而字通常為 16、32 或 64 個位組成。
  • 位（bit）是最基本的概念，在計算機中，由於只有邏輯 0 和邏輯 1 的存在，因此很多東西、動作、數字都要表示為一串二進制的字碼例如： 1001 0000 1101 等等。其中每一個邏輯 0 或者 1 便是一個位。
  • 字節（byte），是由八個位組成的一個單元，也就是 8 個 bit 組成 1 個 Byte。字節有什麼用呢？ 在計算機科學中，用於表示 ASCII 字符，便是運用字節來記錄表示字母和一些符號~例如字符 A 便用 「0100 0001」來表示。
  • 字（Word）代表計算機處理指令或數據的二進制數位數，是計算機進行數據存儲和數據處理的運算的單位。對於 32 位計算機與 64 位計算機，字的大小往往不同。

智能合約部署

要部署一個智能合約，只需發送一個包含編譯後的智能合約代碼的以太坊交易，而不需要指定任何收件人。目前由於以太坊是把編譯好的智能合約包含在交易中，沒有源代碼，因為以太坊執行智能合約的時候面對的是 bytecode，難以在運行前事先驗證智能合約的正確性。

EOF 是什麼

EOF 是對 EVM 的升級，引入了新的合約標準和一些新的操作碼，傳統的 EVM 字節碼（bytecode）是非結構化的指令序列（unstructured sequence of instructions）字節碼。EOF 引入了容器（container）的概念，它實現了結構化的字節碼。容器由一個 header 和幾個 section 組成，來實現字節碼的結構化。升級後 EVM 將可以進行版本控制，並且同時運行多套合約規則。本次 EOF 升級將由 5 個 EIP 共同組成來實現，分別是 EIP-3540, EIP-3670, EIP-4200, EIP-4750 和 EIP-5450。由於 EOF 是一個龐大的升級，因此為了保證 1 月能順利開啟提款，它可能會被推遲。

具體可以看 EVM Object Format（EOF）

EOF 的意義

簡而言之，EOF 是一套新的合約規則。目前在運行的 EVM 只能同時運行一套 interpretation 和 validation 的規則，這套規則會適用於所有現存的合約，稱之為 Legacy contracts。EOF 引入了一套新的合約規則，同時對 EVM 的 interpreter 進行了對應的升級。升級後就可以 EVM 就可以並行運行兩套合約規則，一套 EOF contracts，一套 Legacy contracts。

有了 EOF 後，EVM 來說在進行迭代的時候，就不再受限於向前兼容的需求，升級難度變低了可能會導致未來以太坊 EVM 的升級可能更頻繁。

EVM 迭代頻繁可能會導致對 EVM 兼容的虛擬機有更高的要求，如 zkEVM，要想保持始終能跟上版本，可能需要其他 EVM 兼容的 VM 有自動轉化 EOF 更新到自己的 VM 的能力。

具體每個 EIP 分別做了什麼

EIP-3540: EVM Object Format (EOF) v1

從前鏈上部署的 EVM 字節碼都是沒有一種預先定義的同一結構的，代碼只有在客戶端中被運行前才會被驗證，這既是一種間接成本，也會阻礙開發者引入新功能或棄用老功能。此 EIP 為 EVM 引入一種可以拓展和版本控制的 container，並且聲明瞭 EOF 合約的格式（如下圖），以此為基礎就可以實現在部署 EOF 合約的時候對代碼進行驗證，即 creation time validation，意味著可以防止不符合 EOF 格式的合約被部署，這種改動實現了 EOF 版本控制，會有助於未來停用 EVM 已有的指令或者引入大型功能（如賬戶抽象）

這個 EIP 提供的第一個 tangible feature 是對數據和代碼進行了區分，這種區分非常有助於 on-chain code validators，這會節省它們的 gas 消耗

EIP-3670: EOF - Code Validation

EIP-3670 基於 EIP-3540 ，目的是確保 EOF 合約的代碼是符合格式有效的，對於不符合格式的合約會阻止其部署，不會影響 Legacy bytecode。

EIP-4200: EOF - Static relative jumps

EIP-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 就夠了

EIP-4750: EOF - Functions

EIP-4750 將 4200 的功能更進一步：通過引入 `CALLF` and `RETF` 兩個新的 opcode 是，為無法用 RJUMP、RJUMPI 和 RJUMPV 代替的情況實現了替代方案，以此實現了在 EOF 合約中再也不需要 JUMPDEST 了，也就因此禁止了 dynamic jump。

EIP-5450: EOF - Stack Validation

EIP-5450 為 EOF 合約添加了另一個有效性檢查，這次是圍繞堆棧（stack）。這個 EIP 可防止 EOF 合約部署可能導致堆棧下溢或溢出的情況（stack underflows / overflows）。這樣，客戶端可以減少他們在執行 EOF 合約期間進行的有效性檢查的數量。

背景仍然是以太坊的合約現在在部署的時候是不檢查的，只有在運行的時候才會進行一系列的檢查，棧有沒有溢出（上限 1024），gas 夠不夠之類的。EOF 有一大改進就是讓這些執行的時候才發生的檢查儘可能的少，更多的檢查都在合約部署的時候就發生。

其他小升級

EIP-3651: Warm COINBASE

要理解 EIP-3651 首先要理解 EIP-2929，因為 EIP-3651 其實是解決一個 EIP-2929 造成的問題。

那麼什麼是 EIP-2929？

EIP-2929 全稱 State Assess Lists，簡單來說，EIP-2929 讓一些交易在第一次觸發的時候更貴了（根據 access storage 的類型不同 gas 費用不一樣），因為這些交易的地址訪問需要一個從 Cold 到 Warm 的過程，首次觸發後，這個地址會變為 Warm 狀態，Warm 狀態意味著後續訪問同一個地址的時候會更便宜，因此如果同一筆交易內對如果要執行同一個 Opcode 多次，那麼會比更便宜，而有些 accounts 是默認 warm 的。EIP-2929 當時默認了 sending address 和 receiving address 是 warm 的。其實 EIP-2929 並沒有降低平均的 gas 消耗，甚至略有增加（上升了 0.3% - 0.4%），因為 EIP-2929 的主要目的是為了提高 DoS 攻擊的成本，所以要提高 state access opcode 的 gas 消耗，同時為了平衡實際中用戶發起交易要用到的 Gas，就將一些使用頻率高的 account 默認 warm 了。

EIP-3651 則是要將 `COINBASE` address 也會默認 warm，`COINBASE` address a.k.a feeRecipient address。這個改動主要是為了解決 EIP-2929 導致 `COINBASE` 初始為「Cold」狀態導致涉及 COINBASE 地址的交易費用變貴的問題。具體的改動方式就是將 COINBASE 的地址加入到 EIP-2929 提出的 Access List Framework 中，讓`COINBASE` 的地址也默認是 Warm 狀態的，這樣和 COINBASE 地址交互就不會比 Access list 中其他地址交互消耗更多費用。

EIP-3651 帶來的影響是 MEV extractors, Block builders 和 Vailidators 會在涉及到 COINBASE 地址的交易中降低成本，因為 COINBASE 在 contional payments 中被大量 block builders 使用，根據 William Morriss 所說，EIP-3651 實施後，和 COINBASE Address 交互的大概費用會降低 26 倍，以前 State access includes accounts 大概需要 2600 gas，warm 後只需要 100。

注：什麼是 COINBASE Address

此處的 COINBASE 指的是 Block builders 用來在網絡中接受新 token 的 Software。Block builder 通常將交易從 mempool 中打包成區塊發送給 Validator 進行排序，並從中收取利潤。而在每一筆交易中都需要和 COINBASE Software 進行多次交互，而第一筆交互通常會比較貴，因為目前 COINBASE Address 需要 Warm up，然後交互費用會隨著交互數量上升慢慢下降，而 EIP-3651 可以讓 COINBASE 一開始就是 Warm up 的狀態，這樣會降低轉賬給 COINBASE 的費用

conditional payments：EIP-1559 使 conditional payments 成為了可能，大量 flashbots 使用了這個方法，即將 MaxPriorityFeePerGas 設為 0，這樣在交易失敗的時候就不會收取 Gas Fee。同時這些失敗的交易也具有良好的抗審查性，因為他們失敗了，block builder 沒有收取 Gas 也就不會將他們的信息保存。但是要使用 conditional payments 需要接入 COINBASE Account

EIP-3855: PUSH0 instruction

引入一種新的 opcode 來把 0 值 push 到 stack 裡。PUSH 0 是 EVM 中一種常見情況（有 11.5% 的 PUSH* 指令都用來 PUSH 0 值到 stack 裡了），這個 EIP 會提供一種更高效更便宜的方式來實現這一點（現在是通過 `PUSH1 0` 等方式），同時為所有需要把 0 值放入 Stack 的情況提供了一種統一標準的用法

EIP-3860: Limit and meter initcode

This EIP adds a maximum size for `initcode` and introduces gas metering based on its length. The size limit adds an invariant to the EVM which will make it easier to reason about and propose changes to.

A 2 gas/32 byte cost for `initcode` is introduced to account for the jumpdest-analysis clients must do prior to execution, which previously was not accounted for in the gas schedule.

如果本文有任何事實上的錯誤，若能批評指正萬分感激，如果有意見不同的地方，也歡迎討論，另外本文毫無投資建議，純純的好奇心驅使。

參考

來源
免責聲明：以上內容僅為作者觀點，不代表Followin的任何立場，不構成與Followin相關的任何投資建議。
喜歡
收藏
評論
相關推薦