3

It's the only boundary the taproot/MAST limitation of 128 levels of the tree, ie. 2^128?

Improve this question

1 Answer 1

Reset to default
3

MAST isn't really relevant here. As the Ark vtxo trees are just trees of sequential transactions. In theory they can be arbitrarily large.

Some things are to take into account though:

  • More round participants means more interactivity. Since all participants in the round have to provide signatures for the round to be successful, more participants means higher likelihood a round will fail and will have to be restarted, so the longer a round will take, time-wise. Note that ASPs can limit the number of participants in a round if needed and even run multiple rounds in parallel.

  • More vtxo tree leaves means a higher cost for unilateral exit. The number of transactions a user has to broadcast (and pay fees for) for a unilateral exit is log2(n) with n being the number of leaves in the vtxo tree. While this scales logarithmically, which is pretty great, it can still become a significant burden for users to participate.

  • When broadcasting multiple transactions for a unilateral exit, probably using a fee strategy like CPFP (child pays for parent), mempool policy puts an effective limit on the size of the exit transaction package. Currently, Bitcoin Core has a descendent limit of 25 transactions. Current work on cluster mempool will probably change this limitation and replace it with a cluster size limit (IIRC of 100). The way either of these limits affect Ark exit transactions is subtle and depends on how many people are exiting from the same Ark tx at the same time.

Eventually, I think the latter consideration will be the realistic limiting factor on realistic Ark vtxo tree size.

For example, using pre-signed transactions (clArk, i.e. covenant-less Ark) or using OP_CTV, this effectively limits the number of nodes in the entire tree*. With a limit of 25, that would mean a tree with up to 24 leaves and with a cluster limit of 100, that would mean 99 leaves.

However, with more powerful introspection opcodes**, the intermediate leaves could be fee-bumped so that this limit no longer holds.

*: In fact if only one leaf of the tree can confirm, it can make space for other branches. So let's say all nodes except the leaves is the limit. Meaning that for n leaves, there has to be space for n + 1 txs in the mempool.

**: like OP_TXHASH, OP_CHECKTXHASHVERIFY, OP_TX, direct introspection opcodes (or CAT+CSFS)

Improve this answer
2
  • Considering that you have the limit of 25 descendants in the mempool and that you have to broadcast log2(n) +1 txs when you unilaterally exit, shouldn't the max number of leaves be 2^24?
    – bordalix
    Oct 2 at 15:33
  • You'd think so. But nothing prevents others from broadcasting their leaves as well, and then some of the txs in your branch could be dropped. So to make sure your exit branch can't get dropped from the mempool, you need the entire tree to fit. This is with constructions where you can only add fees on the leaves. Using something like TXHASH, you can add fees to intermediate nodes and then it doesn't matter anymore.
    – Steven Roose
    Oct 6 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.