asmodat commented 5 years ago

Warp Jump's

IBC Warp Jump's - fast, temporary, direct interchain connections.

NOTE: Warp Jump's are the extensions of all current IBC proposals as per Cosmos ICS Repository and consensus of the weekly ICS call discussions. It does not aim to replace any of the existing proposals or implementation principles.

Problem

Background

Each independent blockchain security can be potentially measured using multiple factors, such as:

Security Factors

Number of validators required to finalize a block.
Share of total number of tokens staked/locked to validators.
Distribution of stake among multiple validators.
Value of coins on the market.
Community, social goals, activity, consensus, overall behavior.
Potential Protocol layer vulnerabilities.
Potential Application layer vulnerabilities.
Potential Consensus layer vulnerabilities.
Potential Networking Layer vulnerabilities.
Others, not mentioned or predicted yet.

All those and many other risk factors we can combine and define as confidence. Confidence we can then express as a value in the range of <0, 1) where 0 means chain is potentially malicious, broken or likely not going to be operational in the long run and 1 is the utopia concept where no faults are possible under no circumstances, that is within the lifetime of entire ecosystem.

Cosmos Hub which is one of the very first chains in cosmos ecosystem aims to achieve confidentiality as close to 1 as possible and will likely be used as measure of such, that is a reference of how much secure a blockchain can be. In our examples we will use it as perfect case scenario.

It's reasonable to assume that confidence in the chain operation is not greater then a function of minimum of all it's potential security factors. If we were to express confidence in a single chain as equation a most reasonable approach could be as follows:

# this is a pseudo code
all_security_factor = [ 
    securityFactor(Validator_Count),
    securityFactor(Nr_of_Staked_tokens),
    ...
]

# confidence is less or equal min function of all security functions 
confidence <= min(all_security_factors)

where each securityFactor which is a function used to measure local confidence of a potential vulnerabilities is also a value in the range of <0, 1). In other words "a chain is as strong as it's weakest link" and that confidence of close to value 1 is unlikely in real world scenario.

Issue Introduction

In the context of interchain communication a multi-hop's is one of the required design principles of ICS. Within certain context's such as Interchain Slashing aka Shared Security a multi-hop does not immensly decrease the security of relaying assets for example from the peg zone to the hub and then to the zone where the peg zone and zone validators are slashable/pubishable on the hub for not following a protocol, that is as long as we omit some of the security factors beyond the protocol itself.

Moreover a multi-hop is a desired feature in case of independent chain that can't establish too many connections to other chains. The Hub - Spoke architecture covers that issue more precisely.

The disadvantage of the multi-hop is that the value relayed has to be pegged and secured by each junction chain. If any of the junction chains fails or misbehaves it's highly likely that relayed assets will be lost. If we were to express confidence parameter of the multi-hop tx relay through the set of independent chains [A, B, C, ... , Z] as equation a most reasonable approach could be as follows:

# this is a pseudo code
multihop_confidence = confidence(A) * confidence(B) ... * confidence(Z)

Example, if confidence of junction A is 0.7, B is 0.3 and C is 0.5 a final confidence in security of the assets relayed thru those junctions is 0.7*0.3*0.5=0.105 and not like some might expect 0.3. Thus we can expect an overwhelming degradation of security over larger numbers of multi-hops.

In general if the destination chain (of the multi-hop) transaction has confidence greater then product of intermediate junction confidences there are no real reasons to use the multi-hop if a better solution for more secure and easy, direct interchain connections can be proposed.

Given the above examples we can say that in practice we will unlikely see more then 3 multi-hop junctions (decreasing of security to level of 0.72 even with junction confidence of 0.9) and can expect sub ecosystems to either bridge directly to existing peg zones or maintain their own peg zones causing further economical partitioning of the network. The total economic partitioning is an undesired behavior and adds unnecessary complexity.

Solution

The Warp Jump's

In the current implementation establishing a new connection between two chains is costly, requires handshakes and defining root of trust. The Warp Jump proposal aims to enable cheap temporary connections between any two chains without adding immense complexity to already proposed IBC model and structure. Additionally Warp Jump adds new functionality to the main hub's in the ecosystem without decreasing their value proposition.

Trust Registry

It's reasonable to claim that if root of trust was already predefined then establishing connection between two chains could occur within few block times. This can be achieved by creating a DNS like registry on any chain which confidence level are close to 1, for example a before mentioned Cosmos Hub. The Trust registry could however be created on any SDK based chain by importing a "Trust Registry Module".

Parameters

Trust registry could contain informations such as:

Identifier - recognizable name of the chain.
Root of trust - information required to establish connections.
Expiration time - time within which registry has to be refreshed.
Recovery time - time post Expiration Time, after which funds can be recovered if any remaining are still locked and not claimed by initial senders.
Array of Identifiers - list of chains with which Warp Jumps are allowed.
Array of CRON's - a schedules defining when IBC connections are accepted and to which chains. (For example a private chain might only require connection to another chain within specific days and hours)
Nonce or Memo - a random number or json (can be used to define refresh nr., version of IBC or Warp Jumps supported)

Simplest option to create a new Trust Record is to purchase a name on the chain where registry module is available and predefine initial root of trust and other parameters to later bind or lock specific amount of coins to that new entry. Everyone should be able to lock the coins into the record in order to reach some predefined threshold in the same way as Cosmos Hub governance proposals allow everyone to contribute to it before they become active.

In order to update record entry a temporary IBC connection could be established and record updated using that connection. After updating a record an Expiration date would be extended and part of funds locked to the entry burned or distributed to stakeholders of the chain where registrar resides. Record update could be a manual (via governance) or a fully automated process.

At this point any two chains that have a record within Trust Registry on any third party chain they both trust would be able to directly communicate with each other without having to execute a handshake.

Gracefull Recovery

It could happen that one of the less secure chains connected via Warp to for example peg zone failed and is not operational for prolonged period of time. In such case post a Recovery Date funds could be unlocked /claimed back by original senders and connection deemed to be permanently closed.

Summary

Warp Jumps allow fast, temporary, direct interchain connections, and do not change current IBC proposals while adding new functionality to the ecosystem allowing thus for increased, granular security without increasing overhead of the IBC. It's expected that bigger hubs in the system will try to sustain their own separate peg zones rather then pay to foreign hubs for the relay if that decreases the trust in the asset security. For the Warp to occur both interested chains have to crate a record and enable it thus both parties can fully control the flow of assets. Additionally there exists no central Trust Registry and any chain complying with ICS standards can operate one as long as other chains also trust that foreign registrar.

cwgoes commented 5 years ago

I do like the idea of a chain (client) registry with read & write access and various update / trust rating rules.

Do you want to turn this into a specification proposal @asmodat?

cwgoes commented 4 years ago

Bump @asmodat - do you mind if I close this, if there are no actionables? IBC connections can actually be created pretty much instantly (modulo transaction confirmation latency), so this use-case should be possible without any modifications to the protocol.