以太坊帳戶模型與交易生命週期完整技術參考:從私鑰到區塊確認的深度解析
本文深入剖析以太坊帳戶模型的底層邏輯與交易生命週期的完整流程。涵蓋 EOA 與合約帳戶的本質差異、私鑰到地址的密碼學推導、交易結構與 EIP-1559 費用機制、簽名驗證流程、Mempool 運作、以及從交易發送到區塊確認的完整生命週期。同時探討 EIP-7702 與帳戶抽象的未來演進方向。
以太坊帳戶模型與交易生命週期完整技術參考:從私鑰到區塊確認的深度解析
說到以太坊的帳戶模型,很多人直覺上會覺得「不就是個地址嗎,有什麼好說的」。但如果你認真往下挖,會發現這東西其實藏著很多有趣的設計決策——為什麼要有兩種帳戶?EOA 和合約帳戶的底層差異到底是什麼?交易從你按下發送鍵到被打包進區塊,這中間到底發生了什麼?
今天就讓我們把這些東西一次講清楚。我會從密碼學基礎開始,一路讲到交易的生命週期,包括 EIP-1559 帶來的變化、Mempool 的運作邏輯、還有那些你可能踩過但不知道為什么的坑。
帳戶模型的底層邏輯
為什麼以太坊選擇帳戶模型而非 UTXO?
在開始聊以太坊的帳戶模型之前,我們得先回答一個根本問題:為什麼以太坊不用比特幣的 UTXO 模型?
這個問題困擾了很多從比特幣轉過來的朋友。比特幣的 UTXO 模型其實挺優雅的——每一筆錢都是一個「未花費的交易輸出」,就像你錢包裡的一張張鈔票。當你要轉帳時,系統會把你錢包裡的幾張「鈔票」組合成一筆交易,然後「找零」回來變成新的鈔票。
這個模型的好處是隱私性比較好,因為每次交易的輸入輸出看起來都像隨機拼接的錢。同時因為只關心「這筆錢有沒有被花過」,所以不需要維護一個全局的狀態,併發處理起來也相對簡單。
但問題來了——如果你要在比特幣上實現一個簡單的「自動販賣機」合約,需要追蹤「這台販賣機賣了多少瓶水、庫存還剩多少、誰買了什麼」,這些狀態在 UTXO 模型下很難優雅地表達。你得用一堆 OP_RETURN 或者特殊的地址來模擬狀態,程式碼會變得又臭又長。
Vitalik 當初設計以太坊的時候就果斷放棄了 UTXO 模型,轉而採用帳戶模型。他的想法很直接:絕大多數的金融應用場景,本質上就是在管理「誰有多少錢」這種狀態。與其用 UTXO 繞一圈模擬狀態,不如直接維護一個「狀態庫」,每次交易就是對這個狀態庫做原子性的更新。
這個設計決策影響深遠。現在以太坊上的 DeFi 借貸、質押、衍生品,全都是建立在這個看似簡單的帳戶模型之上的。沒有這個設計,2020 年的 DeFi Summer 根本不可能發生。
兩種帳戶的本質差異
以太坊的帳戶系統裡,其實就兩種東西:外部擁有帳戶(EOA)和合約帳戶(Contract Account)。看起來都是 42 個字元的地址,但底層的實現邏輯天差地遠。
EOA 的組成非常簡單,就是一把私鑰加上對應的公鑰和地址。你可以用這把私鑰簽名發送交易,控制帳戶裡的 ETH 和代幣。你可以把它想像成一把物理世界的鑰匙——誰拿到了誰就能開門。
合約帳戶就不一樣了。它沒有私鑰,取而代之的是一段部署在區塊鏈上的程式碼。當其他帳戶呼叫它的時候,這段程式碼會被 EVM 執行,產生各種副作用——修改儲存變數、呼叫其他合約、轉帳代幣等等。
這兩種帳戶最大的區別在於「誰能觸發動作」。EOA 的動作必須由持有私鑰的人親自簽名發起。合約帳戶自己不會主動做事,它只能被動地回應別人的呼叫。
很多人剛接觸以太坊的時候會問:「那智能合約怎麼自動執行的?」答案就是這麼樸實無華——背後其實有 cron job 或者其他的 EOA 在定時呼叫它。Uniswap 的自動化做市、Compound 的利率結算,這些都不是合約自己「醒來」的,而是有外部的 keeper 機器人在持續呼叫。
密碼學基礎:從私鑰到地址
橢圓曲線密碼學的核心原理
以太坊的帳戶安全建立在 secp256k1 這條橢圓曲線之上。這條曲線的方程式是 y² = x³ + 7,聽起來很數學,但實際上它的運算效率非常高,而且已經被密碼學界研究得很透徹了。
私鑰本質上就是一個介於 1 到 n-1 之間的隨機整數,其中 n 是這條曲線的階,大約是 1.158 × 10⁷⁷。這個數字大到什麼程度呢?即使你用地球上最快的超級電腦,花上幾十億年,也不可能暴力枚舉出別人的私鑰。
從私鑰生成公鑰的過程是這樣的:把私鑰當作一個「倍點」的次數,在曲線上不斷地對一個基準點 G 做加法。因為橢圓曲線的數學性質,這個「倍點」運算是单向的——你可以很快地從私鑰算出公鑰,但幾乎不可能反過來從公鑰推導出私鑰。
// 私鑰到公鑰的推導示意(概念層面)
私鑰 k = 隨機選擇的整數(1 < k < n)
// 公鑰 K = k × G
// 其中 G 是 secp256k1 的基準點
// 「k × G」表示 G 自己加 k-1 次
K.x = k × G.x
K.y = k × G.y
這個所謂的「離散對數難題」就是整個以太坊帳戶安全的基石。只要這個數學問題足夠難,你的私鑰就足夠安全。
地址的生成過程
公鑰有了,但我們日常使用的地址是另一回事。從公鑰到以太坊地址還需要幾步轉換。
第一步是對公鑰做 Keccak-256 雜湊。需要注意的是,以太坊用的是 Keccak 而不是 NIST 標準化的 SHA-3,兩者雖然都叫 Keccak 但實際輸出有差異。很多新手在這裡踩坑——用了錯誤的雜湊函數算出來的地址對不上。
第二步是取雜湊結果的最後 20 位元組。這就是我們看到的以太坊地址,格式是 0x 後面跟著 40 個十六進位字元。
整個流程大概是這樣:
公鑰(64 bytes,128 個十六進位字元)
↓
Keccak-256 雜湊(32 bytes,64 個十六進位字元)
↓
取最後 20 bytes
↓
加上 0x 前綴
↓
以太坊地址(0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D)
為什麼只取最後 20 位元組?這個問題社群裡有過討論。一種說法是 Satoshi 當初選 20 位元組是因為它剛好能裝下 RIPEMD-160 的輸出長度。Vitalik 沿用了這個設計,大概是覺得「比特幣用過的應該沒問題」。不管怎麼說,這個選擇現在已經成為以太坊生態系統的事實標準了。
助記詞與 HD 錢包
現在大家創建錢包很少直接用隨機種子了吧?BIP-39 助記詞才是主流。這個標準把 128 到 256 位的隨機種子轉換成 12 個或 24 個英文單字,號稱「人類可記憶」。
實際上這套方案的原理挺巧妙的。首先你有一串 entropy(熵),長度可以是 128、160、192、224 或 256 位。然後在這個熵後面加上一個 checksum——就是熵的 SHA-256 雜湊的前几位。最後把這個混合後的串切成 11 位一組的區塊,每個區塊映射到一個 2048 個單字的詞庫。
熵(Entropy)
↓
計算 checksum = SHA256(熵) 的前 N 位
↓
拼接:entropy + checksum
↓
切分為 11 位區塊(共 132 或 264 位)
↓
每個區塊映射到 BIP-39 詞庫中的一個單字
↓
12 個或 24 個助記詞
BIP-39 詞庫的設計很有意思。設計者精心挑選了那些「差異明顯、不容易混淆」的單字。比如沒有同時出現 "build" 和 "built",也沒有 "woman" 和 "women"。這是為了減少人為抄寫錯誤的機率。
但我得吐槽一下,BIP-39 的安全性其實比很多人想像的低。12 個助記詞只有 128 位 entropy,加上 checksum 也不過 132 位。這個空間在面對專業攻擊者——比如能燒 GPU 集群進行並行暴力搜尋的那種——其實沒那麼安全。真正的安全性更多來自於「攻擊成本遠高於收益」這個經濟學現實。
交易的結構與類型
一筆交易的完整結構
以太坊的交易看起來就是一個簡單的資料包,但裡面的欄位其實相當豐富。讓我們一個個拆開來看。
交易結構解析:
nonce: 交易序號
- 這個數字用來確保你發送的交易順序正確
- 每個 EOA 帳戶都有自己的 nonce 計數器
- 第一筆交易的 nonce 是 0,然後遞增
gasPrice / maxPriorityFeePerGas / maxFeePerGas: Gas 相關費用
- EIP-1559 之後,費用結構變得更複雜了
- maxFeePerGas 是你願意支付的最高單價
- maxPriorityFeePerGas 是給驗證者的小費
gasLimit: Gas 上限
- 這筆交易最多能消耗多少 Gas
- 如果超過就 revert,不會扣更多
to: 目標地址
- EOA 地址表示轉帳
- 合約地址表示呼叫智能合約
value: 轉帳金額
- 以 Wei 為單位,不是 ETH
- 1 ETH = 10¹⁸ Wei
data: 交易資料
- 轉給 EOA 時通常為空
- 呼叫合約時是函數選擇器 + 參數編碼
signature: 簽章
- v, r, s 三個值
- 用於驗證交易確實由私鑰持有者發送
這裡有個小知識點:很多人以為 data 欄位是給合約用的,其實 EOA 轉帳也可以帶 data。只不過收到轉帳的 EOA 沒有辦法「看到」這個 data,因為 EOA 沒有程式碼也無法執行任何邏輯。但區塊鏈上記錄了完整的 data 內容,所以理論上可以在轉帳時附帶一些「備註」——就像比特幣的 OP_RETURN 一樣。
EIP-1559 帶來的费用革命
2021 年 8 月的倫敦升級實施了 EIP-1559,這是以太坊經濟模型的一次大手術。在那之前,用戶發送交易需要自己估一個 gasPrice,然後等礦工選擇打包。如果你想快點確認,就得提高 gasPrice;如果不著急,可以壓低 gasPrice 等。
問題在於這個拍賣模型太笨了。想像一下你在拍賣行,競標者輪流喊價,最後才知道自己花了多少冤枉錢。礦工當然樂見其成,畢竟 gasPrice 越高越好。
EIP-1559 的核心改變是引入了 Base Fee + Priority Fee 的雙層結構。Base Fee 是網路動態計算的「最低價」,每個區塊都會根據上一個區塊的 Gas 使用量進行調整。如果上一個區塊塞得太滿,Base Fee 就上調;如果太空了,Base Fee 就下調。
調整公式是這樣的:
Base Fee (n+1) = Base Fee (n) × 調整係數
調整係數 = 1 + (父區塊 Gas 使用量 - 目標 Gas 使用量) / 目標 Gas 使用量 / 8
實際上就是:每偏離目標值 1%,Base Fee 調整 12.5%
這個設計厲害的地方在於「負載平衡」。當網路擁堵的時候,Base Fee 會指數級上升,逼著用戶提高願付價格,同時也會讓一些不那麼緊急的交易選擇等待。相反,網路空閒的時候 Base Fee 很低,大家就不用搶著出高價了。
另一個革命性的設計是 Base Fee 的燃燒機制。每筆交易消耗的 Base Fee 會直接從流通中移除。這意味著 ETH 的供應量不再是單調遞增的——當網路活動頻繁的時候,可能會出現淨通縮。
根據超聲波貨幣的追蹤數據,從 2021 年到 2026 年第一季度,EIP-1559 總共燃燒了約 450 萬枚 ETH。這個數字在 2024 年和 2025 年的網路高峰期尤其可觀,曾經連續好幾天出現「負發行」——燒掉的比新挖出來的多。
三種主要的交易類型
以太坊的 EVM 支援幾種不同類型的交易,每種的用途和特性都不太一樣。
Legacy 交易(Type 0)
這是最老派的交易格式,gasPrice 是唯一的費用參數。你設定一個願付的單價,礦工根據出價高低選擇打包。在 EIP-1559 之前,所有的交易都是這個格式。
交易格式:
RLP(nonce, gasPrice, gasLimit, to, value, data, v, r, s)
EIP-1559 交易(Type 2)
現在的主流格式。引入了 maxFeePerGas 和 maxPriorityFeePerGas 兩個參數。maxFeePerGas 是你的「天花板」,確保你最多只會付這麼多;maxPriorityFeePerGas 是給驗證者的小費,決定了你的交易相對於其他人的優先順序。
交易格式:
RLP(chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, v, r, s)
accessList 是 EIP-2930 引入的可選功能,用來「預熱」帳戶和儲存槽。預先聲明要讀寫的狀態位置可以獲得 Gas 折扣,因為節點可以更高效地處理。
Contract Creation 交易
嚴格來說這不算一種「類型」,而是一種特殊情況。當交易的 to 欄位為空(或者是 0 地址)時,EVM 會把 data 欄位的內容當作合約代碼進行部署,創建一個新的合約帳戶。
有趣的是,這種交易的目標地址在部署前是未知的。新的合約地址是由發送者的地址和 nonce 決定的:
新合約地址 = keccak256(rlp(發送者地址, nonce))[12:]
如果使用 CREATE2(EIP-1014),地址還可以通過鹽值和初始化代碼的雜湊進一步控制。這在很多場景下非常有用,比如想在部署前就確定合約地址、或者構建工廠合約之類的應用。
簽名機制與交易驗證
ECDSA 簽章的數學原理
以太坊交易的簽名用的是 ECDSA(橢圓曲線數位簽章算法),具體來說是 secp256k1 曲線配合 ECDSA。這套方案在比特幣上就已經用了,效果經過了十多年的實戰檢驗。
簽名的過程大概是這樣的:
首先,計算訊息的 Keccak-256 雜湊,得到一個 256 位的數字。然後,產生一個隨機的臨時私鑰 k,並用它算出對應的點 R。最後,用私鑰、訊息雜湊和 R 來計算簽章值 s。
簽章生成:
z = hash(訊息) // 訊息的雜湊值
k = 臨時私鑰 // 每次簽名都要隨機選擇
R = k × G // 取 R 的 x 座標
s = k⁻¹ × (z + r × 私鑰) mod n
// 其中 r = R.x mod n
簽章輸出是 (r, s) 這兩個值,加上 v 這個 recovery id。v 的作用是幫助從簽章中恢復出公鑰——因為橢圓曲線上每個 x 座標都對應兩個可能的 y 座標(上下對稱),所以需要一個標記來區分。
以太坊的 v 稍微做了點變形,不是在 {27, 28} 裡選,而是在 {27, 28, 29, 30} 裡選,這是因為以太坊的 chainId 機制會影響 v 的計算。
驗證簽名的過程本質上就是反過來算一遍:如果簽名是合法的,那麼用公鑰、訊息雜湊和 (r, s) 應該能驗證通過;如果私鑰不對,驗證就會失敗。
交易簽名的實際流程
拿 MetaMask 發送交易來說,整個簽名流程大概是這樣的:
錢包先生成交易物件,然後使用你的私鑰對交易的 RLP 編碼內容進行簽名。簽名結果得到 v, r, s 三個值。最後把這些值附加到原始交易物件上,就組成了完整的已簽名交易。
// 已簽名交易的組合方式
交易物件 = {
nonce,
gasLimit,
maxFeePerGas,
maxPriorityFeePerGas,
to,
value,
data,
accessList,
chainId
}
// 簽名主體 = RLP(交易物件去除 v, r, s)
// 簽名結果 = ECDSA(簽名主體, 私鑰)
// 最終的交易 = 原始交易物件 + 簽名結果
這裡有個很關鍵的概念:簽名只針對交易內容的「語義」部分,不包括簽名自己本身。也就是說,你不能對「我包含了我的簽名」這件事再做一次簽名。這個設計防止了簽名的重放攻擊。
EIP-1559 對簽名的影響
EIP-1559 帶來的費用結構變化也影響了簽名的對象。Legacy 交易只簽名 nonce、gasPrice、gasLimit、to、value、data 這些欄位。EIP-1559 交易則簽名 nonce、maxPriorityFeePerGas、maxFeePerGas、gasLimit、to、value、data、accessList、chainId。
注意到沒有?gasPrice 變成了 maxFeePerGas 和 maxPriorityFeePerGas。這就帶來了一個問題:Legacy 交易和 EIP-1559 交易的簽名格式是不相容的。
這怎麼辦呢?以太坊的解決方案是保留兩種簽名演算法。你可以繼續用老式的 EIP-155 風格簽名(適用於 Legacy 交易),也可以用新的 EIP-2930 風格(適用於 EIP-1559 交易)。兩種格式可以共存,這就是所謂的「向前相容」。
交易的生命週期
Mempool:交易排隊等待的世界
當你發送一筆交易後,它並不是直接進入區塊的。在被打包之前,交易會在節點的 Mempool(記憶體池)裡排隊等待。
Mempool 是節點維護的一個交易緩衝區。當你的交易被發送到某個節點後,這個節點會驗證交易的簽名、檢查餘額是否足夠、計算 Gas 是否夠用。如果一切 OK,交易就會進入 Mempool,等待被區塊構建者選中打包。
整個以太坊網路有數以千計的節點,每個節點都有自己的 Mempool。這就意味著不同節點看到的「待打包交易列表」可能略有不同——畢竟網路傳播需要時間,總會有一些延遲。
MEV(最大可提取價值)的概念就是在這個背景下誕生的。區塊構建者可以選擇把哪些交易打包進區塊、以什麼順序打包。聰明的演算法會發現,如果把 A 用戶的 Uniswap 買單排在 B 用戶的買單前面,可能創造出套利機會。這種「排序優先級」本身就成了一種有價值的資源。
Flashbots 的 MEV-Boost 系統就是為了解決這個問題而生的。它把區塊構建和區塊提議分開——驗證者不再自己決定交易排序,而是從一群專業的區塊構建者那裡「投標」購買已經排好序的區塊。這樣一方面减少了 MEV 對共識層的腐蝕,另一方面也讓普通用戶可以通过 Flashbots Protect 避開三明治攻擊。
交易的執行與狀態更新
當交易被選中進入區塊後,EVM 就開始執行它了。執行的過程大致是這樣的:
第一步,扣除 Gas 費用。不管交易最終成功還是失敗,Gas 費用都要先扣掉。計算方式是:Gas Limit × 已消耗的 Gas 單價。剩餘的 Gas 退還給發送者。
第二步,驗證交易簽名。節點用 ECDSA 恢復出發送者地址,確認交易的 nonce 和餘額符合要求。
第三步,執行合約程式碼。如果 to 欄位是 EOA,這步就是轉帳操作。如果 to 是合約地址,EVM 會載入並執行對應的位元組碼。
第四步,處理結果。如果執行成功且沒有 revert,狀態變更就生效;如果 revert 了,所有的狀態變更都會回滾,但 Gas 費用不退。
EVM 的執行是確定性的。這句話的意思是:給定相同的初始狀態和交易內容,全世界所有節點執行完的結果都完全一致。這是區塊鏈能夠達成共識的前提。
一個容易踩的坑是:很多人以為交易 revert 了 Gas 費用就完全損失了,其實不是。實際上只有「已經執行過的部分」消耗的 Gas 才不退。比如你的交易呼叫了一個合約,跑了 90% 的邏輯才 revert,這 90% 消耗的 Gas 是拿不回來的。
區塊確認與最終確定性
以太坊的區塊確認分為兩層:經濟最終確定性和共識最終確定性。
經濟最終確定性是「軟確認」,只要你等夠多區塊,交易的結果基本不可逆了。因為要逆轉需要「丟掉」大量已經確認的區塊,這種攻擊的成本極高。DeFi 應用通常要求 12-35 個確認(約 3-10 分鐘)就可以放心大額轉帳。
共識最終確定性是「硬確認」,在 PoS 機制下叫 Casper FFG。當一個區塊被最終確定後,它就是「永久」的,幾乎不可能被逆轉。以太坊的最終確定時間是 2 個 epoch,大約 12 分鐘。
Casper FFG 的工作原理是這樣的:每 32 個 slot 構成一個 epoch。每個 epoch 結束時,驗證者要對整個 epoch 的最後一個區塊(checkpoint)進行投票。當某個 checkpoint 收到超過 2/3 驗證者權重的投票時,它就被「最終確定」了。
最終確定性有個很酷的安全保證:如果你想「逆轉」一個已經最終確定的區塊,至少需要燒掉 1/3 驗證者質押的 ETH 作為罰款。這就是所謂的「消極最終確定性」(Slashing)—— 作弊是要付出代價的。
帳戶模型的擴展:EIP-7702 與帳戶抽象
EIP-4337 開創的新局面
帳戶抽象(Account Abstraction)是以太坊帳戶模型的革命性擴展。傳統上,只有 EOA 能「主動」發送交易——因為交易必須由私鑰簽名發起。智能合約錢包想要實現更複雜的功能,比如社交恢復、多簽、批量交易等,必須靠一堆變通方案。
EIP-4337 的思路是:不改變以太坊共識層,而是在應用層引入一套替代的交易提交機制。用戶不再直接發送交易,而是發送「用戶操作」(UserOperation)。這些 UserOperation 會被 bundler 收集、打包、提交到區塊。
這個模式下,你的智能合約錢包可以在合約層定義自己的驗證邏輯。比如你可以實現「用我的指紋解鎖後才能發送超過 1000 USD 的交易」這樣的策略。這在傳統 EOA 模式下是不可能實現的。
EIP-4337 還引入了 Paymaster 機制。簡單來說就是「別人幫你付 Gas」。你可以讓某個合約代你墊付交易費用,之後再還給它,或者用項目方的代幣支付 Gas。這極大地改善了新用戶的入門體驗——用戶不需要先買 ETH 就可以使用以太坊應用。
EIP-7702 的更大野心
如果說 EIP-4337 是在不改變現有系統的情況下「繞路」實現帳戶抽象,那 EIP-7702 就是直接「修路」。
EIP-7702 允許 EOA 在交易執行期間臨時獲得智能合約的能力。具體來說,EOA 可以在交易的上下文裡「聲明」自己是一個特定的合約,然後享受這個合約提供的所有功能。
這個提案的意義在於:現有的數以億計的 EOA 帳戶不需要遷移就可以獲得合約錢包的功能。你可以想像成給你的銀行帳戶加了一個「超級功能開關」,打開之後立馬變成功能豐富的智能帳戶。
EIP-7702 預計會在 Pectra 升級中部署。這將是以太坊帳戶模型的又一次重大演進。
常見問題與實務建議
交易卡住的處理方法
遇到交易卡在 Mempool 裡出不來的時候,很多人第一反應是「再發一筆同樣的」。千萬別這麼做——如果你用更高的 nonce 重新發送同一筆交易(same nonce, higher gas price),舊的那筆就會被新交易替代(Replace by Fee, RbF)。但如果你發送的是不同 nonce 的新交易,舊的那筆仍然會被執行,只不過可能要多等很久。
正確的處理方式有幾種:
第一,如果你的錢包支援 RbF,可以在原始交易還未確認的時候,用同一個 nonce 發送一個 gasPrice 更高的新交易。這樣礦工/驗證者會選擇新的那筆,舊的就被替代了。
第二,等。用戶發送的交易如果 gasPrice 太低,最終會被「清除」出 Mempool。不同的節點有不同的清除策略,一般來說幾小時到幾天後就會消失。
第三,加速的方式是提高 gasPrice。EIP-1559 的設計讓你可以比較精確地控制等待時間——如果你願意付更高的 maxPriorityFeePerGas,驗證者就會更願意把你的交易往前排。
nonce 重複的災難
每個帳戶的 nonce 必須嚴格遞增。如果你不小心發送了兩筆 nonce 相同的交易,會發生什麼?
答案是:兩筆交易都會被廣播到網路。礦工/驗證者只能打包其中一筆(因為 nonce 用了就不能再用),另一筆就永久失敗了。這種失誤很難補救,除非你能找到願意幫你「加速」其中一筆的 MEV 搜尋者。
防止這個問題的方法很簡單:不要同時用多個錢包介面發送同一個帳戶的交易。或者使用 wallet.setNonce() 這樣的功能來顯式設置 nonce,而不是依賴錢包自動查詢。
批次交易省 Gas 的技巧
如果你要發送多筆相關的交易,可以考慮把它們組合在一起。
Legacy 交易的 Gas 成本結構是這樣的:
- 每筆交易基礎開銷:21,000 Gas
- 每個 non-zero 字节的 data:16 Gas
- 調用其他合約:額外開銷
如果是批量創建多個合約,用 CREATE2(而不是多個 CREATE)可以節省很多 gas——因為 CREATE2 的地址計算包含了初始化代碼的雜湊,可以「預先計算」好地址,不需要逐個計算。
另一個省 Gas 的技巧是利用內部交易(Internal Transaction)。比如你想給 100 個地址各轉 0.01 ETH,與其發送 100 筆獨立交易,不如部署一個合約,在合約裡用一個迴圈完成所有轉帳。雖然 Gas 總量差不多,但基礎開銷從 21,000 × 100 變成了只有 21,000 + 迴圈迭代的 Gas,省下來的部分很可觀。
結語
以太坊的帳戶模型和交易機制看起來抽象,但理解了這些底層邏輯之後,你在使用以太坊時會少走很多彎路。知道交易簽名的原理,你就會明白私鑰為什麼那麼重要;了解 EIP-1559 的費用模型,你就知道什麼時候發交易最划算;熟悉交易的生命週期,你就知道交易卡住的時候該怎麼處理。
這些知識不會讓你一夜暴富,但能幫你在熊市少踩坑、在牛市多賺錢。至少,當別人問你「你的 ETH 在哪裡」的時候,你能自信地說:「在我的 Ledger 冷錢包裡,只有我有私鑰。」
參考資料
- Ethereum Yellow Paper (Byzantine version)
- EIP-1559: Fee market change for ETH 1.0 chain
- EIP-4337: Account Abstraction using Alt Mempool
- EIP-7702: Set EOA contract code
- Ethereum Execution Layer Specifications
相關文章
- 以太坊狀態機完整技術指南:從交易生命週期到狀態管理的深度解析 — 本文深入剖析以太坊狀態機的完整運作機制,從帳戶模型(EOA 與合約帳戶)的根本差異、交易生命週期的每個階段、狀態 trie 的層次結構、世界狀態的組織方式,到 EVM 的執行模型與狀態轉換函數的數學定義。我們提供完整的技術細節、資料結構解析、以及與其他區塊鏈架構的深度比較,幫助開發者和研究者建立對以太坊狀態管理完整且深入的理論基礎。
- 以太坊帳戶模型 vs UTXO 的設計抉擇:為何以太坊選擇 EOA/合約帳戶模型 — 比特幣的 UTXO 模型和以太坊的帳戶模型代表了區塊鏈狀態管理的兩種截然不同的設計哲學。本文將從技術原理、編程模型、安全特性、隱私表現和擴展性等多個維度,深入剖析這兩種模型的優劣,並詳細解釋以太坊為何選擇帳戶模型而非 UTXO 架構。我們將探討帳戶模型如何支撐以太坊的圖靈完整智慧合約生態,並分析這種選擇在實際應用中帶來的權衡取捨。
- 以太坊密碼學基礎完整指南:橢圓曲線密碼學、簽章機制與 Merkle Tree 結構 — 本文深入分析以太坊密碼學系統的三大支柱:secp256k1 橢圓曲線與 ECDSA 簽章機制的數學原理、KECCAK-256 雜湊函數的設計特點、以及 Patricia Merkle Trie 資料結構在狀態管理中的關鍵角色。我們從密碼學理論出發,經過詳盡的數學推導,最終落實到 Solidity、Go 與 Rust 的實際程式碼範例。涵蓋離散對數問題、點加法/倍增運算、ECDSA 簽章驗證、Merkle Proof、EIP-1559 等核心概念的完整技術解析。
- 以太坊錢包安全實務進階指南:合約錢包與 EOA 安全差異、跨鏈橋接風險評估、2024-2026 年真實被盜事件攻擊鏈深度還原 — 本文深入探討以太坊錢包的安全性實務,特別聚焦於合約錢包與外部擁有帳戶(EOA)的安全差異分析、跨鏈橋接的風險評估方法,以及 2024-2026 年真實被盜事件的完整攻擊鏈還原。我們詳細分析 Orbit Protocol 社交工程攻擊、Raydium 預言機操縱、Venom Finance 多簽被控、Pendle Finance 大規模盜領等重大事件,並提供錢包安全最佳實踐與防護策略,幫助讀者建立全面的錢包安全知識體系。
- 以太坊錢包安全模型深度比較:EOA、智慧合約錢包與 MPC 錢包的技術架構、風險分析與選擇框架 — 本文深入分析以太坊錢包技術的三大類型:外部擁有帳戶(EOA)、智慧合約錢包(Smart Contract Wallet)與多方計算錢包(MPC Wallet)。我們從技術原理、安全模型、風險維度等面向進行全面比較,涵蓋 ERC-4337 帳戶抽象標準、Shamir 秘密分享方案、閾值簽名等核心技術,並提供針對不同資產規模和使用場景的選擇框架。截至 2026 年第一季度,以太坊生態系統的錢包技術持續演進,理解這些技術差異對於保護數位資產至關重要。
延伸閱讀與來源
- Ethereum.org Developers 官方開發者入口與技術文件
- EIPs 以太坊改進提案完整列表
- Solidity 文檔 智慧合約程式語言官方規格
- EVM 代碼庫 EVM 實作的核心參考
- Alethio EVM 分析 EVM 行為的正規驗證
這篇文章對您有幫助嗎?
請告訴我們如何改進:
評論
發表評論
注意:由於這是靜態網站,您的評論將儲存在本地瀏覽器中,不會公開顯示。
目前尚無評論,成為第一個發表評論的人吧!