Transaction Verification on BNB

Protocol Overview

The verification layer serves as the immutable bridge between off-chain Zero-Knowledge (ZK) computations and the on-chain state of the BNB Smart Chain (BSC). It acts as a deterministic gatekeeper: no state transition (deposit or withdrawal) can occur without a valid cryptographic proof that satisfies the protocol's algebraic constraints.

We utilize the Groth16 proof system, chosen for its constant proof size (only 3 group elements) and rapid verification time, which is critical for the gas-constrained environment of the EVM.

Cryptographic Primitives

The verifier contract does not simply check a signature; it validates a complex polynomial relationship using Elliptic Curve Pairings. The verification process relies on the bn256 curve (Alt-Bn128), which is natively supported by BNB Chain precompiles.

The Verification Equation

To accept a state transition, the smart contract must validate the following bilinear pairing equation:

$$e(A, B) = e(\alpha, \beta) \cdot e(vk_x, \gamma) \cdot e(C, \delta)$$

Where:

• : The bilinear pairing function.

• : The proof elements submitted by the user (derived from the witness).

• : The Verifying Key (artifacts from the Trusted Setup).

• : The computed linear combination of public inputs.

Public Input Integration ()

The term is the most critical component for transaction integrity. It binds the generic ZK proof to the specific transaction details. The smart contract constructs by aggregating the Commitment Hash and Token Address into the verification key.

This ensures that a valid proof generated for a 10 BNB deposit cannot be maliciously replayed to withdraw funds or applied to a different token contract.

The Verification Lifecycle

The on-chain verification process follows a strict four-stage lifecycle to ensure atomic security.

1. Input Parsing & Sanity Checks

Before any heavy cryptography occurs, the contract validates the "Public Signals."

• Commitment Verification: Ensures the 32-byte commitment hash provided in the proof matches the hash intended for the Merkle Tree.

• Scope Validation: Verifies that the proof is explicitly bound to the current contract address, preventing cross-protocol replay attacks.

2. The Pairing Check (Precompile 0x08)

The EVM cannot efficiently perform elliptic curve pairings in standard Solidity. The protocol delegates this heavy lifting to the precompiled contract at address 0x08 (bn256Pairing).

• The contract serializes the points ( and ) into a specific byte buffer.

• A low-level staticcall is made to the precompile.

• The precompile returns a boolean indicating if the equation balances.

3. Nullifier Enforcement

To prevent double-spending (a critical risk in privacy protocols), the verifier checks the Nullifier Hash.

• Every private note has a unique, deterministic nullifier derived from the private key.

• When a proof is verified, the nullifier is permanently marked as "spent" in the contract storage.

• If a user attempts to reuse a valid proof, the verifier detects the used nullifier and reverts the transaction immediately.

4. Atomic State Transition

The verification is atomic. If the pairing check returns true and the nullifier is unused:

1. The new Commitment is appended to the on-chain Merkle Tree.

2. The Token Pool balance is updated.

3. The transaction is finalized in the same block.

If any step fails, the entire operation reverts, consuming only the gas used up to that point.

Gas & Performance Optimization

Verification on the BNB Chain is optimized for cost-efficiency. By offloading the complex math to the 0x08 precompile, we minimize the execution overhead.

• Constant Cost: Regardless of the transaction amount or the complexity of the off-chain computation, the on-chain verification cost remains constant.

• Storage vs. Compute: The majority of the gas (~67%) is consumed by the pairing check (Compute), while the remainder is used for state storage (SSTORE).

---