FHE Engine Upgrade v0.5.0 — April 27, 13:00-16:00 UTC. Read migration guide →
2. Security & Integrity2.2 O(1) On-chain Storage

2.2. O(1) On-chain Storage

Traditional Fully Homomorphic Encryption (FHE) implementations on blockchain networks persist full ciphertext objects or intermediate decryption states directly in contract Storage. This approach causes exponential state bloat, unpredictable gas consumption, and severe scalability bottlenecks as bid volume increases.

Fhenix-FairMarket v2.0 enforces a strict O(1) storage model by persisting only a cryptographic bytes32 hash of each submitted ciphertext. All heavy FHE objects remain ephemeral, existing solely in memory during the off-chain coprocessing phase. This architectural constraint guarantees linear state growth, deterministic transaction costs, and complete immunity to storage exhaustion attacks.

Core Storage Principles

PrincipleTechnical Implementation
Hash-Only PersistenceOnly keccak256(abi.encode(encryptedBid)) is pushed to the ciphertextHashes mapping. Full FHE payloads are never written to state.
State DecouplingThe L2 chain acts purely as an immutable event ledger and hash registry. Cryptographic resolution occurs entirely off-chain via CoFHE dispatch.
Gas PredictabilityEach placeBid() transaction consumes a flat ~15k–25k gas, completely independent of auction size, bid count, or FHE parameter complexity.
Zero Plaintext RetentionNo bid values, intermediate states, or decryption results are persisted in Storage or emitted in Events. Enforced by CI lint rules.
Deterministic ReconciliationHash arrays enable off-chain verifiers to cryptographically prove bid inclusion without requiring on-chain storage of the original ciphertexts.

️ Technical Implementation

1. Storage Layout & Hash Persistence

The protocol replaces bulky FHE arrays with a lightweight bytes32[] structure, ensuring constant-space complexity per participant.

// packages/contracts/core/FhenixFairMarket.sol
struct Auction {
 // ... other fields
 mapping(uint256 => bytes32[]) public ciphertextHashes; // O(1) per bid
 mapping(address => uint256) public escrowBalances;
 mapping(address => bool) public hasWithdrawn;
}
 
function placeBid(uint256 auctionId, InEuint32 calldata encryptedBid) external {
 require(state == AuctionState.ACTIVE, "Auction not active");
 require(block.timestamp < auctions[auctionId].endTime, "Auction expired");
 
 // Encrypted solvency check executes off-storage
 FHE.lte(encryptedBid, FHE.asEuint32(escrowBalances[msg.sender]));
 
 // O(1) Storage: Only cryptographic hash is persisted
 bytes32 bidHash = keccak256(abi.encode(encryptedBid));
 ciphertextHashes[auctionId].push(bidHash);
 
 emit BidPlaced(auctionId, msg.sender, bidHash);
}

2. State Growth & Memory Footprint

Data TypeTraditional FHE StorageFhenix-FairMarket v2.0
Per Bid Size~1.2–2.4 KB (Full ciphertext + metadata)32 bytes (bytes32 hash)
100 Bids~120–240 KB3.2 KB
1,000 Bids~1.2–2.4 MB32 KB
Gas ScalingO(n) (Exponential growth with bids)O(1) (Constant per transaction)

This reduction eliminates the primary bottleneck preventing large-scale sealed-bid auctions on L2 networks, enabling thousands of participants without triggering state rent penalties or block gas limits.

️ Security Guarantees & Threat Mitigations

Threat VectorAttack MechanismO(1) Storage Mitigation
State Bloat DoSMalicious actors flood contracts with heavy FHE payloads to exhaust storage limitsOnly bytes32 hashes stored; storage growth is mathematically bounded
Gas ExhaustionHigh bid volume pushes settlement transactions beyond block gas limitsplaceBid() consumes flat ~15k–25k gas; settlement runs off-chain
Plaintext Leakage via StorageDebugging or state inspection tools exposing historical bid valuesZero bid values or FHE objects persist; only irreversible keccak256 hashes remain
Storage Collision AttacksExploiting predictable state layouts to overwrite or corrupt bid registriesStrict mapping(uint256 => bytes32[]) isolation per auctionId; EIP-1967 proxy guards admin slots
Event Log MiningScraping BidPlaced events to reconstruct bidding patterns or valuesEvents emit only auctionId, bidder address, and bytes32 hash; zero plaintext metadata

Architectural Impact

  • Linear Scalability: Auction capacity scales horizontally without vertical storage constraints. The protocol supports enterprise-grade participant volumes while maintaining L2 efficiency.
  • Deterministic Finality Costs: Off-chain CoFHE processing decouples cryptographic computation from on-chain gas markets. Settlement latency becomes independent of network congestion.
  • Auditability & Transparency: Hash-based persistence enables permissionless verification. External auditors can cross-reference off-chain FHEOS outputs against on-chain ciphertextHashes without accessing raw bid data.
  • Future-Proof State Management: As FHE cryptographic parameters evolve (e.g., key rotation, cipher suite upgrades), the on-chain state remains unaffected. Only the hash registry persists, ensuring backward compatibility across protocol versions.

Audit Gate Compliance (P0)

The protocol enforces strict cryptographic storage verification gates. Progression to subsequent phases is blocked until all P0 storage items pass:

  • [] Zero Full Ciphertext Persistence: CI lint rules fail the build if any euint32, eaddress, or raw FHE struct is pushed to Storage or emitted in Events.
  • [] Hash-Only Enforcement: ciphertextHashes mapping exclusively stores keccak256(abi.encode(...)) outputs; size capped at 32 bytes per entry.
  • [] Gas Predictability Validation: hardhat-gas-reporter confirms placeBid() consumes < 25k gas across varying bid volumes (1 → 1,000 participants).
  • [] Storage Collision Protection: EIP-1967 proxy slots are explicitly reserved; business logic mappings start at safe offsets to prevent upgrade layout collisions.
  • [] State Reconciliation Test: CoFHEFlow.test.ts verifies that off-chain FHEOS results cryptographically match on-chain stored hashes before accepting submitResolution().

Next Steps

2.1 Fully Homomorphic Encryption2.3 Pull over Push Refund