學Midnight之前：3個思維陷阱讓Solidity開發者踩坑

如果你寫過以太坊智能合約，大概習慣了這套流程：學Solidity語法，寫合約，部署上鏈，執行時付gas費。邏輯簡單直接，狀態變化全網可見。

Midnight不一樣。它的編程語言Compact第一眼看著像TypeScript，但底層運行模型完全不同——本地執行、零知識證明、顯式公開。這不是"語法換皮"，是整個思維方式要換。

這篇文章講清楚：Midnight和EVM到底哪里不同，為什么Compact不能當成"又一個智能合約語言"來學，以及動手寫代碼前必須先理解的三個關鍵差異。

Compact的代碼確實不難讀。有類型聲明，有export關鍵字，整體風格接近TypeScript而非底層密碼學語言。這個第一印象降低了入門門檻，但也制造了誤解——你以為只是語法熟悉，其實執行方式完全陌生。

代碼能讀懂，不代表你知道它在哪運行、什么值會公開、網絡在驗證什么。把Compact當成"Solidity替代品"的人，很快會在實際開發中卡住。語法通了，設計邏輯卻對不上。

這篇文章就是來填這個坑的：語法熟悉，但思維要切換。

EVM的執行模型很直觀。執行發生在鏈上，狀態轉換也在鏈上處理。全網節點重復同一計算，按結果驗證狀態。好理解，但代價是執行過程和狀態默認公開。

Midnight反過來。用戶在本地做私有計算，網絡只驗證結果是否符合規則——用證明來驗證，而不是重算。最后只把公開的狀態變化寫進鏈。

所以在Midnight里，"調用函數"這個視角不夠用。你得同時問：這個計算在證明什么？結果會導向什么公開狀態？

EVM開發者熟悉的是賬戶模型。全局狀態里存著每個地址的余額，交易直接改這些數值。

Midnight從UTXO出發。核心資產機制基于UTXO結構，這種設計和隱私保護天然契合。不直接改余額，而是消耗舊輸入、創建新輸出。用EVM的語言說，"Alice余額減40，Bob余額加40"；用Midnight的語言說，"消耗舊UTXO，創建一個給Bob的輸出，一個給Alice找零的輸出"。

但Midnight不是純UTXO鏈。它用混合結構：賬本代幣走UTXO，但Compact寫的智能合約資產和邏輯，有時候又像賬戶模型那樣運作。

所以"EVM的對立面"這個描述也不準確。更準確的說法是：UTXO資產機制 + 可選的賬戶式合約行為 + 隱私與證明優先的鏈。

學Compact最常見的錯誤，是只當它在學新語法。實際上要同時分清三個語境：

EVM里，圍著狀態變量和函數調用轉，設計基本能跑通。Compact里，問題本身變了——不是"怎么調用"，而是"什么公開、什么證明、什么私有"。

邊界重新定義了。沒理解這個邊界，代碼能讀，但用這門語言做設計會寸步難行。

EVM網絡默認公開。不用聲明"這個值要公開"，上鏈即公開。

Midnight默認隱私，公開是顯式選擇。

所以Compact里用disclose()把witness或私有計算的值傳到賬本時，這不是什么輔助函數。它是開發者在代碼里明確表達"我要公開這個"的裝置。

這個設計意味著：disclose()不是語法怪癖，而是Midnight和EVM"默認公開"模型差異的最直接體現。

看到這里，核心已經清晰。把Midnight當EVM系技術棧來用，開頭覺得順手，真寫代碼時很快撞墻。

EVM開發的前設：狀態默認公開，執行在鏈上，隱私需要額外設計。Midnight的前設：狀態默認私有，執行在本地，公開需要顯式聲明。

學Midnight，不是背Compact語法。是在隱私和證明成為默認前提的環境里，重新學習怎么設計智能合約。