• We can consider that (informally) there are two key components to enable atomic cross-chain communication:
  • Relay liveness
  • State verification
• Sidechains
  • The definition of "trusted third party" is broad. A DAO can also be a trusted third party. In the case of a bridge between a standard sidechain (or layer 1 chain) and a parent chain for example, the consensus of the sidechain could lock or steal funds deposited into the sidechain via the parent chain. This is because to do state verification, the parent chain does not validate the transactions in the sidechain itself.
  • It trusts that the operators of the sidechain (i.e. the consensus) only moves deposited funds on the parent chain in accordance with the transaction validity rules of the sidechain.
  • Such a bridge is a trusted bridge because it relies on an honest majority assumption to prevent the bridge operators from stealing funds, examples include the Ethereum-Polygon and Ethereum-Solana bridges.
• Rollups
  • Withdrawals from rollups via a parent chain require a trusted third party in the form of a very weak honest minority assumption for liveness: at least one relayer or aggregator must post the rollup blocks on the parent chain.
  • In the case of rollups where any party can be a relayer or aggregator and thus the user themselves can fulfill this role, this requires a synchrony assumption (i.e. there is a synchronous network so that when the user sends a message, it will be received by the network within a certain timeframe).
• Two main types of cross-chain communicationss:
  • Trust-minimized cross-chain communication, which relies on either an honest minority or synchrony assumption for liveness and state verification.
  • Trusted cross-chain communication, which relies on an honest majority assumption for liveness and state verification.
• Cluster
  • A set of chains that communicate with each other (intra-cluster communication) with trust-minimized cross-chain communication including using trust-minimized state verification, such as fraud proofs, validity proofs, or directly validating transactions.
  • A key property of a cluster is that each chain in the cluster can validate the state machine of each other chain in the cluster.
  • Clusters are sovereign, meaning that a chain in cluster A cannot bring a chain in cluster B inside the circle of cluster A without hardforking cluster A or B.
  • In order to maintain trust-minimized state verification between all chains within a cluster, each chain must verify the data availability of the blocks of every other chain within that cluster in a trust-minimized way, either by downloading the data directly or by using techniques such as data availability proofs.