Local Prover vs. Remote Prover Service

Stateless verification requires the generation and verification of cryptographic proofs for execution and consensus data. Colibri.stateless supports two alternative models for proof generation:

• a Local Prover embedded in the client and

• a Remote Prover Service.

Both variants are fully trustless. In all cases, the client accepts only cryptographically verifiable proofs. A prover cannot convince the client of incorrect data; either a valid proof exists or verification fails.

Local Prover

With the Local Prover, all proof generation is performed directly inside the colibri.stateless client. The client operates autonomously and generates all required execution and consensus proofs itself.

Execution proofs are obtained using standard Ethereum mechanisms such as eth_getProof and are verified locally. Consensus proofs are constructed starting from a trusted checkpoint by verifying successive validator and sync committee transitions of the Beacon Chain.

A colibri.stateless client using the Local Prover can independently read blockchain data and generate the necessary proofs without relying on external services.

Advantages

• No dependency on external infrastructure

• Maximum autonomy and self-sovereignty

• Suitable as a fallback mechanism

Limitations

• Lower performance due to the cost of collecting and assembling proof inputs

• Historical proofs cannot be generated if the target state predates the chosen checkpoint

• High computational overhead when many validator transitions must be verified

• zk-proof generation is impractical and not intended for this mode (as it doesn't make sense to create such a proof locally.

Remote Prover Service

With the Remote Prover Service, proof generation is delegated to an external system. The client receives completed proofs and verifies them locally.

This model enables significantly improved performance through:

• Caching of previously generated proofs and data

• Precompiled or aggregated proofs

• Efficient consensus verification using zk-proofs

• Batch generation of proofs for multiple queries or state elements

The Remote Prover Service does not introduce additional trust assumptions. It is not a trusted third party; proofs are either cryptographically valid or rejected by the client.

Trust Model and Security Assumptions

Both the Local Prover and the Remote Prover Service operate under the same trustless security model. The location of proof generation does not affect correctness guarantees. Security derives exclusively from cryptographic verification performed by the client.

Performance and Resource Considerations

Using a Local Prover shifts all proof generation costs to the client, increasing CPU usage, memory consumption, and network bandwidth requirements. In particular, assembling proof inputs and verifying long sequences of validator transitions can be resource-intensive.

The Remote Prover Service significantly reduces client-side requirements. The client verifies compact proofs, while computationally expensive tasks are executed externally. This model is well suited for mobile applications, embedded systems, and environments with strict latency constraints.

Offline Proving

Colibri.stateless enables verification even when the client has no direct internet connectivity. Required data and corresponding proofs can be transferred to the client via alternative channels, after which verification is performed locally without restrictions.

This capability extends blockchain security to environments that are otherwise excluded. Full nodes and classical light clients require continuous network access. RPC-based architectures depend on online connectivity as well and use unverifiable responses.

Colibri.stateless uniquely decouples data transport from verification and enables trustless blockchain interaction on fully offline systems, including air-gapped cold wallets and smart IoT devices using short-range communication such as Bluetooth.