凌晨，ETH 突破 4,100 美元，創下 2025 年以來最高。螢幕上的數字閃了一下，就像有人推了你一把——而你忽然想起，2021 年那根 4,865 美元的長針。幾小時前，前摩根大通首席策略師 Tom Lee 在訪談中重提老比例，並推算如果 ETH/BTC 回到 2017 年的 0.14，在比特幣創新高的情境下，ETH 價格有機會觸及更高水平（其推導約在 16,000 美元），這一差距也是部分分析者看好 ETH 的理由之一。但這種推算基於多個假設條件，並不代表必然結果。但這都是其個人觀點，市場對此仍有不同看法。但他補了一句——加密會先於股市創新高。他預言標普 500 有可能破 6,000 點，而比特幣、以太坊會提前完成自己的“頂點試探”。問題是，這次上漲，真只是情緒回潮嗎？一｜價格與歷史坐標坐標ETH：2021 年歷史高點 4,865 美元 vs 當前 4,100 美元（2025 年內最高）BTC：2021 年歷史高點 69,000 美元 vs 當前 突破 116,000 美元，已創新高ETH/BTC 當前約 0.07，距離 2017 年的 0.14 ，若從歷史比例看，仍存在較大差距。BTC 已經跨入新的價格區間，而 ETH 仍在追趕。這個差距，也許正是 Tom Lee 所說上行潛力的來源。二｜為什麼是以太坊在“承接”上漲？1. 穩定幣：深水航道里的“少而重”穩定幣是鏈上的美元。零售端的高頻結算更多發生在 TRON；但合規資金與高價值清算，更偏在 以太坊及其 L2——USDC、PYUSD 等機構偏好的穩定幣部署在 EVM 生態，它們承載跨境結算、鏈上抵押、協議清算，直接轉化為 ETH 的交易需求與 Gas 收入。承接點：當“鏈上美元”的高價值路由首選 EVM，以太坊就不只是“有人用”，而是“用它辦合規的事”。2. RWA：把真實現金流搬上鏈RWA（現實資產上鏈）是第二條曲線。BlackRock BUIDL 直接部署在以太坊，鏈上配息，TVL 超 20 億美元J.P. Morgan 用 Onyx 許可鏈做抵押結算，並在 Base（以太坊 L2）測試存款代幣這些項目帶來的是真實的金融現金流，而不是炒作資金循環。以太坊在 RWA 市場的佔有率超過 80%，是真正的鏈上金融主場。三｜技術護城河：EVM 與智能合約以太坊的 EVM（Ethereum Virtual Machine） 是一台“世界電腦”，全球節點用同一規則運行同一份程式碼，自動執行、不可篡改。穩定幣的自動清算、RWA 的收益分配、DeFi 的抵押與清算，都在這台電腦裡完成。這不僅是技術上的“可程式設計性”，更是制度層面的“可計算性”。四｜同為基礎層，不同的賽道講到技術護城河，不可避免要和另一條基礎層公鏈——比特幣——做一個比較。以太坊和比特幣，都是加密世界的基礎層——它們就像網際網路時代的 TCP/IP 協議一樣，是整個生態的根基。不同的是，比特幣在設計之初就專注於安全性與儲值，而以太坊則在可程式設計性上打開了無限的可能。這種差異，讓它們在本輪行情中的位置也不同：價格空間：比特幣已經突破歷史新高，進入未知區間；以太坊距離 2021 年的歷史高點 4,865 美元 還有 15% 左右的差距。技術路徑：有人試圖在比特幣上引入智能合約（Taproot、Stacks 等），想讓它也具備可程式設計性，但缺乏 EVM 那樣的通用執行環境與成熟生態，擴展的效率與廣度都受限。所以，如果說比特幣是數字黃金，那麼ETH更像是數字經濟的作業系統——它承接的不只是價格波動的投機情緒，更是穩定幣、RWA、DeFi 等鏈上應用的全部運行邏輯。五｜政策催化：一連串訊號在推高預期過去一個多月裡，加密市場接連收到了三波政策利多，當然，最終效果仍需時間和執行細則的落地。7 月上旬，美國國會通過被市場稱為“天才法案”的立法方案，對加密貨幣業務的監管框架進行明確，被視為向合規化邁出的關鍵一步。7 月 28 日，SEC 在公開講話中承認加密貨幣在全球金融體系中的創新價值，並表示將推動更開放、更明確的監管環境。8 月 7 日，總統簽署行政令，要求修訂 401(k) 投資規則——美國 401(k) 養老帳戶資產規模已達 8.7 兆美元，這是一個實實在在的制度級資金池。這三件事不是孤立發生的，而是一個遞進的過程：先是立法定方向，再有監管表態放鬆，最後是制度級資金入口被打開。它們共同推動了市場對以太坊等核心資產的長期預期。六｜價值落點把這些線索串起來看：BTC 已創歷史新高，ETH 仍有追趕空間；穩定幣和 RWA 的核心業務在 EVM 體系中落地，產生真實現金流；EVM 提供了可程式設計、可計算的技術保障；制度級資產池為潛在資金流入打開了通道。ETH 的上漲，並非單純情緒回潮，而是基礎設施在被持續使用後，價格順著價值抬升的結果。更重要的是，這些支撐不是短期利多，而是會持續作用數年的結構性力量：穩定幣的清算鏈路一旦固化，就很難遷移；RWA 的收益分配邏輯一旦寫進合約，就會不斷生成鏈上現金流；EVM 的生態一旦形成，就會自我強化，吸引更多開發者和機構加入。所以，這輪上漲背後，不只是數字的跳動，而是加密基礎設施在被真實使用後的長期回應。這更像是一條河流找到了更深的河床。價格會有漲落，但河水會沿著這條河床，緩慢而堅定地向前流去。 (方到)

本文通過一個具體的智能合約示例，詳細講解EVM（以太坊虛擬機器）的完整執行流程，從字節碼層面深入分析每個指令的執行過程。我們將以一個簡單的儲存合約為例，完整展示從合約呼叫到執行完成的每一個步驟，包括函數選擇器的匹配機制、參數的解析過程、儲存操作的Gas計算、記憶體管理的動態擴展、以及錯誤處理時的狀態回滾等關鍵環節。通過這個深入的分析，你將能夠理解EVM是如何將高級的Solidity程式碼轉換為底層的虛擬機器指令，每個指令如何影響棧、記憶體和儲存的狀態變化，以及EVM如何通過精密的Gas計量機制和狀態管理系統，在保證安全性和確定性的同時，為智能合約提供高效可靠的執行環境。這不僅有助於開發者編寫更最佳化的智能合約，也為理解區塊鏈虛擬機器的設計原理提供了寶貴的實踐案例。1. 示例合約程式碼我們以一個簡單的儲存合約為例：// SPDX-License-Identifier: MITpragma solidity ^0.8.0;contract SimpleStorage {    uint256 private storedNumber;    function store(uint256 _number) public {        storedNumber = _number;    }    function retrieve() public view returns (uint256) {        return storedNumber;    }}2. 合約字節碼分析當Solidity編譯器處理我們的智能合約時，會生成兩種不同的字節碼：建立字節碼和執行階段字節碼。建立字節碼負責部署合約並初始化狀態，而執行階段字節碼則是合約部署後實際執行的程式碼。編譯後的字節碼（簡化版）：// 合約建立字節碼608060405234801561001057600080fd5b50610150806100206000396000f3fe// 執行階段字節碼608060405234801561001057600080fd5b50600436106100365760003560e01c80632e64cec11461003b5780636057361d14610059575b600080fd5b610043610075565b60405161005091906100a1565b60405180910390f35b6100736004803603810190610068919061008d565b61007e565b005b60008054905090565b8060008190555050565b60008135905061009781610103565b92915050565b6100a081610099565b82525050565b60006020820190506100bb60008301846100a7565b92915050565b6000602082840312156100d357600080fd5b60006100e184828501610088565b91505092915050565b6100f3816100f9565b82525050565b6000819050919050565b61010c816100f9565b811461011757600080fd5b50565b```3. 函數選擇器分析函數選擇器是EVM中函數呼叫路由的核心機制。當外部呼叫智能合約時，EVM需要知道要執行那個函數。這個過程通過函數選擇器來實現 - 它是函數簽名的Keccak256雜湊值的前4字節，作為函數的唯一識別碼。4. store函數執行流程詳解4.1 呼叫資料準備假設我們呼叫 store(42)：呼叫資料: 0x6057361d000000000000000000000000000000000000000000000000000000000000002a- 0x6057361d: 函數選擇器- 000...002a: 參數42的十六進製表示（32字節對齊）4.2 EVM執行環境初始化在執行任何智能合約程式碼之前，EVM需要建立一個完整的執行環境。這個過程包括建立EVM實例、初始化直譯器、分配棧和記憶體空間、載入合約程式碼等步驟。每個元件都有其特定的職責，共同構成了一個安全、高效的執行環境。4.3 詳細指令執行過程現在我們深入到字節碼層面，逐條分析每個指令的執行過程。這個過程展示了EVM如何將高級的Solidity程式碼轉換為底層的虛擬機器指令，以及每個指令如何影響棧、記憶體和儲存的狀態。讓我們逐步分析store函數的字節碼執行：步驟1: 函數選擇器檢查這是合約執行的第一個關鍵步驟。EVM需要確定呼叫者想要執行那個函數，這個過程通過解析呼叫資料中的函數選擇器來完成。同時，還需要進行一些基礎的安全檢查，比如驗證是否傳送了以太幣（對於非payable函數）。字節碼: 60 80 60 40 52 34 80 15 61 00 10 57 60 00 80 fd指令序列分析：1.PUSH1 0x80 (PC=0)操作: 將0x80壓入棧棧狀態: [0x80]Gas消耗: 32.PUSH1 0x40 (PC=2)操作: 將0x40壓入棧棧狀態: [0x40, 0x80]Gas消耗: 33.MSTORE (PC=4)操作: 將0x80儲存到記憶體地址0x40棧狀態: []記憶體: 0x40位置儲存0x80（自由記憶體指針）Gas消耗: 3 + 記憶體擴展成本4.CALLVALUE (PC=5)操作: 獲取交易傳送的以太幣數量棧狀態: [msg.value]Gas消耗: 25.DUP1 (PC=6)操作: 複製棧頂元素棧狀態: [msg.value, msg.value]Gas消耗: 36.ISZERO (PC=7)操作: 檢查棧頂是否為0棧狀態: [msg.value == 0, msg.value]Gas消耗: 37.PUSH2 0x0010 (PC=8)操作: 將跳轉目標地址壓入棧棧狀態: [0x0010, msg.value == 0, msg.value]Gas消耗: 38.JUMPI (PC=11)操作: 如果msg.value == 0則跳轉到0x0010棧狀態: [msg.value]Gas消耗: 10步驟2: 函數選擇器匹配在這個步驟中，EVM會從呼叫資料中提取函數選擇器，並與合約中定義的函數進行匹配。這個過程涉及複雜的字節碼操作，包括資料載入、位運算和條件跳轉。理解這個過程有助於最佳化函數呼叫的Gas成本。字節碼: 60 04 36 10 61 00 36 57 60 00 35 60 e0 1c 80 63 2e 64 ce c1 14 61 00 3b 57 80 63 60 57 36 1d 14 61 00 59 57關鍵指令分析：1.PUSH1 0x04 + CALLDATASIZE + LT檢查呼叫資料長度是否至少4字節（函數選擇器）2.PUSH1 0x00 + CALLDATALOAD從呼叫資料偏移0處載入32字節結果: 0x6057361d000000000000000000000000000000000000000000000000000000000000002a3.PUSH1 0xe0 + SHR右移224位（28字節），提取前4字節函數選擇器結果: 0x6057361d4.DUP1 + PUSH4 0x6057361d + EQ比較提取的選擇器與store函數選擇器匹配成功！步驟3: 參數解析和儲存這是函數執行的核心步驟。EVM需要從呼叫資料中解析出函數參數，然後執行實際的儲存操作。SSTORE指令是整個過程中最昂貴的操作，其Gas成本取決於儲存狀態的變化類型。這裡展示了EVM如何精確計算和收取Gas費用。詳細指令執行：1.參數載入PUSH1 0x04        ; 參數偏移量CALLDATALOAD      ; 載入32字節參數棧狀態: [42]      ; 十進制422.儲存位置準備PUSH1 0x00        ; 儲存槽0（storedNumber變數）棧狀態: [0, 42]3.執行儲存操作SSTORE            ; 將42儲存到槽位0棧狀態: []Gas消耗: 20000 (首次儲存) 或 5000 (更新儲存)4.4 Gas計算詳解Gas消耗詳細分解基礎Gas成本構成呼叫資料成本計算 (68位元組示例)SSTORE操作Gas成本總Gas消耗計算示例store(42) 函數呼叫的完整Gas計算：基礎成本:           21,000 Gas呼叫資料成本:          368 Gas指令執行成本:          200 Gas記憶體擴展成本:           50 GasSSTORE成本:         20,000 Gas (首次儲存)─────────────────────────────────總計:               41,618 Gas如果是更新操作:SSTORE成本:          5,000 Gas (更新儲存)─────────────────────────────────總計:               26,618 GasGas最佳化建議總Gas消耗計算：基礎成本:     21000呼叫資料:       368指令執行:      ~200記憶體擴展:       ~50SSTORE:      20000 (首次) 或 5000 (更新)------------------------總計:        ~41618 (首次) 或 ~26618 (更新)5. retrieve函數執行流程與store函數不同，retrieve函數是一個view函數，它唯讀取資料而不修改合約狀態。這種函數的執行成本相對較低，因為它不需要進行昂貴的儲存寫入操作，也不會觸發狀態變更。讓我們看看它是如何工作的。5.1 呼叫資料呼叫資料: 0x2e64cec1- 只有函數選擇器，無參數5.2 執行流程5.3 關鍵指令執行1.載入儲存值PUSH1 0x00       ; 儲存槽0SLOAD            ; 載入儲存值棧狀態: [storedNumber的值]Gas消耗: 2100 (冷訪問) 或 100 (熱訪問)2.準備返回資料PUSH1 0x40       ; 獲取自由記憶體指針MLOAD            ; 載入記憶體指針值DUP1             ; 複製指針DUP3             ; 複製返回值MSTORE           ; 儲存返回值到記憶體3.返回結果PUSH1 0x20       ; 返回資料長度32字節SWAP1            ; 交換棧頂兩元素RETURN           ; 返回資料6. 狀態變化追蹤在智能合約執行過程中，狀態的變化是核心關注點。EVM通過精確的狀態管理機制，確保每次狀態變更都是可追蹤、可回滾的。這不僅保證了系統的一致性，也為偵錯和審計提供了重要支援。6.1 儲存狀態變化6.2 記憶體佈局變化執行前記憶體佈局:0x00-0x3F: 空0x40-0x5F: 0x80 (自由記憶體指針)0x60-0x7F: 空執行後記憶體佈局:0x00-0x3F: 空0x40-0x5F: 0x80 (自由記憶體指針)0x60-0x7F: 空0x80-0x9F: 返回資料 (僅在retrieve函數中)7. 錯誤處理示例EVM的錯誤處理機制是其安全性和可靠性的重要保障。當執行過程中遇到異常情況時，EVM會採取相應的錯誤處理策略，包括狀態回滾、Gas消耗、錯誤資訊返回等。理解這些機制對於編寫健壯的智能合約至關重要。7.1 狀態快照與回滾機制在深入具體的錯誤處理示例之前，我們需要理解EVM的狀態快照（Snapshot）機制。這是EVM實現原子性操作的核心技術，確保了"要麼全部成功，要麼全部失敗"的執行語義。7.1.1 快照機制的工作原理當EVM開始執行一個合約呼叫時，會首先建立一個狀態快照。這個快照記錄了當前狀態資料庫的"檢查點"，包括所有帳戶的餘額、儲存、程式碼等資訊的當前狀態。// 在Go-Ethereum中的實現func (evm *EVM) Call(caller ContractRef, addr common.Address, input []byte, gas uint64, value *uint256.Int) (ret []byte, leftOverGas uint64, err error) {    // 建立狀態快照    snapshot := evm.StateDB.Snapshot()    // 執行合約程式碼    ret, err = evm.interpreter.Run(contract, input, false)    if err != nil {        // 發生錯誤時回滾到快照點        evm.StateDB.RevertToSnapshot(snapshot)    }    return ret, gas, err}7.1.2 快照的資料結構EVM使用日誌式的快照機制，記錄每個狀態變更操作：type journal struct {    entries []journalEntry    // 狀態變更日誌    dirties map[common.Address]int  // 髒資料索引}type journalEntry interface {    revert(*StateDB)  // 回滾操作    dirtied() *common.Address  // 獲取影響的地址}每種狀態變更都有對應的日誌條目：balanceChange - 餘額變更storageChange - 儲存變更nonceChange - Nonce變更codeChange - 程式碼變更suicideChange - 合約銷毀7.1.3 回滾過程詳解當需要回滾時，EVM會按照以下步驟執行：定位快照點：根據快照ID找到對應的日誌索引位置逆序回滾：從最新的變更開始，逆序執行回滾操作恢復狀態：每個日誌條目的revert()方法會將狀態恢復到變更前清理日誌：刪除快照點之後的所有日誌條目func (s *StateDB) RevertToSnapshot(revid int) {    // 找到快照對應的日誌索引    idx := s.validRevisions[revid]    // 逆序回滾所有變更    for i := len(s.journal.entries) - 1; i >= idx; i-- {        s.journal.entries[i].revert(s)    }    // 清理無效的日誌條目    s.journal.entries = s.journal.entries[:idx]    s.validRevisions = s.validRevisions[:revid]}7.2 Gas不足錯誤Gas不足是智能合約執行中最常見的錯誤之一。當合約嘗試執行一個操作但沒有足夠的Gas來支付其成本時，EVM會立即停止執行並回滾所有狀態變更。這種機制確保了網路的安全性，防止了無限循環和資源濫用。7.3 呼叫資料不足錯誤當呼叫資料的長度不足以包含完整的函數參數時，EVM會採用特定的處理策略。對於缺失的資料，EVM會用零值填充，這可能導致意外的行為。理解這種機制對於編寫健壯的合約輸入驗證邏輯很重要。呼叫資料: 0x6057361d00  (缺少參數資料)執行流程:1. 函數選擇器匹配成功2. CALLDATALOAD 0x04 嘗試載入參數3. 呼叫資料長度不足，返回0值4. 將0儲存到storedNumber8. 總結通過這個詳細的執行示例，可以對EVM有了更直觀的認識。EVM最大的特點就是結果可預測，同樣的程式碼跑出來的結果肯定一樣，而且花費很透明，每個操作要花多少Gas都算得清清楚楚。它對資料管理很嚴格，合約的狀態都存在固定的槽位裡，記憶體用完就丟，臨時資料處理完就清理掉，出錯了還能回滾，把狀態恢復到執行前。從性能角度來說，儲存最燒錢，寫資料到鏈上是最貴的操作，記憶體越用越貴，用得多了成本會飛速上漲，所以傳輸資料要省著點，呼叫時少傳點資料能省Gas，不過常用資料便宜，經常訪問的資料Gas費用更低。寫程式碼的時候要記住幾個要點：儲存要精打細算，合理設計能省一大筆Gas；錯誤要提前想到，各種異常情況都要考慮；安全漏洞要防範，重入攻擊這些坑要避開；程式碼要寫得清楚，自己和別人都容易看懂。總的來說，EVM就是個既安全又高效的智能合約運行環境，掌握了它的脾氣就能寫出更好的合約。 (chaincat)

比特幣是最安全和去中心化的區塊鍊網絡，但存在不支持智能合約、每秒只能處理大約7筆交易、交易確認可能高達數十分鐘等性能上的限制。1月30日，NFT協議“Ordinals”在比特幣主網上啟動，截至3月2日，Ordinals上的NFT數量已經超過25萬。 雖然此舉引發了不少爭議，“比特幣原教旨主義”認為應該盡可能保持比特幣網絡的簡單和穩定，但“比特幣擴展者”希望能給比特幣帶來更多金融用例。不管怎樣，Ordinals的出現引發了又一波在比特幣之上開發應用的熱潮。 Stacks Stacks採用金字塔形的堆棧，底層是比特幣基礎結算層，然後是增加了智能合約和可編程性的Stacks，最上層是增加可擴展性和速度的Hiro。它使用自己的智能合約語言Clarity，並將歷史交易記錄寫入到了比特幣網絡中，因此Stacks是一個比特幣的Layer 2（以前Stacks也稱自己為Layer 1）。Stacks發行有自己的代幣$STX，作為比特幣智能合約的代表，$STX也是近期表現最好的資產之一。