Avatar State Sync

Avatar State Sync uses light client proofs to verify the state of a source chain. A relayer submits a Merkle proof alongside a block header to a destination chain's smart contract. The contract validates the header's consensus (e.g., Tendermint signatures) and then verifies the proof against the header's state root, enabling trustless reading of account balances, storage slots, or event logs.

The protocol is foundational for general message passing between blockchains. Applications use it to trigger actions on a destination chain based on verified events from a source chain. Key implementations include:

• Cross-chain DeFi: Lock-and-mint bridges, yield aggregators pulling data.
• Omnichain NFTs: Verifying NFT ownership or metadata across ecosystems.
• Governance: Executing votes that affect multiple chains from a single dashboard.

Unlike most bridges that rely on a multi-signature wallet or a federated set of external validators, Avatar State Sync's security derives from the underlying source chain's consensus mechanism. This creates a trust-minimized bridge where security is cryptographic and verifiable, not social. The main trust assumption is the economic security of the source chain's validators at the time of the block header's creation.

The system involves several distinct roles:

• Light Client Contract: On-chain verifier that validates headers and proofs.
• Relayers: Off-chain actors who submit headers and state proofs. They can be permissionless or incentivized.
• Wormhole Guardian Network: A specific, permissioned set of nodes that act as the relayer for the Wormhole implementation, observing and attesting to source chain state.
• Application Contracts: Smart contracts that consume the verified state data to execute business logic.

While powerful, the model has inherent limitations:

• Gas Cost: On-chain verification of cryptographic proofs (like Ed25519 signatures) is computationally expensive.
• Latency: Finality must be reached on the source chain before a state proof can be generated and relayed.
• Data Availability: The protocol verifies that state was valid at a past block, but does not guarantee its current availability or liveness.
• Relayer Incentives: A robust, decentralized relayer network is crucial for system liveness and censorship resistance.

The primary challenge is proving that the reported off-chain state (e.g., a wallet balance on Ethereum) is authentic and not fabricated. Solutions rely on cryptographic proofs:

• Light Client Proofs: Using Merkle proofs to verify that a specific piece of data is part of a block header.
• Optimistic Verification: Assuming state is correct but allowing a fraud proof challenge period.
• Zero-Knowledge Proofs (ZKPs): Generating a succinct proof (e.g., a zk-SNARK) that attests to the correctness of the state transition without revealing the underlying data.

Synchronizing state requires waiting for the source chain's finality—the point where a block is irreversible. This creates inherent latency.

• Challenge: High finality times (e.g., Ethereum's ~12-15 minutes) delay syncs.
• Optimization: Using pre-confirmations or soft finality signals from validator sets for faster, albeit less secure, reads.
• Trade-off: Systems must balance speed against the risk of state reversals due to chain reorganizations.

Verifying proofs or storing state data on the destination chain consumes gas, which can be prohibitively expensive.

• Challenge: Complex ZK verification or storing large Merkle roots on-chain.
• Optimization: Batching multiple state updates into a single proof to amortize cost.
• Optimization: State Differencing: Transmitting only the delta (changes) between syncs instead of the full state.

An off-chain relayer network is typically needed to fetch and submit state data. This introduces centralization risks.

• Challenge: Reliance on a few trusted relayers creates a single point of failure.
• Optimization: Incentivizing a permissionless relayer network with staking and slashing.
• Optimization: Proof-of-Stake (PoS) based relay committees where nodes are randomly selected to attest to state.

The destination chain must have access to the underlying data needed to verify a proof.

• Challenge: If data is not publicly available (data availability problem), a proof cannot be verified.
• Solution: Ensuring source chain data is posted to a Data Availability (DA) layer or that proofs are self-contained.
• Example: Using zkRollup state roots where data is available on Ethereum L1.

Lack of common standards makes it difficult for applications to use multiple state sync protocols.

• Challenge: Each bridge or sync protocol has a unique interface.
• Optimization: Adopting standards like the Inter-Blockchain Communication (IBC) protocol's light client model.
• Benefit: Standardized verification allows dApps to compose across any connected chain using a unified interface.

The general category of protocols enabling communication between independent blockchains. Avatar State Sync is a specific implementation that focuses on state verification rather than arbitrary message passing. Key approaches include:

• State Verification: Proving the state of one chain is valid on another (Avatar's method).
• Arbitrary Message Passing (AMP): Sending any data or function calls across chains.
• Bridges: Asset-focused systems that often use messaging protocols as a component.

A resource-efficient node that verifies blockchain state without downloading the entire chain. Avatar State Sync is fundamentally a light client protocol. It enables a destination chain (like Polygon zkEVM) to run a light client of a source chain (like Ethereum), allowing it to independently verify the state of the source chain's State Sync Committee and the Merkle proofs they produce.

A decentralized set of validators specifically tasked with observing and attesting to the state of a source blockchain. In Avatar, this committee:

• Monitors the source chain (e.g., Ethereum).
• Signs Merkle roots of the source chain's state at regular intervals.
• Broadcasts these signed attestations to the destination chain.
• The security of the entire sync depends on the cryptoeconomic security and honest majority of this committee.

A cryptographic proof that a specific piece of data (like a transaction or account state) is part of a larger dataset (like a blockchain's state trie). Avatar State Sync relies on Merkle proofs for efficiency:

• The committee attests to a Merkle root (a hash of the entire state).
• To prove a specific state element (e.g., a token balance), a user submits a compact Merkle proof alongside the committee's signed root.
• The destination chain's light client verifies the proof against the attested root, confirming the state's validity without processing the entire chain history.

A standardized framework that defines how different blockchains communicate and share data/assets. Avatar is an interoperability protocol with a specific architecture. It contrasts with other major protocols like:

• IBC (Inter-Blockchain Communication): Uses light clients and Merkle proofs for Cosmos SDK chains.
• LayerZero: Uses an Oracle and Relayer model for message attestation.
• Wormhole: Uses a Guardian network of nodes for multisig attestations.
• CCIP: Chainlink's approach using a decentralized oracle network.

A bridge architecture that uses zero-knowledge proofs (ZKPs) to verify the state of a source chain. This represents an alternative security model to Avatar's optimistic or multi-signature committee. zkBridges:

• Generate a ZK-SNARK or ZK-STARK proof that a source chain's state transition is valid.
• Provide cryptographic security based on the proof system, not a validator set's economic stake.
• Offer potentially stronger trust assumptions but with higher computational overhead for proof generation.