从真实业务场景出发，学习如何使用 SilverScript 构建一个基于 Kaspa UTXO 的 Escrow（托管）智能合约。

在上一篇文章中，我们已经了解了 SilverScript 合约从编写到部署的完整流程。本篇将通过一个经典的 Escrow（第三方托管） 案例，学习如何设计状态、编写合约逻辑，以及理解 UTXO 模型下的状态迁移。

说明： 目前 SilverScript 仍处于早期开发阶段，官方语言语法和标准库仍可能发生变化。本文示例采用的是接近 SilverScript 设计目标的伪代码，重点在于讲解设计思想，而不是固定语法。

一、什么是 Escrow？

Escrow（托管）是区块链最经典的智能合约应用之一。

例如：

Alice 想购买 Bob 的 NFT。

但是：

• Alice 担心付款后收不到 NFT。

• Bob 担心先发 NFT 后收不到钱。

于是双方约定：

把资金先锁定到一个智能合约中。

只有满足条件：

• Bob 完成交付；

• Alice 确认收货；

资金才会释放。

如果超时，则自动退款。

整个流程如下：

Alice
  │
  │ 100 KAS
  ▼
Escrow Contract
  │
  ├──────────────► Bob（交易成功）
  │
  └──────────────► Alice（超时退款）

这就是一个典型的 Escrow。

二、UTXO 模型下如何实现 Escrow？

很多 Solidity 开发者会想到：

mapping(...)
balance
status

但是在 Kaspa 中：

没有 Storage。

状态全部保存在：

Contract UTXO

例如：

Escrow UTXO

Amount = 100

Buyer = Alice

Seller = Bob

ExpireHeight = 520000

当有人消费这笔 UTXO 时：

新的状态重新写入新的 UTXO。

因此：

State0

↓

State1

↓

State2

每一次交易：

都是新的状态。

旧状态：

已经被 Spend。

三、设计 Escrow 状态

首先，我们需要定义状态。

contract Escrow {

    pubkey buyer;

    pubkey seller;

    uint64 amount;

    uint64 expireHeight;

}

四个字段即可描述整个托管关系。

分别表示：

UTXO 自身：

就是这一份状态。

四、设计业务流程

Escrow 一般只有两个出口。

第一种：

卖家收款。

第二种：

买家退款。

流程图如下：

          Escrow

        /         \

 Deliver OK      Timeout

    │               │

    ▼               ▼

 Seller         Buyer

因此：

整个合约只有两条执行路径。

五、卖家领取资金

首先：

卖家提交：

Seller Signature

然后：

合约验证：

function release(sig sellerSig){

    require(checkSig(sellerSig,seller));

}

如果验证成功：

允许 Spend。

生成：

Output

↓

Seller Wallet

资金完成释放。

是不是很简单？

因为：

Kaspa Script 本质就是：

验证条件。

六、超时退款

第二种情况。

如果：

卖家一直没有交付。

怎么办？

加入：

Block Height。

例如：

function refund(sig buyerSig){

    require(

        currentHeight > expireHeight

    );

    require(

        checkSig(buyerSig,buyer)

    );

}

逻辑非常简单：

满足两个条件：

• 已经超时

• 买家签名正确

允许退款。

七、Contract 生命周期

部署之后：

整个 Escrow 生命周期如下。

第一步

Alice 创建：

Deploy Transaction

生成：

Escrow UTXO

100 KAS

资金被冻结。

第二步

Bob 发货。

Alice 收货。

Bob 发起：

Spend Escrow

节点开始执行：

Unlock Script

+

Lock Script

验证：

Seller Signature

成功。

输出：

100 KAS

↓

Seller

Escrow 完成。

第三步（另一条路径）

如果：

一直没有发货。

区块高度：

Current Height

>

Expire Height

Buyer：

发起：

Refund Transaction

验证：

Buyer Signature

+

Timeout

成功。

输出：

100 KAS

↓

Buyer

资金自动退回。

八、UTXO 如何表示状态迁移？

很多开发者最难理解这一点。

Ethereum：

Escrow

status = OPEN

后来：

status = CLOSED

Storage 被修改。

Kaspa：

不是。

而是：

UTXO A

↓

Spent

↓

UTXO B

或者：

UTXO A

↓

Seller Wallet

根本没有：

"修改状态"

只有：

"生成新状态"

所以：

UTXO：

就是：

状态。

九、加入仲裁人（Arbitrator）

现实中：

很多 Escrow：

还有第三方。

例如：

Buyer

Seller

Arbitrator

那么：

逻辑可以变成：

Seller Signature

OR

Buyer Signature

OR

Arbitrator Signature

SilverScript：

可以写成：

function arbitrate(sig arbSig){

    require(

        checkSig(arbSig,arbitrator)

    );

}

这样：

平台客服：

即可完成仲裁。

十、加入多签

进一步升级。

例如：

DAO 托管。

需要：

2 / 3

Signatures

例如：

Alice

Bob

Carol

满足：

任意两人签名。

即可：

Spend。

这就是：

经典：

M-of-N MultiSig。

未来：

SilverScript：

完全可以支持：

checkMultiSig()

生成：

对应：

Kaspa Script。

十一、Escrow 可以扩展哪些功能？

一个真实商业级 Escrow。

一般还会加入：

Hash Lock

例如：

SHA256(secret)

只有知道：

Secret。

才能领取资金。

实现：

HTLC。

Time Lock

例如：

After 1000 Blocks

才能：

Refund。

Partial Payment

例如：

100

↓

30

↓

70

分阶段付款。

DAO Governance

例如：

DAO：

投票。

决定：

资金释放。

NFT Escrow

例如：

同时：

锁定：

NFT

KAS。

完成：

Swap。

十二、完整生命周期

最后，我们把整个 Escrow 的生命周期串起来。

开发者

↓

编写 Escrow

↓

SilverScript Compiler

↓

Kaspa Script

↓

Deploy Transaction

↓

Escrow UTXO

↓

等待 Spend

↓

验证条件

↓

Seller Release

或

Buyer Refund

↓

Escrow 完成

整个过程中：

真正执行的：

始终都是：

Kaspa Script。

SilverScript：

只是：

帮助开发者：

生成：

Script。

总结

Escrow 是理解 SilverScript 最好的案例，因为它几乎涵盖了 UTXO 智能合约的所有核心概念：

• 状态即 UTXO：没有全局 Storage，每个 UTXO 都代表一个状态快照。

• 规则即脚本：合约本质上是锁定脚本，定义了资产可以在什么条件下被花费。

• 状态迁移即交易：每一次 Spend 都会消耗旧状态，并创建新的状态或直接完成资产释放。

• 验证优先于执行：Kaspa 原生脚本更强调条件验证，而不是像 EVM 那样维护一个长期运行的虚拟机。

掌握了 Escrow 的设计思路之后，就已经具备了开发更复杂 UTXO 智能合约的基础。