Hi list,

The one-sentence version: L2s funded via co-owned 2 of 2 contracts with a single hub entity, without trusting it. I'll summarize here by copying the abstract of the paper [1], followed by a sort of Q&A; I think that's best way to convey the idea.

A contract with a hub lets a user hold the hub’s tokens on a layer 2 and withdraw them as bitcoin without trusting the hub for honesty or liveness. The L2 tokens are collateralised by the bitcoin in the user-hub multisig output, and if the hub refuses a withdrawal, or cannot answer because it is offline, it is enforced on Bitcoin. The only assumptions are those of the layer 2 itself, kept apart from the hub. No change to Bitcoin’s consensus is required. A withdrawal is a claim that a program, the withdrawal statement, ran on some input and produced an output: the statement is proved with RISC Zero and wrapped in Groth16, and a disputed claim is settled on Bitcoin by BitVMX [5], whose interactive search over the execution of a RISC-V program, here a Groth16 verifier, is the technical core of the design. Withdrawals are executed cooperatively in the channel — with overwhelming likeliness because the statement is deterministically verifiable in milliseconds — or, otherwise, a refused one is played as BitVMX’s on-chain search, pre-signed once per contract. The trustlessness gain is paid for with liquidity (with receiving ability only contingent on offered “inbound” from the hub, as in Lightning). The hub (but not user) must also stay live during normal operation, since an offline hub loses disputes by timeout. The design is built and measured on regtest: a real proof of the withdrawal statement is accepted by BitVMX’s unpatched Groth16 verifier in 478 million steps, implying about 22–25 transactions of 8-ary search on chain in the dispute’s worst case.

Here is my 'Q&A' approach which I hope will address the first things you'd think of:

*One central hub is dangerous!

If the hub disappears, the user gets the money. The hub cannot Sybil attack users by printing tokens fictitiously; the honest users' money is all backed. The only remaining risks are inherent to the L2 itself (is it a validity rollup or a quorum? Does it inherit finality from Bitcoin or is finality weaker? Etc.)

*Bridges usually mean you can only withdraw a fixed size utxo, meaning operators and relying on swaps. Surely that applies here?

 No. The withdrawal amount is encoded in bits in the bitcoin transaction witness, in dispute. This allows us to withdraw arbitrary amounts via multiple outputs of certain denominations.

*Don't these constructions usually require a 1 of n honesty assumption from a signing committee?

Not here: we avoid this by the LN-GAP trick: the contract is a bilateral contract between the hub and each user; the presigning happens between them, just as in Lightning.

*But if a bunch of users open channels with a hub, they can just .. pay each other through the channels?

A correct critique, partly, *if* the L2 ledger doesn't do anything but plain payments. Even then, you would avoid receiver liveness being needed, avoid routing and other minor things. But the real answer is: the L2 can offer more functionality. It can use zcash style shielded notes, allowing very high privacy while staying in the L2. It can also (in a different ``lichen'' on a different hub) offer rich smart contracting, etc.

*But this an IOU/ hub's token, so it's not actually bitcoin.

Incorrect with a crucial caveat. See the first point: every sat is redeemable via the user-hub contracts, *without* the hub's permission, one-to-one, so these are actually bitcoin *but only as long as you have liquidity to receive them*. A new user on L2 without a contract with the hub, or a user holding a balance on L2 far in excess of their inbound liquidity in their own contract, is holding *credit*, and has no such guarantee. But that's their choice.

*But still, a single central hub feels like bad design. Why not multiple hubs?

It's because of what these L2 tokens are. They are fungible, *enforceable*claims on the hub's money; they are minted by the hub itself, just on its own say-so. If you had hub 1 and hub 2, those claims are not transferrable trustlessly to the hubs themselves. If hub 2 prints a billion sats out of nothing and users accept it on the L2 they can redeem it with hub1, leaving hub1 out of pocket. From this line of thinking we see an interesting comparison with ecash servers: the hub can print as much as it likes, but it cannot steal/``rug''.

*So what's the catch?

 The negatives are twofold: one is liquidity, and this is easy to understand as the analog of the inbound liquidity pain point in Lightning, because it's basically the same thing. Such a hub *can* give no inbound liquidity to a user: they get tokens on L2 to spend, but they cannot (safely) receive. If they receive, it's just credit that someone else will hopefully buy from them. But the design does not assume that, of course, it allows receiving up to a ``cap'': the user negotiates that extra potential receiving amount (inbound liquidity) when it sets up the contract with the hub. The second negative is very concrete, and is a design decision rather than an absolute requirement: we use BitVMX's bisection (in fact 8-ary not binary) to enforce that the ZKP is valid, on-chain. In the worst case this is 20-25 transactions and may require watchtower design to be easy enough for users to fully rely on. In a correctly built implementation this is exceptionally rare because the incorrect party (trivially established) is guaranteed to pay all the fees (up to its reserve), and lose money.

A lot more detail in [1] of course. And that repo has a "full" proof-of-concept demo (includes the entire L2 inclusion proof to STARK to Groth16 verification of STARK; it's the groth16 verifier that goes into the on-chain dispute).

I think this design is genuinely interesting. Certainly more limited than a completely generic L2 (not in functionality; in scale), but also more practically achievable (in fact I don't think anything stops someone instantiating lichen fully, right now [2]). I guess, many ways to look at it. Feedback welcome.

(Oh, one more thing: why BitVMX's version of these things, with its multiple onchain rounds? it's mainly because it can actually be built. I don't know the actual current status of various schemes like BitVM3, BABE, Glock and its descendants, PIPES and so on; of these, maybe BABE is the most interesting alternative, for Lichen specifically? Not sure).

Cheers,

AdamISZ/waxwing

[1] the paper is at https://github.com/AdamISZ/lichen/blob/master/papers/lichen-draft.pdf

[2] contingent on being confident in all the tricky details of implementing BitVMX's dispute game. No small matter, you can easily "do" it by telling an LLM to do it, but there's a lot of moving parts that need checking carefully. I speak from experience, and I will probably have more such experience soon ...