feat: create dual_ledger_mass_exits.md aka Account Exits

[pdobacz]

Thanks to @paulperegud for help distilling this out.

An idea that came to mind when revisiting mass-exits. A more pragmatic approach allowing a user to "close" their account, leveraging some additional information submitted to the root chain contract by the operator.

This concept of "closing" the account allows for (possibly) cheap proofs and challenges.

[kevsul]

I like this idea!

What's the impact of this though?

The sum_of_funds is a commitment of the operator to much do all the accounts hold at given child chain height.

Will the childchain have to start tracking the balances of every account that it's ever seen? Could get out of hand...

[kevsul]

Is an account exit final? Or can that account deposit in the child chain again after the exit has finalised?

These 2 statements sound kind of conflicting:

- funds that `owner_address` receives after `K` can be operated with normally. (TODO - is that so?)

and

 - it is easy to validate an account exit and reasonable to compute challenge. It suffices to check the `balance(address)` at the moment `K`. It must equal to `sum_of_funds - sum(exclusions)`. If that's not the case, blockchain from `N` to `K` must be scanned to find the violating transaction/exit. After this initial check, all blocks/exits seen must be checked to not include anything spent by `owner_address` ever again.

I mean the last bit of the second statement: all blocks/exits seen must be checked to not include anything spent by 'owner_address' ever again.

[pdobacz]

Will the childchain have to start tracking the balances of every account that it's ever seen?

true that, if done naively. A basic solution would be to prune accounts holding nothing from the account-based ledger. This still will be then not larger than the UTXO set. So the account-based ledger requires careful merklization to be efficient enough.

Also in terms of merklization there's an alternative - keep the account-based ledger for all non-zero account, but only submit at height N the entries that changed at N. This might complicate proof-building a bit, but seems possible at 1st glance. TODO

Is an account exit final? Or can that account deposit in the child chain again after the exit has finalised?

Details to be fleshed out. In case it is hard to make it be non-final, it is safe to assume that no deposits will arrive after an account exit.

A more subtle case is that of non-deposit incoming funds (as those the owner_address can't naturally prevent).

2 statements sound kind of conflicting:

good catch, I'll clarify. For consistency (the TODOed statement is there) I'll assume that we don't require the account exit to be final - it only is "final" for height<K.

So to summarize the "account based final" case - I think both options are still on the table.

[kevsul]

So to summarize the "account based final" case - I think both options are still on the table.

I think non-final is more useful.

If an account exit is going to be a substitute for consolidating UTXOs on the child chain, then ideally you could do an account exit per token. Then you could buy some UsefulToken and exit them all with an account exit to use elsewhere. Then repeat if you need more in the future.

If non-final is not possible, then an account exit should really only to be used to mass exit when the chain goes byzantine.