You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The eq-service presently only supports using the succinct prover network and this required a whitelisted key to use.
As an alternative, allowing the ability to generate a proof on the machine running the eq-service would be beneficial:
Acts as a failsafe when the prover network is problematic
Enables a "Free" option, as no funs/whitelisting is required to generate a proof
Abstract interface to ZK proof generation service
A trait impl for local is likley the best way to write this up IMHO
Perhaps a the gRPC call level, we would allow to selection of an explict prover service (local, network, what proof system/zkVM etc.). Alt/in addition would be to have the operator of eq-service select that (default & fallback) in config.
The text was updated successfully, but these errors were encountered:
The eq-service presently only supports using the succinct prover network and this required a whitelisted key to use.
As an alternative, allowing the ability to generate a proof on the machine running the eq-service would be beneficial:
Perhaps a the gRPC call level, we would allow to selection of an explict prover service (local, network, what proof system/zkVM etc.). Alt/in addition would be to have the operator of eq-service select that (default & fallback) in config.
The text was updated successfully, but these errors were encountered: