MIBZ: Multi-Identity-Based Encryption and Zero-Knowledge Proofs for Real-Time Encrypted Economies

[pememoni]

Title
MIBZ: Multi-Identity-Based Encryption and Zero-Knowledge Proofs for Real-Time Encrypted Economies
Summary
This project proposes a novel cryptosystem that leverages Multi-Party Computation (MPC) and Zero-Knowledge Proofs (ZKPs) to unlock “Magic In-Between Zones”—enabling real-time encrypted economies with privacy, security, and compliance. Traditional ZKP implementations are often limited in composability for shared private states, while MPC frameworks can struggle with verification. Our work bridges this gap with a Threshold Identity-Based Encryption (IBE) scheme and an efficient ZKP mechanism to validate private inputs.
We introduce a multi-identity setup, where decentralized networks collaboratively generate ZKPs for encrypted transactions. This cryptosystem is highly applicable for private-but-auditable trading, sealed-bid auctions, coercion-resistant voting, frontrunning protection, randomness generation, and confidential access control in AI supply chains. As an example, for post-transfer audits, verified encrypted transactions can be decrypted only by a revoker committee, ensuring decentralized governance and lawful compliance. Another interesting example is shuffling the deck by a fully decentralized committee in a way that all inputs are publicly verifiable and players are not affected by the ZKP delays for realtime interaction.

Methodology
Threshold IBE Overview
Threshold IBE is a cryptographic scheme where an encrypted message can only be decrypted if a threshold number of independent entities (validators) collaborate, preventing any single party from having full decryption power. Each validator holds a key share, and decryption requires the participation of multiple validators, ensuring both decentralization and security. This architecture mitigates risks by ensuring that no single validator can decrypt messages alone, supporting confidentiality and security.
ZKP for Encryption Validity
ZKPs are used to ensure that encrypted transactions are valid without revealing any sensitive information. When a user submits a transaction, they encrypt the details (such as asset ID, amount, or owner) using IBE. The user must then generate a ZKP that proves the correctness of the encryption process—i.e., that the encrypted message corresponds to legitimate inputs without disclosing those inputs themselves. The ZKP is included in the transaction payload and verified on-chain by a decentralized verifier. If the proof fails, the transaction is reverted, ensuring that only valid encrypted transactions are processed.

The proposed demo application ensures compliance and accountability without centralized control, built on a network of decentralized Revokers and Validators.

End-to-End Transaction Flow
1. User Transaction
Users initiate encrypted transactions with ZKPs proving their validity. The on-chain ZKP verifier ensures all transaction details
remain private unless malicious behavior triggers further investigation.
2. Suspicious Activity Detection
A Revoker monitors transactions off-chain. Suspicious activities trigger alerts for potential violations of compliance rules.
3. De-Anonymization Request Submission
If flagged, the Revoker submits a public, verifiable de-anonymization request on a governance dashboard. The request is subject to
Validator approval.
4. Validator Review and Voting
Validators, elected through governance processes, review the flagged request. They privately vote based on network policies,
protecting user privacy during decision-making.
5. Threshold Mechanism (On-chain)
A predefined threshold of Validator approvals (e.g., 8 out of 10) is required for the de-anonymization to proceed. Approved votes are recorded on-chain for transparency.
6. De-Anonymization Execution
With sufficient approvals, the flagged transaction is decrypted off-chain. Only the specific transaction is revealed to the Revoker, safeguarding other user data.
7. Post-De-Anonymization
Further suspicious transactions require new requests and approvals. All non-flagged data remains encrypted to ensure privacy while enabling lawful accountability.
Project Timeline and Deliverables
1. December 2024 – January 2025
- Theoretical research, design, and documentation of the cryptosystem, including Threshold IBE, Noir ZKPs, and multi-party proof generation.
2. February 2025 – April 2025
- Implementation of IBE scheme for encrypted transactions.
- Development of ZKPs for validating encrypted data within the system.
3. May 2025 – July 2025
- Final testing and launch of the complete cryptosystem.
- Public documentation and open-source release.
4. August 2025 - October 2025
- Demo release showcasing private-but-auditable transfers

Team
Peyman Momeni
- Role: Co-Founder and Cryptographer at Fairblock
- Background: Graduate from the Cryptography, Security, and Privacy Lab at the University of Waterloo.
- Experience: Designed zkMIPS and Entangled rollups at ZKM, with deep expertise in MPC, ZKPs, and blockchain cryptography.
- Contact: [email protected]

Assumptions and Risks
This system assumes:
- Honest Majority Assumption: Up to t malicious parties can be tolerated in the MPC scheme. If more than t+1 collude, encrypted messages can be decrypted. Future work will explore enhancing security with Trusted Execution Environments (TEE) or staking-based slashing mechanisms.
- ZKP Security: All proofs remain non-interactive and zero-knowledge, ensuring transaction validity without revealing sensitive data.
- Decentralization: No single party holds decryption power, and all de-anonymization actions are publicly auditable to prevent unauthorized behavior.
While malicious Validators could potentially decrypt messages, the impact is limited to confidentiality breaches rather than loss of funds or safety. In contexts where temporary confidentiality is sufficient (e.g., frontrunning protection or auctions), this risk becomes acceptable. To further incentivize honest behavior, we incorporate staking and slashing mechanisms and traitor tracing algorithms for threshold cryptosystems to align Validator interests with user privacy.

Questions and Open Areas
- Risk Mitigation: Should we prioritize TEE-based key generation or economic staking to reduce collusion risks?
- Interoperability: How can the system seamlessly integrate with existing decentralized finance (DeFi) protocols?
- Scalability: What are the best ways to ensure real-time performance of ZKP verification in large-scale networks?

Preferred Start Date
Dec 1st, 2024