Define ICS1.5

[tbruyelle]

Context

Given this blog post, we can define the following versions of the main interchain security (ICS) protocols :

• ICS v1 : Replicated Security
• ICS v2 : Opt-in Security
• ICS v3 : Mesh Security

So ICS1.5 is an evolution of the Replicated Security (RS) protocol, let's define how Replicated Security actually works (for the other protocols I invite you to check the article).

Replicated Security requires a provider chain and one to many consumer chain(s).

The validator set of the provider chain is replicated (hence the name) to each consumer chain. This means that for each new consumer chain (a consumer chain can only be added by a governance proposal in the provider chain), each validator of the provider chain must run a new node for that consumer chain.

Once live, the provider and consumer chains exchange messages using IBC. For example, each time there's a change in the validator set of the provider chain, the consumer chain receives a Validator Set Change (VSC) IBC message to reflect this change in voting power. These IBC communications are handled by new modules, the provider chain must import the x/ccv/provider module, while the consumer chains must import the /x/ccv/consumer module. Note that the consumer module must replace the staking module, since the consumer chain doesn't have its own validator set, and has no staking mechanism. Both modules are hosted in the interchain-security repo.

There's another type of message exchanged in this protocol, the VSCMaturedPackets. This one, sent by the consumer chain, ensures that unbonding operations are synchronized between the provider and consumer chains. In other words, it ensures that an unbonding operation registered in the provider doesn't end earlier than in the consumer chain (due to IBC asynchronicity). This is a safety measure to prevent misbehavior of a validator on the consumer chain. If a validator has unbounded on the provider chain, but due to IBC asynchronicity, has kept his voting power on the consumer chain, he can potentially misbehave on that consumer chain without being slashed.

These VCSMaturedPackets imply a lot of code, and based on @jaekwon idea, we think it could be simplified. We (the decentralists) proposed an ADR where we remove the VCSMaturedPacket but it wasn't accepted at this time.

Define ICS1.5

Removal of VCSMaturedPackets

I believe ICS1.5 is ICS v1 without VCSMaturedPackets, but at this point we have no guarantees that this is actually doable. Recent report done at Informal to see if it's possible to remove these packets found that the above ADR does not guarantee the security model.

Here's an excerpt from the report describing the problem:

A malicious validator can keep sending bogus updates to a light client tracking a consumer chain even though the consumer chain might have stopped or might not be accepting user-generated transactions.

Core and Consumer shards

Another feature of ICS1.5, mentioned in the README is the creation of 2 types of consumer chains, the "core shards" and the "consumer shards". While "consumer shards" is something similar to the consumer chain in RS, "core shards" states about a stronger link between the provider and the consumer chain, especially the fact that the governance of these chains is only handled by the provider chain, hence AtomOne.

There's probably more differences between core and consumer shards, if anyone has more information, please comment this issue.

Other features ?

There may be other features we want in ICS1.5, let's use this issue to list them and evaluate their code complexity and security impact.

[giunatale]

ICS v3 and mesh security are really different things. All versions of ICS rely on validators from the producer chain running nodes of the consumer chain. Mesh security does not involve this at all.

mesh security is more amenable to IBC 2B using the taxonomy proposed by jae (see constitution.md)

I did write something myself about mesh security back when it was announced. Maybe worth a read https://github.com/decentralists/DAO/issues/11 although it does not necessarily reflect how mesh security will actually be implemented, there are many knobs that can be tweaked

---

I think actually the key to ICS1.5 is

Solve IBC1.5, or ICS1.5, where the validator sets are implicit, for fast inter-hub communication with implied IBC, WITHOUT sacrificing independent BFT consensus layers.

from the readme

Indeed, it would be very interesting if we could rely on the fact that valsets are shared for ICS (and hence implicit) and maybe implement an "implicit" IBC that is much faster than the canonical IBC.

For "consumer" and "core" shards, I think there is no modification to ICS required. It's a matter of how the consumer chain is designed. If it's entirely with no token e.g. and diverts all fees to the hub, then it is already a "core shard".

[tbruyelle]

Indeed, it would be very interesting if we could rely on the fact that valsets are shared for ICS (and hence implicit) and maybe implement an "implicit" IBC that is much faster than the canonical IBC.

What exactly does "implicit" mean? I understand it as being defined from the beginning and never moving. But it can't work that way, because you share not only the validator set, but also its voting power, which changes a lot over time.

[giunatale]

the hub and the consumer chains share the same validators, and changes to the hub valset (as well as VP distribution) are reflected on the consumer chains. This is what it means "implicit". Node operators of the producer chain are also node operators of the consumer(s). This notion could be exploited, and it currently isn't.

What exactly does "implicit" mean? I understand it as being defined from the beginning and never moving.

implicit means indirectly known, not immutable.

[tbruyelle]

OK, so it's similar to Replicated Security, I actually thought it was something else.

[giunatale]

It's literally Replicated Security (v1.5 is an improvement over 1 and even using Jae's proposed ICS taxonomy there's a v2 (A and B)).

Aside from simplifying current ICSv1 removing the VCSMaturedPackets, this second aspect is where really a v "1.5" could differentiate. A less delayed communication between blockchains within replicated security might enable some interesting scenarios and possibly even compete as a solution - I'm stretching it, but it is good to shoot high - with the megablock idea (aka "atomic" IBC)

[tbruyelle]

Given recent discussions on this topic, some key aspects of ICS1.5 have raised.

(Disclaimer: The following items provided are not necessarily exact and/or may change in the future, they are written to our best understanding. Some of them might also require more thorough discussion).

• The same validator set is used for all consumer chains.
• 3 kinds of ICS chains: root shard, core shards and consumer shards.
  • Root shard is AtomeOne.
  • Core shards implement features solely defined in the founding documents. They are governed and funded by the root shard.
  • Consumer shards are self-governed and self-funded, thus they can implement their desired features.
• Shards are hosted in virtual containers operated by the provider. These containers could be Linux containers (Docker), virtual environments (VMWare), and can be managed by an orchestrator like Kubernetes (k8s).
• Permissionless: upload your consumer shard image into IPFS, broadcast a specific transaction to AtomOne, and validators will pull the image and will start running it, as long as the balance of the tx signer has enough $ATONE. Unlike ICS1 there’s no need for a governance proposal.
• It’s undecided whether chains will share a global Tendermint instance or each will have its own independent one, however, it’s going to be more likely the second. Orchestration of the Tendermint instances might be handled separately from the ABCI applications, possibly a separate orchestration engine.
• Consumer chains progression from the producer perspective (root shard) might happen optimistically, in order to allow to faster progression and possibly even synchronous cross-shards execution.

Co-authored-by: @giunatale