“`html
In my pursuit to discover the finest option for Cake Wallet to provide user-friendly, non-custodial Lightning to our clients, I’ve delved deeply into both Spark and Ark. Both represent innovative strategies to Bitcoin layer two networks, fundamentally designed to be compatible with the larger Bitcoin network for transactions via the Lightning Network. While both can be utilized “simply” for Lightning transactions, both frameworks are poised for swift growth and broader applications in the months and years ahead.
One aspect to remember is that while Spark and Ark may appear quite alike at first glance, in actual use and execution, they are significantly different.
What is the necessity for new layer twos?
Bitcoin fundamentally serves as a remarkable instrument for freedom, but due to block size limitations, it is evident that most of the global population will never be able to perform transactions on-chain. Enter Lightning, a remedy that enables a single on-chain transaction to facilitate essentially limitless off-chain transactions, broadening the utility of Bitcoin’s base layer and allowing more individuals to engage in transactions.
While Lightning offered an encouraging method for scaling Bitcoin transactions, ultimately it has become evident that its best role is as an interoperability layer rather than a tool for end-users to operate independently. On-chain requirements, liquidity management, liveness demands, and other fundamental challenges render the implementation of user-friendly, self-custodial Lightning almost unattainable. This situation has become clear as the majority of Lightning wallets and use-cases have chosen custodial or federated models to simplify user experience and alleviate implementation difficulties.
The chief advantage that Spark and Ark bring to the Bitcoin ecosystem right from the outset is that they provide a significantly simpler and more accessible method for average developers to offer Lightning to their users, while simultaneously permitting greatly enhanced functionality in the future beyond just Lightning payments.
Ark, demystified
Background
The idea of Ark was conceived in May of 2023 by Burak, a Lightning supporter and developer. The motivation behind its development stemmed from the realization that the Lightning network, as it was structured, failed to serve effectively as an onboarding tool for the average user due to inbound liquidity demands among various other factors, and that privacy often fell short. While Burak created the protocol itself, two firms – Ark Labs and Second – have stepped up to transform the Ark protocol into a comprehensive layer-two network for Bitcoin.
Although both firms are developing around the same open-source Ark protocol, their implementations and goals are quite different. Consequently, I’ll strive to clarify both below wherever possible.
Definitions
Ark: Ark is a protocol for transferring Bitcoin transactions off-chain by utilizing multisig and pre-signed transactions between users and the Ark Operator. Anything feasible on Bitcoin can also be executed on Ark but at a faster rate and with reduced fees.
Ark Operator: The organization managing the centralized Ark server infrastructure and accountable for ensuring liquidity for user’s VTXOs prior to expiration.
Lightning Gateway: The organization that enables Ark users to send or receive Lightning transactions using trustless atomic swaps of Ark VTXOs. This function can be fulfilled by the same entity as the Ark Operator, but is often separate to distribute counter-party risk.
Virtual Transaction Outputs: Also referred to as “VTXOs,” these are quite similar to on-chain UTXOs by nature, but they are virtual as they do not appear as unique UTXOs on-chain and exist entirely off-chain. Users transfer and receive VTXOs within Ark.
Rounds: To achieve true finality and/or refresh VTXOs, Ark users must participate in rounds, collaborating with other Ark users and the Ark Operator to obtain new VTXOs in exchange for a fee.
Executing transactions
Ark operates very much like on-chain Bitcoin transactions, adopting many of the same characteristics while allowing transactions to be nearly instantaneous and trust-minimized among Ark participants. The sender collaborates with the Ark Operator to endorse the VTXO over to the recipient, or in the event of Ark Labs, to create a new, linked VTXO for the recipient. This results in a user experience that mirrors on-chain payments in many respects, but with significantly lower fees and faster transaction times. When users wish to send or receive Lightning payments, they can engage with a Lightning Gateway to perform atomic swaps of VTXOs for Lightning payments as needed. Currently, receiving Lightning payments offline in Ark is not achievable, yet it is likely this will be addressed in a comparably trust-minimized manner within Ark as it is in Spark.
If a user seeks finality (i.e. they’ve received a substantial payment), they can opt to join a round to finalize the transaction and obtain the same finality assurances as on-chain Bitcoin. The timing of this round process will differ based on the Ark Operator – with estimates ranging from every 10 minutes to every hour – and necessitates a relatively lengthy coordinated signing process amongst all users wishing to join the round with the Ark Operator. The frequency of rounds may even fluctuate based on demand, not being constrained to a singular frequency like Bitcoin block times.
As Ark directly inherits Bitcoin scripting and the UTXO model from on-chain Bitcoin, it is likely that Ark will be enhanced to accommodate token protocols like Taproot Assets in the future.
Trust trade-offs
Ark aims for a highly trust-minimized route to scaling Bitcoin, striking a balance between usability and trade-offs between Lightning and Spark. Note that Ark, as a protocol, is evolving rapidly, and some of these trade-offs will ideally be resolved through innovative off-chain techniques or subsequent to the implementation of covenants in Bitcoin.
Absence of out-of-round finality
While Spark lacks demonstrable finality, Ark establishes a sort of middle ground. For minor payments, users can trust the Ark Operator and previous senders to refrain from colluding for security, facilitating instant transfers without the need for collaborative signing rounds. It should be mentioned that by default, payments within Ark will be “out-of-round” payments that lack true finality, a tradeoff that allows Ark to provide an excellent user experience right from the beginning.
Nonetheless, users who require or desire true finality can achieve it by participating in a round and receiving a new VTXO from the Ark Operator. Recipients essentially control their desired trust model.
VTXO expiration
Due to the liquidity necessities involved in operating an Ark instance, Ark Operators need a mechanism to regularly reclaim liquidity. To facilitate this liquidity reclamation, Ark VTXOs will expire periodically (i.e. after 30 days, with the VTXO expiration set by each Ark Operator), requiring their holders to either join a round to renew the VTXO or risk relinquishing control of their assets completely to the Ark Operator. While the Ark Operator is strongly motivated to simply issue a new VTXO to the holder of the expired one when they come back online, both the Ark Operator and the
“““html
The user will possess the capability to utilize funds until a new VTXO is allocated to the user.
To prevent funds from expiring, users must renew their VTXOs within that timeframe either directly or by delegating the refresh to a delegate. Alternatively, atomic exchanges of an expiring VTXO for one with a more prolonged lifecycle could be conducted with an entity such as Boltz for a fee, although this has not yet been implemented.
Intricate round user experience
If you’ve ever utilized Coinjoin on Bitcoin, you are aware of how cumbersome and unreliable collaborating to sign a transaction with other Bitcoin users can be. In Ark, individuals seeking genuine finality for their VTXOs will need to remain available throughout a round signing procedure until it is finished, something that heavily relies on other participants properly completing the signing process. While this is quite straightforward for a wallet operating on an always-online server, it becomes considerably challenging to accomplish reliably on mobile platforms, especially iOS, where no background execution (and consequently no assurance of being online at the correct moment for signing) is guaranteed for any application.
Due to this intricate user experience, Ark Labs have devised a system that utilizes delegated third parties to perform the refresh in a trust-minimized fashion for users, thereby transferring the liveliness requirement to a third party. While this third party lacks the ability to misappropriate funds, if they go offline for any reason or decline to renew a specified VTXO, the user will be compelled to join a round themselves before the expiry interval. To reduce this risk, users may appoint several delegates, reallocating the trust assumptions for expiry to a 1-of-N basis, where if any delegate is honest, their VTXO will be adequately refreshed.
Second also employs a similarly structured system that permits trustless, non-interactive rounds for users, enabling any number of parties to sign for a user during a round (i.e., both the wallet provider and a third-party delegate), where if any of those parties signs correctly, the user’s VTXO is accurately renewed.
It is important to note that while these two solutions can refresh expiring VTXOs, they cannot provide users with true finality without the user’s active participation in the round themselves.
Finally, it’s crucial to highlight that the vast majority of intricacy with the round process can be completely alleviated if a simple covenant is implemented in an update to Bitcoin, which would unlock a substantially enhanced user experience for Ark.
Privacy trade-offs
At its essence, Ark inherits Bitcoin’s inadequate privacy and does not offer any significant privacy enhancements as a protocol. Nonetheless, its capability to offload execution off-chain and broaden Bitcoin’s functionality allows for the development of existing and innovative privacy protocols atop it in the future, with covenants entirely enabling features like private rounds within Ark.
In the near term, Ark Labs have proposed to utilize WabiSabi-like blinded credentials to enhance privacy from the operator when users engage in rounds.
Transaction visibility
While all transactions within Ark do not need to be published on-chain, providing a measure of transience, all transaction specifics are discernible to the Ark Operator and should not be regarded as truly private. Instead, considering the temporary privacy provided by Ark as akin to the VPN model (transferring visibility into transactions from the Bitcoin blockchain to a trusted third party) is a beneficial mental framework.
At present, it remains unclear whether Ark Labs and Second will keep transaction data confidential or make it available publicly, but as with a VPN, users should not completely depend on a commitment to refrain from logging for their privacy.
Discover more
Spark, demystified
Background
The Spark network was initiated earlier this year by the team at Lightspark, a Bitcoin-adjacent organization with a fascinating history. From UMA (a username system featuring natively integrated compliance functionalities for their banking partners) to ties with the failed Libra currency, they possess an unusual track record of developing tools that aren’t quite aligned with Bitcoin’s more cypherpunk origins. However, when I set aside their peculiar track record and concentrated solely on what Spark the protocol genuinely entails, it presents a rather useful, pragmatic, and robust tool overall.
Spark fundamentally adopts many of the advantageous features of statechains, a unique approach to layer twos on Bitcoin conceived by Ruben Somsen in 2018. Spark specifically enhances statechains with the concept of “leaves,” allowing users to send any amount in a transaction instead of being restricted to transact with entire UTXOs, which has been one of the biggest challenges with statechains thus far.
Terminology
Spark Entity: the organization operating a given Spark instance, i.e. Lightspark, comprising a collection of Spark Operators. Since Spark is an open-source protocol, anyone can establish their own Spark Entity, but each Spark Entity determines which Spark Operators can join.
Spark Operator: each Spark Entity consists of one or more Spark Operators, each responsible for validating and signing operations of users within the Spark instance, including fund and token transfers, issuance of new tokens, etc. These can either be the same entity as the Spark Entity, or (ideally) distinct in relation and jurisdiction from the Spark Entity. Currently, the two Operators for Spark are Lightspark themselves and Flashnet, but additional ones are expected to be included in the near future.
Spark Service Provider: an entity that offers various services to Spark users, including utilizing atomic swaps to trustlessly send and receive Lightning payments on behalf of the users.
Spark leaves: Spark addresses the challenges surrounding 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 divided freely into any necessary size.
Executing transactions
At its core, Spark operates by allowing users to seamlessly shift Bitcoin around the Spark network almost instantaneously by collaborating in a trust-minimized manner with Spark Operators to transfer ownership of individual leaves to another individual. There is no requirement for a blockchain, confirmations, or liveliness between sender and receiver, which simplifies and accelerates payments. When a user intends to make a payment on Lightning, they atomically exchange a leaf or leaves from their wallet with a Spark Service Provider who then processes 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 carried out in such a manner that if any of the Spark Operators or previous owner sincerely deletes their keyshare used in the co-signing operation, the leaf becomes solely owned by the recipient, preventing any double-spend. As this process only necessitates collaboration between the Spark Operators and sender and does not require any other Spark users, these signing rounds…
“““html
are extremely swift and robust against DoS assaults.
Spark additionally incorporates a comparable 1-of-N trust framework to facilitate offline reception for Lightning transactions, a significant user-experience enhancement over conventional Lightning wallet utilization. This becomes particularly crucial when utilizing Spark on a mobile wallet, as mobile systems cannot assure background operation or flawless network connectivity 24/7.
Besides standard transactions, Spark has broadened the concept to encompass native token functionality, primarily focusing on stablecoins such as USDT and USDC that can be issued and exchanged effortlessly within the Spark ecosystem. Token transfers themselves adhere to a comparable trust model to regular transactions on Spark and maintain the capability for unilateral exit on-chain.
Ultimately, users in Spark can unilaterally exit on-chain at any moment by publishing a pre-signed exit transaction on-chain. Although the expense of exiting can fluctuate significantly due to factors such as leaf depth and on-chain fee rates, potentially making it costly for smaller amounts, it remains an essential tool to guarantee that funds can be retrieved in case of a malicious or unresponsive Spark Entity.
Trust trade-offs
Spark adopts a very practical array of trade-offs that complement the current challenges faced by Lightning and Bitcoin use today. That said, there are some notable distinctions with Spark in contrast to on-chain Bitcoin or Lightning usage. I prefer to utilize the term “trust-minimized” when discussing Spark (and most other layer 2 networks) because only self-custody of Bitcoin on-chain can genuinely be regarded as “trustless.”
Absence of true finality
The primary risk to self-sovereignty in Spark is the absence of genuine finality, where users can never be certain that their funds cannot be double-spent through collaboration between the Spark Operators and a prior spender. In Spark, finality (the assurance that your funds can only be transferred with your keys) exists – but is not verifiable – on the condition that any individual Spark Operator removes their keyshare after endorsing a Spark transaction. Conversely, if all Spark Operators act maliciously and refuse to remove their keyshare and conspire with a previous sender of a leaf you possess, they can double-spend that leaf and effectively misappropriate funds.
In practice, I believe this 1-of-N trust assumption is sensible, yet it clearly falls significantly short of the standard, on-chain Bitcoin trust assumptions where true finality is inherent. It’s also crucial to note that due to the pseudonymous nature of Spark transactions, the prior sender could be identical to the Spark Entity.
Potentially centralized token control
While token transfers echo the 1-of-N trust presumption of standard Spark transactions, the tokens themselves can be frozen at any moment if the issuer opts to activate this feature. This resembles many centrally governed stablecoins such as USDT (which frequently freeze and confiscate Tether for legal reasons), a significant point to highlight and likely to be implemented in various regulated stablecoins like USDC and USDT.
1-of-N offline Lightning receive security
Although offline Lightning receptions are not trust-minimized in the same fashion as standard Lightning transactions, the theft of funds would necessitate all Spark Operators colluding to misappropriate a single Lightning payment, an act disincentivized due to the small nature of Lightning payments and the immense reputational risk if caught stealing from users, something that is easily detectable due to the intrinsic proof of payment in the Lightning network.
Privacy trade-offs
Spark itself shouldn’t be seen as a privacy instrument, as it inherits fundamental privacy challenges from Bitcoin’s base layer and made some questionable design decisions initially regarding privacy. However, Spark’s core technology could be augmented to offer remarkable privacy with the implementation of blind signing for all transactions, confidential amounts for token transfers, and other privacy technologies that are not typically feasible within the Bitcoin ecosystem.
Transaction visibility
While transactions in Spark aren’t publicly recorded indefinitely on a blockchain like on-chain transactions, every Spark Operator receives complete visibility into transactions. Theoretically, this could provide ephemerality if Spark Operators had a non-logging policy, but in reality, all transaction data is currently shared with an explorer by Flashnet, one of the Spark Operators. This implies that external observers can easily look up Spark addresses and view all transaction details, token balances, and even associate Lightning payments to addresses via timing and amount analysis.
Note that Spark is working on adding the feature for wallet developers to opt-out of this data sharing by marking transactions as private, reverting 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 commit to not publicly publishing this transaction data, but of course, still have the capacity to keep this data locally if they choose to do so.
Absence of address rotation
In its current iteration, Spark does not support spending from multiple distinct Spark addresses in a single transaction. While this is expected to be remedied and has already been recognized as a critical limitation of Spark, at present, this means that most Spark implementations will depend on a single, static address for all transactions, making Spark’s privacy currently less effective than even on-chain Bitcoin. Merging this address reuse with the visibility of all amounts implies that it would be effortless for an attacker to execute timing + amount heuristics on payments to determine which Lightning payments correspond to which Spark addresses.
Spark address disclosures
To complete the set of current privacy challenges in Spark, the core SDKs provided by Spark (and utilized 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 given BOLT 11 invoice and discover every transaction from that user in Spark, thanks to the static addresses and all details being accessible via an explorer as outlined earlier.
Note that this isn’t strictly necessary, can be easily deactivated by wallet developers, and is already removed in the Breez Nodeless SDK that employs Spark and is rapidly gaining traction, yet it is essential to highlight nonetheless.
Learn more
Conclusion
While both Spark and Ark signify an exhilarating new era in Bitcoin usability and scalability, as with all innovations, they come with their unique sets of trade-offs. Although neither presents a flawless solution, it’s thrilling that wallet developers finally have two competing and intriguing choices to integrate the implementation of Lightning, native tokens, and additional functionalities into their wallets and software without the complexities traditionally linked with Lightning. Both Spark and Ark propose a practical solution for scaling Bitcoin, embodying a challenging yet rational path to achieve a balance between trust-minimization, user experience, and scaling.
As both are rapidly advancing protocols, the hope is that the trade-offs posed by both solutions will see swift improvements and reduction in the ensuing months and years, delivering an even better option that brings non-custodial Bitcoin to a wider audience while expanding the possibilities for what can be built atop Bitcoin.
A special thank you to the team at Spark, Ark Labs, Second, Breez, Spiral, and Bitcoin QnA for dedicating their time to provide feedback on this article! It takes a community to unravel all of the trust assumptions and trade-offs associated with these innovative systems, and I am extremely appreciative to each for contributing their valuable time to assist here.
This is a guest post by Seth For Privacy. The views expressed are entirely his own and do not necessarily represent those of BTC Inc or Bitcoin Magazine.
Source link
“`
