Signature Prover

Table of Contents

Role of the Signature Prover

Generating ZK proofs for transaction authentication is currently resource-intensive. As a result, to improve UX and transaction latency, we introduce a new entity into the system: the signature prover. This entity is expected to run robust, high-performance machines capable of generating ZK proofs efficiently to authenticate user transactions on the keystore.

Signature provers will receive, via JSON-RPC, an unauthenticated transaction payload along with a native form of authentication data (e.g. signatures), wrap the authentication data in a ZK proof, and return a fully serialized and authenticated transaction ready for submission to the sequencer.

Signature provers are free to define the interface for receiving the necessary input data for each of their supported circuits.

Relationship to Gas Sponsorship

Signature provers may chose to sponsor gas for users to eliminate the need for users to deposit onto the keystore to rotate their keys. In this case, the JSON-RPC API supports the generation of user signature proofs and sponsor proofs together, with the signature prover sending the resulting authenticated transaction directly to the sequencer.

However, sponsors may want to remain separate from signature prover if the ZK authentication requires private information or if the ZK authentication circuit is unknown to the sponsor. As a result, we do not mandate the unification of these roles at the protocol level.

Maintenance Overhead

When a signature prover is the sole provider for a particular keystore account type and associated ZK circuit, discontinuing support for that account type can pose a significant challenge for users. Specifically, if that signature prover stops generating proofs for a keystore account circuit, users relying on it for key rotations (or UPDATE transactions more generally) will need to generate ZK authentication proofs themselves, which can be a computationally demanding task.

To mitigate these risks, deprecations or transitions of circuit support should be carried out thoughtfully, with clear communication and supportive steps for users. Possible approaches include:

  • Graceful Deprecation Windows: Providing advance notice and overlapping support ensuring users have a suitable timeframe to adapt or migrate to a successor circuit.
  • Accessible Proving Resources: Make the pkey (proving key) and vkey (verification key) readily available, ideally along with a straightforward command-line or graphical tool. By hosting the necessary files in a public repository or download portal and offering a user-friendly binary for less technical users, signature provers can enable anyone to generate proofs locally after end-of-support without extensive technical expertise.

Putting such measures in place provides a safety net for users as keystore account types and circuits are phased out.