从 Hello World 到部署 kaspa Mainnet，完整理解 SilverScript 合约生命周期

上一篇文章《SilverScript 入门：Kaspa 智能合约语言架构解析》中，我们介绍了 SilverScript 的整体架构，理解了编译器的工作原理。

这一篇，我们将站在开发者的角度，完整走一遍一个智能合约从编写、编译、部署到链上执行的全过程。

看完本文，你将理解：

• SilverScript 合约是如何编写的

• 编译器生成了什么

• 合约如何部署到 Kaspa

• 节点如何执行 Script

• 一笔交易如何驱动智能合约运行

一、Kaspa 合约与 Ethereum 合约最大的区别

很多开发者第一次接触 SilverScript 时，最大的误区就是：

它是不是 Solidity？

答案是：

不是。

Ethereum：

Account
    │
Storage
    │
Contract
    │
Transaction

Kaspa：

UTXO
   │
Script
   │
Spend
   │
New UTXO

Ethereum 合约一直存在。

Kaspa 合约实际上存在于：

UTXO 的锁定脚本（Locking Script）中。

换句话说：

不是调用 Contract。

而是：

消费（Spend）某一个 Contract UTXO。

这就是 UTXO Covenant。

官方文档也强调，Toccata 的 L1 合约采用 UTXO 原生模型，状态随 UTXO 演进，而不是账户式全局状态。

二、开发流程

整个开发流程如下：

编写 SilverScript
        │
        ▼
Compiler 编译
        │
        ▼
Kaspa Script
        │
        ▼
创建 Deploy Transaction
        │
        ▼
广播到 Kaspa Mainnet
        │
        ▼
生成 Contract UTXO
        │
        ▼
用户 Spend Contract
        │
        ▼
Script 验证成功

实际上只有两种交易：

• 创建 Contract

• 消费 Contract

所有复杂逻辑都是围绕 UTXO 生命周期展开。

三、第一个 SilverScript 合约

先写一个最简单的 Owner 合约。

例如：

contract Vault {

    pubkey owner;

    function unlock(sig s) {

        require(checkSig(s, owner));

    }

}

这个例子表达的含义非常简单：

只有 Owner 可以花费这笔 UTXO。

是不是很像：

Bitcoin Script：

OP_DUP
OP_HASH160
...
OP_CHECKSIG

SilverScript 的意义就在于：

我们终于不用再手写 Opcode。

而是写：

require(...)

Compiler 自动生成 Script。

四、编译发生了什么？

执行：

silverscript build vault.ss

Compiler 开始工作：

vault.ss

↓

Lexer

↓

Parser

↓

AST

↓

Semantic

↓

Optimizer

↓

Kaspa Script

↓

script.bin

最终得到：

Redeem Script

+

Metadata

+

ABI

真正部署到链上的其实不是源码。

而是：

Script Binary。

五、Deploy Transaction 如何生成？

很多人认为：

Deploy Contract

就是：

上传代码。

实际上完全不是。

Kaspa 没有：

CREATE

CREATE2

这种操作。

真正发生的是：

Wallet

↓

Create Output

↓

Output Script = Contract Script

也就是说：

钱包创建一个：

新的 UTXO。

锁定脚本就是：

Compiler 输出的 Script。

因此：

Contract

其实就是：

一个特殊的 P2SH（或未来 Covenant）UTXO。

六、部署到 kaspa Mainnet

目前 SilverScript 主要面向 Testnet-12，可通过官方工具进行编译和测试部署。

典型流程如下：

silverscript build vault.ss

↓

生成 Script

↓

Wallet Sign

↓

Broadcast

↓

Node Accept

↓

Contract UTXO

如果交易进入区块：

你的第一个 Contract 就已经上线。

官方还提供了在线开发环境，可直接在浏览器中编写、编译并部署到测试网。
SilverScript Studio：SilverScript Studio

七、Contract 如何执行？

这是 Kaspa 最重要的一点。

不是：

Call Contract

而是：

Spend Contract

例如：

Alice：

Contract UTXO
↓

100 KAS

Bob：

发送：

Spend Transaction

节点执行：

Unlock Script

+

Lock Script

验证：

TRUE

交易成功。

否则：

Reject。

整个过程与 Bitcoin Script 十分相似，只不过 SilverScript 提供了更高级、更易维护的开发体验。

八、状态（State）存在哪里？

这是很多 Solidity 开发者最容易困惑的地方。

Ethereum：

Storage

balance = 100

Kaspa：

UTXO

↓

New UTXO

↓

New State

状态不是修改。

而是：

生成新的状态。

例如：

Vault

Balance=100

Spend：

生成：

Vault

Balance=80

旧状态：

Spent。

新状态：

Alive。

因此：

状态演化：

State0

↓

State1

↓

State2

↓

State3

每一个都是新的 UTXO。

官方开发文档建议将状态放入 Redeem Script 的状态预映像（preimage）中，通过新的 UTXO 表示状态迁移，而不是修改已有对象。

九、一个完整的生命周期

下面是一笔 Contract 的生命周期。

Developer

↓

Write Contract

↓

Compile

↓

Script

↓

Deploy

↓

UTXO Created

↓

User Spend

↓

Verify Script

↓

Generate New State

↓

New Contract UTXO

这就是：

Kaspa Covenant。

没有：

Storage。

没有：

Global State。

只有：

UTXO Evolution。

十、未来可以开发哪些应用？

随着 Covenants++、Native Assets 等能力逐步成熟，SilverScript 将适用于多种 UTXO 原生应用。官方示例和路线图已经覆盖了多个方向。

例如：

这些应用都不依赖账户模型，而是通过不断创建新的 Contract UTXO 完成状态更新。

十一、为什么 SilverScript 不需要 EVM？

Ethereum：

Transaction

↓

EVM

↓

Storage

↓

State Root

Kaspa：

Transaction

↓

Script

↓

Validation

↓

New UTXO

因此：

SilverScript 不需要：

• EVM

• Solidity Runtime

• Gas Interpreter

它直接编译成：

Kaspa Script。

节点执行的是：

原生 Script Engine。

这也是 Kaspa 官方一直强调的：

Readable Code → Native Kaspa Script

没有额外虚拟机。

没有额外执行层。

总结

一个 SilverScript 合约真正的生命周期可以概括为：

编写合约
      │
      ▼
SilverScript Compiler
      │
      ▼
Kaspa Script
      │
      ▼
Deploy Transaction
      │
      ▼
Contract UTXO
      │
      ▼
Spend Transaction
      │
      ▼
Script Validation
      │
      ▼
生成新的 Contract UTXO

理解这一流程，也就理解了 Kaspa 智能合约与传统 EVM 合约最本质的区别：Kaspa 合约不是“长期驻留在链上的对象”，而是一系列通过 UTXO 状态迁移不断演化的链上规则。