LogoLogo
  • Imua
    • About
  • Manifesto
    • The Problems
    • The Principles
  • Architecture
    • Imua Design Principles
    • Imua Network
    • Imua Modules
    • Client Chain Bridges
      • Trustless Verification of Client Chain State
      • Handling Race Conditions between Imua and Client Chains
    • Client Chain Contracts
  • Concepts
    • Ecosystem
      • Re/stakers
      • Operators
      • Services (AVS)
        • Service Integration with Imua
        • Service Committee
        • Service Integration Details
    • restaked Proof-of-Stake (rPOS)
    • Multi-Token Restaking
    • Multi-Chain Restaking with Trustless Bridging
    • Voting Power
    • Price Oracle
    • Flexible Integration with AVS
    • Tribe Staking
  • Governance
  • Risk Management
    • Risk Analysis
      • Risk Modeling
      • Risk Parameters
      • Crypto-Economic Risk
      • Unintended Slashing
      • Black Swan Events
    • Risk Mitigation
      • Smart Contract Simplicity
      • Audits
      • Slashing Prevention
      • Slashing Vetos
      • Insurance Pools
      • Circuit Breakers
  • Components
    • Testnet
    • Oracle Module
      • Reaching Consensus on Asset Prices
      • Penalty
      • Implementation Detail
    • Smart Contracts
    • Explorer
    • Registry
  • Validator Setup
    • Prerequisites
    • Node Install
    • Compiling Binary from Source
    • Oracle Price Feeder
    • Running the Node
    • Snapshot
    • Register Option 1 (Bootstrap)
    • Register Option 2 (Post Network Launch)
    • Deposit Tokens
    • Delegating Tokens
    • Confirm Election Status
    • Faucets
    • Managing The Validator
    • Security Best Practices
    • Risks & Mitigation
    • Participation in Governance
    • FAQs & Resources
  • Testnet Upgrade to v1.1.1
  • AVS Setup
    • AVS Overview
    • Prerequisites
    • Building the AVS in Imua
    • Hello-World-AVS Example
    • Becoming AVS Operator
    • AVS Register and Deploy
    • AVS Task Example
    • Enhanced and Automated Edition of hello-avs integration guide&example
  • Whitepaper (2023)
    • .pdf
  • FAQ
    • What problems is Imua solving?
    • What are the main design trade-offs that had to be made with an omnichain design?
    • Does the omnichain design imply added trust assumptions (relative to a single-chain design)?
    • What concurrency-related challenges would you face with a different design?
    • How does Imua integrate with new chains?
    • Do specific chains prove unique challenges w.r.t. integration?
    • How is the cross-chain communication is achieved?
    • What are the known attack / censorship vectors here, if any?
    • Are the restaked tokens being pooled in a centralized account?
    • Who will run the validators in the Imua network?
    • Is Imua an AVS?
    • How does Imua address the risks of overloading L1 social consensus?
    • Does the Imua queuing system raise concerns around latency?
    • What are the main benefits of an omnichain design?
Powered by GitBook
On this page
  1. FAQ

How is the cross-chain communication is achieved?

The communication between Imua and L1 chains is very specific, involving only a “reading” and a “writing” process from Imua to client chains. The reading is for reflecting the restaked assets state and other related data from client chain to Imua system. The writing is for Imua to issue control actions to the client chain such as locking, unlocking and slashing.

The reading process is achieved using a ZK light-client-based bridge. Specifically, Imua validators will host a light client for each integrated client chain. Events about staking and withdrawal from the Imua contracts in client chains will be received and verified by the Imua validators and corresponding state will be updated in the Imua accounting system. No transaction is needed to be sent from client chain to Imua since the message processing logic is built into the validator logic.

The writing process is achieved by Imua validators collectively signing and sending transactions to the client chains. These transactions are signed using a Threshold Signature Scheme (TSS) for its cost-effectiveness. We chose not to use multi-sig based signing due to following tradeoff considerations.

Bridge solutions

Multisig-based

TSS-based

Cost

High (it cost 3000 gas units to verify a ECDSA signature. With our Imua validator set to be at least 100 for decentralization, it will be extremely costly to issue a single action from Imua)

Low (Only one signature is verified on the client chain and it costs the same as any normal transaction, the cost are saved because the complexity of the algorithm happens off-chain in MPC on Imua side)

Complexity

Relatively easy to implement and most logic exist on smart contract level.

Complicated to implement (could be mitigated by adopting well-known open-source TSS implementations), but it’s easy to implement on the client side smart contract since only one signature needs to be verified.

Security

As secure as Imua

As secure as Imua

Existing Adopters

Wormhole, BSC bridge, Ronin Bridge

Thorchain, Multichain, Axelar (based on their whitepaper)

Implementation Risk

Medium

High

PreviousDo specific chains prove unique challenges w.r.t. integration?NextWhat are the known attack / censorship vectors here, if any?

Last updated 2 months ago