Update layout & fix anchor links
This commit is contained in:
Christopher Goes
parent
1cdfef81cd
commit
be3fa5672e
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
This paper specifies the Cosmos Inter-Blockchain Communication (IBC) protocol. The IBC protocol defines a set of semantics for authenticated, strictly-ordered message passing between two blockchains with independent consensus algorithms.
|
||||
|
||||
IBC requires two blockchains with cheaply verifiable rapid finality. The protocol makes no assumptions of block confirmation times or maximum network latency of packet transmissions, and the two consensus algorithms remain completely independent. Each chain maintains a local partial order and inter-chain message sequencing ensures cross-chain linearity. Once the two chains have registered a trust relationship, cryptographically provable packets can be sent between the chains.
|
||||
IBC requires two blockchains with cheaply verifiable rapid finality and Merkle tree substate proofs. The protocol makes no assumptions of block confirmation times or maximum network latency of packet transmissions, and the two consensus algorithms remain completely independent. Each chain maintains a local partial order and inter-chain message sequencing ensures cross-chain linearity. Once the two chains have registered a trust relationship, cryptographically provable packets can be sent between the chains.
|
||||
|
||||
The core IBC protocol is payload-agnostic. On top of IBC, developers can implement the semantics of a particular application, enabling users to transfer valuable assets between different blockchains while preserving, under particular security assumptions of the underlying blockchains, the contractual guarantees of the asset in question - such as scarcity and fungibility for a currency or global uniqueness for a digital kitty-cat.
|
||||
|
||||
|
|
@ -13,23 +13,28 @@ IBC was first outlined in the [Cosmos Whitepaper](https://github.com/cosmos/cosm
|
|||
## Contents
|
||||
|
||||
1. **[Overview](overview.md)**
|
||||
1. Definitions
|
||||
1. Threat Models
|
||||
1. **[Proofs](proofs.md)**
|
||||
1. Establishing a Root of Trust
|
||||
1. Following Block Headers
|
||||
1. **[Messaging Queue](queues.md)**
|
||||
1. Merkle Proofs for Queues
|
||||
1. Naming Queues
|
||||
1. Message Contents
|
||||
1. Sending a Packet
|
||||
1. Receipts
|
||||
1. Relay Process
|
||||
1. [Summary](overview.md#11-summary)
|
||||
1. [Requirements](overview.md#12-requirements)
|
||||
1. [Threat Models](overview.md#13-threat-models)
|
||||
1. **[Connections](connections.md)**
|
||||
1. [Definitions](connections.md#21-definitions)
|
||||
1. [Requirements](connections.md#22-requirements)
|
||||
1. [Connection lifecycle](connections.md#23-connection-lifecycle)
|
||||
1. [Opening a connection](connections.md#231-opening-a-connection)
|
||||
1. [Following block headers](connections.md#232-following-block-headers)
|
||||
1. [Closing a connection](connections.md#233-closing-a-connection)
|
||||
1. **[Packets](packets.md)**
|
||||
1. [Definitions](packets.md#31-definitions)
|
||||
1. [Requirements](packets.md#32-requirements)
|
||||
1. [Sending a packet](packets.md#33-sending-a-packet)
|
||||
1. [Receiving a packet](packets.md#34-receiving-a-packet)
|
||||
1. [Packet relayer](packets.md#35-packet-relayer)
|
||||
1. **[Optimizations](optimizations.md)**
|
||||
1. Cleanup
|
||||
1. Timeout
|
||||
1. Handling Byzantine Failures
|
||||
1. [Timeouts](optimizations.md#41-timeouts)
|
||||
1. [Cleanup](optimizations.md#42-cleanup)
|
||||
1. [Handling Byzantine failures](optimizations.md#43-handling-byzantine-failures)
|
||||
1. **[Conclusion](conclusion.md)**
|
||||
1. **[References](references.md)**
|
||||
1. **[Appendices](appendices.md)**
|
||||
1. [Appendix A: Encoding Libraries](appendices.md#appendix-a-encoding-libraries)
|
||||
1. [Appendix B: IBC Queue Format](appendices.md#appendix-b-ibc-queue-format)
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@
|
|||
|
||||
The specification has focused on semantics and functionality of the IBC protocol. However in order to facilitate the communication between multiple implementations of the protocol, we seek to define a standard syntax, or binary encoding, of the data structures defined above. Many structures are universal and for these, we provide one standard syntax. Other structures, such as _H<sub>h </sub>, U<sub>h </sub>, _and _X<sub>h</sub>_ are tied to the consensus engine and we can define the standard encoding for tendermint, but support for additional consensus engines must be added separately. Finally, there are some aspects of the messaging, such as the envelope to post this data (fees, nonce, signatures, etc.), which is different for every chain, and must be known to the relay, but are not important to the IBC algorithm itself and left undefined.
|
||||
|
||||
In defining a standard binary encoding for all the "universal" components, we wish to make use of a standardized library, with efficient serialization and support in multiple languages. We considered two main formats: ethereum's rlp[[6](./footnotes.md#6)] and google's protobuf[[7](./footnotes.md#7)]. We decided for protobuf, as it is more widely supported, is more expressive for different data types, and supports code generation for very efficient (de)serialization codecs. It does have a learning curve and more setup to generate the code from the type specifications, but the ibc data types should not change often and this code generation setup only needs to happen once per language (and can be exposed in a common repo), so this is not a strong counter-argument. Efficiency, expressiveness, and wider support rule in its favor. It is also widely used in gRPC and in many microservice architectures.
|
||||
In defining a standard binary encoding for all the "universal" components, we wish to make use of a standardized library, with efficient serialization and support in multiple languages. We considered two main formats: ethereum's rlp[[6](./references.md#6)] and google's protobuf[[7](./references.md#7)]. We decided for protobuf, as it is more widely supported, is more expressive for different data types, and supports code generation for very efficient (de)serialization codecs. It does have a learning curve and more setup to generate the code from the type specifications, but the ibc data types should not change often and this code generation setup only needs to happen once per language (and can be exposed in a common repo), so this is not a strong counter-argument. Efficiency, expressiveness, and wider support rule in its favor. It is also widely used in gRPC and in many microservice architectures.
|
||||
|
||||
The tendermint-specific data structures are encoded with go-wire[[8](./footnotes.md#8)], the native binary encoding used inside of tendermint. Most blockchains define their own formats, and until some universal format for headers and signatures among blockchains emerge, it seems very premature to enforce any encoding here. These are defined as arbitrary byte slices in the protocol, to be parsed in an consensus engine-dependent manner.
|
||||
The tendermint-specific data structures are encoded with go-wire[[8](./references.md#8)], the native binary encoding used inside of tendermint. Most blockchains define their own formats, and until some universal format for headers and signatures among blockchains emerge, it seems very premature to enforce any encoding here. These are defined as arbitrary byte slices in the protocol, to be parsed in an consensus engine-dependent manner.
|
||||
|
||||
For the following appendixes, the data structure specifications will be in proto3[[9](./footnotes.md#9)] format.
|
||||
For the following appendixes, the data structure specifications will be in proto3[[9](./references.md#9)] format.
|
||||
|
||||
## Appendix B: IBC Queue Format
|
||||
|
||||
|
|
@ -34,9 +34,9 @@ See [binary format as protobuf specification](./protobuf/queue.proto)
|
|||
|
||||
{ link to the implementation }
|
||||
|
||||
A merkle tree (or a trie) generates one hash that can prove every element of the tree. Generating this hash starts with hashing the leaf nodes. Then hashing multiple leaf nodes together to get the hash of an inner node (two or more, based on degree k of the k-ary tree). And continue hashing together the inner nodes at each level of the tree, until it reaches a root hash. Once you have a known root hash, you can prove key/value belongs to this tree by tracing the path to the value and revealing the (k-1) hashes for all the paths we did not take on each level. If this is new to you, you can read a basic introduction[[10](./footnotes.md#10)].
|
||||
A merkle tree (or a trie) generates one hash that can prove every element of the tree. Generating this hash starts with hashing the leaf nodes. Then hashing multiple leaf nodes together to get the hash of an inner node (two or more, based on degree k of the k-ary tree). And continue hashing together the inner nodes at each level of the tree, until it reaches a root hash. Once you have a known root hash, you can prove key/value belongs to this tree by tracing the path to the value and revealing the (k-1) hashes for all the paths we did not take on each level. If this is new to you, you can read a basic introduction[[10](./references.md#10)].
|
||||
|
||||
There are a number of different implementations of this basic idea, using different hash functions, as well as prefixes to prevent second preimage attacks (differentiating leaf nodes from inner nodes). Rather than force all chains that wish to participate in IBC to use the same data store, we provide a data structure that can represent merkle proofs from a variety of data stores, and provide for chaining proofs to allow for sub-trees. While searching for a solution, we did find the chainpoint proof format[[11](./footnotes.md#11)], which inspired this design significantly, but didn't (yet) offer the flexibility we needed.
|
||||
There are a number of different implementations of this basic idea, using different hash functions, as well as prefixes to prevent second preimage attacks (differentiating leaf nodes from inner nodes). Rather than force all chains that wish to participate in IBC to use the same data store, we provide a data structure that can represent merkle proofs from a variety of data stores, and provide for chaining proofs to allow for sub-trees. While searching for a solution, we did find the chainpoint proof format[[11](./references.md#11)], which inspired this design significantly, but didn't (yet) offer the flexibility we needed.
|
||||
|
||||
We generalize the left/right idiom to concatenating a (possibly empty) fixed prefix, the (just calculated) last hash, and a (possibly empty) fixed suffix. We must only define two fields on each level and can represent any type, even a 16-ary Patricia tree, with this structure. One must only translate from the store's native proof to this format, and it can be verified by any chain, providing compatibility for arbitrary data stores.
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ The proof format also allows for chaining of trees, combining multiple merkle st
|
|||
|
||||
A valid merkle proof for IBC must either consist of a proof of one tree, and prepend "ibc" to all key names as defined above, or use a subtree named "ibc" in the first section, and store the key names as above in the second tree.
|
||||
|
||||
For those who wish to minimize the size of their merkle proofs, we recommend using Tendermint's IAVL+ tree implementation[[12](./footnotes.md#12)], which is designed for optimal proof size, and freely available for use. It uses an AVL tree (a type of binary tree) with ripemd160 as the hashing algorithm at each stage. This produces optimally compact proofs, ideal for posting in blockchain transactions. For a data store of _n_ values, there will be _log<sub>2</sub>(n)_ levels, each requiring one 20-byte hash for proving the branch not taken (plus possible metadata for the level). We can express a proof in a tree of 1 million elements in something around 400 bytes. If we further store all IBC messages in a separate subtree, we should expect the count of nodes in this tree to be a few thousand, and require less than 400 bytes, even for blockchains with a quite large state.
|
||||
For those who wish to minimize the size of their merkle proofs, we recommend using Tendermint's IAVL+ tree implementation[[12](./references.md#12)], which is designed for optimal proof size, and freely available for use. It uses an AVL tree (a type of binary tree) with ripemd160 as the hashing algorithm at each stage. This produces optimally compact proofs, ideal for posting in blockchain transactions. For a data store of _n_ values, there will be _log<sub>2</sub>(n)_ levels, each requiring one 20-byte hash for proving the branch not taken (plus possible metadata for the level). We can express a proof in a tree of 1 million elements in something around 400 bytes. If we further store all IBC messages in a separate subtree, we should expect the count of nodes in this tree to be a few thousand, and require less than 400 bytes, even for blockchains with a quite large state.
|
||||
|
||||
See [binary format as protobuf specification](./protobuf/merkle.proto)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## 2 Proofs
|
||||
## 2 Connections
|
||||
|
||||
([Back to table of contents](README.md#contents))
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ The basis of IBC is the ability to verify in the on-chain consensus ruleset of c
|
|||
|
||||
Note that of all these, only _H<sub>h</sub>_ defines a signature and is thus attributable.
|
||||
|
||||
### 2.2 Basics
|
||||
### 2.2 Requirements
|
||||
|
||||
To facilitate an IBC connection, the two blockchains must provide the following proofs:
|
||||
|
||||
|
|
@ -32,15 +32,17 @@ The merkle proof _M<sub>k,v,h</sub>_ is a well-defined concept in the blockchain
|
|||
|
||||
_valid(H<sub>h </sub>,M<sub>k,v,h </sub>)_ ⇒ _[true | false]_
|
||||
|
||||
### 2.3 Establishing a Root of Trust
|
||||
### 2.3 Connection Lifecycle
|
||||
|
||||
#### 2.3.1 Opening a Connection
|
||||
|
||||
All proofs require an initial _H<sub>h</sub>_ and _C<sub>h</sub>_ for some _h_, where Δ_(now, H<sub>h</sub>) < P_.
|
||||
|
||||
Any header may be from a malicious chain (e.g. shadowing a real chain state with a fake validator set), so a subjective decision is required before establishing a connection. This can be performed by on-chain governance or a similar decentralized mechanism if desired. Establishing a bidirectional initial root-of-trust between the two blockchains (_A_ to _B_ and _B_ to _A_) is necessary before any IBC packets can be sent.
|
||||
|
||||
### 2.4 Following Block Headers
|
||||
#### 2.3.2 Following Block Headers
|
||||
|
||||
We define two messages _U<sub>h</sub>_ and _X<sub>h</sub>_, which together allow us to securely advance our trust from some known _H<sub>n</sub>_ to some future _H<sub>h</sub>_ where _h > n_. Some implementations may require that _h = n + 1_ (all headers must be processed in order). IBC implemented on top of Tendermint or similar BFT algorithms requires only that Δ_<sub>vals</sub>(C<sub>n</sub>, C<sub>h</sub> ) < ⅓_ (each step must have a change of less than one-third of the validator set)[[4](./footnotes.md#4)].
|
||||
We define two messages _U<sub>h</sub>_ and _X<sub>h</sub>_, which together allow us to securely advance our trust from some known _H<sub>n</sub>_ to some future _H<sub>h</sub>_ where _h > n_. Some implementations may require that _h = n + 1_ (all headers must be processed in order). IBC implemented on top of Tendermint or similar BFT algorithms requires only that Δ_<sub>vals</sub>(C<sub>n</sub>, C<sub>h</sub> ) < ⅓_ (each step must have a change of less than one-third of the validator set)[[4](./references.md#4)].
|
||||
|
||||
Either requirement is compatible with IBC. However, by supporting proofs where _h_-_n > 1_, we can follow the block headers much more efficiently in situations where the majority of blocks do not include an IBC packet between chains _A_ and _B_, and enable low-bandwidth connections to be implemented at very low cost. If there are packets to relay every block, these two requirements collapse to the same case (every header must be relayed).
|
||||
|
||||
|
|
@ -68,3 +70,7 @@ Define _max(T)_ as _max(h, where H<sub>h</sub>_ ∈ _T)_. For any _T_ with _
|
|||
By induction, there must exist a set of proofs, such that _max(update…(T,...)) = h+n_ for any n.
|
||||
|
||||
Bisection can be used to discover this set of proofs. That is, given _max(T) = n_ and _valid(T, X<sub>h </sub>|<sub> </sub>U<sub>h </sub>) = unknown_, we then try _update(T, X<sub>b </sub>|<sub> </sub>U<sub>b </sub>)_, where _b = (h+n)/2_. The base case is where _valid(T, X<sub>h </sub>|<sub> </sub>U<sub>h </sub>) = true_ and is guaranteed to exist if _h=max(T)+1_.
|
||||
|
||||
#### 2.3.3 Closing a Connection
|
||||
|
||||
{ todo }
|
||||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
The above sections describe a secure messaging protocol that can handle all normal situations between two blockchains. It guarantees that all messages are processed exactly once and in order, and provides a mechanism for non-blocking atomic transactions spanning two blockchains. However, to increase efficiency over millions of messages with many possible failure modes on both sides of the connection, we can extend the protocol. These extensions allow us to clean up the receipt queue to avoid state bloat, as well as more gracefully recover from cases where large numbers of messages are not being relayed, or other failure modes in the remote chain.
|
||||
|
||||
### 4.1 Timeouts
|
||||
### 4.1 Timeouts
|
||||
|
||||
Sometimes it is desirable to have some timeout, an upper limit to how long you will wait for a transaction to be processed before considering it an error. At the same time, this is an obvious attack vector for a double spend, just delaying the relay of the receipt or waiting to send the message in the first place and then relaying it right after the cutoff to take advantage of different local clocks on the two chains.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Now chain A can rollback all transactions that were blocked by this flood of unr
|
|||
|
||||
Note that in order to avoid any possible "double-spend" attacks, the timeout algorithm requires that the destination chain is running and reachable. One can prove nothing in a complete network partition, and must wait to connect; the timeout must be proven on the recipient chain, not simply the absence of a response on the sending chain.
|
||||
|
||||
### 4.2 Clean up
|
||||
### 4.2 Cleanup
|
||||
|
||||
While we clean up the _send queue_ upon getting a receipt, if left to run indefinitely, the _receipt queues_ could grow without limit and create a major storage requirement for the chains. However, we must not delete receipts until they have been proven to be processed by the sending chain, or we lose important information and sacrifice reliability.
|
||||
|
||||
|
|
@ -89,8 +89,7 @@ This allows us to invoke the _IBCcleanup _function to resolve all outstanding me
|
|||
|
||||
|
||||
|
||||
|
||||
### 4.3 Handling Byzantine Failures
|
||||
### 4.3 Handling Byzantine failures
|
||||
|
||||
While every message is guaranteed reliable in the face of malicious nodes or relays, all guarantees break down when the entire blockchain on the other end of the connection exhibits byzantine faults. These can be in two forms: failures of the consensus mechanism (reversing "final" blocks), or failure at the application level (not performing the action defined by the message).
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
([Back to table of contents](README.md#contents))
|
||||
|
||||
### 1.1 Summary
|
||||
|
||||
The IBC protocol creates a mechanism by which two replicated fault-tolerant state machines may pass messages to each other. These messages provide a base layer for the creation of communicating blockchain architecture that overcomes challenges in the scalability and extensibility of computing blockchain environments.
|
||||
|
||||
The IBC protocol assumes that multiple applications are running on their own blockchain with their own state and own logic. Communication is achieved over an ordered message queue primitive, allowing the creation of complex inter-chain processes without trusted third parties.
|
||||
|
|
@ -10,7 +12,7 @@ The message packets are not signed by one psuedonymous account, or even multiple
|
|||
|
||||
In this paper, we define a process of posting block headers and Merkle tree proofs to enable secure verification of individual packets. We then describe how to combine these packets into a messaging queue to guarantee ordered delivery. We then explain how to handle packet receipts (response/error) on the source chain, which enables the creation of asynchronous RPC-like protocols on top of IBC. Finally, we detail some optimizations and how to handle Byzantine blockchains.
|
||||
|
||||
### 1.1 Definitions
|
||||
### 1.2 Definitions
|
||||
|
||||
_Blockchain_ - A replicated fault-tolerant state machine with a distributed consensus algorithm. The smallest unit produced through consensus is a block, which may contain many transactions, each applying some arbitrary mutation to the state.
|
||||
|
||||
|
|
@ -20,9 +22,9 @@ _Finality_ - The guarantee that a given block will not be reverted within some p
|
|||
|
||||
_Attributable_ - Knowledge of the pseudonymous identity which made a statement, whom we can punish with some deduction of value (slashing) if the statement is false. Synonymous with accountability.
|
||||
|
||||
_Unbonding Period_ - Proof-of-stake algorithms need to lock the stake (prevent transfers) for some time to provide a lower bound for the length of a long-range attack [[3](./footnotes.md#3)]. Complete finality is associated with a subset of the proof-of-stake class of consensus algorithms. We assume the proof-of-stake algorithms utilized by the two blockchains have some unbonding period P.
|
||||
_Unbonding Period_ - Proof-of-stake algorithms need to lock the stake (prevent transfers) for some time to provide a lower bound for the length of a long-range attack [[3](./references.md#3)]. Complete finality is associated with a subset of the proof-of-stake class of consensus algorithms. We assume the proof-of-stake algorithms utilized by the two blockchains have some unbonding period P.
|
||||
|
||||
### 1.2 Threat Models
|
||||
### 1.3 Threat Models
|
||||
|
||||
_False statements_ - Any information we receive may be false.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
## 3 Packet Queue
|
||||
## 3 Packets
|
||||
|
||||
([Back to table of contents](README.md#contents))
|
||||
|
||||
|
|
@ -6,7 +6,7 @@ IBC uses an asynchronous message passing model that makes no assumptions about n
|
|||
|
||||
The IBC protocol as defined here is payload-agnostic. The packet receiver on chain _B_ decides how to act upon the incoming message, and may add its own application logic to determine which state transactions to apply (or not). Both chains must only agree that the packet has been received and either accepted or rejected, which is determined independently of any application logic.
|
||||
|
||||
To facilitate building useful application logic, we introduce a reliable messaging queue (hereafter just referred to as a queue) to allow us to guarantee a cross-chain causal ordering[[5](./footnotes.md#5)] of IBC packets. Causal ordering means that if packet _x_ is processed before packet _y_ on chain _A_, packet _x_ must also be processed before packet _y_ on chain _B_. IBC implements a [vector clock](https://en.wikipedia.org/wiki/Vector_clock) for the restricted case of two processes (in our case, blockchains).
|
||||
To facilitate building useful application logic, we introduce a reliable messaging queue (hereafter just referred to as a queue) to allow us to guarantee a cross-chain causal ordering[[5](./references.md#5)] of IBC packets. Causal ordering means that if packet _x_ is processed before packet _y_ on chain _A_, packet _x_ must also be processed before packet _y_ on chain _B_. IBC implements a [vector clock](https://en.wikipedia.org/wiki/Vector_clock) for the restricted case of two processes (in our case, blockchains).
|
||||
|
||||
Formally, given _x_ → _y_ means _x_ is causally before _y_, and chains A and B, and _a_ ⇒ _b_ means _a_ implies _b_:
|
||||
|
||||
|
|
@ -28,7 +28,21 @@ For example, an application may wish to allow a single fungible asset to be tran
|
|||
|
||||
This section provides a high-level specification of the queue interface and a list of the necessary proofs. To implement wire-compatible IBC, chain _A_ and chain _B_ must also use a common encoding format. An example binary encoding format can be found in Appendix C.
|
||||
|
||||
### 3.1 Queue Specification
|
||||
### 3.1 Definitions
|
||||
|
||||
We introduce the abstraction of an IBC _connection_: a set of the required components to facilitate bidirectional communication between two blockchains _A_ and _B_.
|
||||
|
||||
An IBC connection consists of four distinct queues, two on each chain:
|
||||
|
||||
_Outgoing<sub>A</sub>_: Outgoing IBC packets from chain _A_ to chain _B_, stored on chain _A_
|
||||
|
||||
_Incoming<sub>A</sub>_: Execution logs for incoming IBC packets from chain _B_, stored on chain _A_
|
||||
|
||||
_Outgoing<sub>B</sub>_: Outgoing IBC packets from chain _B_ to chain _A_, stored on chain _B_
|
||||
|
||||
_Incoming<sub>B</sub>_: Execution logs for incoming IBC packets from chain _A_, stored on chain _B_
|
||||
|
||||
### 3.2 Requirements
|
||||
|
||||
A queue can be conceptualized as a slice of an infinite array. Two numerical indices - _q<sub>head</sub>_ and _q<sub>tail</sub>_ - bound the slice, such that for every _index_ where _head <= index < tail_, there is a queue element _q[q<sub>index</sub>]_. Elements can be appended to the tail (end) and removed from the head (beginning). We introduce one further method, _advance_, to facilitate efficient queue cleanup.
|
||||
|
||||
|
|
@ -65,22 +79,6 @@ Each IBC-supporting blockchain must implement a reliable ordered packet queue wi
|
|||
**tail** ⇒ **i**
|
||||
> return _q<sub>tail</sub>_
|
||||
|
||||
### 3.2 Connection Abstraction
|
||||
|
||||
We introduce the abstraction of an IBC **connection**: a set of the required components to facilitate bidirectional communication between two blockchains _A_ and _B_.
|
||||
|
||||
An IBC connection consists of four distinct queues, two on each chain:
|
||||
|
||||
_Outgoing<sub>A</sub>_: Outgoing IBC packets from chain _A_ to chain _B_, stored on chain _A_
|
||||
|
||||
_Incoming<sub>A</sub>_: Execution logs for incoming IBC packets from chain _B_, stored on chain _A_
|
||||
|
||||
_Outgoing<sub>B</sub>_: Outgoing IBC packets from chain _B_ to chain _A_, stored on chain _B_
|
||||
|
||||
_Incoming<sub>B</sub>_: Execution logs for incoming IBC packets from chain _A_, stored on chain _B_
|
||||
|
||||
### 3.3 Merkle Proofs for Queues
|
||||
|
||||
In order to provide the ordering guarantees specified above, each blockchain utilizing the IBC protocol must provide proofs that particular IBC packets have been stored at particular indices in the outgoing packet queue, and particular IBC packet execution results have been stored at particular indices in the incoming packet queue.
|
||||
|
||||
We use the previously-defined Merkle proof _M<sub>k,v,h</sub>_ to provide the requisite proofs. In order to do so, we must define a unique, deterministic key in the Merkle store for each message in the queue:
|
||||
|
|
@ -91,14 +89,9 @@ The index is stored as a fixed-length unsigned integer in big endian format, so
|
|||
|
||||
Once written to the queue, a packet must be immutable (except for deletion when popped from the queue). That is, if a value _v_ is written to a queue, then every valid proof _M<sub>k,v,h </sub>_ must refer to the same _v_. In practice, this means that an IBC implementation must ensure that only the IBC module can write to the IBC subspace of the blockchain's Merkle store. This property is essential to safely process asynchronous messages.
|
||||
|
||||
The queue name must be unambiguously associated with a given connection to another chain, so an observer can prove if a message was intended for chain A or chain B. In order to do so, upon registration of a connection with a remote chain, we create two queues with different names (prefixes).
|
||||
Each incoming & outgoing queue must be provably associated with another uniquely identified chain, so that an observer can prove that a message was intended for that chain and only that chain. This can easily be done by prefixing the queue keys in the Merkle store with a string unique to the other chain, such as the chain identifier or the hash of the genesis block.
|
||||
|
||||
* _ibc:<chain id of A>:send_ - all outgoing packets destined to chain _A_
|
||||
* _ibc:<chain id of A>:receipt_ - the results of executing the packets received from chain _A_
|
||||
|
||||
These two queues have different purposes and store elements of different types. By parsing the key of a merkle proof, a recipient can uniquely identify which queue, if any, this message belongs to. We now define _k =_ _(remote id, [send|receipt], index)_. This tuple is used to route and verify every message, before the contents of the packet are processed by the appropriate application logic.
|
||||
|
||||
### 3.4 Message Contents
|
||||
These two queues have different purposes and store elements of different types. By parsing the key of a Merkle proof, a recipient can uniquely identify which queue, if any, this message belongs to. We now define _k =_ _(remote id, [send|receipt], index)_. This tuple is used to route and verify every message, before the contents of the packet are processed by the appropriate application logic.
|
||||
|
||||
We define every message in a _send queue_ to consist of two fields: an enumerable _type_, and an opaque _payload_. The IBC protocol relies on the type for routing, and lets the appropriate module process the data as it sees fit. The _receipt queue_ stores if it was an error, an optional error code, and an optional return value. We use the same index as the received message, so that the results of _A:q<sub>B.send</sub>[i]_ are stored at _B:q<sub>A.receipt</sub>[i]_. (read: the message at index _i_ in the _send_ queue for chain B as stored on chain A)
|
||||
|
||||
|
|
@ -106,7 +99,7 @@ _V<sub>send</sub> = (type, data)_
|
|||
|
||||
_V<sub>receipt</sub> = (result, [success|error code])_
|
||||
|
||||
### 3.5 Sending a Message
|
||||
### 3.3 Sending a packet
|
||||
|
||||
{ todo: cleanup wording }
|
||||
|
||||
|
|
@ -132,7 +125,7 @@ _A:IBCreceive(S, M<sub>k,v,h</sub>)_ ⇒ _match_
|
|||
|
||||
Note that this requires not only an valid proof, but also that the proper header as well as all prior messages were previously submitted. This returns success upon accepting a proper message, even if the message execution returned an error (which must then be relayed to the sender).
|
||||
|
||||
### 3.6 Receipts
|
||||
### 3.4 Receiving a packet
|
||||
|
||||
{ todo: cleanup logic }
|
||||
|
||||
|
|
@ -157,7 +150,7 @@ This enforces that the receipts are processed in order, to allow some the applic
|
|||
|
||||
|
||||
|
||||
### 3.7 Relay Process
|
||||
### 3.5 Packet relayer
|
||||
|
||||
{ todo: cleanup wording }
|
||||
|
||||
Loading…
Reference in New Issue