search

hypersign-protocol / whitepaper

2 stars 0 forks source link

Research on IBC #11

Closed Vishwas1 closed 2 years ago

Vishwas1 commented 2 years ago
arnabghose997 commented 2 years ago

Source: IBC Whitepaper (https://github.com/cosmos/ibc/raw/old/papers/2020-05/build/paper.pdf)

arnabghose997 commented 2 years ago

Sending token from blockchain A to blockchain B, and then back to blockchain A

The value that tokens represent can be transferred across chains, but the token itself cannot. When sending the tokens with IBC to another blockchain:

  1. Blockchain A locks the tokens and relays proof to blockchain B
  2. Blockchain B mints its own representative tokens in the form of voucher replacement tokens
  3. Blockchain B sends the voucher tokens back to blockchain A
  4. The voucher tokens are destroyed (burned) on blockchain B
  5. The locked tokens on blockchain A are unlocked

Source: http://tutorials.cosmos.network/understanding-ibc-denoms/

arnabghose997 commented 2 years ago

Source: IBC Whitepaper (https://github.com/cosmos/ibc/raw/old/papers/2020-05/build/paper.pdf)

Vishwas1 commented 2 years ago

IBC Paper notes

Ledgers hosting IBC must provide :

The data payloads in IBC packets are opaque to the protocol itself - modules on each ledger determine the semantics of the packets which are sent between them.

Similar to TCP/IP spec

Interfaces

How does IBC works

The primary purpose of IBC is to provide reliable, authenticated, ordered communication between modules running on independent host ledgers. This requires protocol logic in the areas of data relay, data confidentiality and legibility, reliability, flow control, authentication, statefulness, and multiplexing.

In the IBC architecture, modules are not directly sending messages to each other over networking infrastructure, but rather are creating messages to be sent which are then physically relayed from one ledger to another by monitoring “relayer processes”.

IBC assumes the existence of a set of relayer processes with access to an underlying network protocol stack and physical interconnect infrastructure. For correct operation and progress in a connection between two ledgers, IBC requires only that at least one correct and live relayer process exists which can relay between the ledgers.

These relayer processes:

IBC data packets consists of consensus state, client, connection, channel, and packet information, and any auxiliary state structure necessary to construct proofs of inclusion or exclusion of particular key/value pairs in state.

All data which must be proved to another ledger must also be legible; i.e., it must be serialised in a standardised format agreed upon by the two ledgers

IBC handler: the part of the ledger implementing the IBC protocol

Cryptographic commitments are used to prevent datagram forgery: the sending ledger commits to outgoing packets, and the receiving ledger checks these commitments, so datagrams altered in transit by a relayer will be rejected.

Host Ledger Requirements

  1. The host ledger must support a module system
  2. The host ledger must provide a key/value store interface allowing values to be read, written, and deleted. These functions must be permissioned to the IBC handler module so that only the IBC handler module can write or delete a certain subset of paths.
  3. Host ledgers must provide the ability to introspect their current height, current consensus state. and a bounded number of recent consensus states.
  4. Host ledgers must implement a port system, where the IBC handler can allow different modules in the host ledger to bind to uniquely named ports.
  5. Host ledgers must support an exception or rollback system, whereby a transaction can abort execution and revert any previously made state changes

Architecture

Clients

The client abstraction encapsulates the properties that consensus algorithms of ledgers implementing the in-terblockchain communication protocol are required to satisfy.

The algorithm utilised in IBC to verify the consensus transcript and state sub-components of another ledger is referred to as a validity predicate, and pairing it with a state that the verifier assumes to be correct forms a light client.

A validity predicate is an opaque function defined by a client type to verify headers depending on the current consensus state

A consensus state is an opaque type representing the state of a validity predicate.

Light Client: A light client is the algorithm with which an actor can verify updates to the state of another ledger which the other ledger’s consensus algorithm has agreed upon, and reject any possible updates which the other ledger’s consensus algorithm has not agreed upon.

Connections

The connection abstraction encapsulates two stateful objects (connection ends) on two separate ledgers, each associated with light client of the other ledger, which together facilitate cross-ledger sub-state verification and packet relay (through channels).

A connection end is state tracked for an end of a connection on one ledger.

enum ConnectionState {
 INIT,
 TRYOPEN, 
 OPEN,
}
interface ConnectionEnd {
 state: ConnectionState
 counterpartyConnectionIdentifier: Identifier
 counterpartyPrefix: CommitmentPrefix
 clientIdentifier: Identifier
 counterpartyClientIdentifier: Identifier
 version: string
}

Channels

The channel abstraction provides message delivery semantics to the interblockchain communication protocol in three categories: ordering, exactly-once delivery, and module permissioning.

A channel serves as a conduit for packets passing between a module on one ledger and a module on another, ensuring that packets are executed only once, delivered in the order in which they were sent and delivered only to the corresponding module owning the other end of the channel on the destination ledger.

Each channel is associated with a particular connection, and a connection may have any number of associated channels.

Channels are payload-agnostic. The modules which send and receive IBC packets decide how to construct packet data and how to act upon the incoming packet data, and must utilise their own application logic to determine which state transactions to apply according to what data the packet contains.

IBC packets are relayed from one ledger to the other by external relayer processes.

Two ledgers, A and B, confirm new blocks independently, and packets from one ledger to the other may be delayed, censored, or re-ordered arbitrarily. Packets are visible to relayers and can be read from a ledger by any relayer process and submitted to any other ledger.

The IBC protocol must provide ordering (for ordered channels) and exactly-once delivery guarantees to allow ap-plications to reason about the combined state of connected modules on two ledgers

A channel is a pipeline for exactly-once packet delivery between specific modules on separate ledgers, which has at least one end capable of sending packets and one end capable of receiving packets.

Exactly-once: a packet sent on one end of a channel is delivered no more and no less than once, eventually, to the other end.

A channel end is a data structure storing metadata associated with one end of a channel on one of the participating ledgers

interface ChannelEnd { 
 state: ChannelState // is the current state of the channel end.
 ordering: ChannelOrder  //  whether the channel is ordered or unordered.
 counterpartyPortIdentifier: Identifier // port on the counterparty ledger which owns the other end of the channel
 counterpartyChannelIdentifier: Identifier //  identifies the channel end on the counterparty ledger.
 nextSequenceSend: uint64 // stored separately, tracks the sequence number for the next packet to be sent.
 nextSequenceRecv: uint64 // stored separately, tracks the sequence number for the next packet to be received.
 nextSequenceAck: uint64 // stored separately, tracks the sequence number for the next packet to be acknowledged.
 connectionHops: [Identifier] //  stores the list of connection identifiers, in order, along which packets sent on this channel will travel. At the moment this list must be of length 1. In the future multi-hop channels may be supported.
 version: string // 
}

Channel State: 

enum ChannelState {
 INIT,   // just started the opening handshake
 TRYOPEN, //  has acknowledged the handshake step on the counterparty ledger.
 OPEN,  //  has completed the handshake and is ready to send and receive packets.
 CLOSED, //  has been closed and can no longer be used to send or receive packets.
}
Packets

A Packet, encapsulating opaque data to be transferred from one module to another over a channel, is a particular interface defined as follow:

interface Packet {
 sequence: uint64 // number corresponds to the order of sends and receives, where a packet with an earlier sequence number must be sent and received before a packet with a later sequence number.
 timeoutHeight: uint64 // indicates a consensus height on the destination ledger after which the packet will no longer be processed, and will instead count as having timed-out.
 timeoutTimestamp: uint64 //  indicates a timestamp on the destination ledger after which the packet will no longer be processed, and will instead count as having timedout.
 sourcePort: Identifier // identifies the port on the sending ledger.
 sourceChannel: Identifier //  identifies the channel end on the sending ledger
 destPort: Identifier //  identifies the port on the receiving ledger
 destChannel: Identifier // identifies the channel end on the receiving ledger
 data: bytes //  is an opaque value which can be defined by the application logic of the associated modules.
}

Channel life cycle

Datargram Previous State Next State
ChannelOpenInit (executed on A) [, ] [INIT, _]
ChannelOpenTry (executed on B) [INIT, _] [INIT, TRYOPEN]
ChannelOpenAck (executed on A) [INIT, TRYOPEN] [OPEN, TRYOPEN]
ChannelOpenConfirm (executed on B) [OPEN, TRYOPEN] [OPEN, OPEN]

Sending Packets

The sendPacket() function is called by a module in order to send an IBC packet on a channel end owned by the calling module to the corresponding module on the counterparty ledger.

Note that the full packet is not stored in the state of the ledger — merely a short hash-commitment to the data and timeout value. The packet data can be calculated from the transaction execution and possibly returned as log output which relayers can index.

Receieving Packets

The recvPacket() function is called by a module in order to receive and process an IBC packet sent on the corre- sponding channel end on the counterparty ledger.

Acknowledgements

The acknowledgePacket() function is called by a module to process the acknowledgement of a packet previously sent by the calling module on a channel to a counterparty module on the counterparty ledger.

Relayers

Relayer algorithms are the physical connection layer of IBC — off-ledger processes responsible for

In the IBC protocol, one ledger can only record the intention to send particular data to another ledger — it does not have direct access to a network transport layer. Physical datagram relay must be performed by off-ledger infrastructure with access to a transport layer such as TCP/IP.

This standard defines the concept of a relayer algorithm, executable by an off-ledger process with the ability to query ledger state, to perform this relay.

A relayer is an off-ledger process with the ability to read the state of and submit transactions to some set of ledgers utilising the IBC protocol

Basic Relayer Algorithm

Relaying Packets

Packets in an ordered channel can be relayed in either an event-based fashion or a query-based fashion.

Relaying acknowledgements

Acknowledgements can most easily be relayed in an event-based fashion. The relayer should:

Bundling

If the host ledger supports it, the relayer process can bundle many datagrams into a single transaction, which will cause them to be executed in sequence, and amortise any overhead costs.

Incentivisation

Vishwas1 commented 2 years ago

image

image

image

Vishwas1 commented 2 years ago

image