资产走 UTXO、合约走账户：Alephium 的 Stateful UTXO 两本账

两种账本的旧账

智能合约平台几乎都选了账户模型：每个地址挂一个余额字段，合约读写全局状态；Bitcoin 一脉的 UTXO 模型则把每一笔钱表示成”销毁旧输出、生成新输出”，天然可并行、授权边界清晰，但很难承载可变状态，“状态”只能编码进交易结构里。Alephium 的选择不是二选一，而是把账本劈成两半：所有资产——原生币 ALPH 和其他代币——由 UTXO 管理，智能合约的状态则用账户式结构管理。官方文档把这套组合称为 Stateful UTXO，缩写 sUTXO。这个切法直接决定了用户和开发者看到的两件事：其一，代币不是合约账本里的数字，而是归地址所有的 UTXO 碎片；其二，合约可以有可变状态，但每个合约地址在系统里恰好只有一个 UTXO，这个唯一输出是合约资产进出的总闸门。

“今天的输出今天不能花”的三条禁令

一笔交易分输入与输出，sUTXO 定了条硬规矩：交易自己生成的输出，不能再被同一笔交易花掉。官方文档把这条规则放到合约场景里举了三个例子：Alice 从借贷平台拿到贷款后，不能在同一笔交易里顺手拿这笔钱去买 NFT；Bob 从某个 HODL 合约取款的同时，Eve 不能在同一笔交易里也从该合约取款；Alice 转给 Bob 的资产，Bob 也不能在同一笔交易里转回去。原因在于合约资产必须穿过那个唯一 UTXO：每笔交易都会销毁并重建它，依赖自身输出的交易在并发下会自相打架。Danube 升级之后，官方文档记录了一处放宽：交易脚本 TxScript 可以把多个合约调用之间、属于交易发起者本人的资产输出串起来用，但别人的资产输出与合约输出仍然受老规矩约束——组合性放开了一个缺口，安全边界没有拆。

授权那一笔，去哪了

账户模型绕不开 approve：代币登记在合约账本里，所以先签一纸”允许合约动我的币”，授权本身成了经典风险源——无限授权、误授权、忘撤销。Alephium 没有这道手续，官方文档称之为隐式同意：只要交易里某个包含特定代币的输入被授权花费，就说明主人已经同意这笔代币在本次交易语境内被使用，同一笔交易里被调用的合约可以直接转移它。授权范围从”发给合约的一张长期通行证”塌缩成”这一笔交易”本身，过期授权的风险面直接消失。对应到用户直觉：签名时看到的就是本次换手的完整边界，而不是又给某个合约开了一张不知道什么时候会用完的支票。

分片、尘埃与押金

Alephium 同时是一条分片链：官方文档写明主网当前运行 4 个分组、共 16 条链（数字以文档当前版本为准），dApp 需要知道自己落在哪个分组、哪条链上，跨组交互要按分片架构来设计。更特别的是防状态膨胀的经济设计：普通 UTXO 输出不得低于 0.001 ALPH 的尘埃门槛（dust amount），低于则整笔交易无效；合约 UTXO 的最低押金（minimal contract deposit）为 0.1 ALPH，由于 Ralph 语言里的 map 类型靠子合约实现，每新增一个映射条目还要再存一笔同额的条目押金。押金不是消费：合约销毁后可以领回。把价格立在那里的目的，是让开发者为状态占用付费，把合约总数与状态规模压在健康水位——这套账同时约束了合约 UTXO 集合与账户模型那半边状态的大小。

语言与用户之间

以上机制由自研的 Ralph 语言与 Alphred 虚拟机承载；除合约外，平台还有 TxScript 这一组件：不部署新合约也能执行的一次性或可复用逻辑，把多个合约调用组合进同一条交易，省去”聚合合约”的部署开销。对用户，sUTXO 的形态意味着代币无需长期授权、合约动钱的边界更清楚；也因为”同笔交易不得花自身输出”的限制，一些在 EVM 上一键完成的多步操作会被组织成一次 TxScript 调用，交互手感与熟悉的链有差异。这是一条以资产安全与可扩展性为卖点、但生态仍在建设中的公链；本文按官方文档机制口径解释，数字与参数可能随升级变化，不构成投资建议。