您现在的位置：kastop>> Kas信息 Kaspa网络>>正文内容

SilverScript × Kasplex L2：构建 L1 + L2 混合调用 DApp 实战

作者：未知来源：kastop.com 发布时间：2026年07月03日

当 L1 负责资产安全，L2 负责复杂计算，Kaspa 生态将形成一种全新的混合智能合约架构。

随着 SilverScript 的推出，Kaspa 开始具备原生 Layer1（L1）可编程能力；与此同时，Kasplex zkEVM 提供了兼容 EVM 的 Layer2（L2）执行环境。这两者并不是竞争关系，而是分别解决不同的问题：

SilverScript（L1）：管理 UTXO、资产安全、Covenant、本地状态。
Kasplex zkEVM（L2）：运行 Solidity 合约、DeFi、DAO、DEX、NFT 等复杂应用。Kasplex 官方将其定位为基于 Kaspa 的 Based Rollup zkEVM，由 L1 提供排序和数据可用性。

本文将通过一个真实的业务案例，介绍如何设计 SilverScript + Kasplex L2 的混合调用架构。

为什么需要 L1 + L2 混合架构？

假设我们开发一个去中心化 OTC 交易平台。

用户希望：

KAS 始终由 Kaspa L1 保护；
订单撮合、报价、积分、仲裁等复杂逻辑运行在 L2；
最终资金交割仍由 L1 Covenant 保证。

如果全部放到 L2：

User

↓

Bridge

↓

L2 Wallet

↓

Smart Contract

所有资产都需要先进入 L2。

而如果全部放到 L1：

SilverScript

↓

Kaspa Script

又不适合实现复杂订单簿、AMM 或治理逻辑。

因此，最佳方案是：

Kaspa L1

+

Kasplex zkEVM

混合架构设计

整个系统可以拆成四层：

              用户

               │

        Wallet / SDK

      ┌────────┴────────┐

      ▼                 ▼

 SilverScript       Kasplex L2

   Covenant        Solidity

      │                 │

      └────────┬────────┘

               ▼

        Kaspa Layer1

职责划分如下：

模块	职责
SilverScript	锁仓、Escrow、Native Asset、权限验证
Kasplex zkEVM	订单撮合、DAO、积分、NFT、复杂业务逻辑
Indexer	同步 L1/L2 状态
Wallet SDK	发起 L1 与 L2 交易

这种模式与 Kasplex 官方提出的 L2 执行 + Kaspa L1 排序/结算思路一致。

案例：去中心化 Escrow Marketplace

假设 Alice 和 Bob 在 Marketplace 上交易一件数字资产。

业务流程如下：

Alice

 │

 │ 创建订单

 ▼

Kasplex L2

 │

 │ Matching

 ▼

Order #1001

 │

 │

 ▼

SilverScript Escrow

 │

 │ Lock 100 KAS

 ▼

Kaspa L1

这里：

L2 不直接保管资金。

资金始终锁在：

SilverScript Escrow。

第一步：L2 创建订单

L2 合约负责：

CreateOrder()

↓

OrderID

↓

Buyer

↓

Seller

↓

Price

例如：

Order

ID = 1001

Price = 100 KAS

Status = OPEN

这里只保存：

业务状态。

不保存：

真正资产。

第二步：L1 锁仓

Wallet：

调用：

SilverScript。

例如：

contract Escrow {

    buyer;

    seller;

    amount;

    orderId;

}

部署：

生成：

Escrow UTXO

↓

100 KAS Locked

这里：

OrderID：

来自：

L2。

因此：

L1：

知道：

锁的是：

哪一笔订单。

第三步：L2 更新订单状态

L2：

监听：

L1。

发现：

Escrow Created

于是：

更新：

OPEN

↓

FUNDED

整个过程：

由：

Indexer：

完成。

例如：

Kaspa Node

↓

Indexer

↓

L2 API

↓

Update Order

很多混合架构都会采用这种事件同步方式，而不是让 L1 主动调用 L2。

第四步：卖家发货

Bob：

上传：

NFT。

或者：

完成：

线下交付。

L2：

修改：

FUNDED

↓

DELIVERED

注意：

资金：

依然：

没有移动。

第五步：买家确认

Alice：

点击：

Confirm

L2：

生成：

一条：

Settlement。

例如：

Release

↓

OrderID

↓

Buyer Signature

然后：

Wallet：

调用：

SilverScript。

第六步：L1 释放资金

SilverScript：

验证：

require(

buyerSigned

)

require(

orderMatched

)

成功。

Spend：

Escrow。

输出：

Seller Wallet

↓

100 KAS

交易完成。

整个资金结算发生在 L1。

为什么不用 L2 保存资金？

这是整个设计最重要的一点。

如果：

资金：

放到：

L2。

那么：

Bridge

↓

Custody

↓

Withdraw

增加了：

桥接风险。

而：

SilverScript：

一直运行：

Kaspa 原生：

Script。

所以：

Asset

=

Kaspa L1

而：

Business Logic

=

Kasplex L2

形成：

职责分离。

L1 与 L2 如何通信？

目前，SilverScript 并不存在直接调用 Solidity 合约的机制；反之，Kasplex zkEVM 也不会直接执行 SilverScript。两者通常通过交易、事件和索引器协同：

L2

↓

Emit Event

↓

Indexer

↓

Wallet

↓

L1 Transaction

↓

SilverScript

反方向：

Kaspa Block

↓

Indexer

↓

Event

↓

L2 Contract

因此：

真正通信的是：

事件（Event）

而不是：

函数调用。

一个完整的数据流

整个调用链可以表示为：

用户
↓
Kasplex Marketplace
↓
Create Order
↓
Wallet
↓
SilverScript Lock
↓
Kaspa L1
↓
Indexer
↓
L2 Update
↓
Delivery
↓
Confirm
↓
SilverScript Release
↓
Seller

整个系统：

形成：

双层架构。

还可以扩展哪些应用？

这种混合模式不仅适用于 Escrow，还适合更多场景：

场景	SilverScript（L1）	Kasplex L2
DEX	资产托管、最终结算	AMM、订单簿、流动性管理
NFT 市场	NFT 所有权约束	挂单、竞拍、版税计算
DAO	国库资金锁定	提案、投票、治理逻辑
借贷	抵押资产管理	利率模型、清算算法
GameFi	游戏资产所有权	游戏逻辑、排行榜、任务系统
RWA	实物资产托管	KYC、审批、收益分配

混合架构的优势

相比将所有逻辑放在 L1 或全部迁移到 L2，这种设计具有明显优势：

资产安全：KAS 和原生资产始终由 L1 Covenant 控制。
复杂逻辑：Solidity 合约继续运行在 Kasplex zkEVM，无需放弃成熟的 EVM 工具链。
可扩展性：复杂计算放到 L2，L1 保持轻量验证。
开发效率：开发者可以分别使用 SilverScript 和 Solidity，在最适合的层实现各自职责。

总结

SilverScript 与 Kasplex L2 并不是替代关系，而是互补关系。

可以用一句话概括它们的定位：

SilverScript 负责“资产与规则”，Kasplex L2 负责“应用与计算”。

未来，一个成熟的 Kaspa DApp 很可能采用这样的架构：

                Frontend
                    │
        ┌───────────┴───────────┐
        │                       │
        ▼                       ▼
  Kasplex zkEVM          SilverScript
 (业务逻辑/DeFi)       (资产/托管/Covenant)
        │                       │
        └───────────┬───────────┘
                    ▼
               Kaspa Layer 1

这种分层方式兼顾了 L1 原生资产安全 与 L2 丰富应用生态，也是 Kaspa 生态未来可能广泛采用的一种系统架构。不过，需要注意的是，目前官方尚未发布 SilverScript 与 Kasplex zkEVM 的标准跨层调用协议，实际项目通常依赖事件监听、索引器、SDK 和跨层消息机制来完成协同，因此本文案例属于一种符合现有架构思路的参考设计，而不是已经标准化的官方接口。