The Ark Protocol, a very splendid UTXO based Bitcoin OffChain Protocol, in its current non-convenant iteration, is presently faced with some not so splendid UX Flaws. These Flaws are categorized into two:
In cases where a premature sweep is conducted using the linear properties of Schnorr signatures, the recovered liquidity from such a sweep remains dependent on the transaction frequency of users and the depth of the Ark tree, given that a binary tree structure is employed. A proposed solution by João Bordalo involves utilizing a splitting function for VTXOs based on a predefined ratio. Building on this idea, I suggest a more dynamic splitting approach that accounts for the average transaction size. This adjustment could better optimize the protocol by reducing both the cost of unilateral exits and the overall size of the Ark tree. Regardless of the specific approach taken, a reduction in liquidity requirements is likely to result.
The current implementation of the Ark Protocol relies on pre-signed transactions, which introduces reliability concerns due to the myriad of issues users may encounter during the signing process. The use of a binary tree system means that half of the users are interdependent, requiring proper cooperation for successful signing. Additionally, the depth of the tree directly affects the failure rate—deeper trees result in a higher likelihood of failure. Consequently, the probability of failure increases with the number of participants involved in a round.
My proposed solution involves replacing the use of a single binary tree with a forest of smaller trees, where the size of each tree is determined by a liquidity parameter and the arrangement is based on user transaction frequency, which I suggest measuring periodically. Since reliability is a function of the number of users involved, smaller trees would improve reliability by reducing interdependence. However, excessively small trees could negatively impact transaction costs, so a balance must be maintained. In this approach, all transactions would first be sorted by the receiver’s transaction frequency. They would then be grouped according to the liquidity parameter, and each group would be transformed into a binary tree. This method aims to optimize both reliability and liquidity requirements in the use of a premature sweep, as sorting enables some portion of liquidity to be released before a full-sweep, inadvertently making it more appealling to have long sweep duration, improving UX. This method aims to optimize both reliability and liquidity requirements when a premature sweep is enabled, as sorting allows a portion of liquidity to be released before a full sweep. This inadvertently makes longer sweep durations more appealing, thereby enhancing the overall user experience.