Morph Channel Explained: Separating Value, State Evidence, and Fee Responsibility on CKB

[janx]

Great write-up.

I fully agree with the core direction: funding and state should be decoupled. This is the kind of design space where the Cell model is more expressive than the Bitcoin UTXO. Perun on CKB also adopts a decoupled approach, a comparison between Morph and Perun’s ways of decoupling would be interesting.

I also like the version-based design using state_number. It avoids much of the revoked-transaction machinery used in penalty-based channels, and it takes advantage of CKB’s programmability instead of working around missing transaction semantics. This is why Generic Payment Channel Construction and Its Composability uses a monotonically increasing nonce to manage state versions. It’s simple and very CKB-native.

One broader design question I find interesting is what to do in adversarial cases. Should the protocol only prevent an incorrect state from becoming the final settlement, or should it also punish the party who tried to publish the stale state?

• Both approaches have trade-offs. For example, PoW does not have an explicit slashing penalty: failed or orphaned work is simply wasted. PoS systems usually do have explicit penalties, although in PoS this may be closer to a necessity than an optional UX choice. Payment channels sit somewhere else in the design space. A penalty mechanism gives stronger deterrence: if publishing an old state can make you lose a lot of money, you are less likely to try it. But the downside is that honest users can also be hurt by mistakes. The stronger the penalty, the more scary it is for normal users to participate.

• Lightning is an example on the other side. Its penalty-based design gives strong anti-cheating incentives, but it also forces node operators to manage revoked transactions and old state very carefully. If a node database is corrupted, a backup is restored incorrectly, or a cloud host crashes and restarts from stale state, an honest user may accidentally publish an old transaction and suffer a major loss. That operational burden raises the participation cost. In the long run, higher participation cost can hurt decentralization.

• So I think Morph’s “newer state wins” approach is attractive from a user-risk perspective. It focuses on preventing stale evidence from becoming final, rather than turning every stale publication into a slashable offence. But this also means the design must take griefing, watchtower reliability, sponsor budget exhaustion, and challenge-window sizing very seriously.

I also think the difference between Morph resizing and Lightning splicing is worth discussing more explicitly.

• In Lightning, splicing is usually understood as combining “close the old channel” and “open a new channel with a different capacity” into one flow. Technically it’s a different channel after splicing. The term “splicing” makes intuitive sense here.

• Morph’s operation seems slightly different. Morph SPLICE is more like updating the channel’s funding context under the same logical channel_id: the channel continues, the managed value increases or decreases, and the state/funding context advances. This is closer to “resize” or “re-anchor” than to a literal close-and-open splice.

• That said, both require an on-chain transaction and a funding output change. So the difference could be subtle and perceptual. It may matter for users and external integrations - should wallets, explorers, watchtowers, indexers, and SDKs treat this as the same channel with a new funding context, or as a new funding object linked to an old one? Is channel_id the stable integration key, while (channel_id, funding_epoch) identifies the current funding context? Would a different wording like “resize” better reflect the difference?

• Related to that, I am not fully convinced that StateHeader.funding_epoch is strictly necessary for protocol safety in the minimal design. It may make some checks simpler and logs/debugging/auditing easier. But it is still another signed field, another consistency condition, and more state cell data. It would be useful to analyze whether funding_epoch is a minimal safety requirement or an engineering/auditability convenience.

One more subtlety: fee bumping in CKB is not Bitcoin’s “replace-by-fee.” It means rebuilding the publication transaction against the currently live State Cell, using different sponsor inputs and a higher fee rate. Because the State Header doesn’t commit to which sponsor inputs are used, the watchtower can do this without re-signing. If the original tx is stuck because fees spiked, the watchtower builds a fresh one. The only invariant is that the new tx must consume the current live State Cell — CKB’s single-spend rule guarantees that a stuck tx and a new tx cannot both succeed.

• CKB does support RBF : a higher-fee transaction can replace an old pending transaction if they share at least one input.
• So I suppose the intended point here is not that Morph never uses RBF. Rather, Morph does not rely on the Lightning/Bitcoin style complicated fee-bump design, e.g. pre-signed fee-bump transactions. In Morph, the participant signatures authorize the StateHeader, not the sponsor coin selection or fee rate. Therefore a participant can simply rebuild a fresh publication/supersession transaction and choose different sponsor inputs freely to pay higher fee, thanks to that state evidence and fee-paying sponsor inputs are decoupled.

I’m also curious about liquidity management in channel factories - how should liquidity be transferred between members or between child channels within a factory? Does it require on-chain transactions? I think this topic deserves more analysis and explanation.

The Lightning Network on Bitcoin is the canonical implementation of this idea. It works. Millions of people use it. But it has structural problems that come from Bitcoin’s data model, not from anyone’s engineering mistake. Morph Channel is an attempt to get the same guarantees on a different kind of ledger — CKB , while sidestepping those structural problems at the root.

I want to highlight and applaud this paragraph: Bitcoin has taught us a huge amount, and Lightning is an impressive engineering achievement. But every time I see Bitcoin developers spend enormous effort on clever, fragile, sometimes even ugly workarounds for base-layer limitations, I cannot help feeling that a lot of human effort is being spent fighting the wrong battle.

Personally, I am pessimistic about endlessly stacking tricks on top of Bitcoin to make it do everything. Bitcoin’s most important job is store-of-value. The problems that really threaten that role are things like quantum-resistance and long-term economic sustainability. Many other applications should be solved with new designs that address the problem at the root, instead of forcing everything through Bitcoin’s constraints.

It’s great to see Morph asking what a channel should look like if we start from the Cell model directly.