Subsidiary Replicated Chain Security (SRCS)

[KaiserKarel]

Introduction

Union uses CometBLS as the consensus algorithm, which is not supported by Tendermint chains by default. We previously proposed an intermediate hopchain with CometBFT consensus, supporting CometBLS and CometBFT IBC connections.

sequenceDiagram
    Osmosis->>Hop: CometBFT
    Hop-->>Union: CometBLS
    Union->>Ethereum: CometBLS

Loading

For chains connecting to hop and union, we can provide abstractions through multi-hop routing such that they are essentially unaware of the dual chain setup.

Problem

Introducing a secondary chain adds security issues to the network and poses some questions.

• Are the validator sets different?
• What happens when hop validators commit fraud?
• What happens when union validators commit fraud?

Essentially, we rely on and the honest-majority assumption twice when introducing hop.

We could use ICS (interchain security) to ensure that hopchain is validated by union, however, ICS is unfinished, and intended for sovereign chains. hopchain is not sovereign and does not need its own governance, staking, validator selection, etc.

Proposed Solution

I propose Subsidiary Replicated Chain Security (SRCS) as an alternative to ICS, which in effect ensures that hop validators == union validators.

SRCS provides the following guarantees:

1. For every union block produced, a hop block is produced.
2. When union validators rotate, hop validators rotate.
3. When hop validators commit fraud, union validators are slashed.

With this, we guarantee security and liveliness for Hop.

Implementation

We use a modified CometBLS IBC connection between hopchain and union. This light-client has the following features:

• The valroot is set by union. Hopchain cannot change the valroot itself.

Over this IBC connection, we transfer union block headers for each height, and embed the height in the hop block, meaning that for each hop block, a matching union header can be found in the hop block.

We support a few IBC messages in Hop which are used for governance control, such as:

• SetValidators: updates the hop validators

[hussein-aitlahcen]

One thing we may consider is relying on the fact that cosmos v0.47 allow for wasm light clients (just like us using ETH wasm light client). This would mean that we wait for cosmos chains to upgrade and then implements our cometbls verifier in wasm. The cosmwasm contract would be symmetric to the solidity implementation and technically allow any v0.47+ cosmos chain to initiate an IBC connection Union.

The drawback here is that we need to wait for chains to be on v0.47+. I do think it's worth it though.

[KaiserKarel]

Yeah, I few months ago it didn't look peachy with chain maintenance, but notional has done tremendous work there. I reckon we do not need to implement something like this.