I also wanted to add a clarification from the discussion on yesterdays call about the design space here that I hope will be useful.
It’s worth distinguishing between two kinds of snark accounts depending on the level of coordination between users of a single account. For lack of better terminology, we could call these “end user snark accounts” (e-snac) and “rollup snark accounts” (r-snac), with the difference being that users of an e-snac have high coordination ability and users of an r-snac don’t. This matters for the UX of replay protection, but in my understand we actually want to support both.
End User Snark Account (e-snac)
The e-snac can basically be identical to the existing account structure, using the existing sequence numbers for replay protection, but just replacing the secp256k1 pubkey with a zk verification key for an arbitrary circuit. The assumption is that users of a single e-snac can coordinate so they can set the right sequence number when they send a tx. This requires no new state to be added to the blockchain (besides handling the potentially much larger verification keys) and in principle could/should be added to the Cosmos-SDK as a new “signature scheme” that all SDK chains could benefit from. I think this is basically what @musalbas originally proposed.
If users are not coordinated, and thus can’t coordinate on picking the right sequence number in the right order, they won’t know which seq number to pick and will race each other, leading to lots of failed txs. In principle we could set up some kind of off-chain “sequencer” service that users transact through to get the right sequence number but we can’t guarantee they use it and it introduces a new central point of failure. Solving this requires more protocol design.
Rollup Snark Account (r-snac)
Hence the r-snac, which the options in the OP address, to support replay protection across uncoordinated users. This adds more complexity to the design and is why we need more state beyond just the base account type, though some of the options have significant drawbacks. What I’ve gathered from the calls / comments / my own view of the original options is that:
- Option 1 - only allows one withdrawal per block (since users need to know which withdraw id is being added to the merkle tree and what the new merkle tree root is)
- Option 2 - allows users to grief eachother by spamming the withdrawls to arbitrarily delay another users withdrawal
- Option 3 - mostly orthogonal to the other options in my view (just a question of when the state transition update proof is verified)
- Option 4 - seemingly the most favoured option, temporarily adds more state but otherwise addresses the problems of Option 1 and 2
- Option 5 - limits parallelism across rollups
IBC for r-snac
At the end of the day, designing an account that supports replay protection across uncoordinated users is exactly what unordered channels in IBC were designed for (ICS-04), and so the preferred Option 4 above is something like a partial implementation of this piece of IBC, with the core difference that it supports pruning where IBC currently does not. But as we show in our writeup, pruning can also be easily added to IBC. Additionally, there may be some concern that IBC is a bit bulkier than a custom stripped down solution, which might be true, though there is also some ongoing effort to simplify the IBC core to make it easier to integrate in more places. In the meantime, IBC seems to be the primary way that the Celestia state machine is expanding (e.g. see CIP-9, CIP-12, CIP-14, all proposed in the upcoming lemongrass upgrade)
In the model of using IBC for an r-snac, instead of a “snark account” what we really have is a snark based IBC client - this is the object in the Celestia state that verifies the state transitions of the rollup. On top of this IBC client we can layer any of the IBC application protocols, including token transfer, interchain accounts, nft transfer, etc. It’s at this application layer that we’d have an actual account (eg. every IBC token transfer channel is really a single account that holds the token balances) which in turn would be controlled by the underlying IBC client (in this case, a snark-based one).
The nice thing about this is that with interchain accounts (ICA), a rollup would be able to send any Celestia tx, and so rollups could stake TIA, participate in gov, send IBC transfers to others, etc.
Hope that is a useful/clarifying summary!