2. EnclaveProtocol: Adding Privacy Capabilities to Blockchain
2.1 Three Major Privacy Capabilities
EnclaveProtocol provides three dimensions of privacy protection capability enhancement for blockchain ecosystems through innovative cryptographic constructions and distributed system design. This section elaborates on the privacy protection capabilities of each dimension from the perspectives of theoretical analysis and system design.
2.1.1 Transaction Process Privacy
Core Capabilities:
This protocol achieves the following core capabilities in transaction process privacy:
Full Anonymous Transaction: Through zero-knowledge proof technology, complete hiding of transaction sender, receiver, and transaction amount is achieved, meeting Strong Anonymity requirements. From a cryptographic perspective, zero-knowledge proofs ensure the Zero-Knowledge Property of transaction information, meaning verifiers cannot obtain any information about transaction content from the proof
Relationship Privacy Protection: No traceable on-chain associations exist between transaction parties, third parties cannot infer transaction relationships through on-chain data. From a graph theory perspective, this achieves privacy protection of transaction relationship graphs, preventing Relationship Network Analysis attacks
Batch Privacy Operations: Supports one-to-many privacy allocation mechanisms, where multiple recipients are unaware of each other's existence, achieving Recipient Isolation. From a system design perspective, this achieves privacy protection for batch operations through Cryptographic Commitment and zero-knowledge proofs
Decentralized Verification: Requires no centralized components, adopts pure on-chain zero-knowledge proof verification mechanisms, ensuring decentralization. From a distributed systems perspective, this meets decentralization requirements and avoids Single Point of Failure risks
Technical Implementation:
From the perspectives of cryptography and system design, the technical implementation of transaction process privacy includes:
Zero-Knowledge Proof Mechanism: Uses zero-knowledge proof technology to hide transaction participants and amount information. From a cryptographic theory perspective, zero-knowledge proofs satisfy three basic properties: Completeness, Soundness, and Zero-Knowledge, ensuring verifiers cannot obtain any information about transaction content from the proof
Commitment Mechanism: Protects allocation plan privacy through cryptographic commitment mechanisms. From a cryptographic perspective, commitment mechanisms satisfy two basic properties: Hiding and Binding, ensuring allocation plans are invisible before submission and unalterable after submission
Nullifier Mechanism: Prevents double-spending attacks through Nullifier mechanisms while protecting privacy. From a security perspective, Nullifier mechanisms ensure each fund unit can only be used once through cryptographic hash functions, meeting Anti-Double-Spending requirements
Batch Withdrawal Mechanism: Supports batch withdrawals, multiple vouchers can be combined for withdrawal, improving privacy. From a system design perspective, batch withdrawals reduce Gas costs through Aggregated Proof mechanisms while improving privacy by increasing transaction complexity
Application Scenarios:
Application scenarios for transaction process privacy include:
Corporate Privacy Payment Scenario: When enterprises pay salaries to employees, protect payment relationships and amount information, preventing business secret leakage and competitive analysis
B2B Transaction Privacy Scenario: B2B transactions protect both parties and amount information, preventing business secret leakage and strategy analysis
Personal Transfer Privacy Scenario: Transfers between individuals are completely anonymous, protecting personal privacy and preventing wealth exposure and security risks
2.1.2 Digital Asset Privacy
Core Capabilities:
This protocol achieves the following core capabilities in digital asset privacy:
Asset Origin Privacy: Hides the original source and circulation paths of assets through cryptographic mechanisms, preventing on-chain tracking and analysis. From a cryptographic perspective, this achieves Untraceability of asset origins through Deposit Pool mechanisms and zero-knowledge proofs
Asset Holding Privacy: Protects user asset holdings from public exposure, preventing them from becoming attack targets. From a security perspective, this achieves privacy protection for asset holdings through privacy pool mechanisms and zero-knowledge proofs, meeting Wealth Privacy requirements
Asset Allocation Privacy: Supports flexible asset splitting and allocation mechanisms, each allocation voucher is independently managed and unrelated. From a system design perspective, this achieves privacy protection for asset allocation through Multi-Voucher technology, meeting Allocation Privacy requirements
Cross-Chain Asset Privacy: Supports multi-chain deployment architecture, achieving privacy protection for cross-chain assets, preventing cross-chain correlation analysis. From a distributed systems perspective, this achieves cross-chain privacy protection through Unified Abstraction Layer, meeting Cross-Chain Privacy requirements
Technical Implementation:
From the perspectives of cryptography and system design, the technical implementation of digital asset privacy includes:
Deposit Pool Mechanism: Through deposit pool mechanisms, assets are deposited into privacy pools, hiding asset origins. From a cryptographic perspective, deposit pools achieve Untraceability of asset origins through Mixing Mechanisms
Multi-Voucher Technology: Through multi-voucher technology, assets are split into multiple independent vouchers, each voucher is independently managed. From a system design perspective, multi-voucher technology ensures voucher uniqueness and security through independent nullifier mechanisms
Zero-Knowledge Proof Mechanism: Through zero-knowledge proofs, proves asset ownership without exposing asset information. From a cryptographic theory perspective, zero-knowledge proofs ensure Verifiability and Privacy of asset ownership
Cross-Chain Asset Allocation Mechanism: Supports cross-chain asset allocation, protecting cross-chain asset associations. From a distributed systems perspective, this achieves cross-chain privacy protection through unified abstraction layers
Application Scenarios:
Application scenarios for digital asset privacy include:
Asset Protection Scenario: Protects user asset holdings, prevents wealth exposure, meeting security and privacy requirements
Investment Privacy Scenario: Protects investment portfolios and investment strategies, prevents tracking and analysis, meeting investment privacy protection needs
Cross-Chain Privacy Scenario: Protects asset distribution across different chains, prevents cross-chain correlation analysis, meeting cross-chain privacy protection needs
2.1.3 On-Chain Wealth Management Privacy
Core Capabilities:
This protocol achieves the following core capabilities in on-chain wealth management privacy:
Wealth Distribution Privacy: Protects users' wealth distribution across different chains, preventing comprehensive wealth exposure. From a security perspective, this achieves privacy protection for wealth distribution through multi-chain deployment and privacy pool mechanisms, meeting Global Wealth Privacy requirements
Portfolio Privacy: Supports privacy-preserving asset allocation and portfolio management, protecting investment strategies. From a system design perspective, this achieves privacy protection for portfolios through multi-voucher technology and zero-knowledge proofs, meeting Investment Strategy Privacy requirements
Revenue Distribution Privacy: Enterprises, DAOs, and projects can privately distribute revenue to multiple recipients. From a cryptographic perspective, this achieves privacy protection for revenue distribution through one-to-many privacy allocation mechanisms and zero-knowledge proofs, meeting Distribution Strategy Privacy requirements
Fund Flow Privacy: Protects fund flow information, prevents on-chain analysis and tracking, protecting management strategies. From a system design perspective, this achieves privacy protection for fund flows through privacy pool mechanisms and zero-knowledge proofs, meeting Flow Privacy requirements
Technical Implementation:
From the perspectives of cryptography and system design, the technical implementation of on-chain wealth management privacy includes:
Multi-Voucher Technology: Through multi-voucher technology, supports complex wealth management scenarios. From a system design perspective, multi-voucher technology achieves privacy protection for complex wealth management scenarios through independent management and flexible combination
One-to-Many Privacy Allocation Mechanism: Through one-to-many privacy allocation, supports private asset allocation to multiple recipients. From a cryptographic perspective, this achieves privacy protection for batch allocation through cryptographic commitments and zero-knowledge proofs
Batch Withdrawal Optimization Mechanism: Through batch withdrawal optimization, supports flexible asset combination and withdrawal. From a system design perspective, batch withdrawals reduce Gas costs through aggregated proof mechanisms while improving privacy
Zero-Knowledge Proof Mechanism: Through zero-knowledge proofs, protects allocation strategies and amount information. From a cryptographic theory perspective, zero-knowledge proofs ensure privacy and verifiability of allocation strategies
Application Scenarios:
Application scenarios for on-chain wealth management privacy include:
Corporate Wealth Management Scenario: Enterprises privately manage funds, allocate assets to multiple recipients, protecting management strategies and allocation plans
Project Dividend Scenario: Projects distribute dividends to multiple investors, protecting allocation strategies and amounts, preventing investment strategy leakage
DAO Governance Scenario: DAOs distribute rewards to multiple contributors, protecting governance decision processes, meeting governance privacy needs
Charity Donation Scenario: Charitable organizations distribute funds to multiple recipients, protecting recipient privacy, meeting charity privacy protection needs
2.2 Core Innovation: Deposit ID Binding Mechanism
EnclaveProtocol successfully solves the "Impossible Triangle of Privacy Payment" problem by introducing the Deposit ID Binding Mechanism, achieving privacy protection in three dimensions. This section elaborates on the technical principles and innovations of this mechanism from the perspectives of theoretical analysis and system design.
Innovative Solution:
From the perspectives of cryptography and distributed systems, the Deposit ID binding mechanism achieves the following technical breakthroughs:
✅ Variable Denomination: Supports arbitrary amount deposits and arbitrary proportion allocation, achieving transaction process privacy. From a system design perspective, this achieves flexibility requirements through separation of fund anchors and allocation proofs
✅ Strong Double-Spending Prevention: Through Deposit ID + Proof Hash + Commitment triple verification mechanism, ensures digital asset privacy. From a security perspective, the triple verification mechanism achieves strong double-spending prevention through multi-layer protection, meeting cryptographic security requirements
✅ Full Decentralization: Pure on-chain implementation, no centralized dependencies, supports on-chain wealth management privacy. From a distributed systems perspective, this meets decentralization requirements and avoids single point of failure risks
Technical Breakthrough Points:
From the perspective of theoretical analysis, the technical breakthrough points of the Deposit ID binding mechanism include:
Traditional Approaches: Directly using commitment as nullifier, cannot effectively prevent double-spending attacks in variable denomination scenarios, cannot add complete privacy capabilities to blockchain. From a cryptographic theory perspective, traditional approaches have uniqueness constraint failure problems in variable denomination scenarios
EnclaveProtocol Approach: Using Deposit ID as Fund Anchor, commitment as Allocation Proof, achieves Separation of Uniqueness and Flexibility between fund uniqueness and allocation flexibility, adding complete privacy protection capabilities to blockchain. From a system design perspective, this separation design solves double-spending prevention problems in variable denomination scenarios by introducing fund anchors
2.3 System Architecture: Architecture Design for Adding Privacy Capabilities to Blockchain
EnclaveProtocol adopts a three-layer architecture design to add privacy capabilities to blockchain ecosystems:
┌─────────────────────────────────────────┐
│ Multi-Chain Ecosystem Layer │
│ TRON / BSC / ETH / Other Chains │
│ (Adding Privacy Protection Capabilities)│
└─────────────────┬───────────────────────┘
│
┌─────────────────▼───────────────────────┐
│ EnclaveProtocol Privacy Core Layer │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ Smart Contract│ │ ZK Proof Network │ │
│ │ System │ │ │ │
│ │ - Deposit Pool│ │ - Proof Gen │ │
│ │ - Withdraw │ │ - Proof Verify │ │
│ │ Pool │ │ - Privacy Protect│ │
│ │ - Verify │ │ - Transaction │ │
│ │ Contract │ │ Privacy │ │
│ │ - Multi-Voucher│ │ │ │
│ │ Management │ │ │ │
│ └──────────────┘ └──────────────────┘ │
│ ┌────────────────────────────────────┐ │
│ │ Three Privacy Capabilities │ │
│ │ - Transaction Process Privacy │ │
│ │ - Digital Asset Privacy │ │
│ │ - On-Chain Wealth Mgmt Privacy │ │
│ └────────────────────────────────────┘ │
└─────────────────┬───────────────────────┘
│
┌─────────────────▼───────────────────────┐
│ Application Access Layer │
│ Web DApp / Mobile / B2B API / B2C API │
│ (Using Privacy Protection Capabilities) │
└─────────────────────────────────────────┘2.4 Core Workflow: Achieving Three Privacy Dimensions
Phase 1: Deposit
Payer A calls: deposit() payable
Contract execution:
1. Generate incremental depositId = nextDepositId++
2. Record deposits[depositId] = {amount: msg.value, owner: msg.sender, used: false}
3. Return depositId to APhase 2: Allocation Plan Generation (Off-chain)
Multi-Voucher Splitting:
A determines allocation plan (supports multi-voucher technology):
allocations = [
{seq: 0, amount: 3 ETH}, // Voucher 1
{seq: 1, amount: 2 ETH}, // Voucher 2
{seq: 2, amount: 1 ETH} // Voucher 3
]
A generates:
- secret_A = random(32 bytes)
- commitment = F(allocations ∥ secret_A ∥ depositId)
Each voucher generates independent nullifier:
- nullifier_0 = keccak256(commitment || 0 || amount_0)
- nullifier_1 = keccak256(commitment || 1 || amount_1)
- nullifier_2 = keccak256(commitment || 2 || amount_2)Phase 3: Zero-Knowledge Proof Generation
A uses SP1 circuit to generate two types of proofs:
Type 1 - Submission Proof (proof_submit):
- Private inputs: allocations, secret_A
- Public inputs: commitment, depositId, totalAmount, submitter
- Constraints:
* Verify A owns the deposit corresponding to depositId
* Verify allocations total <= deposit amount
* Verify commitment calculation is correct
Type 2 - Individual Withdrawal Proof (proof_withdraw_X):
- Generate independent proof for each recipient X
- Prove allocation_X is indeed included in commitment
- Do not expose other recipients' informationPhase 4: On-Chain Submission
A calls: submitCommitment(commitment, depositId, totalAmount, proof_submit)
Contract verification:
1. SP1 proof validity
2. depositId is unused and owned by A
3. totalAmount <= deposits[depositId].amount
On success:
1. deposits[depositId].used = true
2. validCommitments[commitment] = true
3. Insert commitment into hash treePhase 5: Receipt Distribution (Multi-Voucher Support)
A distributes vouchers to each recipient:
{
allocation: {seq: seq_X, amount: amount_X},
commitment: commitment,
credential: credential_X, // Independent Merkle proof
proof_withdraw: proof_withdraw_X
}
Each voucher contains:
- seq: Voucher sequence number, used to generate unique nullifier
- amount: Voucher amount
- credential: Independent proof information for the voucher
- proof_withdraw: Withdrawal proof
Supported scenarios:
- Single recipient can receive multiple vouchers
- Multiple recipients can receive different vouchers from the same commitment
- Vouchers can be flexibly combined for usePhase 6: Recipient Verification and Withdrawal (Multi-Voucher Support)
After recipient X receives the voucher:
1. Verify commitment validity on-chain: validCommitments[commitment] == true
2. Verify voucher nullifier is unused: usedNullifiers[nullifier_X] == false
3. Generate final_proof, proving:
- allocation_X (seq, amount) belongs to commitment
- commitment belongs to hash tree
- nullifier_X calculation is correct
4. Call withdraw(X, amount_X, final_proof)
5. Contract verification:
- Verify nullifier uniqueness
- Verify proof validity
- Mark nullifier as used
6. Execute transfer
Multi-voucher withdrawal scenarios:
- Single voucher withdrawal: Directly call withdraw
- Multiple voucher batch withdrawal: Select multiple vouchers, generate aggregated proof, one-time withdrawal
- Cross-commitment withdrawal: Support combination withdrawal of vouchers from different commitments