The primary concern with Ark thus far has centered on the problem of liquidity lockup. As transaction volume increases on the network, the service provider must lock up more liquidity, resulting in Ark being characterized as a network with high capacity but low velocity.
Running Ark on a server already addresses liquidity concerns effectively. On a server, Ark can operate in 24-hour rounds, allowing ASPs to recycle their funds daily. This alone represents a substantial improvement over Lightning, as setting up a server allows for effortless payment acceptance without the need to open channels.
While running Ark on a server is already quite efficient in terms of liquidity, the founding idea behind Ark was to eliminate technical barriers and scale bitcoin payments for all in a user-friendly manner. This is where Ark v2 comes in.
Ark v2 enables Ark Service Providers (ASPs) to reclaim their liquidity without having to wait for the expiration period (4 weeks) to elapse. It almost sounds too good to be true, ha?
With the current Ark design, here’s what the TapTree structure of the shared UTXO looks like:
There are two branches; the sweep branch and the unroll branch.
The sweep branch can be triggered by ASP after 4 weeks, to efficiently reclaim the locked funds.
The unroll branch can be triggered by anyone, anytime, to start unrolling the congestion control tree all the way to leaves.
With the Ark V2 design, here’s what the new TapTree structure looks like:
There are two upper TapBranches; the left upper TapBranch, and the right upper TapBranch.
sweep and unroll branches remain under left upper TapBranch, where;
- The sweep branch remains unchanged.
- The unroll branch can no longer be triggered at any time; instead, it can be triggered after 2 weeks from the tree creation.
An upper TapBranch is added to the root. We name this branch the right upper TapBranch, or simply the revocation branch. This branch corresponds to various combinations of revocation possibilities.
When a sufficient number of users spend their vTXOs, the ASP enters revocation branch to efficiently reclaim the corresponding portion of their liquidity, without involving any time constraint.
Ark v2 introduces a similar mechanism to that of Lightning’s revocation scheme. In Lightning, users revoke their channel state by revealing a secret. Similarly, in Ark v2, users reveal a secret upon spending a vTXO. Unlike Lightning’s revocation scheme, though, here the revocation secrets are aggregated and are utilized for the collective redemption of funds.
Each vTXO owner holds an individual revocation secret. When a sufficient number of vTXO owners reveal their secrets, the ASP aggregates them;
Aggregate revocation secret = sec1 + sec2 + sec3 … + secn
Aggregate revocation public = sec1⋅G + sec2⋅G + sec3⋅G … + secn⋅G
With a valid signature generated from this aggregate secret, the ASP gains access to some corresponding leaf within the revocation branch.
A revocation branch can encompass up to millions or even billions of leaves, each representing an aggregate revocation public key combination, which in turn corresponds to a specific revocation possibility. While building such massive trees might be computationally expensive, a corresponding leaf can be easily unlocked with a simple CHECKSIG:
<aggregate_revocation_public> OP_CHECKSIGThe revocation leaf, must also use a covenant to constrain the outputs of the spending transaction to the ASP and the remaining tree, directing locked funds back into the ASP while redistributing funds to vTXO holders.
The final resulting script for a revocation leaf would be;
<aggregate_revocation_key> OP_CHECKSIGVERIFY <asp_key> OP_CHECKSIGVERIFY
<constrained_outputs_template> OP_CHECKTEMPLATEVERIFYA shared UTXO with 16 vTXOs contains a revocation branch with 805 leaves total. Such branch can be easily structured by the ASP, and re-structured by the client to verify the content of the branch.
In the event that the number of registered vTXOs in a round surpasses 16, the combination tree deepens, potentially necessitating a revocation branch with millions or even billions of leaves. Luckily a MAST can accommodate up to 340282366920938463463374607431768211456 leaves, and it scales well with log n on-chain footprint for the control block, which further benefits from a witness discount.
The issue lies less in the on-chain footprint and more in the computation. To construct such massive revocation branches, ASPs require custom hardware like VPUs.
As clients are unable to reconstruct such massive revocation branches, they must verify the content of the revocation branch using a zero-knowledge proof generated by the VPU provided to them by the ASP.
Alternatively, ASPs can divide shared UTXO outputs into several chunks, each containing 16 vTXOs, adding up 43 vBytes in each chunk.
Overall, the new design appears to involve considerable effort, but it seems to be worth it.
Note that the revocation design alters the outpoint reference of the vTXOs, rendering CHECKSIG-based connectors unusable. Instead, introspection combined with CSFS-based connectors must be employed with the new design. This means a vTXO now must only sign the outpoint reference of the connector to forfeit itself, excluding its own outpoint context from the signature message.
Special thanks to Matt Corallo for inspiring me to work on a revocation design.
