SNARK Account State

[evan-forbes]

One of the main motivations for SNARK Accounts is minimizing the state added by a rollup or external system that want to control an account. Ideally, SNARK accounts would have a very similar impact on the state machine as a normal account.

What exact state needs to go in the SNARK account relative to a normal account also has yet to be determined. Per a synchronous discussion, the initial account might look something along the lines of

message SNARKAccount {
  option (cosmos_proto.implements_interface) = "AccountI";

  string address          = 1; // optional, as we could always regenerate the address if needed
  string verification_key = 2;
  uint64 account_number   = 3;
  uint64 sequence         = 4;
  uint32 version          = 5;
}

As mentioned in the forum post, adding a small amount of state might be extremely beneficial for certain types of rollups that controlling an account via a SNARK.

… however if we add some extra state, it can be beneficial to rollups. For example, if add a special transaction type to also update the state root of a rollup on-chain, this means the rollup no longer has to recursively prove previous proofs.

[cmwaters]

Won't the state of the account also need to embody the validity predicate (or rules) to allow for withdrawal (and deposit)?