In my quest to find the best solution for Cake Wallet to offer user-friendly, non-custodial Lightning to our users, I’ve gone deep down the rabbit hole of both Spark and Ark. Both are quite novel approaches to Bitcoin layer two networks, and are designed at their core to be interoperable with the broader Bitcoin network for payments via the Lightning Network. While both can be used “just” for Lightning payments, both networks are positioned to rapidly expand and be used for far more than that over the coming months and years.
One thing to keep in mind is that while Spark and Ark on their face seem rather similar, in practice and in implementation they are quite distinct.
Why do we need new layer twos?
Bitcoin at its core is an incredible tool for freedom, but due to block size constraints, we know that the majority of the world will never be able to make transactions on-chain. Enter Lightning, a solution that allows one on-chain transaction to allow for essentially infinite off-chain transactions, expanding the usefulness of Bitcoin’s base layer and making it possible for more people to transact.
While Lightning provided a promising approach to scaling Bitcoin payments, ultimately the realization that its best role is as an interoperability layer and not as a tool for end-users to run themselves has become clear. On-chain requirements, liquidity management, liveness requirements, and other core hurdles make the implementation of user-friendly, self-custodial Lightning next to impossible. This has become apparent as most Lightning wallets and use-cases have opted to use custodial or federated models out of a need to simplify the user experience and the implementation difficulty.
The biggest win that Spark and Ark provide to the Bitcoin space out of the gate is providing a much simpler and easier way for the average developer to provide Lightning to their users, while allowing for greatly expanded functionality down the line beyond Lightning payments.
Ark, simplified
History
The concept of Ark was created in May of 2023 by Burak, a Lightning advocate and developer. The driving force behind its creation was the realization that the Lightning network as constructed was not effective as an onboarding tool for the average individual due to inbound liquidity requirements among many other things, and that privacy was often lacking. While Burak invented the protocol itself, two companies – Ark Labs and Second – have stepped in to build the Ark protocol into an end-to-end layer-two network for Bitcoin.
While both companies are building around the same open-source Ark protocol, their implementations and objectives are rather dissimilar. As a result, I’ll do my best to distill both below where possible.
Terminology
Ark: Ark is a protocol for moving Bitcoin transactions off-chain by leveraging multisig and pre-signed transactions between users and the Ark Operator. Anything you can do on Bitcoin, you can do on Ark but faster and with lower fees.
Ark Operator: The entity running the centralized Ark server infrastructure and responsible for providing liquidity for user’s VTXOs before expiry.
Lightning Gateway: The entity that provides the ability for Ark users to send or receive Lightning payments using trustless atomic swaps of Ark VTXOs. This function can be provided by the same entity as the Ark Operator, but is often distinct to spread out counter-party risk.
Virtual Transaction Outputs: Also called “VTXOs”, these are very similar to on-chain UTXOs in nature, but are virtual as they aren’t represented as unique UTXOs on-chain and live entirely off-chain. Users send and receive VTXOs within Ark.
Rounds: In order to gain true finality and/or refresh VTXOs, Ark users will need to join rounds, where they work together with other Ark users and the Ark Operator to get new VTXOs in exchange for a fee.
Making transactions
Ark functions very similarly to on-chain Bitcoin transactions, and inherits many of the same mannerisms while allowing transactions to be near-instant and trust-minimized between Ark participants. The sender works with the Ark Operator to sign the VTXO over to the recipient, or in the case of Ark Labs to create a new, chained VTXO for the recipient. This allows a user-experience similar in many ways to on-chain payments, but with far lower fees and far faster transaction times. When the user wants to send or receive Lightning payments, they can work with a Lightning Gateway to atomically swap VTXOs for Lightning payments as-needed. At the moment no offline receive for Lightning payments in Ark is possible, but it’s likely this will be solved in a similarly trust-minimized way within Ark as it is in Spark.
If the user desires finality (i.e. they’ve received a large payment), they can choose to join a round to finalize the payment and gain the same finality assumptions as on-chain Bitcoin. The frequency of this round process will vary by Ark Operator – with estimates ranging from every 10min to every hour – and requires a relatively lengthy coordinated signing process between all users seeking to join the round with the Ark Operator. The round frequency can even vary based on demand, and is not something that has to be set in stone to a single frequency unlike Bitcoin block times.
As Ark inherits Bitcoin scripting and the UTXO model directly from on-chain Bitcoin, Ark will likely be extended to support token protocols like Taproot Assets in the future.
Trust tradeoffs
Ark targets a very trust-minimized approach to scaling Bitcoin, striking something of a middle-ground in terms of usability and tradeoffs between Lightning and Spark. Note that Ark as a protocol is rapidly developing, and some of these tradeoffs will hopefully be solved through the use of novel off-chain methods or after the implementation of covenants in Bitcoin.
Lack of out-of-round finality
While Spark lacks provable finality, Ark strikes something of a middle ground. For small payments, users can rely on the Ark Operator and previous senders to not collude for security, allowing for instant transfers with no need for collaborative signing rounds. Note that by default, payments within Ark will be “out-of-round” payments that lack true finality, a tradeoff that allows Ark to deliver a good user experience out of the box.
That being said, users who do need or want true finality can have it by joining a round and receiving a new VTXO from the Ark Operator. Receivers are essentially in control of their preferred trust model.
VTXO expiration
As a result of the liquidity requirements to operate an Ark instance, Ark Operators need a way to reclaim liquidity regularly. To allow this liquidity reclamation, Ark VTXOs will expire regularly (i.e. after 30d, with the VTXO expiry being set by each Ark Operator), requiring their owners to either join a round to refresh the VTXO or risk giving up control of their funds entirely to the Ark Operator. While the Ark Operator has strong incentives to merely issue a new VTXO to the owner of the expired one when they come back online, both the Ark Operator and the user will have the ability to spend funds until a new VTXO is issued to the user.
To avoid funds expiring, users will be required to refresh their VTXOs within that window either directly or by offloading refresh to a delegate. Alternatively, atomic swaps of an expiring VTXO for one with a longer lifecycle could be done with an entity like Boltz for a fee, but that is not yet implemented.
Complex round user experience
If you’ve ever used Coinjoin on Bitcoin, you know how tedious and unreliable collaboratively signing a transaction with other Bitcoiners can be. In Ark, those seeking true finality for their VTXOs will need to be available throughout a round signing process until its completion, something that will depend heavily on other participants properly completing the signing process. While this is quite trivial to accomplish for a wallet running on an always-online server, it’s rather complex to reliably perform on mobile platforms, especially iOS where no background execution (and thus no ability to be online at the right time for signing) can be guaranteed for any app.
As a result of this complex user experience, Ark Labs have come up with a system that leverages delegated third parties performing the refresh in a trust-minimized way for users, offloading the liveliness requirement to a third party. While this third party has no ability to steal funds, if they are offline for any reason or refuse to refresh a given VTXO, the user will be forced to join a round themselves before the expiry period. To mitigate this risk, users can designate multiple delegates, shifting the trust assumptions for expiry to a 1-of-N assumption, where if any delegate is honest their VTXO will be refreshed properly.
Second also have a similarly designed system that enables trustless, non-interactive rounds for users, allowing any number of parties to sign for a user during a round (i.e. the wallet provider and a third-party delegate) where if any of those parties signs properly, the users VTXO is properly refreshed.
Note that while these two solutions can refresh expiring VTXOs, they cannot give users true finality without the user actively participating in the round themselves.
Lastly, it’s important to call out that the vast majority of complexity with the round process can be entirely mitigated if a simple covenant is deployed in an upgrade to Bitcoin, something that would unlock a vastly improved user experience for Ark.
Privacy tradeoffs
At its core, Ark inherits Bitcoin’s poor privacy and doesn’t provide any notable privacy improvements as a protocol. That being said, its ability to offload execution off-chain and expand Bitcoin’s functionality allows existing and novel privacy protocols to be built on top of it in the future, with covenants fully unlocking things like private rounds within Ark.
In the short-term, Ark Labs have planned to use WabiSabi-like blinded credentials to improve privacy from the operator when users participate in rounds.
Transaction visibility
While all transactions within Ark don’t need to be published on-chain, providing some loose ephemerality, all transaction details are visible to the Ark Operator and shouldn’t be considered private in the truest sense. Instead, viewing the ephemeral privacy provided by Ark as analogous to the VPN model (offloading visibility into transactions from the Bitcoin blockchain to a trusted third-party) is a useful mental model.
It’s unclear at this time if Ark Labs and Second will keep transaction data private or publish it publicly, but as with a VPN users should not rely entirely on a promise to not log for their privacy.
Learn more
- Official docs (Ark Labs): https://docs.arkadeos.com/
- Official docs (Second): https://docs.second.tech/
- Excellent Ark explainer video from Second: https://www.youtube.com/watch?v=WvwmLv0SgAc
- “Ark and the train analogy”: https://pakovm.substack.com/p/ark-and-the-train-analogy-a-guide
Spark, simplified
History
The Spark network was launched earlier this year by the folks at Lightspark, a Bitcoin-adjacent company with an interesting history. From UMA (a username system with natively integrated compliance features for their banking partners) to connections with the failed Libra currency, they have an odd track record of building tools that aren’t quite up to par with Bitcoin’s more cypherpunk roots. But, when I put aside their odd track record and focused purely on what Spark the protocol actually is, it presents a rather useful, pragmatic, and powerful tool overall.
Spark at its core takes a lot of the useful features of statechains, a novel approach to layer twos on Bitcoin created by Ruben Somsen in 2018. Spark specifically extends statechains with the idea of “leaves”, allowing users to send any amount in a transaction instead of being solely able to transact with whole UTXOs, one of the biggest issues with statechains up to this point.
Terminology
Spark Entity: the entity running a given Spark instance, i.e. Lightspark, made up of a collection of Spark Operators. As Spark is an open-source protocol, anyone can start their own Spark Entity, but each Spark Entity controls which Spark Operators can join.
Spark Operator: each Spark Entity is composed of one or more Spark Operators, each of which are responsible for validating and signing operations of users within the Spark instance, including transfers of funds and tokens, issuance of new tokens, etc. These can be the same entity as the Spark Entity, or (hopefully) distinct in relationship and jurisdiction from the Spark Entity. Currently the two Operators for Spark are Lightspark themselves and Flashnet, but more are slated to be added in the near future.
Spark Service Provider: an entity that provides various services to Spark users, including using atomic swaps to trustlessly send and receive Lightning payments on the users behalf.
Spark leaves: Spark solves the issues around whole-coin transfer requirements in statechains with the introduction of leaves. These can be thought of similarly to UTXOs within Bitcoin, as they can be freely broken up into any size necessary.
Making transactions
At its core, Spark functions by allowing users to easily move Bitcoin around the Spark network near-instantly by working in a trust-minimized way with Spark Operators to transfer ownership of individual leaves to another person. There is no need for a blockchain, confirmations, or liveness between sender and receiver, making payments simple and very fast. When a user wants to make a payment on Lightning, they atomically swap a leaf or leaves from their wallet with a Spark Service Provider who then sends the payment trustlessly on their behalf for a fee.
To transfer a Spark leaf, the sender co-signs ownership of the leaf over from themselves + Spark Operators to the new owner + Spark Operators. This is done in such a way that if any of the Spark Operators or previous owner honestly deletes their keyshare used in the co-signing operation, the leaf is then solely owned by the recipient and no double-spend is possible. As this operation only requires collaboration between the Spark Operators and sender and not any other Spark users, these signing rounds are very fast and resistant to DoS attacks.
Spark also includes a similar 1-of-N trust model to do offline receive for Lightning payments, a key user-experience improvement over standard Lightning wallet usage. This is especially important when using Spark on a mobile wallet, as mobile platforms cannot guarantee background execution or perfect network access 24/7.
In addition to regular payments, Spark has extended the idea to include native token support, with the core focus being on stablecoins like USDT and USDC able to be issued and transferred seamlessly within the Spark network. Tokens transfers themselves share a similar trust model to standard transactions on Spark, and retain the ability to unilaterally exit on-chain.
Lastly, users in Spark can unilaterally exit on-chain at any time by publishing a pre-signed exit transaction on-chain. While the cost of exiting can vary widely due to variables like leaf depth and on-chain fee rates, likely pricing out smaller amounts, it’s a critical tool to ensure that funds can be retrieved in the event of a malicious or unavailable Spark Entity.
Trust tradeoffs
Spark makes a very pragmatic set of tradeoffs that compliment the current issues befalling Lightning and Bitcoin usage today. That being said, there are some major differences with Spark compared to on-chain Bitcoin or Lightning usage. I prefer to use the term “trust-minimized” when talking about Spark (and most other layer two networks) as only self-custody of Bitcoin on-chain can truly be viewed as “trustless”.
Lack of true finality
The core risk to self-sovereignty in Spark is the lack of true finality, where users can never know for sure that their funds cannot be double-spent through collusion between the Spark Operators and a previous spender. Within Spark, finality (knowing that your funds can only be moved with your keys) exists – but is not provable – on the condition that any single Spark Operator deletes their keyshare after signing off on a Spark transaction. On the flip side, if all Spark Operators are malicious and refuse to delete their keyshare and collude with a previous sender of a leaf you own they can double-spend that leaf and effectively steal funds.
While in practice I think this 1-of-N trust assumption is reasonable, it obviously falls far short of the regular, on-chain Bitcoin trust assumptions where true finality is a default. It’s also important to note that due to the pseudonymous nature of Spark transactions, the previous sender could be the same entity as the Spark Entity.
Potentially centralized token control
While transfers of tokens themselves share the 1-of-N trust assumption of regular Spark payments, the tokens themselves can be frozen at any time if the issuer decides to enable this functionality. While this is similar to many centrally controlled stablecoins like USDT (who freeze and confiscate Tether quite often for legal reasons), it’s important to callout and will likely be enabled in many regulated stablecoins like USDC and USDT.
1-of-N offline Lightning receive security
While offline Lightning receives are not trust-minimized in the same way standard Lightning payments are, theft of funds would require all Spark Operators to collude to steal a single Lightning payment, something that is disincentivized due to the small size of Lightning payments and the massive reputational risk if caught stealing from users, something that is easy to detect due to the inherent proof of payment in the Lightning network.
Privacy tradeoffs
Spark itself should not be viewed as a privacy tool, as it inherits core privacy problems from Bitcoin’s base layer and has made some poor design choices initially when it comes to privacy. That being said, Spark’s core technology could be extended to have fantastic privacy with the introduction of blind signing for all transactions, confidential amounts for token transfers, and other privacy technologies that aren’t normally possible within the Bitcoin ecosystem.
Transaction visibility
While transactions within Spark aren’t published for all time to a blockchain like on-chain transactions, all Spark Operators do get full visibility into transactions. In theory this could provide ephemerality if Spark Operators had a non-logging policy, but in practice all transaction data is currently being published to an explorer by Flashnet, one of the Spark Operators. This means that outside observers can trivially look up Spark addresses and see all transaction details, token balances, and even link Lightning payments to addresses using timing and amount analysis.
Note that Spark is working to add the ability for wallet developers to opt-out of this data publishing by marking transactions as private, which then falls back to the same VPN-like trust model as previously described for Ark. If a wallet developer opts to enable this (as I hope they all will!), the Spark Operators will promise not to publish this transaction data publicly, but of course still have the ability to store this data locally if they so choose.
Lack of address rotation
In its current form, Spark doesn’t support spending funds from multiple distinct Spark addresses in a single transaction. While this is slated to be fixed and already acknowledged as a key shortcoming of Spark, at present it means that most Spark implementations will rely on a single, static address for all transactions, making Spark’s privacy at the moment worse than even on-chain Bitcoin. Combining this address re-use with all amounts being visible means that it would be trivial for an attacker to perform timing + amount heuristics on payments to ascertain which Lightning payments pertain to which Spark addresses.
Spark address leaks
To complete the trifecta of current privacy problems in Spark, the core SDKs provided by Spark (and used by the most common implementation of Spark in Wallet of Satoshi) by default include the user’s Spark address unnecessarily in BOLT 11 Lightning invoices. This means that anyone can easily decode a provided BOLT 11 invoice and learn every transaction from that user in Spark, thanks to the use of static addresses and all details being published to an explorer as detailed above.
Note that this isn’t absolutely necessary, can easily be disabled by wallet developers, and is already removed in the Breez Nodeless SDK that utilizes Spark and is rapidly gaining adoption but is important to callout nonetheless.
Learn more
- Official docs: https://docs.spark.money/home/welcome
- Bitcoin Layer 2: Statechains: https://bitcoinmagazine.com/technical/bitcoin-layer-2-statechains
Conclusion
While both Spark and Ark present an exciting new time in the world of Bitcoin usability and scalability, as with all things they come with their own unique sets of tradeoffs. While neither is a perfect solution, it’s exciting that wallet developers finally have two competing and interesting options to solve the implementation of Lightning, native tokens, and other functionality into their wallets and software without the complexity traditionally associated with Lightning. Both Spark and Ark present a pragmatic outcome for scaling Bitcoin, representing a hard but sane path to do things in a way that balances trust-minimization with user-experience and scaling.
As both are rapidly evolving protocols, the hope is that the tradeoffs presented by both solutions will be rapidly improved upon and minimized in the coming months and years, providing an even better option that gets non-custodial Bitcoin into the hands of many more people while extending the things that we can build on top of Bitcoin.
A special thank you to the folks at Spark, Ark Labs, Second, Breez, Spiral, and Bitcoin QnA for taking the time to provide feedback on this article! It takes a tribe to work out all of the trust assumptions and tradeoffs of these novel systems, and I’m extremely grateful to each for taking out some of their valuable time to help here.
This is a guest post by Seth For Privacy Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
