Description
Summary
Tendermint is a BFT consensus algorithm run by multiple nodes. IBC semantics does not distinguish single-machine node and distributed state machine, so Tendermint can be run on multiple chains, using IBC instead of TCP/IP.
Here are some correspondence between Tendermint-over-nodes and Tendermint-over-chains.
| Nodes | Chains |
|---|---|
| Private Keys | Validator Consensus Key Sets |
| Public Keys | Light Clients |
| Transactions selected by the Proposer | Transactions selected by the Proposer Chain |
| State Machine | State Machine running Onchain |
| Transaction Mempool | Transaction Mempoll Onchain |
| Blockchain | Superchain |
| P2P Network | N-by-N IBC Connection |
| Doublesign | Equivocation |
Consensus related storage must be onchain(within the state machine of each chain)
P2P network is replaced by n-by-n IBC connection. The participants have to be fully connected with each other to verify the light client. The chains cannot verify chain they are not directly connected with without a trusted chain. The lightclient information, however, does not need to be updated by blockchain transaction because the superchain itself(which is running on each blockchain) has the lightclient information of all chains. The superchain transactions still need to be submitted.
One of the alternative approaches is large valset blockchain. Here are some comparisons between them:
-
LV blockchain will have higher block frequency than superchains
-
LV blockchain will run separately from their conceptual subpart chains -> less overhead
-
Superchains can be spined off dynamically with a known state machine
-
Superchains are harder to attack because of heterogeneous staking mechanisms between subpart chains
-
Superchains can have "chain as first-class object" concept
Examples
Interchain Consortium
Multiple chains can run a full consortium superchain without having representatives. Consortium superchains can have governance, common asset, basket token, etc.
High secure Superchain
Superchains can consist of large number of subpart chains, where each has a large number of validators. Superchain's state machine can endure large byzantine attacks without spending hashpowers. Downtime will be covered simply by the number of validators.
Sharded blockchain
Superchain can be used as a sharding mechanism, where the superchain maintains the global validator set and splitting, and the subpart chains updates their validator set accordingly. Each subpart chain can run different vm code and different contracts. When one chain fails the superchain bans the byzantine validators and spin-off a new chain with the latest known state. It is possible that the superchain can disconnect a subpart chain if the transactions are not properly recorded on a slowchain(#76) and recover the full state replaying the recorded state.