Ark: Bitcoin's New Layer 2 Protocol

An accessible explainer

Authors: Sinz_Bitguide (Bitguide.io) & moonsettler (Github)

1. Introduction

Ark is a new layer 2 Bitcoin protocol proposed by Burak that opens up exciting possibilities and simultaneously addresses several existing challenges with bitcoin payments such as scaling, on-chain footprint and privacy. Ark enables private and trustless payments at scale for the hyperbitcoinized world and is interoperable with the Lightning network.

Lightning (LN) enabled cheap, instant, p2p payments that feel like magic. However, LN transactions do face certain challenges in scaling to the planetary level. Ark precisely attempts to fill those gaps while still being compatible and complementary with LN. Let us first review these LN challenges and then dive into Ark.

Challenges of Noncustodial Lightning

If you have tried teaching new users how to make Lightning payments you may have noticed most people just want it to be cheap, quick, and work with minimal setup. The current non-custodial Lightning requires interactive channel setups; users need to open and maintain channels and obtain inbound liquidity. It is not as easy as it should be. Thus, the custodial LN solutions that abstract the complexities and channel management have become very popular. At least three issues have slowed down the adoption of non-custodial Lightning in the current state:

1- Channel Management and Liquidity Re-Balancing: On LN you cannot receive payments without inbound liquidity, and thus, to maintain your node in usable condition you need to constantly balance liquidity. You need to lock up liquidity and ensure everyone on a payment route has locked enough liquidity for it to happen. Additionally, the utilization of this locked liquidity is low: liquidity is allocated on a provisional basis; it remain locked and ready at all time while the user may only do a few transactions a day – i.e., a fixed cost for intermittent usage. Further, to improve payment success rate we need abundant liquidity on all channels of a payment route, and that will inevitably lead to low utilization.

It is literally not possible to receive funds over the Lightning Network without first sourcing receiving [i.e., inbound] liquidity. That is a core limitation of the protocol itself. Do we want to solve this problem at the level of the protocol itself, seeing as that is where the current limitation is, or do we want to lean on centralized services and marketplaces to do so? – Shinobi, 2022 on Bitcoin Magazine

2- On-Chain Footprint: In the current state of the Lightning protocol, each non-custodial user needs their own channel which requires an on-chain transaction. If we are to onboard 1 billion people, we would need 1 billion on-chain transactions which can take years. It is also directly impacted by on-chain fees. Even if we managed to somehow open 1 billion channels, the possibility of mass force-closures would be catastrophic as the chain could not accommodate those transactions or the justice transactions in case an older state was used before the timelocks expire.

3- Offline Receipt: In non-custodial LN you cannot receive funds if you are offline.

So clearly, there are things to improve and work is being done to address them (e.g., channel factories, PTLCs). Ark is one such attempt that aims to provide a better user experience by reducing the user-side friction of transactions.

2. Ark: A New Layer Two Protocol

Ark is a layer 2 Bitcoin protocol that provides non-custodial, cheap, scalable, private payments with minimal on-chain footprint and automatic coinjoins, thereby solving several problems at once.

Ark is a second-layer solution designed to help scale Bitcoin transactions by using a shared UTXO model that enables anonymous, off-chain payments through an untrusted intermediary called the Ark Service Provider (ASP). ASPs are always-on servers that provide liquidity to the network, similar to how Lightning service providers work […] Ark is a liquidity network that operates like Lightning, but without introducing liquidity constraints or a direct link between the sender and receiver. It uses virtual UTXOs, to enable anonymous, scalable, off-chain payments. ASPs provide liquidity to the network and charge fees for their services. – Burak

How Does Ark Improve Payments?

With Ark there is no gossip/routing, and users directly work with a central Ark coordinator – Ark Service Provider or ASP. The ASP puts up a lot of liquidity and has a much more complicated job compared to a Lightning Service Provider but the user has a simple experience. All liquidity management burden is handed off to the ASP and user transactions look like on chain transactions. Payments are made cheap via the shared-UTXO model and are made private via off-chain coinjoin like mixing. At its desired scale, Ark may lock up a huge amount of liquidity, but it's better utilized than locking liquidity up into individual channels and thus not having it available where it eventually needs to be. However, payments might take a few seconds because the ASP has to coordinate coinjoin rounds and aggregate transactions. It should be notes that payments are not trustlessly confirmed until the tx confirms on-chain (see Ruben Somsen’s article).

How does Ark function to achieve these properties?

Ark Simplified

In this section, we will attempt to present a simplified model of how Ark works, abstracting the complexities under the hood. An Ark payment first requires the user to connect to an Ark service provider (ASP) and converts their coins (UTXOs) to virtual coins (vTXOs) which are off-chain and trustless Bitcoin guarantees. This process is called “lifting”. The conversion of on-chain Bitcoin to off-chain Bitcoin guarantees is conceptually similar to what happens on the Lightning network. Owners of vTXOs can unilaterally exit Ark and reveal their vTXOs on-chain to receive UTXOs. To clarify the mechanism, let’s assume Alice wants to make a payment to Bob:

A. Lifting: The first step is for Alice to lift her coins. This is an atomic swap where she will give up a UTXO (+ fees) to receive a vTXO from the ASP at the same time. The ASP makes a special transaction, called pool transaction (Pool TX), where it mixes UTXOs from many users (among other things) and creates a shared UTXO as well as many off-chain vTXOs for each of those users including one for Alice.

B. Payment: Alice then instructs the ASP to take her vTXO and pay Bob. She will only need to know Bob’s address. This payment is also atomic and private. The ASP does not know which vTXO belongs to which user and blindly mixes them to produce another anonymous vTXO set. Ark’s magic occurs in the fact that the post-mix vTXOs can only be claimed by the intended recipients even though the ASP has no idea who owns them. Put another way, the ASP is simply coordinating blind coinjoin rounds. Bob does not have to be online to receive the funds, can claim them at any time, transfer them to others, or move them on-chain.

3. Under the Hood

Let’s review the process of a payment in Ark step by step – Alice wants to onboard to Ark and send a payment to Bob.

1- Signup: Alice installs an Ark wallet, generates or selects an npub (public key). Then, she chooses one ASP from among several available ones to process her payments.

2- Funding: Alice, then, needs to fund the wallet. She will lift her on-chain UTXO’s and move them over to Ark:

2-1- The ASP receives several of these lifting requests, and creates a pool transaction (PoolTX1). The pool transaction aggregates users’ UTXOs into one UTXO jointly owned by the ASP and the users. The on-chain footprint is a single UTXO. The ASP will be making many of these pool transaction on a periodic basis (e.g., every 5 seconds), and Alice will join an upcoming one. Thus, ASPs leave a constant on-chain footprint while processing many transactions.

The pool transaction is atomic. The ASP creates a PSBT, where the user’s input to be uplifted is included. The users sign this PSBT in any order, and finally the ASP signs it too. There are only two possible outcomes – either the users get their vTXOs or they retain custody of their original inputs. When the user signs the transaction that signature is only valid to the exact outputs as presented to them. If anything changes, the ASP needs to get new signatures from everyone. Which requires an efficient coordination process that can deal with issues such as DOS attacks, slow user responses due to connection issues with Tor and mobile networks. We have not yet encountered a concrete solution to this issue and it remains an open question.

2-2- How does Ark enable shared ownership of an on-chain UTXO? every user receives a virtual UTXO or a vTXO. The vTXOs remain off-chain and are akin to “signed unconfirmed transactions” that could be revealed on-chain and redeemed at any time by the user if they choose to exit Ark for any reason. So the user remains in full control of their funds and even if the ASP shuts down or become uncooperative.

3- Atomic Payments: So now Alice has some vTXOs and can use them to initiate a payment to Bob. Ark enables atomic payments via the following mechanism:

3-1- Alice receives Bob’s address for payment. This address functions similarly to a Silent Payment Address (32 byte public key). Burak has proposed to use npub-s (nostr public keys). The ASP or other participants in the coinjoin round cannot know which vTXOs belong to which addresses. Alice then selects “coins” or vTXOs she wants to transfer to Bob and informs the ASP that she is ready for a payment.

3-2- The ASP, then constructs its next pool transaction (let’s call it PoolTX2), but this time it includes a payment to Bob in it in the form of a vTXO constrained to unique public keys derived from Bob’s public key (npub). This process of constraining can be achieved via BIP119 covenants or with all recipients creating a series of multi-sig transactions with the ASP. Using the covenant mechanism, the ASP creates an unconfirmed payment to Bob which is not revealed on chain yet. Note that without covenants, Ark transactions require interactivity from both senders and receivers. But, covenants will reduce the interactivity requirement to senders only.

3-3- The ASP then shows Alice the unconfirmed payment to Bob.

3-4- Atomic swap: Alice sends her vTXOs to ASP CONTINGENT upon Bob’s payment hitting the main chain – an atomic swap and involves no trust in the ASP. Ark enables Alice to make a payment contingent upon another payment through a new contract type invented by Burak called Anchor Time-Locked Contracts (ATLCs).

3-4-1- Hypothetically, this could have been an OP Code that says: approve this transaction only if this other transaction has occurred previously. But without such an OP Code, Ark uses a work around: connectors.

3-4-2- As the ASP generates PoolTX2, it also generates a small UTXO called a connector as one of the outputs. The connector carries a dust amount (a few sats) and has no function other than enabling Alice to make a contingent payment. A more complete picture of the second pool transaction is below.

3-4-3- The ASP shows the connector to Alice, and Alice uses that as one of the inputs to her payment transaction along her main vTXO. Without a connector Alice would only be sending the vTXO as the sole input to the ASP. Now she adds the connector UTXO as another required input. The result is that Alice’s payment will only go through if the ASP has honestly completed PoolTX2 and revealed it on-chain, giving Bob his unquestionable claim to his owed funds. If the ASP does not honor that transaction, the connector UTXO outpoint (transaction id, index) would not exist in the UTXO set, and the ASP cannot claim Alice’s vTXO. Alice only loses funds if Bobs gets them. This mechanism is what is known as the ATLC.

4- Payment is complete. Now Bob can keep his vTXOs on Ark, spend them like Alice did, or unilaterally exit and convert them to on-chain UTXOs if the ASP stops cooperating.

The above steps can take a few seconds because the ASP needs to coordinate transactions like the above across many users (to enable a coinjoin round for both added privacy and lower fees).

4. Synergies Between Ark and Lightning

A global point of sale system powered by Lightning can be interoperable with Ark. The two networks can synergistically work to scale Bitcoin.

Lightning as the Connective Tissue

In the current form of Ark, ASPs operate independently by default and do not communicate with other. It is expected that the Lightning network will function as the Bitcoin rails between ASPs, who professionally manage their well-funded and well-balanced channels. To switch ASPs users can pay a Lightning invoice and move over. Under this vision, LN becomes the connecting tissue between various protocols and services on top of Bitcoin.

Paying Lightning Invoices

Lightning invoices can be paid via Ark. The user will present an LN invoice to ASP that he wants to pay. He will coin-select the vTXOs and offer the fees.

The ATLC (Anchor Time-Locked Contract) attached to the vTXO that is being spent, can be complimented with an HTLC where the ASP has to know a certain preimage (the hash of which is the payment hash from the LN invoice that the user wants to pay) to claim ownership of the vTXO.

Then the ASP pays the invoice and presents the user with the preimage. The user now sees that the ASP presented proof of payment and thus he considers the invoice paid and the vTXOs spent.

5. Possible Issues

Liquidity Requirements

ASP needs a lot of liquidity to function properly. Every transaction on Ark needs separate liquidity. If we are sending a several transactions 1000 sats each back and forth 10 times, in a simplified calculation, the ASP needs at least 10,000 of liquidity to process it (for a more detailed calculation see Ruben’s article). For this reason, ASPs are expected to converge to a few large providers with large idle Bitcoin holdings (Micro Strategy, Blockstream, …) or maybe a few federations of smaller players. Such large hodlers will have an incentive to put up their capital for use in a trustless protocol such as Ark and charge service fees.

Monthly Sweeps

Newly created vTXOs expire after two weeks if the users do not claim/spend them, and the ASP will sweep them to free up liquidity. To prevent this, user wallets will need to log in at least once a month and refresh vTXOs or renew them. This can be addressed at the wallet-level but is a noteworthy protocol-level consideration. A benign ASP may “roll over” unclaimed and swept vTXOs to a new pool, this does not actually costs him extra liquidity, but at this point the user is at the mercy of the ASP until the new pool transaction confirms (and other necessary pieces of information are obtained by the user).

Dust Limit

If on-chain fees increase significantly, exiting to the base layer can become uneconomical. Thus, users will be having vTXOs that may not be economically enforceable on-chain.

Legal Pressure

The ASPs could be labeled as money-transmitters. They are likely large enough to be easily identified, and can be subject to regulatory hostility depending on the jurisdictions.

6. Conclusion

Ark is a new Layer 2 Bitcoin protocol that provides self-custodial, scalable, footprint-minimal payments with automatic coinjoins, thereby solving several problems at once. It gives users the power of atomic payments with no trust in the Ark service providers. If ASPs become unresponsive or begin censoring transactions, users can unilaterally exit to the base layer. Ark complements other Bitcoin innovations. It is interoperable with the Lightning network and can utilize it to connect ASPs. Additionally, fedimints that cannot afford an on-chain presence, could exist on top of Ark. It is currently under development and would achieve its full potential with covenants. In sum, Ark is a major step forward in enabling global Bitcoin adoption.

Acknowledgements

We would like to thank Burak, Ruben Somsen, and Ziya Sadr for their valuable input to an earlier version of this article. We also thank Rocket for the initial idea and contributions throughout.

Sinz_Bitguide (Bitguide.io | Twitter | Nostr)
moonsettler (Github | Twitter | Nostr)