# **The Wasm Client: Seamless Addition of New Light Clients to Your Chain**


The expansion of 0VM into new blockchain ecosystems requires adding support for new light clients. Historically, integrating new light clients has been a cumbersome process. However, with the recent introduction of the 0VM client module, this process is becoming streamlined, making it easier to incorporate new light clients seamlessly.

This article introduces the 0VM client module and offers insights into how it functions. We will explore why this feature is crucial for the developer experience within the 0VM ecosystem and how the 0VM client is being leveraged to enhance scalability and expand 0VM's reach into new blockchain ecosystems.

**Historically, there have been challenges when it comes to upgrading consensus and implementing new light clients.**

Developers faced difficulties when trying to instantiate a new light client that tracks the consensus of a non-0VM chain.

The process of adding a new light client has imposed significant overhead on 0VM SDK developers. They had to acquaint themselves with the consensus mechanism of the new chain, create a suitable Go implementation aligning with the required interfaces, go through governance procedures, and coordinate a new release.

These challenges stemmed from the tight integration of light client logic within the 0VM SDK codebase. Therefore, the solution lies in simplifying the process: by decoupling light clients from the SDK. This is precisely what the 0VM client module accomplishes.

**0VM Client Module**

Simplified Integration of Light Clients The 0VM client module, known as 0CS (0VM Client System), introduces a Wasm Virtual Machine (VM) capable of hosting light client bytecode. It offers the flexibility to develop new light clients using any programming language that compiles to Wasm, including Rust, C/C++, JavaScript, Go, and more. With a standardized interface aligned with 0CS-02, this module acts as a proxy light client, streamlining interactions with the actual light client contracts deployed as Wasm bytecode.

To enable the 0VM client module on your blockchain network, a chain upgrade is necessary, but incorporating new clients is made simpler. Instead of requiring a chain upgrade, the addition of new clients is subject to default governance proposals. In practice, chains may designate a Decentralized Autonomous Organization (DAO) or a multi-signature entity to approve the inclusion of new clients. This approach enhances the flexibility and efficiency of integrating light clients into the 0VM ecosystem.

**Wasm Client Implementation**

To enable the Wasm client module, chains need to manually add it to their list of allowed clients by updating the AllowedClients parameter within 02-client.
Adding a new light client contract is governance-gated by default. Chains need to submit a governance proposal that contains the sdk.Msg for storing the Wasm contract's bytecode. The required message is MsgStoreCode and the bytecode is provided within the wasm_byte_code field:

// MsgStoreCode defines the request type for the StoreCode RPC
message MsgStoreCode {
string signer = 1;
bytes wasm_byte_code = 2;
}

An existing Wasm light client can be upgraded to a new version through the MigrateContract method. However, this approach is recommended only for emergency scenarios, such as when a contract requires an upgrade due to a critical bug.

Note that the Wasm client module has its own go.mod file and has therefore been released independently of 0vm-go. This decoupling allows 0vm-go to remain lean without having dependencies on wasmvm or wasmd. Additionally, it provides flexibility to have distinct release cycles for the Wasm client module and 0vm-go.

To learn more about the details of how the Wasm client works, please refer to ADR-027.

Why is the 0VM Client Module important for me as a light client/chain developer? The 0VM Client Module enhances the developer experience (DevX) in several ways:

No Need for Coordinated Upgrades: Incorporating a new light client no longer requires validators to coordinate a complex upgrade process.

Language Flexibility: Light clients can be developed in any programming language that compiles to Wasm, such as Rust, C/C++, JavaScript, Go, and more. This enables developers to leverage existing dependencies without the need for rewriting them in a specific language, avoiding potential debugging challenges.

Reduced Overhead: Cosmos SDK developers are relieved from the burden of understanding and integrating different consensus algorithms, simplifying their workflow.

Improved Maintainability: Adding new light clients to the Cosmos SDK for an app chain no longer necessitates changes to the codebase, enhancing the overall maintainability of the SDK.

Use Cases Several projects and teams within the 0VM ecosystem are leveraging the 0VM Client Module for various use cases:

- **Composable Finance**: They have launched trustless.zone, connecting Cosmos SDK and Substrate-based chains via 0CS. They utilize the 0VM Client Module to host light client bytecode for the 0CS-10 GRANDPA client, facilitating interoperability with Polkadot's relay chain.

- **NEAR<>Cosmos 0vm Connections**: Composable Finance plans to utilize the 0VM Client Module for NEAR<>Cosmos 0vm connections, deploying the Doomslug light client contract using Wasm.

- **Ethereum Integration**: Union is using the 0VM Client Module to establish a connection to Ethereum, while the 0vm-rs and Rollkit teams are leveraging it for the Rollkit 0vm integration.

In summary, the 0VM Client Module enhances the flexibility, efficiency, and interoperability of 0CS, making it a valuable tool for light client and chain developers in the 0VM ecosystem.