Celestia Improvement Proposals (CIPs)

Abstract

This proposal introduces a ZK-based Hyperlane Interchain Security Module (x/zkism) that enables trust-minimized cross-chain message verification using Groth16 zero-knowledge proofs. The module allows external networks to securely transfer assets through Celestia without relying on trusted operators or multisigs.

Motivation

Hyperlane’s most widely deployed Interchain Security Module is the Multisig ISM, which relies on a trusted set of validators to attest to cross-chain messages. A ZK ISM provides networks the flexibility to configure their own message passing security via a generalized circuit - whether that’s a consensus proof, a TEE-based proof, an optimistic ZK proof, or a full ZK execution proof.

Prover programs can be written using SP1. Support for additional ZKVMs like Risc0 could be added in future upgrades. This provides networks an option to upgrade to a secure, proof-based path to transfer assets via Celestia.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Module Overview

The x/zkism module implements a Hyperlane Interchain Security Module that maintains opaque state along with SP1 Groth16 verifier configuration. The first 32 bytes of state serve as a trusted state root used for membership verification.

State

The module maintains two collections:

1. ISMs: Per-ISM records containing ownership, current state, and verifier configurations
2. Messages: Authorized message IDs awaiting consumption by the Hyperlane router

Message Types

MsgCreateInterchainSecurityModule

Creates a new ZK ISM with initial trusted state and verifier keys.

Fields:

• creator: Transaction signer
• state: Initial trusted state (minimum 32 bytes). The first 32 bytes serve as the trusted state root for membership verification.
• merkle_tree_address: Address of the merkle tree being tracked on the external chain (32 bytes)
• groth16_vkey: On-chain Groth16 verifier key for proof verification
• state_transition_vkey: Program-specific verifier key commitment for state transitions, used as public input during verification (32 bytes)
• state_membership_vkey: Program-specific verifier key commitment for state membership, used as public input during verification (32 bytes)

MsgUpdateInterchainSecurityModule

Updates ISM state through a verified state transition proof.

Fields:

• id: ISM identifier
• proof: Groth16 proof bytes
• public_values: Public values for proof verification
• signer: Transaction signer

MsgSubmitMessages

Authorizes Hyperlane messages through a verified state membership proof. The message IDs to authorize are embedded within public_values as part of StateMembershipValues, cryptographically binding them to the proof.

Fields:

• id: ISM identifier
• proof: Groth16 proof bytes
• public_values: Public values containing state root and message IDs (see StateMembershipValues)
• signer: Transaction signer

Proof Types

The module processes two proof categories:

1. StateTransitionValues: Contains the previous state, new state, and any additional data needed to verify the state transition. The proof demonstrates that the new state is a valid successor to the previous state according to the network’s rules.
2. StateMembershipValues: Contains the state root, merkle tree contract address, and message IDs. The circuit commits to the merkle tree address in its outputs, which is asserted against the ISM’s configured merkle_tree_address. The proof demonstrates that the specified messages are included in the state represented by the root.

Groth16 Verification

The SP1 verifier operates on 260-byte proofs: 4-byte SP1-specific prefix + 256-byte Groth16 proof payload. The prefix MUST validate against the verifying key hash. Public witnesses combine the program verification key commitment and hashed public values as field elements in the BN254 curve.

Hyperlane Integration

The module integrates with Hyperlane’s router through the Verify method, which checks authorized message IDs and consumes them upon authorization. This prevents replay attacks by ensuring each message can only be processed once.

Queries

• Ism: Get a single ISM by ID
• Isms: List all ISMs with pagination
• Messages: Get authorized messages for an ISM

Rationale

Why Hyperlane ISM Pattern

Hyperlane’s ISM architecture provides a modular security framework where different verification methods can be plugged in. The ZK ISM extends this by adding cryptographic proof verification as an alternative or supplement to multisig-based security.

Why Groth16

Groth16 provides constant-size proofs (256 bytes) with fast verification, suitable for on-chain verification where computational costs matter. Popular ZKVMs like SP1 and Risc0 support Groth16 proof generation, enabling developers to write prover programs in Rust.

Why Generic Verifier Design

The module stores verifier configurations per-ISM rather than hardcoding them. This allows different networks to use different prover programs while sharing the same verification infrastructure on Celestia.

Tradeoffs

ZK ISM suits high-value transfers or networks prioritizing security over speed/cost.

Backwards Compatibility

This is a consensus-breaking change that requires a network upgrade. However, it is purely additive and does not affect existing functionality or other modules.

Security Considerations

1. Honest-but-untrusted prover assumption: The design assumes provers generate valid proofs but may attempt to submit proofs for unauthorized state transitions. The cryptographic verification ensures only valid proofs are accepted.

2. One-time message consumption: Authorized messages are removed from storage after verification, preventing replay attacks where the same proof could authorize the same message multiple times.

3. Proof prefix validation: The 4-byte proof prefix MUST match the verifying key hash to prevent proofs generated for one verifier from being used with another.

4. Cryptographic implementation dependency: Security relies on correct implementation of Groth16 verification and the BN254 curve operations. The module uses audited cryptographic libraries.

5. State root integrity: The first 32 bytes of ISM state serve as the trusted root for membership proofs. State transitions MUST be verified before updating this root.

6. Blast radius containment: If a ZK ISM is compromised (due to verifier bugs or cryptographic vulnerabilities), only Hyperlane routes using that specific ISM are affected. Other ISMs and IBC routes remain secure. This modular isolation limits the impact of any single ISM failure.

Reference Implementation

The reference implementation is available at: https://github.com/celestiaorg/celestia-app/pull/6438

Copyright

Copyright and related rights waived via CC0.