Enhance Mopro for Generic Workflows

[ElusAegis]

Problem

Mopro's current design assumes packages are primarily used for Zero-Knowledge Proofs (ZKP), enforcing default prove and verify functions. While useful for ZKP-specific tasks, this limits its utility for projects requiring generic or fully custom workflows.

Details

To address these issues, the following solutions are proposed:

1. Support for Custom Workflows:

   • Make prove and verify functions optional.
   • Enable developers to define custom Rust functions with a single procedural macro, such as #[uniffi::export] or a custom equivalent.

2. Move Beyond UDL Files:

   • Transition from UDL files to procedural macros to simplify integrations and offer greater flexibility.

Acceptance Criteria

• prove and verify functions are optional, and developers can define fully custom workflows.
• Procedural macros replace UDL files, simplifying integration and improving flexibility.

[vivianjeng]

Thank you for the suggestion 🙏🏻
I will consider this more and discuss with our team members

Simply summarize this issue's solution and the current implementation:
Current implementation:

• Define functions like

  pub fn generate_circom_proof(...) {
     #[cfg(feature = "circom")]
     // implement prover
     #[cfg(not(feature = "circom"))]
     panic!("Circom is not enabled in this build. Please pass `circom` feature to `mopro-ffi` to enable Circom.")
  }

• Generate UDL file like

  [Throws=MoproError]
  GenerateProofResult generate_circom_proof(string zkey_path, record<string, sequence<string>> circuit_inputs);

• build.rs file

  uniffi::generate_scaffolding(udl_path.to_str().unwrap()).unwrap();

Procedural macros

• Define functions like

  // Option 1: make `generate_circom_proof` optional (suggested in the issue)
  #[cfg(feature = "circom")]
  #[uniffi::export]
  pub fn generate_circom_proof(...) {
     // implement prover
  }
  
  // Option 2: keep the `generate_circom_proof` interface
  #[uniffi::export]
  pub fn generate_circom_proof(...) {
     #[cfg(feature = "circom")]
     // implement prover
     #[cfg(not(feature = "circom"))]
     panic!("Circom is not enabled in this build. Please pass `circom` feature to `mopro-ffi` to enable Circom.")
  }

• lib.rs file

  uniffi::setup_scaffolding!();

Reference: https://github.com/zkonduit/ezkl/blob/main/src/bindings/universal.rs

[sifnoc]

I think this is an inevitable issue for improving the developer experience. Currently, whenever a proof generation function is declared, modifying the UDL file is required, which is not good experiences. In the comments, Vivi describes two options:

Procedural macros

• Define functions like

  // Option 1: make `generate_circom_proof` optional (suggested in the issue)
  #[cfg(feature = "circom")]
  #[uniffi::export]
  pub fn generate_circom_proof(...) {
     // implement prover
  }
  
  // Option 2: keep the `generate_circom_proof` interface
  #[uniffi::export]
  pub fn generate_circom_proof(...) {
     #[cfg(feature = "circom")]
     // implement prover
     #[cfg(not(feature = "circom"))]
     panic!("Circom is not enabled in this build. Please pass `circom` feature to `mopro-ffi` to enable Circom.")
  }```

The first approach aligns with the current implementation:

mopro/mopro-ffi/src/lib.rs

Lines 14 to 15 in 0a3d5a0

	#[cfg(feature = "circom")]
	pub use circom_prover::{prover, witness};

However, the second option may not be suitable when using both the circom and halo2 feature flags.