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

What are the known attack / censorship vectors here, if any?

The Imua system consists of the smart contracts in L1 chains and the Imua protocol itself. The potential attack / censorship vectors are:

  • Attack on L1 chains:

    • DOS or censorship

      • Effect: users won’t be able to restake or withdraw tokens.

      • Mitigation: chain selection needs to be done based on selective criteria.

    • Smart contract exploit

      • Effect: users won’t be able to restake or withdraw tokens or users could be exposed to potential theft of tokens.

      • Mitigation: smart contracts implemented on each L1 chain have minimally complex business logic, which allows for simpler code, a smaller attack surface, and more reliable security audits.

  • Attack on the Imua chain:

    • DOS or censorship

      • Effect: normal operations such as reward distribution or slashing could be delayed.

      • Mitigation: Imua network will consist of a decentralized validator set as well as a proper block proposer rotation and censorship detection mechanism. Through these, such an attack will be greatly mitigated and the delay of operations will be kept at an acceptable level (minutes at most).

    • PoS attack by controlling majority vote

      • 33% vote collusion.

        • Effect: The Imua chain will halt and it will have similar effect as a DOS attack with a different duration.

        • Mitigation: Imua itself will have protocol-level slashing mechanism to prevent malicious behavior like this.

      • 66% vote collusion

        • Effect: Imua chain will be able to send a malicious transaction to client chains.

        • Mitigation: Imua doesn’t have permission to transfer user’s asset to other addresses so attackers won’t be able to benefit financially from such an attack. With a properly implemented and designed PoS consensus mechanism such an attack can be mitigated. Worst case scenario, if such an attack does happen, as with all other blockchains, social consensus of the Imua community can slash the attacker and recover assets with a honest network.

PreviousHow is the cross-chain communication is achieved?NextAre the restaked tokens being pooled in a centralized account?

Last updated 2 months ago