Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

第三章:一个误解引发的连锁反应

一个十九岁少年的判断

2013 年末,一个十九岁的俄裔加拿大少年写出了一份白皮书的早期稿。

他叫 Vitalik Buterin。在此之前,他已经在比特币社区活跃了两年多——十七岁时参与创办了Bitcoin Magazine(并担任首席撰稿人),写过大量关于比特币技术和经济学的文章,对比特币的脚本系统有深入的了解。他不是一个门外汉。恰恰相反,他是当时比特币社区中最敏锐的年轻头脑之一。据Vitalik后来的回顾,他曾尝试在比特币生态内推进更通用的合约表达,但未获主流路线采纳。

但就是这个对比特币了如指掌的人,在他的白皮书中做出了一个关键判断:比特币的脚本语言太受限了。它不是图灵完备的,不支持循环,不能实现复杂的智能合约逻辑。如果想在区块链上构建去中心化应用——不只是转账,而是任意的、可编程的商业逻辑——就需要一个全新的平台。

这个判断,催生了以太坊。

以太坊后来成为市值第二大的加密货币,催生了 DeFi、NFT、ICO 等一系列现象级应用,重塑了整个行业的版图。数以千计的项目建立在它之上,数以百亿计的资金流入它的生态。以太坊将“通用型智能合约平台“推向主流,并重塑了这个品类。

但如果当初那个十九岁少年的判断本身就是错的呢?

如果比特币的脚本系统从来就能做智能合约,只是被人为阉割了呢?

这不是事后诸葛亮式的马后炮。这是一个需要被严肃审视的技术问题。因为如果起点是错的,那么从这个起点出发的整条路径——以太坊的架构选择、账户模型的设计、全局状态的引入、图灵完备虚拟机的构建——都需要被重新评估。一个误解,可能引发了一场持续十余年的连锁反应。

被削弱的比特币

要理解 Vitalik 的误解从何而来,必须先理解一段被大多数人遗忘的历史。

2009 年 1 月,中本聪发布了比特币的初始版本。这个版本中的脚本系统,远比今天大多数人想象的强大。它包含了丰富的操作码(opcodes):字符串拼接(OP_CAT)、子串提取(OP_SUBSTR)、位运算(OP_AND、OP_OR、OP_XOR)、乘法和除法(OP_MUL、OP_DIV)、左移右移(OP_LSHIFT、OP_RSHIFT)——这些操作码组合在一起,赋予了比特币脚本相当强大的数据处理能力。

然后,在 2010 年 8 月,中本聪做了一件事:他禁用了其中大量的操作码。

原因是安全漏洞。已明确记录的触发点包括OP_LSHIFT崩溃等漏洞,OP_CAT等操作码也被认为存在DoS风险,在同一轮安全收缩中一并禁用。这是一个真实的安全问题,中本聪选择了最直接的应对方式——直接禁用这些操作码。

这个决定在当时是合理的。比特币刚上线一年多,网络还很脆弱,用户极少,全网算力微乎其微,任何一个严重漏洞都可能是致命的。中本聪的做法类似于一个建筑师在发现脚手架不牢固时,先拆掉有问题的部分,等打好地基后再重新搭建。有观点认为,这些禁用本质上是临时的安全措施,一种解读是等网络成熟后可以评估如何安全地恢复——这是一个务实的工程决策。

中本聪在那段时间的其他行为也印证了这一点。他对比特币协议做了大量的修改和完善,始终保持着对代码的积极维护。禁用操作码是他整体安全加固工作的一部分,而不是某种对脚本功能的哲学性否定。

但问题是:中本聪在 2011 年离开了。

他没有留下一份路线图说“等网络稳定后,请恢复这些操作码“。他只是消失了。而接管比特币开发的 Bitcoin Core 团队,不但没有恢复这些操作码,反而在后来的版本中进一步限制了脚本的能力。需要指出的是,Bitcoin Core 也并非完全停止了脚本层面的演进——P2SH、CLTV、CSV、SegWit、Taproot 等升级在特定方向上增强了脚本的表达力和灵活性,但这些改进并未恢复早期被移除的通用数据处理操作码。这些被禁用的操作码,从“临时安全措施“变成了“永久性残疾“。

到 2013 年 Vitalik 审视比特币脚本系统时,他看到的是一个功能受限的版本。没有字符串操作,没有位运算,没有乘除法——一个难以承载通用应用逻辑的脚本系统。他得出“比特币脚本太受限“的结论,在当时的语境下,并不令人意外。

但这里存在一个关键的逻辑错误:他把人为施加的限制,当成了设计本身的局限。

这就好比看到一辆被拆掉了发动机的汽车,然后宣布“汽车不能自己移动,所以我们需要发明一种全新的交通工具“。汽车当然能自己移动——只是发动机被人拆了。你要做的不是发明新东西,而是把发动机装回去。

这个区分至关重要。如果比特币脚本的限制是设计层面的——即中本聪故意设计了一个功能受限的脚本系统——那么另建一个更强大的平台就是合理的选择。但如果限制是后天施加的——即比特币脚本本来就很强大,只是被人为禁用了——那么正确的做法应该是恢复它原有的能力,而不是推倒重来。

Vitalik没有推动比特币恢复原有能力,而是另起炉灶创建了以太坊。整个行业跟着他走上了一条完全不同的道路。

“世界计算机“的诞生

既然判断比特币“不能“做智能合约,Vitalik 的逻辑推演就顺理成章了:我们需要一个全新的区块链,一个从底层就为智能合约设计的平台。

2014 年,以太坊白皮书正式公开发布。在白皮书中,Vitalik 将比特币的脚本系统描述为“智能合约概念的一个弱版本“——这个判断精确地反映了他对比特币脚本能力的认知:不是完全没有,但远远不够。他的核心主张可以概括为一句话:构建一台“世界计算机“——一个去中心化的、图灵完备的计算平台,任何人都可以在上面部署和执行任意程序。

为了实现这个愿景,以太坊做出了一系列根本性的架构选择。这些选择在当时看起来都很合理,但每一个都埋下了日后的隐患。

第一个选择:图灵完备的虚拟机。

比特币脚本不支持循环——这在 Vitalik 看来是它最大的缺陷。以太坊的 EVM(以太坊虚拟机)支持循环,支持条件跳转,支持任意复杂的控制流。开发者可以用 Solidity 语言编写任何逻辑——理论上。

但图灵完备带来了一个经典的计算机科学问题:停机问题。对于任意一段图灵完备的代码,你无法在执行前判断它是否会终止。如果有人提交一段包含无限循环的智能合约,每个验证节点在执行它时都会陷入死循环,整个网络就瘫痪了。

比特币用一种极其优雅的方式回避了这个问题:由于不支持循环且存在多重资源限制(操作数大小、签名操作数、栈元素等),脚本执行具有静态上界。停机问题在语言层面被消除了。

以太坊选择了另一条路:引入 Gas 机制。每一步计算操作消耗一定数量的 Gas,用户在发起交易时预先支付 Gas 费用,Gas 耗尽时执行强制终止。这个方案可行,但代价是引入了一个全新的复杂子系统——Gas 价格需要估算(估高了浪费钱,估低了交易失败)、Gas费用受拥堵、MEV、区块空间竞争等因素影响,用户体验和费用可预测性长期是以太坊的一大难题、Out-of-Gas 导致交易回滚但手续费照扣(用户花了钱却什么都没得到)。比特币用一条简洁的语言约束解决的问题,以太坊用一套持续演化的经济机制来应对——而这套机制本身不断产生新的问题。

第二个选择:账户模型。

这是以太坊做出的最根本、影响最深远的架构决策。比特币使用 UTXO(未花费的交易输出)模型,以太坊选择了账户模型。Vitalik 选择账户模型的理由很直接:它更容易编程。对于习惯了传统数据库开发的程序员来说,账户模型就像银行系统的数据库——每个用户有一行记录,交易就是修改记录中的数字。直观、简单、上手快。而 UTXO 模型对大多数开发者来说是陌生的,它要求一种完全不同的思维方式。

但这两种模型之间的差异,不是开发便利性的差异,而是哲学层面的根本分歧。要理解以太坊后来遇到的几乎所有困境,都要从这个选择说起。

第三个选择:全局可变状态。

账户模型的直接后果是:以太坊需要维护一个全局的、可变的状态树。每个账户的余额、每个智能合约的存储数据,都记录在这棵巨大的状态树中。任何一笔交易都可能读取和修改这棵树上的任意节点。这个设计决策的后果,我们将在后面详细分析。

这三个选择——图灵完备虚拟机、账户模型、全局可变状态——共同构成了以太坊的架构基因。它们之间是紧密耦合的:因为选择了图灵完备,所以需要 Gas 机制来防止无限循环;因为选择了账户模型,所以需要全局状态来追踪每个账户的当前状态;因为有了全局可变状态,图灵完备的合约才能实现复杂的状态转换逻辑。

这套架构让开发者可以用接近传统编程的方式来编写智能合约——这是它的巨大优势,也是它迅速获得开发者青睐的原因。但这套架构也从第一天起就注定了以太坊将面临一系列结构性的困境——扩容瓶颈、状态膨胀、安全漏洞。这些不是可以通过“更好的代码“来修复的 bug,而是架构本身的必然产物。

硬币与账本:两种记账的哲学

要理解以太坊的困境从何而来,必须先理解 UTXO 模型和账户模型的根本差异。这不是两种技术方案之间的比较,而是两种完全不同的思维方式。

先从日常经验出发。

想象你身上有 100 块钱。在不同的记账方式下,这 100 块钱的“存在方式“完全不同。

UTXO 模型:硬币式记账。

你的 100 块钱不是一个数字,而是一堆具体的“硬币“——可能是一张 50 元纸币加两张 20 元加一张 10 元。每一张纸币都是一个独立的、具体的存在。当你要买一杯 30 元的咖啡时,你掏出那张 50 元纸币递给老板,老板找你 20 元。在这个过程中,那张 50 元纸币被“消费“了(不再属于你),同时产生了两个新的“硬币“:一个 30 元归老板,一个 20 元归你。

比特币的 UTXO(Unspent Transaction Output,未花费的交易输出)就是这样运作的。事实上,在比特币的源代码中,UTXO 的数据结构就叫 Coin——硬币。每一笔交易消费一组已有的“硬币“(输入),产生一组新的“硬币“(输出)。你的“余额“不是存储在某个地方的一个数字,而是所有属于你的、还没有被花费的“硬币“的总和。

账户模型:银行式记账。

你的 100 块钱就是银行数据库里的一个数字:“张三,余额 100 元”。当你买咖啡时,银行把你的余额从 100 改成 70,把咖啡店的余额加 30。没有“硬币“被传递,只有数字被修改。你的“钱“不是一个独立存在的东西,而是一个中心化数据库中一行记录的一个字段。

以太坊的账户模型就是这样运作的。每个地址都有一个“账户“,账户里记录着余额、nonce(交易计数器),如果是智能合约账户,还记录着合约代码和存储数据。转账就是修改两个账户的余额数字。所有这些账户信息汇聚在一起,构成了一棵巨大的全局状态树——以太坊的每个节点都必须维护这棵树的完整副本。

表面上看,账户模型更直观、更简单——毕竟我们每天使用的银行系统就是账户模型。但这种直觉上的“简单“,在区块链的语境下会带来一系列深刻的后果。

区别的本质在于:UTXO 模型中,“钱“是独立的对象;账户模型中,“钱“是共享状态的一个属性。

这句话听起来很抽象。让我用一个类比来说明它为什么重要。

想象一个巨大的农贸市场。在 UTXO 的世界里,每个人都拿着自己的硬币在不同的摊位前交易。你在东头买苹果,我在西头买白菜,两笔交易同时发生,互不干扰——因为你用的是你的硬币,我用的是我的硬币,我们之间没有任何共享的状态。一千个人可以同时在一千个摊位前交易,市场的吞吐量随摊位和交易者的数量线性增长。

而在账户模型的世界里,整个农贸市场只有一个收银台。每个人的余额都记录在收银台的大账本上。你买苹果——排队走到收银台——收银员翻开账本,找到你的名字,修改余额——然后下一个人。我要买白菜?对不起,请排队。因为收银员正在修改的那本账本是共享的,任何两笔涉及同一本账本的交易都必须排队——否则就会出现经典的数据库竞态条件:两个人同时读取余额100,各扣50,写回的都是50,结果只扣了50而不是100。

这就是 UTXO 模型和账户模型在并行处理能力上的根本差异。它不是一个可以通过优化来弥合的性能差距,而是数据结构本身决定的结构性差异。

全局状态的诅咒

账户模型的核心特征是全局状态——一个巨大的、所有节点都必须维护的状态树,记录着以太坊上每一个账户的余额、每一个智能合约的存储数据、每一段合约代码。

这棵状态树有多大?截至 2025 年,节点存储需求持续增长,全节点已在数TB量级,归档节点根据客户端与模式不同在数TB至20TB以上不等。这个数字还在持续增长。

但真正的问题不是存储空间的大小,而是全局状态对系统架构施加的一个不可逾越的约束:串行执行。

在以太坊中,任何一笔交易都可能读取和修改全局状态树上的任意节点。一个 DeFi 合约可能在一笔交易中同时访问多个代币合约的状态、价格预言机的数据、流动性池的余额。这意味着,在交易执行之前,你无法确定这笔交易会访问状态树的哪些部分。

当两笔交易可能访问状态树的相同部分时,它们就不能并行执行——必须一笔一笔按顺序来。而在以太坊的 DeFi 生态中,大量交易都会访问同一组热门合约(Uniswap、Aave、USDT 合约等),状态依赖无处不在。

结果是:当前以太坊主网执行以顺序语义为主;账户模型与全局状态使安全、通用的并行执行明显更难实现。

以太坊的 nonce 机制进一步强化了这种串行性。每个账户有一个递增的 nonce 值,从同一账户发出的交易必须严格按 nonce 顺序执行。即使网络中有一千笔来自不同账户的交易可以并行处理,只要其中有几笔涉及同一个热门合约,整个执行流水线就被卡住了。

这就是为什么以太坊的吞吐量始终无法突破每秒几十笔交易的数量级,即使硬件性能在这十多年间提升了几个数量级。瓶颈不在硬件,而在数据结构。你可以给汽车换一台更强劲的发动机,但如果道路只有一条单车道,再强劲的发动机也无法提高通行量。全局共享状态就是那条单车道。

UTXO 模型不存在这个问题。每个 UTXO 是一个独立的、自包含的状态单元,不引用任何全局状态。消费不同 UTXO 的两笔交易之间数据依赖为零,可以同时处理。冲突检测极其简单——只需检查两笔交易是否试图消费同一个 UTXO。这是最理想的并行化场景:零共享状态,零通信开销。

类比成计算机科学的术语:UTXO 模型是一个天然的无锁数据结构(lock-free data structure),而账户模型是一个需要全局锁的共享内存模型。任何一个有并发编程经验的工程师都知道,全局锁是性能的死敌。你可以加更多的 CPU 核心,但只要存在全局锁,多核的性能提升就会被锁竞争抵消殆尽——这就是著名的阿姆达尔定律(Amdahl’s Law)。

以太坊团队当然不是不知道这个问题。他们最初的扩容路线图就包含了“执行分片“——把状态树分成多个分片,每个分片独立执行交易,以此实现并行化。但这个方案最终被放弃了。原因很简单:账户模型下,跨分片交易极其难以处理。DeFi 的核心卖点是“可组合性“——一笔交易可以同时调用多个合约,像乐高积木一样组合。如果这些合约分布在不同的分片上,可组合性就会被打破。以太坊最终转向了 Rollup 路线——部分源于执行分片在账户模型和组合性要求下实现复杂、权衡困难,而不是单一原因导致的转向。

中本聪选择 UTXO 模型不是偶然的。扩容的瓶颈不应该在数据结构上——数据结构的限制是一堵硬墙,加再多硬件也突破不了。真正的瓶颈应该在带宽和存储上——而这些是随硬件技术进步持续改善的工程参数。UTXO 模型把瓶颈放在了正确的地方,账户模型把瓶颈焊死在了错误的地方。

一只价值六千万美元的蝴蝶

全局可变状态不仅造成了扩容困境,还带来了更加直接和惨痛的后果——安全灾难。

2016 年 6 月 17 日,以太坊历史上最臭名昭著的事件发生了。

“The DAO”——一个建立在以太坊上的去中心化投资基金——在上线仅两个月后被黑客攻破。The DAO 的构想很宏大:它通过众筹募集了价值约 1.5 亿美元的以太币(约1150万枚ETH),成为当时最大的众筹项目之一。投资者持有 DAO 代币,可以投票决定基金的投资方向——这是一个完全由代码驱动的、没有董事会的投资基金。但攻击者利用一个叫做“重入攻击“(reentrancy attack)的漏洞,从合约中转走了价值约 6000 万美元的以太币(其中约360万枚ETH在攻击中被转入child DAO)——占总资金池的三分之一,也占当时以太币总市值的近 15%。

重入攻击的原理,暴露了全局可变状态的致命缺陷。

简化来说,The DAO 的提款函数执行了这样的逻辑:先把钱发给用户,再更新用户的余额。看起来没什么问题——攻击者利用合约在接收转账时自动执行代码的特性,劫持了程序的执行流。直到你意识到,在以太坊的账户模型中,“发钱“这个操作本身可以触发接收方的代码执行。攻击者部署了一个恶意合约作为接收方,这个合约在收到钱的瞬间,立即再次调用 The DAO 的提款函数——而此时 The DAO 还没来得及更新余额,所以它会再次发钱。如此反复,将大量ETH递归转入child DAO;这些资金当时并非立即可提取,但足以触发全网危机与硬分叉争论。

用日常语言来描述:这就像你去银行取钱,银行先把钱给你,然后才在账本上更新余额。而你在银行更新余额之前,又跑去另一个柜台说“我要取钱“,银行一查账本——余额还没扣呢——于是又给你一次。如此循环,直到保险箱搬空。

在现实的银行系统中,这种事不会发生——因为银行的每一步操作都在一个事务(transaction)中原子性地完成,余额扣除和资金转出是同步的。但在以太坊的智能合约中,全局状态的修改顺序完全由合约代码决定。如果开发者写错了顺序——先转账、后更新状态——重入漏洞就出现了。

这不是某个程序员的低级错误。这是全局可变状态在智能合约环境中的结构性风险。

在传统软件工程中,全局可变状态(global mutable state)早已被公认为错误的温床。每一本软件工程教科书都会告诫你:尽量减少可变状态,尽量避免全局变量,因为当多个代码路径可以修改同一份数据时,bug 会以组合爆炸的方式增长。这就是为什么现代编程语言越来越强调不可变性(immutability)和局部状态(local state)。

而以太坊的智能合约环境,恰恰是全局可变状态的极端场景。所有合约共享同一个全局状态树。任何合约都可以调用任何其他合约,而被调用的合约可以修改全局状态,然后返回调用方——调用方可能完全不知道全局状态已经在它脚下被改变了。这种环境下,安全漏洞不是意外,而是必然。

The DAO 事件之后,以太坊社区做了什么?他们投票决定进行一次硬分叉——直接在协议层面把攻击者窃取的资金转回来。这个决定本身就充满了讽刺:一个号称“Code is Law“(代码即法律)的平台,在代码按照规则执行了一次攻击之后,选择了人为干预来逆转结果。这次硬分叉导致以太坊社区分裂为两条链——以太坊(ETH)和以太坊经典(ETC)。后者坚持“代码即法律“的原则,拒绝逆转交易。

但比硬分叉的哲学争议更重要的是,The DAO 事件暴露的安全问题从未被根本解决。重入攻击只是全局可变状态引发的安全漏洞中最早的、最有名的一种。在此之后,以太坊生态经历了一波又一波的安全事故:

整数溢出攻击、闪电贷操纵预言机、抢跑交易(front-running)、三明治攻击、代理合约升级漏洞、访问控制缺陷——全局可变状态显著放大了合约交互复杂度;与此同时,语言设计、mempool透明性、预言机架构和权限管理也分别构成独立风险源。每部署一个新合约,它就成为全局状态树上一个新的可读写节点,与所有其他合约产生潜在的交互——以及潜在的漏洞。

截至 2025 年,以太坊及其 EVM 兼容链上的智能合约安全事故累计造成的损失已达逾百亿美元。这不是因为开发者不够聪明,不是因为审计公司不够尽职——而是因为在全局可变状态的架构上编写安全的代码,从根本上来说就是一场永无止境的军备竞赛。攻击面是架构决定的,防御只能在应用层打补丁。

UTXO 模型的安全特性与此形成鲜明对比。在 UTXO 模型中,每个 UTXO 是独立的状态单元,脚本只能访问当前交易的输入和输出——没有全局状态可以被意外读取或修改。一笔交易的执行不会影响另一笔交易的状态。重入攻击在 UTXO 模型中根本不存在——因为没有“在转账过程中被回调“的可能性。脚本验证是纯函数式的:给定输入,产生确定的输出,没有副作用。

这不是说 UTXO 模型上的智能合约绝对不会有 bug。任何软件都可能有 bug。但 UTXO 模型的架构从结构上消除了整类安全漏洞——那些由全局可变状态引发的漏洞。就像函数式编程不能保证你的程序不出错,但它通过消除副作用,从结构上消除了并发 bug 中最常见、最难调试的一大类。这是架构层面的安全优势,不是应用层面的补丁。

状态膨胀:一个只会变大、不会变小的问题

全局状态还有一个更隐蔽、更长期的问题:它只增长,不收缩。

在以太坊上,任何人都可以创建一个智能合约,在合约中写入任意数据。这些数据一旦写入状态树,就永久存在。即使合约不再被使用,即使账户余额归零,它们在状态树中占据的空间也不会被释放。因为任何未来的交易都可能引用这些“过时“的状态——在全局可变状态的模型中,你无法安全地删除任何东西,因为你不知道是否有其他合约依赖它。

这就是“状态膨胀“(state bloat)问题。2025 年,以太坊基金会的 Stateless Consensus 研究团队公开警告:网络中不断膨胀的账户记录、合约存储和字节码数据,正在让节点运营者面对越来越沉重的存储、同步和服务负担。

状态膨胀造成的直接后果是:运行全节点的门槛越来越高。一个普通用户在家里的电脑上运行以太坊全节点,需要至少 2TB 的高速 SSD 存储、16GB 以上的内存、稳定的高速网络连接。这些硬件要求不是一次性的——随着状态的持续增长,你隔几年就需要升级一次硬件。当这个门槛高到只有数据中心和大型机构才能轻松承受时,网络的去中心化程度就会不知不觉地下降。少数大型节点运营商——Infura、Alchemy等基础设施服务商——它们在RPC访问与状态服务层面拥有很强的集中度,影响用户和开发者接入网络的方式,大多数用户和开发者通过这些中心化服务商来访问以太坊网络,而不是运行自己的节点。这与区块链“无需信任、无需许可“的初衷背道而驰。

以太坊社区正在研究多种应对方案——状态过期(State Expiry)、无状态客户端(Statelessness)、Verkle 树——但这些都是在既有架构上的补丁。它们试图缓解症状,但不能改变根因:账户模型需要全局状态,全局状态必然持续膨胀。

UTXO 模型没有这个问题。UTXO被消费后就从活跃集合中移除——活跃状态集具有天然回收机制,但链历史本身仍持续增长,两者需严格区分。UTXO 集合的大小取决于当前未花费的交易输出数量,而不是历史上所有交易的累积。这是一个自然的“垃圾回收“机制——旧的 UTXO 被花费,新的 UTXO 被创建,状态集合在动态平衡中保持合理的大小。你可以把它想象成一个水池,一边有水流入(新创建的 UTXO),一边有水流出(被花费的 UTXO),水位(状态大小)在进出之间保持大致稳定。而以太坊的全局状态更像一个只有进水管没有出水管的蓄水池——水位只能升,不能降。

连锁反应的全貌

现在我们可以回过头来,看清这场连锁反应的完整链条:

第一环:操作码被禁用。 2010年中本聪出于安全考虑禁用了大量操作码,这本是一个临时的安全措施。但中本聪的离开使得这个临时决策失去了纠正的机会。后续的 Bitcoin Core 团队不仅没有恢复这些操作码,反而在“小区块“的路线下进一步限制了比特币的能力。一个工程决策,就这样演变成了意识形态的一部分。

第二环:行业形成“比特币不能做智能合约“的共识。 当人们审视功能受限的比特币脚本系统时,看到的是一个功能极其有限的东西。没有人去追问“它本来能做什么“,所有人都接受了“它就是这样“的现状。这个误解从一个技术判断变成了行业共识,从行业共识变成了不言自明的前提。

第三环:以太坊诞生。 既然比特币“不能“做智能合约,那就需要一个新的平台。以太坊应运而生,带着全新的架构设计——账户模型、全局状态、图灵完备虚拟机。

第四环:账户模型的代价逐一浮现。 串行执行导致吞吐量瓶颈。全局可变状态导致安全漏洞层出不穷。状态膨胀导致节点成本持续攀升。每一个问题都有直接的经济后果——拥堵时高达数百美元的 Gas 费、The DAO 等安全事件中数十亿美元的损失、日益中心化的节点基础设施。

第五环:L2 和 Rollup 成为“解决方案“。 当主链扩容被架构瓶颈卡死时,行业转向了链下扩容——把交易推到 Layer 2 上执行。但正如上一章所分析的,许多现阶段L2在排序器、升级权限、退出路径等方面仍存在不同程度的信任假设,这与比特币式最小信任目标之间形成张力。

第六环:千链万链的碎片化世界。 以太坊的“成功“证明了“智能合约平台“这个品类的商业价值,于是 Solana、Avalanche、Cardano、Polkadot……数以百计的“以太坊杀手“涌现出来,每一个都宣称比以太坊更快、更便宜、更安全。它们各自做出了不同的工程取舍——有的选择更高的节点硬件要求来换取吞吐量,有的采用不同的共识机制,有的在编程语言上另辟蹊径——但没有一个从根本上反思账户模型本身的问题。结果就是第一章描述的那个碎片化世界——上百条互不兼容的链、资产被困在孤岛上、跨链桥成为黑客的提款机。

回顾这条链条,每一环都有其内在逻辑。Vitalik 看到了受限版的比特币脚本,得出了合理的结论;以太坊的架构设计在当时的认知水平下是一致的;L2 是在主链扩容受阻后的自然反应;其他公链的涌现是市场对以太坊不足的回应。每一步单独来看都“说得通“。

但如果第一环的前提就是错的——如果比特币脚本从来就能做智能合约,只是被人为阉割了——那么整条链条都建立在一个虚假的前提之上。

被遗忘的可能性

如果中本聪当初禁用操作码只是临时的安全措施,而不是永久的设计决策,那么正确的技术路径应该是什么?

答案其实不复杂:恢复比特币脚本原有的操作码,在 UTXO 模型的基础上实现智能合约。不需要发明新的共识机制,不需要设计新的虚拟机,不需要创建新的代币——若要沿这一路线推进,本质上仍需要新的共识升级——只是升级方向是恢复或重建早期被移除的能力,而非另起一种全局状态架构。然后在已经被证明有效的架构基础上向前发展。

单个比特币脚本确实不支持循环,因此单个脚本不是图灵完备的。但比特币的交易模型允许一种更深层的计算范式:每笔交易消费一组 UTXO,执行脚本验证,产生新的 UTXO 携带新状态。每笔交易是一个计算步骤,交易链是一个计算序列。单个步骤保证终止——没有无限循环的风险——但步骤序列可以无限延伸,从而实现任意复杂度的计算。

本文主张,若把跨交易状态传递纳入统一计算模型,UTXO系统可以逼近或实现通用计算能力——后续章节将进一步论证这一观点。安全性和计算能力在不同的层面上被分别保证。这是一个极其优雅的设计:在微观层面用简单性保证安全,在宏观层面用组合性实现通用计算。

这不是纯理论。sCrypt、RUN 等项目已经在实践中证明(值得注意的是,这些项目运行在 BSV 等恢复了原始操作码的 UTXO 链上,而非 BTC 主网):开发者可以使用高级语言编写基于 UTXO 模型的智能合约,已实现状态化智能合约、代币协议、零知识证明验证等功能。比特币不需要一个单独的“智能合约平台“——它本身就是一个。

但这个可能性,在 2013 年被行业集体忽略了。原因并不神秘:当时比特币脚本已经被削弱了三年,而 Bitcoin Core 团队没有任何恢复操作码的意愿。在这种现实下,Vitalik 选择另起炉灶,而不是说服比特币社区恢复脚本功能,是一个可以理解的决定。

问题不在于 Vitalik 的决定——问题在于整个行业在此后十多年间,从未回头审视那个最初的前提。“比特币不能做智能合约“这句话被重复了太多次,以至于没有人再去质疑它。一个由人为决策导致的临时限制,被当作了技术架构的固有属性。一代又一代的开发者在这个错误的前提上建造了整个生态系统。

关于比特币脚本的完整能力,以及 UTXO 模型如何在保持安全性的同时实现图灵完备的智能合约,我们将在第十四章中做详细的技术论证。这里只需要记住一个核心结论:以太坊要解决的那个问题——“在区块链上实现可编程的智能合约”——从一开始就不需要一个全新的平台来解决。

代价的清单

让我们用一张清单来总结这个误解造成的代价。

扩容困境。 账户模型的串行执行瓶颈使以太坊的吞吐量被锁死在每秒几十笔交易。即使硬件性能提升了几个数量级,这个瓶颈依然存在。UTXO 模型的天然并行性意味着吞吐量可以随硬件性能线性扩展——在并行验证上具有更好的工程潜力。

安全灾难。 全局可变状态催生了重入攻击、闪电贷操纵、三明治攻击等一整个类别的安全漏洞。自 The DAO 事件以来,以太坊生态因智能合约漏洞造成的累计损失达逾百亿美元。UTXO 模型的无全局状态设计从架构层面消除了这些漏洞类别。

状态膨胀。 全局状态只增不减,运行全节点的成本持续攀升,网络的去中心化程度在不知不觉中下降。UTXO 模型的自然状态回收机制不存在这个问题。

生态碎片化。 以太坊的“成功“催生了数百个竞争性公链,导致了第一章描述的碎片化灾难——资产困在孤岛上,跨链桥成为安全噩梦,用户转个账要先搞清楚网络拓扑。

L2 信任倒退。 主链扩容受阻后,行业转向 L2 方案,重新引入了中心化排序器和“先信任再申诉“的信任模型——这正是中本聪当初要消除的东西。

这些代价不是独立的事件,而是一条因果链上的环环相扣。每一个代价都可以追溯到同一个源头:在一个错误的前提上做出的架构选择。

历史无法重来。以太坊已经存在,它的生态已经建立,数以亿计的资金已经流入。成千上万的开发者在以太坊上投入了他们的才华和青春,构建了真实可用的应用——DeFi 让金融操作对任何人开放,NFT 让数字艺术有了稀缺性的可能,DAO 让组织治理有了全新的实验场。这些创新的价值是真实的,参与者的努力是值得尊重的。

但理解这段历史的意义在于:它帮助我们看清当下的困境不是偶然的,不是因为工程师不够聪明,不是因为资金不够充裕——而是因为在出发的那一刻,方向就偏了。以太坊试图解决的问题是真实的——区块链需要智能合约能力。但它给出的答案,建立在一个错误的前提之上。

好消息是:正确的技术路径并没有消失。它一直在那里,等待被重新发现。比特币的 UTXO 模型和脚本系统,经过恢复和完善,完全可以承载以太坊试图实现的一切功能——而且没有全局状态的诅咒、没有串行执行的瓶颈、没有状态膨胀的无底洞。

正本清源的第一步,是承认那个误解的存在。