学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语法。是在隐私和证明成为默认前提的环境里，重新学习怎么设计智能合约。