Hyperchain withdrawal handler

[kantai]

Withdrawals must be handled in the hyperchains contract. The best experience for users and miners would be if the act of issuing an anchor block commitment also “unlocked” the funds for the user in L1, and then the user could execute the withdrawal on L1 themselves. There’s two ways this could work:

1. The “withdrawn” funds are written to a well-known path in the Clarity MARF. The Clarity path is already committed in the anchor block. The withdraw function in the hyperchains contract on L1 would then allow a user to withdraw funds if they can supply a proof that, given an anchor block (which the contract already knows about), the funds were marked withdrawn by the tx-sender. This is all theoretically possible: it’s a straight-forward Merkle proof. However, in practice, getting serialization and verification to work in Clarity1 may prevent this from working (MARF proofs are also very large!)
2. The “withdrawn” funds are written to their own Merkle tree, which would have a serialization scheme tailored to Clarity1. Miners, when they issue their block commits, commit to both an anchored block hash and the withdrawn funds merkle root.

The short-term easiest way to handle withdraws in the implementation would be to simply rely on miners to issue the withdraws on the L1 chain. This, however, would present a large burden to the miners: they now need to manage issuing L1 transactions other than their block commitments, so they will need to do careful nonce management. They will also be responsible for transaction fees on those withdrawals, handling long-pending transactions, operating a withdrawal queue, etc. Needless to say, I think this approach should be avoided if at all possible.

[pavitthrap]

Leaving a note here to remember to think about runtime costs of the newly added withdraw Clarity functions. Options:

• use cost of burn operations as approximation
• benchmark costs

[kantai]

Closing this as finished.