The zkCompression Layer is the final stage in the Cubane Cubic Consensus Mechanism (CCCM), tasked with compressing validated transaction data into compact, cryptographically secure proofs for on-chain storage. This layer enhances the CCCM architecture by reducing the on-chain footprint while maintaining a robust off-chain record for auditing purposes.

The zkCompression layer is responsible for Data compression, finality of transactions and on-chain integration.

• It reduces the size of validated transaction data to ensure minimal storage and transmission costs on the blockchain.
• Provide a final, immutable cryptographic proof that represents the validated transactions.
• Generate hashes or concise representations for on-chain storage while preserving off-chain data for verification and auditing.

Understanding the flow within zkCompression Layer:

The zkCompression Layer collects zk-proofs and associated transaction metadata from the Validation Layer. Each batch of zk-proofs includes:

• Individual zk-proof hashes.
• Metadata such as timestamps and validation results.

Compression Algorithm

The core function of this layer is the compression algorithm, which operates as follows:

1. Merkle Tree Construction:
   • A Merkle Tree is built using the individual zk-proof hashes.
   • The root hash of the tree serves as a concise representation of the entire batch.
2. Recursive zk-Proofs:
   • Recursive zk-proofs are generated to represent the batch as a single zk-proof.
   • This technique drastically reduces the size of the proof while maintaining verifiability.
3. Hash Generation:
   • A cryptographic hash is created for the batch, embedding:
     • The root hash of the Merkle Tree.
     • Timestamps and other relevant metadata.
4. Off-Chain Metadata Creation:
   • Off-chain data includes the full Merkle Tree and individual zk-proofs.
   • This ensures that the data can be audited and verified without relying solely on the blockchain.

On-Chain Storage

• The cryptographic hash generated in the compression process is stored on the blockchain as part of the new block.
• This hash serves as the immutable proof of the batch’s validation and finality.

Reward Distribution

• Once the batch is successfully compressed and stored:
  • Rewards are distributed to the Leader Node (LDN) and Member Nodes (MNs) of the cube responsible for validation.