Skip to content

feat: build scalable cryptographic verification for Federation & Cross-Provider (#32) #50

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kasim672 wants to merge 2 commits into
base: main
Choose a base branch
from
+43 −73
Open

feat: build scalable cryptographic verification for Federation & Cross-Provider (#32) #50

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7012b75
feat: build scalable cryptographic verification for Federation & Cros…
kasim672 Jul 22, 2026
851e0b4
Merge branch 'main' into feat/issue-32-scalable-crypto-verification-f…
kasim672 Jul 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 15 additions & 33 deletions schemas/zk-sync-request.schema.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,43 +113,25 @@
},
"batch_proof": {
"type": "object",
"description": "Serialized ZK rollup proof demonstrating correct multi-state transition batch logic",
"required": [
"pi_a",
"pi_b",
"pi_c"
"proving_scheme",
"proof_data"
],
"properties": {
"pi_a": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$"
}
},
"pi_b": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$"
}
}
"proving_scheme": {
"type": "string",
"enum": [
"groth16",
"plonk",
"halo2"
],
"description": "The cryptographic proving system used"
},
"pi_c": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$"
}
"proof_data": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$",
"description": "The hex-encoded serialized proof payload"
}
},
"additionalProperties": false
Expand Down
48 changes: 15 additions & 33 deletions schemas/zk-sync-response.schema.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,43 +108,25 @@
},
"batch_proof": {
"type": "object",
"description": "Serialized ZK rollup proof demonstrating correct multi-state transition batch logic",
"required": [
"pi_a",
"pi_b",
"pi_c"
"proving_scheme",
"proof_data"
],
"properties": {
"pi_a": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$"
}
},
"pi_b": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$"
}
}
"proving_scheme": {
"type": "string",
"enum": [
"groth16",
"plonk",
"halo2"
],
"description": "The cryptographic proving system used"
},
"pi_c": {
"type": "array",
"minItems": 2,
"maxItems": 2,
"items": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$"
}
"proof_data": {
"type": "string",
"pattern": "^0x[a-fA-F0-9]+$",
"description": "The hex-encoded serialized proof payload"
}
},
"additionalProperties": false
Expand Down
13 changes: 6 additions & 7 deletions specs/EPIC-Federation-Cross-Provider-Issues.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,15 +29,14 @@ This document outlines the detailed issues to be created in the issue trackers o
* JSON schema files created in `schemas/`.
* Validate that handshake, delta sync requests/responses, and claim verification proof structures conform to schemas.

### Issue PROTOCOL-303: Conformance Test Suite for Federated Syncing Protocols
* **Type**: Feature / Test Suite
* **Priority**: Medium
* **Status**: Draft
### Issue PROTOCOL-303: Abstract Cryptographic Verification for Federation Sync (Issue #32)
* **Type**: Feature / Refactor
* **Priority**: High
* **Description**:
Create an automated conformance test checklist and validation suite for providers implementing the federated synchronization protocol.
Abstract cryptographic proof verification models across the Federation & Cross-Provider Synchronization protocol to be proving-system agnostic, replacing hardcoded Groth16 (`pi_a`, `pi_b`, `pi_c`) structures with generalized `proving_scheme` and `proof_data` fields.
* **Acceptance Criteria**:
* Add conformance checklist document in `conformance/` for federated state sync.
* Define test vectors for mutual authentication, User Consent Token (UCT) validation, and delta sync payload compliance.
* [RFC-006](RFC-006-Federated-State-Sync.md) details scheme-agnostic batch proof verification (Groth16, PLONK, Halo2).
* [`zk-sync-request.schema.json`](../schemas/zk-sync-request.schema.json) and [`zk-sync-response.schema.json`](../schemas/zk-sync-response.schema.json) schemas use generalized proof payloads (`proving_scheme`, `proof_data`).

---

Expand Down
7 changes: 7 additions & 0 deletions specs/RFC-006-Federated-State-Sync.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,6 +85,13 @@ Used when a provider needs to verify a single claim value on-demand without perf
* Raw `claim_value` and `salt` (if authorized by the UCT).
3. **Verification**: Provider A validates the membership proof against its verified local copies of Provider B's state root.

### 3.4. Cryptographic Proof Architecture & Scalable Verification
To maintain scalability across heterogeneous federation nodes, the sync protocol decouples verification logic from specific zero-knowledge proving backends:

* **Scheme Agnosticism**: All block `batch_proof` structures contain a generalized `proving_scheme` field (e.g., `groth16`, `plonk`, `halo2`) paired with a serialized `proof_data` payload.
* **Batch Verification**: Syncing nodes can verify state transition proofs across multiple blocks in a single batch pass, reducing CPU overhead during catch-up operations.
* **Recursive & Dispersed Verification**: Federated providers can utilize recursive proof aggregation to collapse $N$ sequential block transitions into a single unified verification token, scaling cross-provider catch-ups efficiently.

---

## 4. Conflict Resolution Policy (CRP)
Expand Down