Hi everyone, I’m Sonny. A few months ago, I published an article titled “No Card Binding, Pay As You Chat: A Web3 Payment Experiment” (《 No need to bind a card—pay as you chat: a Web3 payment experiment》), documenting my first exploration into CKB as a Web3 beginner. Today, I’m still a beginner, but I’ve learned more about Fiber Network—and I want to share my new insights and why I believe Fiber represents the future direction for payment channels.
Looking Back at My Early Exploration Project
I still remember when I first grasped the UTXO and Cell models and couldn’t wait to build a unidirectional payment channel. Writing contracts in JavaScript, using the since field for timelocks, implementing the “sign first, go on-chain later” mechanism through funding tx hash—these things excited me for days.
The project actually worked: every time the AI returned a chunk, an off-chain micropayment was automatically completed. That was the first time I truly understood what “off-chain payment” meant, and it was an important starting point for me in the Web3 world.
But this project had its limitations.
What Were the Limitations?
1. Funds Were “Trapped”
My design at the time was for users to establish unidirectional channels with AI service providers. If a user locked 1000 CKB, that money could only be paid to that specific service provider.
What if the user wanted to switch to a different AI service? They had to close the original channel and open a new one—waiting for on-chain confirmation and paying fees again.
More awkwardly, if users wanted to use multiple services simultaneously (say, one for coding, one for image generation, one for translation), each service provider required a separate fund lock. The 1000 CKB would quickly be fragmented, with less and less available for each transaction.
2. Channels Were “Unidirectional” Dead Ends
Spillman Channels only allow buyers to pay sellers. This means:
- Service providers cannot refund users
- Users cannot transfer money to each other
- Funds can only flow in one direction until depleted
To solve this problem at the time, I added a “manual settlement” feature—but this was already a compromise outside the protocol.
3. Zero Network Effects
Every user and every service provider was an isolated “island.” Even if User A and User B both used the same service provider, they couldn’t transact directly with each other.
Imagine: if you want to shop on Taobao, you must first open a “dedicated account” to deposit money; to shop on JD.com, you must open another “dedicated account”; to transfer money to friends, you need yet another “dedicated account”—and these accounts can’t transfer funds between each other. Is that still called a payment network?
Fiber Network Solves All of This
When I delved deeper into Fiber Network, I discovered that those headache-inducing problems I faced actually have elegant solutions.
1. One Channel, Access to the Entire Network
The core of Fiber is multi-hop routing. You don’t need to establish direct channels with every service provider; you only need to connect to one routing node to pay anyone on the network.
The old me:
User ──Channel1──→ AI Service A
│
├──Channel2──→ AI Service B
│
├──Channel3──→ AI Service C
│
└──Channel4──→ Translation Service D
The new me:
User ──Channel──→ Routing Node ──┬──→ AI Service A
├──→ AI Service B
├──→ AI Service C
└──→ Translation Service D
Capital efficiency improved by N times. The same 1000 CKB, previously split into 4 parts, can now be used in full for any transaction.
2. Bidirectional Channels, Funds Can Flow
Fiber’s channels are bidirectional. This means:
- Service providers can refund users
- Users can transfer money to each other
- Funds can flow back and forth in the channel without depleting in one direction
Remember that “manual settlement” compromise I made? In Fiber, this is natively supported.
3. Network Effects: Connection is Value
Fiber is a true payment network, not a collection of isolated channels.
Alice ──Channel──→ Routing Node X ──Channel──→ Bob
│
├──→ Merchant A
├──→ Merchant B
└──→ Merchant C
Alice can transfer money to Bob, pay any merchant, and even pay Bitcoin Lightning users through cross-chain functionality—all while maintaining just one channel.
4. Production-Grade Security
My original implementation only had simple timelocks with no penalty mechanism. If a user maliciously broadcast an old state, the service provider could only accept the loss.
Fiber provides complete HTLC/PTLC contracts and penalty mechanisms:
- Malicious broadcasting of old states is penalized, resulting in loss of all funds
- Watchtower services protect offline users
- Atomic guarantees for multi-hop payments
These are things my early exploration project simply couldn’t match.
But Isn’t Fiber More Complex?
You might ask: since Fiber is so powerful, isn’t it more complex to implement?
The answer is: not really.
Fiber Shields You from Underlying Complexity
Remember how much I had to manually handle to implement the Spillman Channel? Timelocks, multi-sig contracts, signature verification, transaction construction…
Fiber provides APIs for creating channels, making payments, and more, shielding you from all this underlying logic. You don’t need to manually implement:
- Multi-sig contracts
- Timelock logic
- Signature verification
- Transaction construction and broadcasting
Just call simple APIs to open channels, make payments, and close channels.
Want to Quickly Experience Fiber? I Wrote a Getting Started Guide
I wrote a quick start guide:
This article will guide you through:
- Starting a Fiber node with one click
- Quickly experiencing the Fiber API
- Understanding Fiber’s basic concepts
- Laying the foundation for future development
You’ll find that implementing payment channel functionality with Fiber requires much less code than my original implementation from scratch—because Fiber has already encapsulated the logic for establishing channels, making payments, and more.
Moreover, when you need more complex features (like bidirectional payments, multi-hop routing), Fiber can seamlessly support them. This is the charm of progressive enhancement.
Final Words
A year ago, I wrote a simple solution to solve a simple problem. I was excited at the time because it was the first time I truly understood what “off-chain payment” meant.
But now I know that simple solutions often only solve simple problems. When you want to build a real payment network, infrastructure like Fiber is the right direction.
However, I want to be honest: Fiber Network is still in its early stages. Not many people are using it yet, and the network topology isn’t rich enough. This means:
- You may not immediately experience the convenience of “one channel connecting to the entire network”
- Multi-hop routing options are still limited
- Sometimes you still need to establish direct channels
But this is exactly why we need more developers to join.
Only when more people use it, more nodes join, and more channels are established can Fiber’s network effects truly emerge. At that point, when you open a channel, you’ll be connected to the entire ecosystem; when you want to pay anyone, you can do so through a few hops.
This isn’t “already built infrastructure”—it’s a network we need to build together.
From Spillman Channel to Fiber Network, this has been my journey of growth. I hope this article helps you avoid some detours—and I hope you’ll join us in building the Fiber network.
从 Spillman Channel 到 Fiber Network
大家好，我是 Sonny。几个月前，我发布了那篇《 不用绑卡，边聊边付：一个 Web3 版的支付实验》的文章，记录了自己作为 Web3 新手在 CKB 上的第一次探索。现在，我依然是个初学者，但我对 Fiber Network 有了更多了解——想和大家分享一下我的新认识，以及为什么我认为 Fiber 是支付通道的未来方向。
先回顾一下当年的探索项目
记得那时候，我刚搞懂 UTXO 和 Cell 模型，就迫不及待地写了一个单向支付通道。用 JavaScript 写合约、用 since 字段做时间锁、通过 funding tx hash 实现"先签名后上链"——这些在当时让我兴奋了好几天。
那个项目确实跑起来了：AI 每返回一个 chunk，就自动完成一次链下支付。那是我第一次真正理解"链下支付"的含义，也是我在 Web3 世界的重要起点。
但这个项目有其局限性。
探索项目的局限在哪里？
1. 资金被"困死"了
我当时的设计是用户和 AI 服务商建立单向通道。假设用户锁定了 1000 CKB，那这笔钱就只能付给这一个服务商。
如果用户想换一家 AI 服务商呢？必须关闭原通道，重新开新通道——又要等链上确认，又要付手续费。
更尴尬的是，如果用户同时用多家服务（比如一家写代码、一家画图、一家做翻译），每个服务商都要锁定一笔资金。1000 CKB 很快就被拆得七零八落，每笔交易可用的额度越来越小。
2. 通道是"单向"的死胡同
Spillman Channel 只能买家付款给卖家。这意味着：
- 服务商无法给用户退款
- 用户之间无法互相转账
- 资金只能朝一个方向流动，直到耗尽
我当时为了解决这个问题，加了一个"手动结算"的功能——但这其实已经是协议之外的妥协了。
3. 网络效应为零
每个用户和每个服务商都是独立的"孤岛"。A 用户和 B 用户即使都用同一个服务商，他们之间也无法直接交易。
想象一下：如果你要在淘宝上买东西，必须先在淘宝开一个"专用账户"存钱；要在京东买东西，必须再开一个"专用账户"存钱；要给朋友转账，还得再开一个"专用账户"——而且这些账户之间资金不能互通。那还叫支付网络吗？
Fiber Network 解决了这一切
当我深入了解 Fiber Network 后，才发现当初那些让我头疼的问题，其实都有优雅的解决方案。
1. 一个通道，全网通行
Fiber 的核心是多跳路由。你不需要和每个服务商建立直接通道，只需要连接到一个路由节点，就可以向网络中的任何人付款。
以前的我：
用户 ──通道1──→ AI服务商A
│
├──通道2──→ AI服务商B
│
├──通道3──→ AI服务商C
│
└──通道4──→ 翻译服务商D
现在的我：
用户 ──通道──→ 路由节点 ──┬──→ AI服务商A
├──→ AI服务商B
├──→ AI服务商C
└──→ 翻译服务商D
资金效率提升了 N 倍。 同样的 1000 CKB，以前被拆成 4 份，现在可以全额用于任何一笔交易。
2. 双向通道，资金流动起来
Fiber 的通道是双向的。这意味着：
- 服务商可以给用户退款
- 用户之间可以互相转账
- 资金可以在通道中来回流动，不会单向耗尽
还记得我当初那个"手动结算"的妥协吗？在 Fiber 里，这是原生支持的功能。
3. 网络效应：连接即价值
Fiber 是一个真正的支付网络，而不是一堆孤立的通道。
Alice ──通道──→ 路由节点X ──通道──→ Bob
│
├──→ 商户A
├──→ 商户B
└──→ 商户C
Alice 可以给 Bob 转账，可以给任何商户付款，甚至可以通过跨链功能给 Bitcoin Lightning 用户付款——而这一切只需要维护一个通道。
4. 生产级的安全保障
我当初的实现只有简单的时间锁，没有惩罚机制。如果用户恶意广播旧状态，服务商只能认栽。
Fiber 提供了完整的HTLC/PTLC 合约和惩罚机制：
- 恶意广播旧状态会被惩罚，损失全部资金
- 瞭望塔服务保护离线用户
- 多跳支付的原子性保证
这些是我当初那个探索项目无法比拟的。
但 Fiber 不是更复杂吗？
你可能会问：既然 Fiber 功能这么强大，实现起来会不会很复杂？
答案是：并不会。
Fiber 帮你屏蔽了底层复杂性
还记得我当初为了实现 Spillman Channel，需要手动处理多少事情吗？时间锁、多签合约、签名验证、交易构造……
Fiber 提供了创建通道、支付等 API，帮你屏蔽了所有这些底层逻辑。 你不需要手动实现：
- 多签合约
- 时间锁逻辑
- 签名验证
- 交易构造和广播
只需要调用简单的 API，就能完成通道的开启、支付和关闭。
想快速体验 Fiber？我写了一篇入门指南
我专门写了一篇快速启动指南：
这篇文章会带你：
- 一键启动 Fiber 节点
- 快速体验 Fiber API
- 理解 Fiber 的基本概念
- 为后续开发打下基础
你会发现，用 Fiber 实现支付通道功能，代码量比我当初从零实现要少得多——因为 Fiber 已经帮你封装好了建立通道、支付等逻辑。
而且，当你需要更复杂的功能（比如双向支付、多跳路由）时，Fiber 也能无缝支持。这就是渐进式升级的魅力。
写在最后
一年前的我，为了解决一个简单的问题，写了一个简单的方案。当时的我很兴奋，因为那是我第一次真正理解"链下支付"的含义。
但现在的我知道，简单的方案往往只能解决简单的问题。当你想要构建一个真正的支付网络时，Fiber 这样的基础设施才是正确的方向。
不过，我也想坦诚地说：Fiber Network 现在还处于早期阶段，用的人还不多，网络拓扑还不够丰富。这意味着：
- 你可能无法立即体验到"一个通道连接全网"的便利
- 多跳路由的选择还不够多
- 有时候还是需要建立直接通道
但这正是我们需要更多开发者加入的原因。
只有用的人多了，节点多了，通道多了，Fiber 的网络效应才能真正发挥出来。到那时，你开启一个通道，就能连接到整个生态；你想付款给任何人，都能通过几跳路由完成。
这不是一个"已经建成的基础设施"，而是一个需要我们一起搭建的网络。
从 Spillman Channel 到 Fiber Network，这是我的成长之路。希望这篇文章能帮你少走弯路——也希望你能加入进来，一起把 Fiber 的网络搭建起来。