Evaluating Compact for a distributed threat intel verification circuit (circom 2.1.9, Poseidon/BN254)

Technical Questions
1

Following up on a conversation in #dev-chat where norm pointed me to the forum for Compact team input.

The problem

We’re building a distributed threat intelligence network where nodes need to verify that anonymized attack signatures match across a mesh without revealing which node observed the attack, when it was observed, or the node’s position in the network. The verification layer needs to scale to 1,000+ concurrent provers.

Current circuit spec

The circuit is implemented in circom 2.1.9 using Poseidon over BN254.

5 private inputs:

  • attack_signature (256-bit hash of raw pattern data)

  • node_id (unique node identifier)

  • timestamp (observation time)

  • nonce (replay protection)

  • private_key (node credential)

4 public outputs:

  • correlation_key (derived value that matches across nodes observing the same attack pattern, without revealing which nodes saw it)

  • nullifier (prevents double-reporting of the same observation)

  • epoch (time window identifier, coarser than timestamp to prevent timing correlation)

  • credential_commitment (proves the node is authorized without revealing identity)

The core constraint logic: Poseidon hashes the attack_signature with a domain separator to produce the correlation_key. Two nodes that independently observe the same attack pattern will produce identical correlation keys, but neither can determine the other’s identity, timestamp, or position. The nullifier is derived from node_id, attack_signature, and epoch to prevent a single node from submitting duplicate observations within the same time window.

The question for the Compact team

Norm clarified that Compact compiles to ZKIR, not R1CS, so there’s no direct porting path from circom. That leaves three possible integration paths, and I’d like the team’s input on which is viable:

  1. Native rewrite in Compact. Can ZKIR express the constraint structure above? Specifically: does Compact support Poseidon hashing natively or through a standard library? Can it handle the derived-value pattern where two independent provers produce matching public outputs from different private inputs? Are there constraints on the number of private inputs or the circuit depth that would limit this design?

  2. Hybrid architecture. Keep proof generation in circom/snarkjs externally and use Midnight only for on-chain verification and shielded state management. Is there a path for verifying externally generated proofs (Groth16 or PLONK) within a Compact contract? This would let us leverage Midnight’s shielded state model for node identity without rewriting the circuit.

  3. Custom integration layer. If neither of the above fits cleanly, is there an established pattern for bridging external proof systems into Midnight’s transaction model?

Context

The detection system behind this is deployed on production infrastructure. We have a working edge classifier (Rust/WASM on Cloudflare Workers) and a ZK circuit challenge open for distributed systems engineers evaluating the circuit spec. We hold two US patents covering the detection and verification architecture.

We completed the full Midnight Academy track (Explorer, Scholar, Builder) this week and posted in #dev-chat yesterday. Evaluating Midnight alongside RISC Zero for the verification layer. The answer to this question determines whether Midnight handles just the identity/shielded-state piece or the full proof lifecycle.

Appreciate any guidance from the team. Happy to share the full circuit source if it helps the evaluation.