A detailed explanation of the Bitcoin Layer 2 protocol Ark: an alternative to the Lightning Network?

The Ark protocol allows users to send and receive funds without introducing liquidity constraints.

Written by: Peng SUN, Foresight News

In the development process of the Bitcoin Lightning Network, although PTLC and CoinJoin have improved the centralization and privacy issues to a large extent, liquidity is one of the flaws that hinder the large-scale adoption of the Lightning Network. Usually, for new users, after downloading the lightning wallet, they must find inbound liquidity (Inbound Liquidity) to receive bitcoins from the lightning channel. The amount of inbound and outbound liquidity (Outbound Liquidity) also determines the user's ability How many bitcoins are received and sent. At the same time, in the lightning channel, the total amount of liquidity is fixed and cannot be changed unless the channel is closed and reset. Therefore, overall, the actual user experience brought about by Lightning Network liquidity may not be good.

On Miami Beach not long ago, Bitcoin 2023 was in full swing. Bitcoin developer Burak Keceli brought the Bitcoin Layer 2 protocol Ark to the audience on this issue. This is an alternative to the Lightning Network. Send and receive funds without restrictions. Today, Foresight News will introduce how Ark works and its technical features.

1. Working method

In the Bitcoin network, a transaction is composed of input and output. The total amount of Bitcoin held by the address is called the unspent transaction output (Unspent Transaction Output, UTXO). BTC going to the new address after signing the unlock script will become UTXO again. The Ark protocol uses a shared UTXO set for anonymous off-chain payments. The submitted but undisclosed transaction output in the protocol is called a virtual UTXO (vTXO). There are two ways to obtain vTXO, one is to obtain it from users who already own vTXO; the other is to convert UTXO on the chain to vTXO at a ratio of 1:1 through the atomic two-way peg mechanism lifting. Of course, users can unilaterally convert vTXO to UTXO on the chain without seeking cooperation from ASP.

The Ark protocol involves two parties, the user and the Ark Service Provider (ASP). Users are non-interactive entities that hold, send, and receive vTXO, while ASPs are similar to Lightning Network service providers, acting as a trustless intermediary that provides vTXO liquidity to the network and charges liquidity fees. At the same time, ASP also acts as a blind CoinJoin coordinator, providing privacy protection for transactions by providing simple adjustments and blinded mixing.

When a user makes a payment on the protocol, the vTXO needs to be paid in the shared vTXO pool created by the ASP. ASP is online 24 hours a day, and its main job is to create a blind transaction pool every 5 seconds, blindly mix transactions, and avoid payment tracking. At the same time, ASP can redeem the sender's vTXO into on-chain assets, and use its own on-chain funds to create new vTXO for CoinJoin. Therefore, even if the transaction pool on the chain is publicly available, it only shows one or a few inputs provided by the ASP, and data observers on the chain cannot find the real payer. Subsequently, a vTXO output containing newly created vTXOs is generated from the ASP's blind transaction pool. vTXOs are bundled and nested under this shared output and can be exposed on-chain. In the Ark protocol, the vTXO output life cycle is only 4 weeks, and the payee needs to receive nested vTXO (nested vTXO) by co-signing n-of-n multi-signature within the first two weeks. If the vTXO is unclaimed for the first two weeks, the vTXO will return to the control of the sender, similar to HTLC timeouts on the Lightning Network. On the other hand, if the ASP happens to be uncooperative or non-responsive during this time, and does not co-sign the ATLC, then the vTXO owner can expose its nested vTXO, and then wait until after some relative time window (24 hours) encoded in the contract. Receive funds. Of course, ASPs will be able to liquidate them individually if the vTXOs that are disclosed remain unclaimed for more than 4 weeks.

2. Technical features

No liquidity restrictions

Compared with the Lightning Network, the Ark protocol does not introduce the so-called Lightning Channel, outbound liquidity and inbound liquidity.

Non-interactive

Ark's non-interactive payment is realized in a way similar to Bitcoin's silent payment, that is, the payee provides a "shared secret" between the sender and the payee, and provides the sender with a similar silent payment private public key. Each newly created vTXO is adjusted with a temporary shared secret containing a payment promise that will be revealed to the anchor ATLC as proof of payment when the vTXO is spent, i.e. when the 2-of-2 connector is closed.

However, the current reception of the Ark protocol is a compromise of non-interactive. It uses an interactive method, that is, n-of-n multi-signatures to limit transaction output. Its asynchronous offline reception is not yet perfect, and the payee must Run the Ark client online to sign to limit the output of the shared UTXO. In other words, users must come online every week or two to receive their tokens, otherwise unclaimed tokens will be cleared by the ASP. Therefore, for Ark, in order to truly achieve complete non-interaction and enable users to receive offline payments, there must be a "covenant" primitive similar to BIP-118 and BIP-119 to limit transaction output. In fact, even adding such a primitive to the Lightning Network would still prevent non-interactivity.

Absolute Atomicity

The so-called atomicity means that a transaction is indivisible, either completely successful or completely failed. Ark uses a new lock-type primitive called Txlock to ensure absolute atomicity of off-chain transfers. Txlock is a condition under which unlocking can only be done if there is a mutually agreed transaction identifier.

In the Ark protocol, the Txlock condition is satisfied using a connector. Connectors are a special type of output on the protocol whose primitive is that if we want Bitcoin Script to check for the existence of a particular transaction ID, we simply append the output of that transaction to the spending transaction and check against the spending Transaction Prevouts check a pre-signed signature. The connector output point (outpoint) in the signature hash (sighash) preimage (preimage) will be submitted to the transaction ID we want to satisfy the Txlock condition. In the Ark context, this is a pool transaction that includes a vTXO of the intended payee. Txlocks are used in Anchored Timelock Contracts (ATLCs) to provide atomic single-hub payment schemes. When a vTXO is first created, the ATLC is attached to it. When a vTXO is spent, the vTXO owner cooperates with the ASP to sign atlc:connect, and through the ATLC's 2-of-2 key path, the pre-attached ATLC is connected to the connector to form a Txlock.

This Txlock structure ensures that, if the attached ATLC is to be claimed by the ASP, the context of the connector output point must remain unchanged. In other words, an ASP cannot double spend the transaction pool it creates. This provides the sender with an atomic payment structure, since the payee's vTXO is nested in the same transaction pool as the connector.

Fewer on-chain Footprints

Compared with the Lightning Network, Ark has no concept of opening and closing channels, and has fewer interactions with the chain, so it takes up less space on the chain.

Privacy

CoinJoin "mixing currency" privacy service provided by ASP; payees do not need to obtain inbound liquidity, run servers in real time to collect payments, and leak privacy to external observers.

Compatible with Lightning Network

Just like ATLC and connectors, Ark can be compatible with the Lightning Network by attaching hash time lock contracts (HTLC) and point time lock contracts (PTLC) to the transaction pool. The attached HTLC exists under another shared UTXO called the HTLC output, which also expires after four weeks. The moment an ASP forwards an HTLC to its transaction pool, it forwards it to the wider Lightning Network. This means ASP is also a Lightning service provider. Ark users can also receive payments from the Lightning Network using vTXOs embedded with HTLCs.

Since anyone can run an ASP, users can send lightning invoices through different ASPs, after attaching HTLCs (or PTLCs) to transaction pools created by different ASPs, HTLCs can be forwarded to the final collection through multi-party payment (MPP) people.

Zero confirmation vTXO

The Ark protocol supports zero-confirmation vTXO, and the payment is credited every 5 seconds with the creation of the transaction pool, but the settlement is once every ten minutes. Therefore, the payment is credited immediately, and the payee can spend its zero-confirmation vTXO to transfer funds or pay lightning invoices (similar to receiving codes) without waiting for on-chain confirmation. Therefore, in theory, when a transaction pool transaction is still in the memory pool, ASP can double spend the transaction. However, Burak said that due to the absolute atomicity of the transfer, if the ASP double-spends the recipient's vTXO under the CoinJoin transaction ID agreed upon by both parties, then the ASP will not be able to redeem the sender's vTXO.

Burak believes that, in the future, Ark could utilize a hypothetical data manipulation operation code "opcode" (OP_XOR or OP_CAT) to limit the nonce in ASP's signature to avoid double spending. At that time, if the double spend occurs in a CoinJoin transaction, the user can forge the ASP signature to claim the previously redeemed vTXO.

3. Summary

The founder of the Ark protocol was originally a strong critic of the Lightning Network. His criticisms of the Lightning Network’s inbound liquidity, asynchronous reception, on-chain footprint, receiver privacy, and interactivity were the seeds of Ark’s birth. Burak himself admitted that some of his previous objections could be resolved in the long run, but he couldn’t find a “good recipe” for inbound liquidity. Driven by this idea, Ark came into being. Its innovation will greatly reduce the threshold for users to use Layer 2 payment, and imitate many Bitcoin primitives such as CoinJoin, blinding, and silent payment to build the Ark protocol to realize Bitcoin. Scalability and privacy payments. Compared with the Lightning Network, the Ark protocol not only proposes a solution to its inherent liquidity problem, but is also compatible with the Lightning Network, at least it is already a protocol that can complement it.

Still, Ark leaves a lot to be desired. For example, the payee must sign up every week or two to receive the tokens, which creates a new user experience problem. In fact, there has been some debate in the Bitcoin developer community about the double-spend problem brought about by Ark's adoption of zero-confirmation (0-conf). If it can be further improved on non-interactive and double-spending issues, then Ark's user experience and protocol security will also be greatly improved. In addition, Ark is completed off the chain. Although the sender and payee cannot be observed on the chain, whether ASP has private data still needs to be questioned.

References