Maintenance Overhead
OpenVM Version Management
Selecting and committing to a specific version of OpenVM is essential when writing a circuit, as different versions can generate distinct proving and verifying keys, even for identical Rust code. To ensure stability and security, it’s important to use an audited release rather than working with a development build or the main branch.Deprecation of a Signature Prover
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 (orUPDATE
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.