As described in Using Keystore Accounts, the state of each keystore account contains a vkey which specifies the authentication rule enabling the account holder(s) to update the associated signing data in data or the authentication rule itself in vkey. To build a new keystore-enabled smart account or integrate an existing modular smart account into the keystore, wallet developers must write a new authentication rule conforming to the ZK Account Authentication specfication. The section will explain how to do this by writing authentication logic in Rust with OpenVM and setting up a signature prover for a new keystore account type. There are three steps to writing a new keystore-enabled smart account, as follows:
  • Implementing a ZK Authentication Rule: The authentication logic for a keystore account is represented as the vkey for a ZK circuit generated using the Halo2 proof system. The proof must have as public inputs dataHash (a commitment to data for the account) and msgHash (the hash of the message the ZK proof is authenticating). For convenience, developers can generate ZK circuits from authentication functions written in Rust by using the OpenVM framework, although any ZK circuit adhering to the format can be used with the keystore. The outcome of this step is a keystore-compatible vkey which can be used for ZK authentication on the keystore.
  • Implementing a Key Data Consumer: To enable usage of data from the keystore, developers must implement a Key Data Consumer which implements authentication in EVM against a keystore account’s data which has already been authenticated against the keystore state root. The outcome of this step can be integrated into the Keystore Validator contract to add support for the user’s authentication type.
  • Setting up a Signature Prover: Users transacting on the keystore to update or rotate their keys will need to generate ZK proofs which verify against their vkey. To assist with this process, we anticipate wallet developers will provide a signature prover API to generate proofs on behalf of users. If the vkey is generated from a Rust function using OpenVM, a signature prover can be easily deployed from open-source code. Axiom will also offer a signature prover service for commonly used keystore account types.
The following subsections give more details on each step.