If you read the earlier “Chat-and-Pay” piece, you should already have a sense of off-chain micropayments: money doesn’t run on-chain — it flows in real time through a channel both parties agreed on. That article was about proving feasibility — could we technically make a payment happen automatically every time an AI response came in.
This time I want to push it further: not just proving it works, but seeing what product shape and network structure emerge when Fiber Network enters a concrete, real-world scenario.
The scenario I picked is EV charging. The reasoning is straightforward: charging is a continuous action, costs accumulate in real time by duration or energy consumed, which naturally fits a “pay-as-you-use” streaming payment model. More importantly, the scenario is specific enough to reveal design details of Fiber Network that usually go unnoticed — things like multi-hop routing, Hub fees, and an interesting question: why does a decentralized payment network naturally evolve a node that looks like a “Hub”?
Live demo: https://54-180-28-237.sslip.io
Product Walkthrough: Open a Browser, Start Charging and Paying
The app interface has two main sections: the charging UI for users, and an operations dashboard for admins. Let’s start with the user side.
Overall Layout
When you open the page, you’ll see a dark, tech-themed interface with a clear layout — network topology map on the left, charging controls on the right.
Top Status Bar
At the very top are two info strips:
- Left — Vehicle Status: Battery level (starts at 23%), remaining range, energy efficiency. These numbers update in real time during charging, giving you a direct sense of “power going in.”
- Right — Fiber Node Status: Shows connection state (green/red dot), number of established channels, channel balance, on-chain balance. Clicking “Connect” launches a WASM light node in the browser, authenticates via Passkey, and automatically connects to the Router. No seed phrase, no wallet app to download — as natural as logging into a website with your fingerprint.
Left Side: Charging Network Map
The left half of the screen is a real-time network topology map, rendered in SVG with animations to visualize the Fiber network’s connections:
- You (User Node): bottom-left, your browser’s WASM node
- Fiber Hub (Router): center, the network’s relay node
- Four charging stations: Tesla, ChargePoint, EA, and EVgo distributed around
Nodes are connected by lines: User → Hub is solid (your direct channel), Hub → Station is dashed (Router-to-station channels). Click any station to switch the active target.
The most immediate visual feedback comes during charging: each completed off-chain payment triggers a particle light that travels from the User node along the connection line to the Hub, then onward to the target station. This isn’t a fake frontend animation — particles are only generated in the payment success callback. Hovering over the Fiber Hub also reveals the current routing fee rate (default 10%).
Right Side: Station Details
The upper-right panel shows details for the currently selected station:
- Station name and brand: e.g. “Tesla Supercharger”
- Power and rate: 250 kW · 1.44 CKB/kWh · 0.50 CKB / 5s
- Availability: green “AVAILABLE” badge
- Action button:
- Before connecting: “CONNECT FIBER NODE FIRST” (blue, disabled)
- Connected but no channel: “OPEN CHANNEL” (prompts to open a payment channel)
- Connected with channel: “START CHARGING”
- During charging: “STOP CHARGING” (red)
Bottom Right: Transaction Log
Below Station Details is a scrolling transaction log that shows every operation during a charging session:
14:32:01 Connected to Tesla
14:32:02 Initializing invoice-based payment...
14:32:03 Invoice payment stream active - 0.5 CKB every 5s
14:32:08 ✓ Invoice paid: a3f7e2d8... (0.500000 CKB)
14:32:13 ✓ Invoice paid: 8b1c4a9e... (0.500000 CKB)
Each entry is timestamped, successful payments marked with a green check. The log keeps only the last 20 entries to avoid clutter.
Complete User Flow
Putting all the pieces together, a user’s full experience goes like this:
- Open the page → see the Network Map and Tesla station
- Click “Connect” (top-right) → browser requests Passkey (system fingerprint / Face ID) → WASM node starts → auto-connects to Router → top status bar turns green, showing on-chain balance
- Open payment channel → after connecting, the system checks if you have an active channel. If not, Station Details shows an “OPEN CHANNEL” button. Click it and a modal appears with your CKB address and current on-chain balance. You need to fund this address with some CKB (recommended ≥100 CKB) and confirm to open the channel. Once opened, that CKB is locked in the channel between you and the Router, becoming your available payment balance
- Click “START CHARGING” → a charging session begins → an invoice is generated and paid every 5 seconds
- Watch the session → battery level climbs, particle lights fly across the map, the transaction log scrolls, and the channel balance at the top slowly decreases
- Click “STOP CHARGING” → the payment stream stops, the log prints a session summary (“Session: 12 transactions, 6.000000 CKB total”)
The four actions the user actively takes are: Connect, Open Channel, Start, Stop. Opening a channel is a one-time thing — on subsequent visits you can go straight to Start.
About funding: This project runs on CKB Testnet, so all funds are test tokens. If your on-chain balance shows 0, head to the CKB Testnet Faucet to get free test tokens. Paste your CKB address (shown in the Open Channel modal) on the faucet page and tokens should arrive within minutes.
Admin Dashboard
In the bottom-left corner is a small “ADMIN DASHBOARD” link. Clicking it takes you to the operations backend, where you can view:
- Dashboard Overview: Today’s revenue, transaction count, routing fees collected, active sessions, lifetime revenue, lifetime routing fees, and a revenue leaderboard across stations
- Router Network: Total channel count, user connections, station connections, total routing fees, total forwarded transactions, and per-user channel balances and status
- Stations / Transactions / Statistics: Per-station operational data, individual transaction details, and time-based analytics
The dashboard’s core value is letting operators see Hub fee revenue (the 10% the Router takes from every payment) and each station’s share of revenue side by side. In a traditional aggregated payment platform this is usually a black box — here every number is public and verifiable.
Why Multi-hop: You Don’t Need to Know Every Merchant
There’s a design choice in this simulator that’s easy to overlook but fundamentally determines whether the whole network works: as a user, you only establish a direct channel with the Router (Hub) node — yet you can pay any of Tesla, NIO, XPeng, or EA.
Aggregated payment platforms in Web2 can also do this — Alipay, WeChat Pay, Stripe all let you pay merchants you don’t have a direct account with. But the difference lies in the path money takes and the trust model.
In traditional aggregated payments, your money flows through the payment platform (Alipay, WeChat), into their clearing system, and then gets settled to the merchant. This means: the platform custodies your funds, the platform holds complete transaction data, the platform sets the rules and fees, and both merchants and users must trust the platform not to abuse its power.
In Fiber Network, the Router never touches users’ money. Your CKB is locked in an on-chain channel between you and the Router. The Router only forwards payment commitments, and settlement can always be enforced on-chain. You don’t need to trust that the Router won’t run off with your funds — it can’t. Channel states are publicly verifiable, routing paths propagate through the gossip protocol, and anyone can audit.
That’s the real meaning of multi-hop payments in a decentralized network: not aggregation itself, but aggregation without requiring centralized custody.
This is Fiber’s multi-hop payment capability.
The first benefit is obvious: the user side stays extremely light. You don’t need to open a separate channel and deposit funds for every merchant. One channel to the Router, and you can pay every merchant in the network.
The second benefit runs deeper: liquidity flows through the network instead of being trapped point-to-point. If you only have a channel with Tesla and end a session with leftover balance, but next time want to charge at NIO — your money is stuck. With the Router as a relay, your balance can be forwarded through the Router to any channel it connects to. The Router becomes a “liquidity switch.”
The third benefit is about scalability. Imagine this network growing from 4 stations to 400. If every user had to build individual channels to all 400 stations, the network would never work. But multi-hop routing collapses the topology from O(n²) to O(n) — users connect to the Hub, the Hub connects to merchants. This is exactly how BGP routing works on the internet, and Fiber Network follows a similar path.
How a Router Becomes a Hub: The Natural Emergence of High-Connectivity Nodes
The multi-hop routing described above leads to a more interesting phenomenon: the Router isn’t just a technical relay for messages — it takes on a distinct role in the network’s topology.
Note that I said “distinct role,” not “special status.” There’s a difference.
In our simulator, the Router collects a routing fee from every payment that passes through it — 10% of the payment amount by default. This fee is deducted from the total the user pays, the Router takes its cut, and the remainder goes to the charging station. A natural question arises: could the Hub become a new monopolist?
To answer that, we need to understand what makes a Hub in Fiber Network fundamentally different from a “gateway” in traditional payment systems.
In traditional payments, acquirers and payment gateways are monopolistic central nodes — they have barriers to entry (licenses, compliance reviews), they custody funds (your money goes to their accounts first), and they control information (transaction data is held by them, opaque to both merchants and users). Merchants who want to accept payments must go through these gateways — there’s no alternative.
A Hub in Fiber Network is completely different. It has no barrier to entry — anyone can download fnn, run a node, stay online, provide channel liquidity, and become a Hub. It doesn’t custody funds — users’ CKB is locked in channels between the user and the Hub; the Hub can’t touch it and can always be challenged with on-chain settlement. It doesn’t monopolize information — channel states, payment routes, and node information are all public on-chain or propagated through the gossip protocol.
So strictly speaking, a Fiber Hub isn’t a “centralized node” — it’s an ordinary node with higher connectivity in a decentralized network. It looks like a center in the topology because network effects naturally selected it there, not because the protocol gave it special privileges.
So what’s the point of the fee?
First, the fee prices the Hub’s relay service. Keeping a node online 24/7, maintaining bidirectional channel liquidity, handling path discovery and payment forwarding — all of this costs real machine resources and capital. Without economic incentive, nobody provides the service.
Second, the fee creates the precondition for competition — but at this stage, competition doesn’t yet exist. In the current single-Router demo, the 10% rate is set unilaterally by the operator. “Users can freely choose a lower-fee Router” is a vision the protocol supports, but actually realizing it requires a mature multi-Router ecosystem. This is precisely the core question discussed later in this article — how a centrally operated platform gradually opens up to competition.
Third, the emergence of Hubs isn’t a compromise of decentralization — it’s the natural evolution of a decentralized network at scale. A pure mesh P2P topology looks beautiful in theory but doesn’t scale in practice. The Hub structure collapses topology complexity to O(n) while preserving every participant’s right to freely join and leave. This isn’t “layered decentralization” — it’s the same decentralized protocol taking different topological forms at different scales.
Our charging simulator works exactly this way: users connect through lightweight browser nodes, the Router acts as a connectivity amplifier handling network relay — and as this Router’s connections grow, it naturally earns the status of a Hub — while charging stations operate independently. None of the three parties is subordinate to another, any party can be replaced at any time, but together they form a working payment system.
Regional Network Model: The Hub as an Aggregator
Pushing this thinking further, what would a Hub look like in a real-world setting?
Imagine a commercial district in a city with 20 charging stations, each owned by a different operator. Each operator runs their own Fiber node, but they may not want — or have the capacity — to maintain network-wide routing or handle cross-district payments. That’s where a “district Router” becomes valuable — it connects all 20 nodes into the broader Fiber network, letting users find every station through a single entry point.
In this model:
- Users only know the district Router — they don’t need to care which 20 operators are behind it
- Operators only maintain their channel to the Router — they don’t need to worry about the full network topology
- The Router provides connectivity and handles route discovery
This isn’t speculative. In traditional payment systems, acquirers and aggregated payment platforms play exactly this “regional connector” role. But the key difference with Fiber Network is: anyone can take on this role, merchants can switch freely, and users always control their own funds. Traditional acquirers monopolize information and access — merchants must go through them to accept payments, the platform sees all transaction data, and can freeze funds. A Fiber Hub only forwards and routes — funds stay in channels, and payment commitments can always be settled on-chain. This is reconstructing the functionality of traditional centralized networks using a decentralized protocol.
But this leads to a commercial question you can’t avoid: who runs this Router? If each district’s Router is operated by a different team, how do merchants know which one to connect to? How do users know whether the Hub they’re connected to covers the stations they need? The answers point directly to the go-to-market path this article ultimately discusses.
Platform Model vs. Fully Decentralized: Two Paths to Market
At this point, there’s a question that needs a direct answer: what form should this project take going forward?
First, let’s be clear about where this demo actually stands — it runs on our VPS, the Router and all four Station nodes are maintained by us, the Admin Dashboard’s revenue stats rely on a local SQLite database, and external station operators can’t self-onboard. It’s essentially a minimal centralized platform prototype: we have the server, the admin backend, and station onboarding capability. If we close a partnership, we can offer operators one-click deployment — they connect to our Router and start accepting payments.
But that’s not the only path. Another possibility is “fully decentralized”: each station operator runs their own node, connects directly to a public Fiber network (say, a foundation-maintained official Router), and users’ browser nodes auto-route payments.
I’ve thought seriously about both models, and each has its pros and cons.
Option A: Platform Model (Our Current Direction)
Core logic: We act as the service provider and approach station operators for partnerships. Operators don’t need to understand Fiber — they just plug into our system. We handle deployment, frontend, data analytics, and payment routing.
Advantages:
- Clear business model: we can charge deployment fees, take a cut of routing fees, or charge SaaS subscriptions. Revenue sustains development and operations
- Unified user experience: users open one page and see all stations, regardless of which Router is behind them. We handle payment failures
- Data creates value: the admin dashboard’s transaction stats, revenue rankings, and user behavior analytics are attractive to operators — individual stations can’t produce this on their own
- Operational flexibility: we can run subsidies, dynamic pricing, A/B test fee rates, and iterate quickly
- Zero barrier for operators: they just provide a receiving address and rate configuration — no node-running or channel management
- Compliance has a responsible entity: if regulators need someone to hold accountable, the platform is there
Disadvantages:
- Trust cost: operators need to believe we won’t tamper with anything. Even though funds are locked in channels and can’t be moved by us, the Router is under our control
- Single point of failure: if our Router goes down, no station receives payments. This is the platform model’s core vulnerability, mitigated through redundant deployment and failover mechanisms
- Scaling ceiling: as operator count grows, Router channel management costs scale linearly
- Thin competitive moat: another team could build the same platform with lower fees
Option B: Fully Decentralized (Public Network)
Core logic: Each station operator runs their own node, connects to a public Fiber network (e.g., a foundation-maintained official Router). Users’ browser nodes auto-route payments.
Advantages:
- Minimum trust cost: operators don’t need to trust any platform — only the protocol itself
- Maximum network effects: all stations on one open network, theoretically users connect once and can pay any station
- Anti-censorship, anti-monopoly: no centralized entity can freeze accounts, raise fees, or kick a station off the network
Disadvantages:
- No commercial entity: the official node doesn’t generate profit — who guarantees 24/7 uptime?
- User experience nightmare: users manage their own channel balances, handle payment timeouts, and have no one to call for support. Regular users won’t accept this
- Heavy operational burden for operators: they need to maintain nodes, monitor channels, and troubleshoot technical issues. Most charging station operators don’t have the capability or willingness for this
- No data aggregation: each station only sees its own transactions — no industry trends or competitive benchmarks
- Compliance vacuum: who handles payment disputes? Who is responsible to regulators?
My Take: Start Centralized, Then Gradually Open Up
Honestly, the platform model is the more realistic starting point. Station operators won’t partner with you because of “decentralization” — they partner because it makes them more money or saves them costs. The platform’s value proposition is clear: zero tech investment, an additional customer acquisition channel, a data dashboard, and someone to handle support.
But that doesn’t mean we stay a closed platform forever. The more ideal evolutionary path is “thicken the platform, thin the protocol”:
| Phase | Platform Does | Protocol/Network Does | How Single-Point Risk Is Addressed |
|---|---|---|---|
| Now | Runs Router, maintains nodes, provides frontend and admin, collects fees | Serves as the underlying payment channel | Single-point risk borne by the platform team |
| Next | Opens API — external developers can also connect to our Router; stations choose whether to use our frontend | Nodes begin gossiping route information | Platform deploys redundant Router instances with automatic failover |
| Long-term | Platform degrades into a “value-added service provider” — data analytics, user ops, customer support only — no longer monopolizing the Router | Multiple Routers compete; protocol-level auto-routing | Multi-Router network is naturally decentralized — any single node going down doesn’t affect the whole network |
At this long-term state, the relationship between the platform and station operators looks like Shopify and merchants: merchants can use Shopify’s store builder, payment gateway, and analytics — but they can also move their store to another platform or build a standalone site at any time. The choice is with the merchant — that’s what decentralization actually means.
Pure decentralization is a means, not an end. The goal is for operators to earn more, for users to worry less, and for the network to sustain itself. The platform model is the shortest path to that goal at this stage.
From Experiment to Product: What Off-Chain Payments Actually Change
After building this project, I’m increasingly convinced that Fiber Network’s real value isn’t about “how much faster than Lightning” or “how much cheaper than Layer 1.” Those technical metrics matter, but they’re just prerequisites. The real value is: it makes “pay-as-you-use” business models — nearly impossible in Web2 — viable in Web3.
In Web2 charging apps, why can’t you truly “pay per kWh as you charge”? Technically, it’s not impossible — through pre-authorization and real-time deductions, existing stations already settle by the minute or by energy segments. The problem isn’t technical; it’s cost structure and who captures the value: credit card fees make micro-settlements economically unviable, settlement cycles range from T+1 to T+30, you get zero share of the yield generated while the platform holds your funds, and your spending data is fully captured by the payment pipeline. Essentially, you get a near-real-time experience, but the price is full surrender of fund control and privacy.
What Fiber Network does is turn payment itself into part of the network infrastructure, rather than a service you have to buy from a third party. The per-transaction cost of off-chain micropayments approaches zero, settlement latency approaches zero, and fund control returns to the user.
When payment stops being an external service that requires “application for access,” “fee payment,” and “waiting for settlement,” and instead becomes a built-in network-layer capability — like TCP/IP — new business models emerge naturally.
Charging is just one example. Streaming pay-per-second, cloud computing per-request billing, API pay-per-call — these scenarios in Web2 either don’t work because of payment costs, or work unfairly because of platform monopoly. Fiber Network offers a new possibility: matching the efficiency of value flow to the efficiency of information flow.
Final Thoughts
This simulator is far from a mature product. It runs on CKB Testnet, there’s only one Router instance, channels require manual pre-funding, and the browser WASM node still hits compatibility issues in some environments. These limitations are real.
But it proves one thing: Fiber Network is already capable enough to support a complete end-to-end user scenario — identity creation, channel opening, multi-hop payments, and real-time visualization, all running in a single web page.
The next thing I most want to validate is whether the “thicken the platform, thin the protocol” evolutionary path actually works. Specifically, two things first: opening the API so external developers can also connect to our Router and stations can choose whether to use our frontend or build their own; and deploying redundant Router instances to eliminate the single-point risk in the current architecture. Let’s see what operators and users choose when the choice is genuinely theirs and system availability is assured.
If that validates, the next steps are fee marketization, multi-Router competition, and shared data layers. None of it requires starting over — each step progressively decentralizes from the existing platform. That’s what I find most compelling about this approach: it’s not a 0-to-1 gamble, but a 1-to-N gradual release.
If you’re interested in this direction, come try it, discuss it, build it together.
Live demo: https://54-180-28-237.sslip.io
Open source: https://github.com/HappySonnyDev/fiber-charge-sim
See you in the next article.
如果你读过之前那篇"边聊边付"，应该对链下微支付有个初步印象：钱不在链上跑，而是在双方约定的通道里实时流转。那篇文章验证的是可行性——技术上能不能做到每收到一段 AI 回复，就自动完成一次支付。
这次我想把它往前推一步：不只是验证技术可行性，而是看看当 Fiber Network 走进一个具体场景时，它会呈现出什么样的产品形态和网络结构。
场景选的是电动车充电。理由很简单：充电是一个持续发生的动作，费用按时间或电量实时累积，天然适合"用多少付多少"的流式支付模型。更重要的是，这个场景足够具体，能让我们看清 Fiber Network 里一些平时容易被忽略的设计——比如多跳路由、Hub 手续费、以及一个很有意思的问题：一个去中心化的支付网络，为什么也会演化出"Hub"这种看起来像是中心的节点？
在线体验：https://54-180-28-237.sslip.io
产品体验：打开网页就能充电付款
整个应用的界面分为两大部分：面向用户的充电主界面，和面向管理员的运营后台。先来看用户侧的体验。
整体布局
打开网页，你会看到一个深色科技风的界面，布局非常清晰——左边是网络拓扑图，右边是充电操作区。
顶部状态栏
最上方是两条信息带：
- 左侧 — 车辆状态：电池电量（初始 23%）、剩余续航里程、能耗效率。这些数字在充电过程中会实时更新，让你直观感受到"电在充进去"。
- 右侧 — Fiber 节点状态：显示当前是否已连接（绿色/红色圆点）、已建立的通道数量、通道余额、链上余额。点击"Connect"后，浏览器会在后台启动 WASM 轻节点，通过 Passkey 完成身份认证，然后自动连接到 Router。整个过程不需要助记词，不需要下载钱包 App，就像用指纹登录网站一样自然。
左侧：Charging Network Map
占据屏幕左半部分的是一张实时网络拓扑图，用 SVG + 动画直观展示整个 Fiber 网络的连接关系：
- You（用户节点）：左下角，你的浏览器 WASM 节点
- Fiber Hub（Router）：中心位置，网络的中继节点
- 四个充电站：Tesla、ChargePoint、EA、EVgo 分布在四周
节点之间用线条连接：User → Hub 是实线（你的直连通道），Hub → Station 是虚线（Router 与各个充电站的通道）。点击任意充电站可以切换选中状态。
最直观的视觉反馈在充电过程中：每完成一笔链下支付，会有一颗粒子光点从 User 节点出发，沿着连线飞向 Hub，再折向目标充电站。这不是前端模拟的假动画，而是真实的支付事件触发的——支付成功回调里才会生成粒子。Hover 到 Fiber Hub 上，还能看到当前的路由费率（默认 10%）。
右侧：Station Details
右上方是充电站详情面板，显示当前选中站点的信息：
- 站名与品牌：如 “Tesla Supercharger”
- 功率与费率：250 kW · 1.44 CKB/kWh · 0.50 CKB / 5s
- 可用状态：绿色 “AVAILABLE” 标识
- 操作按钮：
- 未连接时显示 “CONNECT FIBER NODE FIRST”（蓝色，不可点）
- 已连接但未开通通道时显示 “OPEN CHANNEL”（引导开通支付通道）
- 已连接且有通道时显示 “START CHARGING”（开始充电）
- 充电中变为 “STOP CHARGING”（红色，停止）
右侧下方：Transaction Log
Station Details 下方是交易日志面板，实时滚动显示充电过程中的每一笔操作：
14:32:01 Connected to Tesla
14:32:02 Initializing invoice-based payment...
14:32:03 Invoice payment stream active - 0.5 CKB every 5s
14:32:08 ✓ Invoice paid: a3f7e2d8... (0.500000 CKB)
14:32:13 ✓ Invoice paid: 8b1c4a9e... (0.500000 CKB)
每条支付记录前面带时间戳，已成功的支付打绿色勾。日志只保留最近 20 条，避免刷屏。
完整的交互流程
把以上模块串起来，一个用户的完整体验是这样的：
- 打开网页 → 看到 Network Map 和 Tesla 站点
- 点击右上角 “Connect” → 浏览器请求 Passkey（系统指纹/面容确认）→ WASM 节点启动 → 自动连接 Router → 顶部状态栏变绿，显示链上余额
- 开通支付通道 → 首次连接后，系统会检测你是否已有活跃的通道。如果没有，Station Details 面板会显示 “OPEN CHANNEL” 按钮。点击后弹出一个 Modal，显示你的 CKB 地址和当前链上余额。你需要向这个地址充值一定数量的 CKB（建议 ≥100 CKB），然后点击确认开通通道。开通后，这笔 CKB 会锁定在你和 Router 的通道里，成为你的可用支付额度
- 点击 “START CHARGING” → 系统创建充电会话 → 每 5 秒自动生成并支付一张 Invoice
- 观看充电过程 → 电池电量缓慢上涨，粒子光点在地图上飞行，交易日志滚动，顶部通道余额逐渐减少
- 点击 “STOP CHARGING” → 支付流停止，日志打印会话总结（“Session: 12 transactions, 6.000000 CKB total”）
整个过程中，用户需要主动做的四步是：Connect、Open Channel、Start、Stop。通道开通只需一次，之后再次访问时可以直接 Start。
关于充值：这个项目跑在 CKB Testnet 上，所有资金都是测试币。如果你的链上余额显示为 0，可以前往 CKB Testnet Faucet 领取免费测试币。在 Faucet 页面粘贴你的 CKB 地址（Open Channel Modal 里有显示），几分钟内就会到账。
Admin Dashboard（运营后台）
左下角有一个不起眼的 “ADMIN DASHBOARD” 入口，点进去是运营后台。这里可以查看：
- Dashboard 总览：今日收入、今日交易笔数、今日路由手续费、活跃会话数、历史累计收入、历史累计路由费，以及各充电站的收入排行榜
- Router Network：当前 Router 通道总数、用户连接数、Station 连接数、总路由手续费、已转发的交易总数，以及每个用户通道的余额和状态
- Stations / Transactions / Statistics：各充电站的运营数据、每笔交易的详情、按时间维度的统计分析
后台最核心的价值，是让运营方直观看到 Hub 的手续费收入（Router 从每笔支付中抽取的 10%）和 各车商的分成收入。这在传统的聚合支付平台里通常是黑箱，但在这里每一笔都公开可查。
为什么需要多跳：用户不需要认识每一个商家
在这个模拟器里，有一个关键设计可能不太显眼，但它决定了整个网络能不能运转起来：你作为用户，只和 Router（Hub）节点建立了直接通道，但你却能向 Tesla、NIO、XPeng、EA 任意一个节点付款。
这在传统支付里也不是做不到——支付宝、微信支付、Stripe 都是聚合平台，用户不需要拥有每个商家的账户也能完成付款。但区别在于资金的路径和信任的假设。
在传统聚合支付中，你的钱先经过支付平台（支付宝、微信），进入它们的清算体系，再由平台结算给商家。这中间涉及：平台托管你的资金、平台掌握完整的交易数据、平台设定规则和费率、商家和用户都需要信任这个平台不会滥用权力。
在 Fiber Network 里，Router 不碰用户的钱。用户的 CKB 锁定在自己和 Router 之间的链上通道里，Router 只是转发支付承诺，最终可以通过链上结算来保证履约。你不需要信任 Router 不会卷款跑路——它跑不了。通道状态公开可查，路由路径通过 gossip 协议传播，任何人都可以验证。
这就是多跳支付在去中心化网络里的真正意义：不是"聚合"本身，而是在不需要中心化托管的前提下实现聚合。
它带来的第一个好处是显而易见的：用户侧极轻。你不需要给每个商家都开一条通道、存一笔押金。只要有一条到 Router 的通道，整个网络里的商家你都能付。
第二个好处更深层：流动性在网络里流动，而不是被困在点对点之间。假设你只在 Tesla 有通道，充完电余额剩了不少，但你下次想充 NIO——钱就卡住了。有了 Router 作为中继，你的余额可以通过 Router 转发到任何一条它有连接的通道上。Router 成了网络里的"流动性交换机"。
第三个好处关乎可扩展性。想象这个网络从 4 个充电站扩展到 400 个。如果每个用户都要和 400 个站点分别建通道，这个网络永远跑不起来。但多跳路由让拓扑从 O(n²) 降到了 O(n)——用户连 Hub，Hub 连商家。互联网的 BGP 路由就是这么工作的，Fiber Network 也在走类似的路。
Router 如何变成 Hub：高连接度节点的自然出现
上面说的多跳路由，引出了一个更有意思的现象：Router 不只是转发消息的技术中继，它还会在网络的拓扑结构中扮演一个特殊角色。
注意我说的是"特殊角色"，而不是"特殊地位"。这是有区别的。
在我们的模拟器里，Router 会从每笔经过它的支付中收取一笔路由费——默认是支付金额的 10%。这笔钱从用户付的总额里扣，Router 拿走自己的部分，剩下的转给充电站。有人可能会问：Hub 会不会变成新的垄断者？
要回答这个问题，得先搞清楚 Fiber Network 里的 Hub 和传统支付体系里的"网关"有什么本质区别。
在传统支付里，收单机构、支付网关是垄断性的中心节点——它们有准入门槛（需要牌照、资质审核），它们托管资金（你的钱先打到它们的账户），它们控制信息（交易数据由它们掌握，商户和用户都不透明）。商户想接入支付体系，必须通过这些网关，别无选择。
Fiber Network 里的 Hub 完全不同。它没有任何准入门槛——任何人下载 fnn 跑一个节点，保持在线，有通道流动性，就可以成为 Hub。它不托管资金——用户的 CKB 锁在用户和 Hub 的通道里，Hub 动不了，随时可以在链上结算。它也不垄断信息——通道状态、支付路径、节点信息全部公开在链上或通过 gossip 协议传播。
所以严格来说，Fiber Hub 不是"中心化节点"，而是去中心化网络中一个连接度更高的普通节点。它之所以在拓扑上像中心，是因为网络效应自然筛选出来的，而不是协议赋予的特殊地位。
那手续费的意义是什么？
第一层，手续费是对 Hub 提供中继服务的定价。保持节点 24 小时在线、维护通道双向流动性、处理路径发现和支付转发，这些都有真实的机器和资金成本。没有经济激励，这个服务就没人提供。
第二层，手续费创造了竞争的前提——但目前这个阶段，竞争还不存在。在当前只有一个 Router 的 demo 里，10% 的费率是由运营方单方面设定的。"用户可以自由选择手续费低的 Router"是协议层面支持的愿景，但要真正实现，需要多 Router 生态的成熟。这也正是本文后面要讨论"中台模式如何演进"的核心问题：一个被运营的中台，怎样逐步走向开放竞争。
第三层，Hub 的出现不是对去中心化的妥协，而是去中心化网络的自然演化。纯粹的网状 P2P 在理论上很美，但在实际中不可扩展。Hub 结构把拓扑复杂度降为 O(n)，同时保留了每个参与者自由选择、自由退出的权利。这不是"分层去中心化"，而是同一个去中心化协议在不同规模下的不同拓扑形态。
我们的充电模拟器正是如此：用户通过轻量级的浏览器节点接入，Router 作为连接放大器负责网络中继——当这个 Router 的连接数增长到一定程度，它就自然获得了 Hub 的地位——充电站各自独立运营。三方谁都不是对方的附庸，任何一方都可以随时被替换，但三方合在一起，构成了一套能跑的支付系统。
区域网络模型：Hub 作为"聚合节点"
顺着这个思路再往下想，Hub 在真实场景里会呈现出什么样的形态？
想象某个城市的一个商圈，里面有 20 个充电桩，分属不同的运营商。每个运营商自己跑一个 Fiber 节点，但他们不一定愿意或者有能力去维护全网路由、处理跨区支付。这时候，一个"商圈 Router"就很有价值了——它负责把这 20 个节点接入更大的 Fiber 网络，让用户通过一个入口就能找到所有充电站。
在这个模型里：
- 用户只认商圈 Router，不用关心背后是哪 20 个运营商
- 运营商只维护自己和 Router 的通道，不用关心全网拓扑
- Router 提供连接服务，同时承担路由发现的责任
这不是幻想。传统支付体系里的收单机构、聚合支付平台，扮演的正是"区域连接"的角色。但 Fiber Network 的关键区别在于：任何人都可以成为这个角色，商户可以自由切换，资金始终由用户自己控制。传统收单机构垄断了信息和准入——商户必须通过它才能接受支付，平台可以看到所有交易数据，可以冻结资金。Fiber Hub 只负责转发和路由，资金在通道里，支付承诺可上链结算。这是用去中心化的协议，重构了传统中心化网络的功能。
但到这里就出现了一个商业上绕不开的问题：谁来做这个 Router？如果每个商圈的 Router 由不同的团队运营，商户怎么知道连哪个？用户怎么知道自己连的 Hub 能不能覆盖到他需要的充电站？这些问题的答案，直接指向了这篇文章最终要讨论的落地路径。
中台模式 vs 完全去中心化：商业落地的两种路径
聊到这里，有一个问题必须正面回答：这个项目未来应该以什么形态跑？
需要先说清楚当前这个 demo 的真实状态——它跑在我们的一台 VPS 上，Router 和四个 Station 节点都由我们维护，Admin Dashboard 的收入统计依赖本地 SQLite，外部车商还不能自主接入。它本质上是一个最小化的中台原型：我们有服务器、有管理后台、有车商接入能力。如果谈成合作，我们可以给车商提供一键部署，他们接入我们的 Router 就能开始收款。
但这不是唯一的路径。另一种想象是"完全去中心化"：车商各自跑节点，直接连到一个公共的 Fiber 网络，用户支付时自动寻路。
两种模式我都认真想过，各有优劣。
方案 A：中台模式（我们当前的方向）
核心逻辑：我们作为服务商去找车商谈合作。车商不用懂 Fiber，接入我们的系统就行。我们提供一键部署、前端界面、数据统计、支付路由。
优势：
- 商业模式清晰：可以向车商收部署费、抽手续费分成、或者收 SaaS 月费。有收入才能持续投入开发和运营
- 用户体验统一：用户打开同一个网页，看到所有车商的站点，不用关心背后连的是哪个 Router。支付失败了我们兜底
- 数据产生价值：Admin 后台的流水统计、收入排行、用户行为分析，这些聚合数据对车商有吸引力，单个车商自己做不了
- 运营灵活：可以做补贴活动、动态调价、A/B 测试费率，快速迭代
- 车商零门槛：车商只需要提供一个收款地址和费率配置，不用自己跑节点、维护通道
- 合规有主体：如果有监管要求，中台可以作为责任主体对接
劣势：
- 信任成本：车商需要相信我们不会做手脚。虽然资金在通道里动不了，但 Router 是我们控制的
- 单点风险：我们的 Router 宕机，所有车商都收不到款。这是中台模式最核心的脆弱性，需要通过冗余部署和故障转移机制来缓解
- 扩展天花板：车商多了以后，Router 通道管理成本线性增长
- 竞争壁垒薄：另一个团队也可以做同样的中台，而且费率更低
方案 B：完全去中心化（公共网络）
核心逻辑：车商各自跑节点，直接连到一个公共的 Fiber 网络（比如由基金会维护的官方 Router）。用户支付时浏览器节点自动寻路。
优势：
- 最低信任成本：车商不需要信任任何中台，只信任协议本身
- 网络效应最大化：所有车商在同一个开放网络里，理论上用户连一次就可以付给任何车商
- 抗审查抗垄断：没有中心化实体可以冻结账户、提高费率、或者把某个车商踢出网络
劣势：
- 没有商业主体：官方节点不盈利，谁来保证 7x24 在线？
- 用户体验灾难：用户要自己管理通道余额、处理支付超时、找客服没人理。普通用户不可能接受
- 车商运营负担重：车商要自己维护节点、监控通道、处理技术故障。大部分充电桩运营商没有这个能力和意愿
- 无数据聚合：每个车商只能看到自己的流水，看不到行业趋势和竞品对比
- 合规真空：支付纠纷找谁？监管要求谁负责？
我的判断：先中台启动，再逐步开放
坦率说，中台模式是更现实的起点。车商不会因为"去中心化"就跟你合作，他们因为"能多赚钱"或"能省钱"才合作。中台给车商的价值是明确的——零技术投入、多一个获客渠道、有数据看板、有人兜底客服。
但这不意味着我们要永远做一个封闭的中台。更理想的演进路径是**“中台做厚，协议做薄”**：
| 阶段 | 中台做什么 | 协议/网络做什么 | 如何消除单点风险 |
|---|---|---|---|
| 现在 | 跑 Router、维护节点、提供前端和 Admin、收手续费 | 只是底层支付通道 | 单点风险由中台团队兜底承担 |
| 下一步 | 开放 API，让外部开发者也能接入我们的 Router；车商可以自选要不要用我们的前端 | 节点间开始 gossip 传播路由信息 | 中台部署冗余 Router 实例，实现故障自动切换 |
| 远期 | 中台退化为"增值服务提供商"——只提供数据分析、用户运营、客服支持，不再垄断 Router | 多个 Router 并存竞争，协议层自动寻路 | 多 Router 网络天然去中心化，任一节点下线不影响全局 |
到这个远期状态，中台和车商的关系有点像 Shopify 和商家：商家可以用 Shopify 的建站工具、支付网关、数据分析，但也可以随时把店铺搬到别的平台，或者自建独立站。选择权在商家手里，这才是去中心化的真正含义。
纯粹的去中心化是手段，不是目的。目的是让车商多赚钱、让用户少操心、让网络可持续运转。中台模式在现阶段是实现这个目的的最短路径。
从实验到产品：链下支付到底改变了什么
做完这个项目，我越来越觉得，Fiber Network 真正的价值不在于"比闪电网络快多少"或者"比 Layer 1 便宜多少"。这些技术指标当然重要，但它们只是前提。真正的价值在于：它让"用多少付多少"这种在 Web2 里几乎不可能实现的商业模式，在 Web3 里变得可行。
在 Web2 的充电 App 里，为什么你不能真正做到"充一度电付一度电的钱"？技术上并非做不到——通过预授权+实时扣费，现有的充电桩已经可以按分钟或按电量分段结算。但问题不在技术，在成本结构和利益分配：信用卡的手续费让小额结算在经济上不划算，结算周期从 T+1 到 T+30 不等，资金被平台占用期间产生的收益和你无关，你的消费数据被支付通道完整掌握。本质上，你付出了接近实时的体验，但代价是资金控制权和隐私的全面让渡。
Fiber Network 做的事情，是把支付本身变成了网络基础设施的一部分，而不是一个需要向第三方购买的服务。链下微支付的单笔成本趋近于零，结算延迟趋近于零，资金控制权回归到用户手里。
当支付不再是一个需要"申请接入"、“缴纳手续费”、"等待结算"的外部服务，而是一个像 TCP/IP 一样内嵌在网络层的基础能力时，很多新的商业模式就会自然涌现。
充电只是其中一个例子。流媒体按秒付费、云计算按请求计费、API 按调用量结算——这些场景在 Web2 里要么因为支付成本做不起来，要么因为平台垄断做得不公平。Fiber Network 提供了一种新的可能性：让价值流转的效率，匹配上信息流转的效率。
写在最后
这个模拟器还远不是一个成熟产品。它跑在 CKB Testnet 上，Router 只有一个实例，通道需要手动预充值，浏览器的 WASM 节点在某些环境下还会遇到兼容性问题。这些限制都是真实的。
但它证明了一件事：Fiber Network 已经足够支撑一个端到端的用户场景，从身份创建、通道开通、多跳支付到实时可视化，全部可以在一个网页里跑通。
下一步最想做的是验证"中台做厚，协议做薄"这个演进路径能不能跑通。具体来说，先从两件事开始：第一是开放 API，让外部开发者也能接入我们的 Router，让车商可以自选用我们的前端还是自建前端；第二是部署冗余 Router 实例，消除当前架构的单点风险。看看当选择权真正交出去、系统可用性得到保障的时候，车商和用户会怎么选。
如果这一步验证了，再往下就是手续费市场化、多 Router 竞争、数据层共享。每一步都不需要推倒重来，而是在现有中台的基础上逐步放权。这也是我觉得这个路线最有吸引力的地方：它不是从 0 到 1 的赌博，而是从 1 到 N 的渐进释放。
如果你对这个方向感兴趣，欢迎来体验、来讨论、来共建。
在线演示：https://54-180-28-237.sslip.io
项目开源：https://github.com/HappySonnyDev/fiber-charge-sim
我们下一篇文章见。