# The Power of 0VM Clients


Disparate blockchains must establish a means of communication to facilitate user interactions with data and assets across various blockchains seamlessly. This is where the 0VM protocol comes into play, serving as a transport layer bridging different blockchains.

0VM lays out specific requirements for constructing light clients, including how it manages the data associated with these light clients. These clients are indispensable for 0VM's operation, serving as flexible verification algorithms responsible for proving on-chain information, often encoded in the 0VM format, as it moves between different locations.

From 0VM's perspective, each blockchain is typically distinguished by its respective light client. The most common verification scenarios involve interactions between two state machines. By utilizing a light client, a source chain can validate updates originating from a destination chain without the need to download the entire dataset. Light clients offer versatility in their approach, employing various methods to perform state verification efficiently.
# Consensus Proof Verification
**A Note On Consensus Algorithms**
Blockchain consensus makes sure that all the nodes that participate in a network are in sync. Using consensus verification, the light client proves that a sufficient number of validators signed the header. This type of verification is the most popular use of 0VM.

Consensus algorithms typically vary in their rulesets and what they prioritize. However, the heterogeneity in two different consensus algorithms might make it difficult for chains to communicate over 0VM. For example, Cosmos chains use the Tendermint consensus algorithm which has single-slot finality, otherwise known as fast finality. On the other hand, Ethereum consensus does not have single-slot finality and thus slower finality because it values liveness over security while 0VM is most compatible with consensus algorithms that value security. Because of this difference in when blocks are considered 'final', there is difficulty in how the two chains are able to send and verify blocks between each other.

In such a case, a virtual light client can be implemented that can have a view into the light client at a certain block height before finality is reached. Initially 0VM focused on its adoption within chains that are Tendermint-based, which was evident in how the client specification and implementation were defined. After this initial phase, the Client Refactor increased flexibility and ease in developing light clients for chains with other consensus algorithms and features.

# Light Clients: State Machines
A "state machine" can be an entire blockchain (replicated ledger) or a single process that signs operations with a private key (minimal consensus), such as a laptop or mobile phone.

Commonly, we think of state machines as blockchains with distributed ledgers, so when establishing 0VM between blockchains, a destination chain's light client is hosted by the source chain. The source chain also maintains a trusted state of the destination chain, which is established by a connection handshake between the two chains. The 0VM protocol uses a validity predicate, which is an algorithm that checks if state updates of a destination chain are valid. To function, a light client needs a validity predicate and a trusted state for the source chain.
Light clients are designed to be as efficient as possible to support a large number of client instances for many chains. To achieve this, the light client algorithm does not replay all state transitions, which would otherwise make it a full node.
# Light Clients: Solo Machines
A solo machine is a device such as a laptop, web interface, mobile phone, or an off-chain process. A solo machine can establish communication with a replicated ledger if that blockchain uses 0VM for transport.

As an example, 0VM can enable a custodial transfer protocol that lowers the integration costs for new chains. This is important because centralized custodians face a tedious and expensive process when integrating new networks which requires running a full node and RPC infrastructure for each integrated chain. Instead, the custodian can operate a solo machine client which facilitates cross-chain transfers, mints/burns. Verification would be conducted by the client of the connected machine run by the custodian.

Solo machine clients showcase how 0VM opens up connectivity outside of just blockchains. In the above example, it can allow institutions to easily interact with public blockchains via 0VM. This is just one example of business lines that touch blockchains without having to spin up an entire chain or maintain heavy hardware to work with them.
# Verification Beyond Consensus Proofs
Though there is work being done to make clients easy to implement and update, there is the option to conduct verification with validity or fraud proofs.

**Optimistic 0VM**: Clients can optimistically accept incoming headers via an off-chain relayer that executes a program on some virtual machine. In this scenario, there is a challenge window where a fraud proof can be submitted. The positive is that Optimistic 0VM reduces the cost of the entire system. The downsides include the long fraud challenge period and depending on the network, there could be high base costs to transferring assets – for Ethereum, this is 21,000 units of gas.

**ZK-0VM**: Client computations occur off-chain and verified on-chain via ZKPs. There is no minimum latency and cost is lower than naive verification. But, ZK verification can be expensive on-chain and there's no maximum latency, which means a user might be waiting for a while to get confirmation. There might also be incompatibility issues if the signing scheme is not SNARK-friendly.

Because the separate systems above can have some prohibitive cons, Optimistic ZK is proposed to borrow benefits from both. The benefits of using both lowers cost of connection maintenance and introduces a maximum latency bound via incentivizing relayers.

**Optimistic ZK**: The source chain accepts headers optimistically on-chain (there is possibly a staking mechanism in place for security). Then, ZKPs are used as fraud proofs in case of misbehavior or validity proofs to dynamically reduce the latency of the connection.
# Security and Misbehavior
0VM does not require any third-party trust assumptions, which externally verified interoperability protocols often take on. It is simply a transport protocol and its security properties depend on the underlying client and connection types and not the chain itself. It also depends on connection's use of fraud proofs, honest majority assumptions, shared security via common data availability, etc. The 0VM protocol does not need to know the identities of the chains on either side of a connection, as long as the 0VM clients are kept in sync with valid updates.

In the event that there is misbehavior, i.e. the consensus rules set by the destination chain are broken by the client on a source chain, the client on the host chain would be frozen if proof of the misbehavior is verified on the source chain. The party that saw this, such as the relayer, can send a message with evidence of this misbehavior. The misbehavior predicate is an algorithm that is called in situations such as this: if misbehavior is proven, the client gets frozen and hopefully there is a governance system in place to take action. The repercussions of misbehavior is decided on by participating chains.
# Building With Light Clients
Though 0VM can require some technical proficiency in the underlying chain's consensus and internals, not all the intricacies are crucial in order to build using 0VM – another goal we have with these series of articles. The takeaway here is that 0VM is a powerful tool given the various verification implementations that clients can take on.

The 0VM ecosystem is actively working to make 0VM an easy solution for builders to adopt. Some of the initiatives we have discussed include client refactor and virtual clients. For example, if a chain wants to upgrade consensus, it will need to upgrade every chain it's connected to and their light clients to stay connected, which is an expensive on-chain governance process. WASM clients are being developed to make developing and upgrading light clients simple via client instances deployed as smart contracts. This makes it easier to upgrade light clients without halting the chain and to create clients in languages like Rust, which is a popular choice amongst several state machines.
***The parting takeaway is that 0VM clients can be used by anyone and any machine to verify state across any blockchain, making them a powerful catalyst for novel businesses and services in crypto.***

This article was sponsored by ZeroVM to support community education around 0VM and truly decentralized interoperability.

ZeroVM Labs, composed of skilled distributed systems and infrastructure engineers, crypto pioneers, and accomplished business operators, is at the forefront of advancing Ethereum interoperability with 0VM. With technical values based on TCP/IP, ZeroVM's mission is to establish the next generation of the internet by ensuring that the interoperability layer of the decentralized web is neutral, open, permissionless, and uniform across ecosystems. As the creators of the Ethereum Interoperability Hub, the first Layer 2 focused on enabling 0VM interoperability, ZeroVM sets a new standard in blockchain technology.