Externally verified bridges rely on an 3rd-party set of actors to attest the correctness of data that is transported between chains. This is typically represented as an multisig, MPC system, PoS validator set, or oracle/relay.
External verification is easy to extend to any chain, and can support generalized messages at low latency. However, the security of a message passed between chains fully relies on the verifier set - this means that security scales with the size of the set. In most cases, externally verified bridges have far less security than the underlying chains, implying that they are not trust-minimized.
External bridges with large validator sets and staked incentives (e.g. PoS systems) are more secure than their smaller counterparts.
Optimistic bridges use fraud proofs to ensure the validity of data relayed across chains. Every message that passes through an optimistic bridge remains in a “pending” state during the dispute window until it is considered valid. During this time, watchers can dispute the message if the data is incorrect.
Optimistic bridges assume that there is at least one Watcher online somewhere (1-of-n assumption) that can send a transaction to chain. They also assume that Watchers will not abuse their position to censor the system. Censorship risk can be minimized using economic (dis)incentives.
In a natively verified bridge, a chain's own validator set verifies information coming in from another chain. This happens by implementing a light client of one chain within the VM of another, typically within a zk-snark to keep expensive computation offchain.
Because light clients verify consensus but not the state transitions of the block itself (the latter requires Data Availability), they assume the existence of an honest relayer who can give them the "correct" block from a connected chain. This makes them vulnerable to attacks where the validators of one chain produce an invalid block (for example, through a 51% attack) to spoof a message through the bridge.
Natively verified bridges have an additional tradeoff in that they require custom work for each chain with a new consensus mechanism. For some domains, for example with rollups, there may not be a light-client based strategy for bridging that works without additional trust tradeoffs.
Despite the above, natively verified bridges (regardless of whether they use ZKPs) are the best mechanism for moving data between two discrete blockchains.
Locally verified bridges are a special case of bridging where only the parties involved in a given cross-domain interaction verify the interaction. This is typically done through schemes like atomic swaps.
The challenge of locally verified bridges is that they require the liveness of all parties involved in a transaction, degrading UX and making it impractical to execute transactions that involve more than 2 parties. This further means that only some types of transactions are supported. For example, a peer-to-peer transfer is possible because there are only two parties involved, but many types of peer-to-contract interactions would not be possible as every chain user would be involved.
Local verification techniques are typically used in conjunction with other mechanisms such as optimistic bridges to improve latency. You can learn more about what types of messages can be executed immediately through local verification in our Authentication section.
Rollups are another special case. Rollups exist specifically to solve for the "honest relayer" assumption that exists with light client based bridges. They do this by creating a strict heirarchy between the parent chain (the L1) and the rollup, with all rollup data being available on the L1. This allows the L1 to run a "full client", directly verifying the state transitions of the rollup itself.
Rollup bridges are the most secure mechanism to communicate between any two domains. Period.
However, they can only exist between a rollup and its L1. See our section on Intercluster vs Intracluster communication for details.