# IBC Snark Account

*authors: Ethan Buchman & Aditya Sripal*

We wanted to follow up on the idea of using IBC for C[elestia Snark Accounts](https://forum.celestia.org/t/celestia-snark-accounts-design-spec/1639), since most of the Snark account design options look more or less like a partial implementation of ICS-20 (IBC token transfer).

Essentially, the ZK updates can be implemented as an ICS-02 client, which is a generalized scheme that operates on blobs and can accomodate ZK proofs. The benefit of this is that it fits in a common standard, and allows other IBC standards to be layered on top (eg. both ICS-20 token transfer and ICS-27 interchain accounts), which would enable generalized functionality between Celestia and its rollups without requiring repeated rounds of custom protocol design.

The withdraw mechanics and replay protection that most of the Snark Account design options focus on come for free from ICS-20. However, ICS20 as currently designed does result in significant state bloat (commitments stored in state for every packet sent), but this can actually be addressed by adding an extra IBC message to clean up the state after packet timeouts (this would benefit all IBC users, but it seems might be a requirement for Celestia. Note Celestia currently incurs this state bloat in all its existing IBC connections, which might be acceptable for 10s of chains, but not for millions of rollups).

In what follows we first sketch how to capture the ZK updates as an ICS-02 client. Then we briefly sketch how to prune the ICS-20 state.

## Client Mechanics

ICS-02 is the generalized IBC client interface defined [here](https://github.com/cosmos/ibc/blob/main/spec/core/ics-002-client-semantics/README.md). At a glance, it defines a `Consensus State` and a `Client State`, and datagrams `Client Messages` and related handlers (`CreateClient`, `UpdateClient`, `SubmitMisbehaviour`) to instantiate and update them. The client then offers APIs for verifying membership or non-membership of elements in the state.

In the world of Tendermint chains, the `ConsensusState` is the Tendermint Header, the `ClientState` tracks the validator set and state root so the headers and Merkle proofs can be verified, the `ClientMessage` is a Tendermint light client update message. Finally `verifyMembership` checks a generalized merkle proof as defined in [ICS-23](https://github.com/cosmos/ics23). This "standard" implementation of an ICS-02 client is defined in [ICS-07](https://github.com/cosmos/ibc/blob/main/spec/client/ics-007-tendermint-client/README.md).

In the world of Celestia to rollup communication, we are largely replacing Tendermint light client verification with ZK proofs of rollup state transition functions. And since the rollups depend on Celestia block space anyways, their client verification can also be simplified.

Here we briefly sketch what the client management looks like going both ways:

L1 to L2 "state update":
- There does not need to be a real client on the L2. This is to prevent having the Tendermint Light client algorithm in the STF of a zk rollup.
- Note: The downside of not having a true client in the rollup STF is that IBC direct connections are only possible with the L1. Connection to the rest of the ecosystem is still possible by routing through the L1
- Instead packets from L1 to L2 will simply be added as part of the sequencing logic (these are the "Deposit Transactions" defined in the [original Snark Accounts writeup](https://hackmd.io/@succinct/SJ4LeWyop))
- i.e. Rollup block producers must add IBC packet flow messages (RecvPacket, AcknowledgePacket, etc) as part of their block creation. These would be system transactions for sequencer rollups and public inputs for based rollups.
- Open question: How would we include packet flow messages that cannot be triggered by changes in L1 state, the only example of this is TimeoutPacket. We emit Timeout event upon receiving a packet that has already timed out so this could be used by sequencers, though this doesn't exist in state.
- Celestia IBC logic can write the relayer messages directly into the namespace to enforce ordering between Deposit Tx's and regular txs. This could also be done for the Timeout.

L2 to L1 state update:
- Implement an ICS-02 client with ZK proof of the state machine. This would live on the Celestia chain and there would be one per rollup.
- The Client State itself contains the verification key(s) for state updates and for proofs of inclusion/exclusion in state.
- The ConsensusState contains the state root and the timestamp
- UpdateClient takes in a ClientMessage that includes a ZK proof of the next state update and verifies it before adding the next ConsensusState
- Misbehaviour performs a no-op since we do not have misbehaviour in ZK rollups
- VerifyMembership accepts a CommitmentProof that is a ZK proof of the commitment to a Path and Value at the given State root (ie. proving that an IBC packet was committed on the rollup)
- Similar logic for VerifyNonMembership

With these clients in place, ICS-20 can be layered on top by standard means, allowing for transfers to and from rollups. Each ICS-20 channel would involve its own escrow account on the Celestia chain. This does mean there are more state objects on Celestia than just a single `SnarkAccount` but the benefit is that with the client mechanics in place we can easily layer multiple different IBC protocols (token transfer, interchain accounts, nft transfer, etc) on top of a single client.

All the replay protection for token transfers comes from the ICS-20 standard itself. However, as we cover next, ICS-20 does have significant state bloat, though this can be addressed.

## State Pruning

The ICS-20 flow is as follows. On a sender chain (eg. the rollup), a user initates an IBC transfer with a specified timeout which results in funds being escrowed and an "outgoing" packet commitment stored in state. Proof of this packet is then relayed to the receiver chain (eg. Celestia). On receiving, the receiver chain stores a receipt (hash of the packet), and creates and stores an acknowledgement, which is then relayed back to the sender. If the receiver does not receive the packet in time, the original packet times out. No future receiving of the packet is possible, and the sender can time out the packet.

In either case, the sender prunes everything, but the receiver does not (for the sake of replay protection). Thus during a succesful transfer the receiver stores both the receipt commitment and the ack commitment, and it does this for every packet, which is obviously significant state bloat. While this is overall problem for IBC chains that needs to be addressed, it's especially acute for chains with high IBC traffic, and would presumably be a barrier to Celestia adopting it for communication with its rollups.

Fortunately, a simple extension of the IBC protocol (ICS-04 unordered channels, which ICS-20 is an instance of) should allow for the receiver commitments to be safely pruned, though this would require an extra message on the receiver. Once the packet timeout has passed, a proof that the sender has pruned everything can be sent to the receiver, allowing it to prune the commitments related to that packet. At this point, all intermediate data from the packet would be pruned from state.