Hi list,
I'm excited to publicly publish a new second-layer protocol design I've been
working on over the past few months called Ark.
Ark is an alternative second-layer scaling approach that allows the protocol
users to send and receive funds without introducing liquidity constraints. This
means a recipient can get paid without an onboarding setup, such as acquiring
inbound liquidity. The protocol also consumes orders of magnitude less on-chain
footprint than Lightning, as there is no concept of opening and closing
channels.
Ark has a UTXO set that lives off the chain. These UTXOs are referred to as
virtual UTXOs or vTXOs in short. Virtual UTXOs are like short-lived notes that
expire after four weeks. Users must spend their vTXOs upon receiving them
within this four-week timeframe or return them to themselves to reset the
four-week timer. Virtual UTXOs live under a shared UTXO and can be revealed
on-chain.
When a payment is made on the protocol, existing vTXOs are redeemed, and new
vTXOs are created, similar to how on-chain funds flow. To improve the anonymity
set of the coin ownership, vTXOs values are restricted to a set of sats values
ranging from one sat to a million sats.
Users can acquire vTXOs from someone who already owns them or use a process
called lifting, an atomic two-way peg mechanism that doesn't require trust.
Lifting lets users lift their on-chain UTXOs off the chain for a 1:1 virtual
UTXO. Users can unilaterally redeem a virtual UTXO for an on-chain UTXO without
asking for cooperation.
When sending funds, users coin-select & destroy their virtual UTXOs and create
new ones for the recipient (plus change) in an off-chain mixing round. Keys for
each new virtual UTXO are tweaked with a shared secret that reveals proof of
payment when spent. The payment destination is a dedicated well-known public
key similar to silent payments; however, the payment trace is obfuscated
through plain tweaking and blinded mixing.
Ark 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 and charge liquidity fees, similar to how Lightning
service providers work. ASPs on Ark are both (1) liquidity providers, (2)
blinded coinjoin coordinators, and (3) Lightning service providers. ASPs main
job is to create rapid, blinded coinjoin sessions every five seconds, also
known as pools. A user joins a pool session to make a payment, initially
coin-selecting and registering their vTXOs to spend, registering vTXOs for
intended recipients, and finally co-signing from their vTXOs to redeem them.
Ark can be built on Bitcoin today, but we have to compromise on
non-interactivity to do so. Recipients must be online to sign from n-of-n
multisig to constrain the outputs of a shared UTXO, outputs as in vTXOs. With
this approach, users won’t be able to receive offline payments; they need to
self-host an Ark client (like Lightning). To make Ark work without running a
server, we need a covenant primitive such as BIP-118 or BIP-119.
BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by
hardcoding a 65-byte signature and a 33-byte unknown public key type in a
script. Alternatively, BIP-119 CTV can directly constrain transaction outputs
to a template hash. Other alternatives would be (1) TXHASH, (2) CAT + CSFS +
TAGGEDHASH, or (3) XOR + CSFS + TAGGEDHASH combinations.
Ark uses a new locktype primitive called txlock to ensure the absolute
atomicity of a transfer schedule. Txlock is a condition in which only the
existence of a mutually agreed transaction identifier can unlock the condition.
A txlock condition could be satisfied by a hypothetical opcode called
OP_CHECKPREVTXIDFROMTHEUTXOSETVERIFY. However, Ark uses an alternative approach
to achieving the same outcome using connectors. Connectors are a special output
type on the protocol. The primitive is that if we want the Bitcoin script to
check if a particular transaction id exists, we simply attach an output from
that transaction into our spending transaction and check a pre-signed signature
against prevouts of our spending transaction. The connector outpoint in the
sighash preimage commits to the transaction id for which we want to satisfy the
txlock condition. In the Ark context, this is the pool transaction containing
vTXOs of intended recipients. Txlocks are used in Anchor Time Locked Contracts
(ATLCs) to provide an atomic single-hub payment schedule.
Anchor Time Locked Contracts (ATLCs) are conditional payments used on the Ark
protocol. When a vTXO was created in the first place, an ATLC was attached to
it, similar to how an eltoo:trigger is attached to a funding output during
Eltoo channel formation. When a vTXO is spent, the pre-attached ATLC connects
to a connector to form a txlock.
This txlock formation ensures that, for the attached ATLC to be claimed by the
service provider, the outpoint context of its connector must remain unchanged.
In other words, Ark service providers should not double-spend pool transactions
they create. This provides an atomic payout construction for senders, as payout
vTXOs nest under the same transaction of connectors. The link between
connectors and newly created vTXOs is obfuscated through blinded mixing between
those.
Pool transactions are created by Ark service providers perpetually every five
seconds, which are effectively blinded, footprint-minimal, rapid coinjoin
rounds. ASP funds the pool with their own on-chain funds in exchange for vTXOs
redemptions. Therefore, the pool transaction that hits on-chain has only one or
a few inputs the ASP provides. The pool transaction has three outputs: vTXOs
output, connectors output, and ASP change. Service providers place vTXOs for
the intended recipients to claim (under the vTXOs output) and connectors for
senders to connect (under the connectors output) in their pool transactions.
The first output of the pool transaction, vTXOs output, contains newly created
vTXOs of the coinjoin round. vTXOs are bundled and nested under this shared
output and can be revealed on-chain. vTXOs output expires four weeks after its
creation, and once it expires, the ASP who funded this output in the first
place can solely sweep it. Nested vTXOs under the vTXOs output are expected to
be redeemed by their owners in this window period. Nested vTXOs may be revealed
in this four-week timeframe if the factory operator happens to be
non-collaborative or non-responsive for a long period. Upon revealing a vTXO, a
unilateral exit window can be triggered by attaching the pre-signed ATLC,
similar to Eltoo. In the optimistic big picture, however, the final result is
almost always a pool transaction with few inputs and three outputs where pool
content is rarely revealed on-chain. Therefore, vTXOs & connectors remain
almost always off the chain.
Ark can interoperate with Lightning by attaching HTLCs and PTLCs to a pool
transaction, just like ATLCs and connectors. The attached HTLCs live under
another shared UTXO called the HTLCs outputs, which also expire after four
weeks. Ark service providers forward HTLCs to the broader Lightning Network the
moment after they them to their pool transaction. This means Ark service
providers are also Lightning service providers. Ark users can also get paid
from Lightning using HTLC-nested vTXOs.
Ark is an open network where anyone can run their own ASP infrastructure. This
means a user can have a vTXO set associated with different ASPs. The Ark
protocol design allows users to pay lightning invoices from different vTXO
sources using multi-part payments (MPP). Upon attaching HTLCs (or PTLCs) to
multiple pools operated by various ASPs, HTLCs can be forwarded to the end
destination via MPP.
A pool transaction can be double-spent by the Ark service provider while it
remains in the mempool. However, in the meantime, the recipient can pay a
lightning invoice with their incoming zero-conf vTXOs, so it’s a footgun for
the service operator to double-spend in this case.
A transfer schedule from a sender to a receiver is atomic in nature. ASPs
cannot redeem senders' vTXOs if they double-spend recipients' vTXOs under the
mutually agreed pool transaction id. A future extension of Ark can utilize a
hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain the ASP's
nonce in their signatures to disincentivize double-spending. Users can forge
ASP's signature to claim their previously redeemed vTXOs if a double-spend
occurs in a pool transaction. This is effectively an inbound liquidity-like
tradeoff without compromising on the protocol design.
On Ark, payments are credited every five seconds but settled every ten minutes.
Payments are credited immediately because users don’t have to wait for on-chain
confirmations to spend their zero-conf vTXOs further. They can hand over
zero-conf vTXOs to others or pay lightning invoices with them. This is because
the ASP who can double-spend users' incoming vTXOs is the same ASP who routes
Lightning payments.
You can find more info at https://arkpill.me/deep-dive
https://www.arkpill.me/deep-dive.
- Burak
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
