ACE Runtime - A ZKP-Native Blockchain Runtime with Sub-Second Cryptographic Finality

This paper introduces ACE Runtime, a ZKP-native blockchain architecture that achieves sub-second cryptographic finality by separating identity authorization from execution to replace per-transaction signature verification with lightweight attestations and a single aggregated zero-knowledge proof per block.

The Gist

Imagine a busy airport. In most current high-speed blockchains (like Solana), every single passenger (transaction) arriving at the gate must stop, show their passport, have their photo taken, and get a stamp from a security guard before they can even walk toward the plane.

Even if you have 100,000 passengers, the security line is the bottleneck. The more people there are, the longer the line gets. To make this faster, the airport has to hire expensive, super-fast security guards (GPUs) for every checkpoint, which costs a fortune and limits who can run the airport.

ACE Runtime is a new airport design that changes the rules of the game. It separates "Who you are" from "What you are doing."

Here is how it works, using simple analogies:

1. The "Magic Wristband" vs. The Passport Check

The Old Way (Solana): Every time you buy a ticket or board a plane, you must present your full passport and have a guard verify your signature. This takes time and requires expensive equipment.

The ACE Way:

• Step 1 (The Wristband): When you arrive, you get a special, lightweight HMAC wristband. This isn't a full signature; it's a quick, cheap check that says, "This person is authorized to be here." It takes a microsecond to check—like a quick glance at a color-coded band.
• Step 2 (The Boarding): Because the wristband is so fast to check, the airport can let thousands of people through the gate almost instantly. The plane (the block) takes off in 400 milliseconds.
• Step 3 (The Audit): After the plane has taken off, a specialized team in a back office (the GPU) looks at the list of everyone who boarded. They use a powerful computer to generate one single magic receipt (a Zero-Knowledge Proof) that proves every single person on that plane had a valid wristband and wasn't a fraudster.

The Result: Instead of checking 100,000 passports one by one, the airport only needs to verify one magic receipt at the end.

2. The "Two-Tier" Arrival

ACE introduces a clever concept called Two-Tier Finality:

• Soft Finality (The "It's Taking Off" moment): Once the plane leaves the gate (400ms), everyone agrees the flight is happening. It's highly unlikely to be cancelled, but technically, it hasn't been fully audited yet.
• Hard Finality (The "Flight Log" moment): About 200ms later (600ms total), the back office finishes the audit and posts the "Magic Receipt." Now, it is mathematically impossible to change the passenger list. The flight is 100% confirmed.

This is 20 times faster than Solana's current "hard" confirmation time and doesn't require expensive hardware for the people just watching the flight.

3. Who Needs the Expensive Equipment?

In the old system, every security guard (validator) needed a super-computer (GPU) to check passports. This made it expensive to run a node, leading to fewer, richer people running the network.

In the ACE system:

• The "Builder" (The Pilot): Needs the super-computer to generate the Magic Receipt.
• The "Validators" (The Air Traffic Controllers): Only need a standard laptop. They just check the wristbands (fast) and verify the single Magic Receipt (very fast).

This drops the cost of running a validator by about 30–50%, allowing more people to join and making the network more decentralized.

4. Why This Matters for the Future (Quantum Computers)

Imagine a future where hackers have "Quantum Computers" that can break current digital locks (like the ones used in passports today).

• Old Systems: If a hacker breaks the lock, they can forge a passport. The whole system collapses.
• ACE System: The "wristband" is based on math that is very hard to break even with quantum computers. Even if the "Magic Receipt" system needs an upgrade later, the core identity system (the wristband) is already safe. It's like having a vault that is already reinforced against a future super-weapon.

Summary: The Big Wins

• Speed: You get a "hard" confirmation in 0.6 seconds (like a blink of an eye).
• Cost: You don't need a $7,500 computer to help run the network; a standard server is enough.
• Capacity: Because the "security check" is so fast, the airport can handle 32,000 passengers per second (transactions) without getting clogged.
• Efficiency: The data sent over the internet is 5 times smaller because we aren't sending 100,000 passports; we're just sending one receipt.

In a nutshell: ACE Runtime stops checking every single person's ID at the gate. Instead, it gives them a quick pass, lets them fly, and then does a super-fast, high-tech audit of the whole group afterward. This makes the whole system faster, cheaper, and ready for the future.

Technical Summary

Here is a detailed technical summary of the paper "ACE Runtime — A ZKP-Native Blockchain Runtime with Sub-Second Cryptographic Finality" by Jian Sheng Wang.

1. Problem Statement

Current high-performance Layer-1 blockchains (e.g., Solana) face a fundamental throughput bottleneck caused by per-transaction cryptographic signature verification.

• O(N) Verification Cost: Every transaction requires a signature verification (e.g., Ed25519) on the critical execution path. As block size ($N$) increases, verification time scales linearly, consuming a significant portion of the block interval.
• Hardware Centralization: To maintain high throughput, validators must use GPUs for batched signature verification. This raises the entry barrier (approx. $7,500 hardware cost) and centralizes the network.
• Post-Quantum Vulnerability: Transitioning to post-quantum signature schemes (e.g., ML-DSA-44) would increase transaction data size by ~38×, rendering current architectures infeasible due to bloated block sizes and verification costs.
• Latency: Hard cryptographic finality in existing high-throughput chains often requires multiple confirmations (e.g., Solana's ~12s), limiting real-time application viability.

2. Methodology: The ACE Runtime Architecture

The paper proposes ACE Runtime, a blockchain execution layer built on the ACE-GF (Atomic Cryptographic Entity Generative Framework) primitive, which separates Identity Binding from Per-Transaction Authorization.

Core Innovation: Attest–Execute–Prove Pipeline

The system decouples the critical path from heavy cryptographic proving using a three-phase pipeline:

1. Attest (Phase 1a - Critical Path):
   • Instead of full signatures, users submit lightweight HMAC-based attestations derived from a Root Entropy Value (REV).
   • Validators perform a lightweight check (~1–5 µs per transaction) verifying the HMAC credential against the user's on-chain identity commitment (id_com).
   • This replaces the O(N) signature verification with O(1) format/binding checks.
2. Execute (Phase 1b - Critical Path):
   • Transactions are executed in parallel (using a Sealevel-enhanced scheduler) based on the lightweight attestations.
   • The block is published with soft finality (via BFT voting) after ~400 ms.
3. Prove (Phase 2 - Off-Critical Path):
   • A dedicated Builder (running on GPU) generates a Zero-Knowledge Proof (ZK) for the entire block asynchronously.
   • The proof (Groth16 on BN254) cryptographically binds the attestations to the user's id_com and verifies the execution state.
   • This proof is published as a Finality Certificate in the next slot, achieving hard finality (~600 ms total).

Key Cryptographic Primitives

• Identity-Authorization Separation: Users hold a single high-entropy secret (REV). Keys for different chains/contexts are derived via HKDF. The on-chain identity is a hash commitment (id_com), hiding public keys and preventing "harvest now, decrypt later" attacks.
• Attestation: A tuple (obj_hash, id_com, domain, credential) where the credential is HMAC-SHA256(k_attest, obj_hash || domain).
• Proof Aggregation: Individual transaction proofs are recursively aggregated into a single Groth16 proof per block, ensuring verification cost is constant regardless of block size.

3. Key Contributions

1. O(1) Block Verification: By shifting authorization verification to a single per-block ZK proof, the system achieves constant verification time (~0.5 ms) regardless of the number of transactions.
2. Sub-Second Hard Finality: The architecture targets ~600 ms for cryptographic hard finality (vs. 12s for Solana), combining BFT soft finality (400 ms) with asynchronous ZK hard finality.
3. GPU-Free Non-Builder Validators: Non-builder validators only need to verify the single Groth16 proof and perform lightweight attestation checks, eliminating the need for expensive GPUs.
4. Post-Quantum Readiness: The identity layer is hash-based (Poseidon/HMAC), offering inherent quantum resistance. The ZK layer can be upgraded to post-quantum SNARKs (e.g., STARKs) without changing the identity or attestation layers.
5. Bandwidth Efficiency: Removing per-transaction signatures and public keys reduces block data size by ~5× (e.g., from ~1.2KB to ~244B per transaction), significantly improving propagation speed.

4. Results and Quantitative Evaluation

Based on analytical modeling and a Rust reference implementation (Apple M3 Pro):

• Throughput:
  • Conservative estimate: ~16,000 TPS.
  • Optimized estimate: ~32,000 TPS.
  • Bandwidth-limited ceiling: ~512,000 TPS (vs. ~101,000 TPS for Solana).
• Verification Speedup:
  • 4,000× reduction in per-block verification cost for a 1M transaction block compared to Solana (GPU-batched).
  • 20× faster hard finality latency compared to Solana.
• Latency Breakdown:
  • AttestCheck: ~1–5 µs/tx (CPU).
  • Execution: ~10–50 µs/tx (CPU).
  • Proof Generation: ~240 ms (GPU, parallel).
  • Total Hard Finality: ~600 ms.
• Hardware Costs:
  • Non-builder validator cost reduced by 30–50% (no GPU required).
  • Builder cost remains high (GPU required) but is a specialized role.

5. Significance and Implications

• Architectural Paradigm Shift: ACE Runtime demonstrates that separating identity binding from transaction authorization allows for O(1) verification at the Layer-1 level, a feat previously only attempted in Layer-2 rollups.
• Decentralization: By removing the universal GPU requirement, the economic barrier to running a validator node is significantly lowered, potentially increasing network decentralization.
• Scalability: The design solves the "signature verification bottleneck" that limits current high-throughput chains, enabling massive block sizes without linear latency penalties.
• Future-Proofing: The system is designed to be agnostic to the underlying signature scheme, allowing seamless migration to post-quantum cryptography without architectural overhaul.

Conclusion

ACE Runtime presents a viable path to high-throughput, low-latency blockchain execution by leveraging Identity-Authorization Separation and Zero-Knowledge Proofs. It effectively trades the linear cost of signature verification for a constant-cost ZK proof, achieving sub-second finality and reducing hardware requirements, thereby addressing the primary bottlenecks of current high-performance blockchains.