ICS ?: Recursive Tendermint

[mossid]

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.

[Miniminitrue]

Relevant research here: https://arxiv.org/pdf/2402.00220.pdf (See Trustboost)