Get desktop application:
View/edit binary Protocol Buffers messages
Branch will hash data and then pass it through operations from first to last in order to calculate the root node. Visualize Branch as representing the data closest to root as the first item, and the leaf as the last item.
Used in:
if either are non-empty, enforce this prefix on all leaf/inner nodes to provide second preimage resistence
this is the data to get the original hash, and a set of operations to calculate the root hash
Data is the end value stored, used to generate the initial hash store
Used in:
optional prefix allows second preimage resistance
If it is KeyValue, this is the data we want If it is SubTree, key is name of the tree, value is root hash
Used in:
HashOp is the hashing algorithm we use at each level
Used in: ,
IBCPacket sends a proven key/value pair from an IBCQueue. Depending on the type of message, we require a certain type of key (MessageKey at a given height, or StateKey). Includes src_chain and src_height to look up the proper header to verify the merkle proof.
chain id it is coming from
height for the header the proof belongs to
the proof of the message, includes key and value
the message type, which determines what key/value mean
Used in:
TODO: root, height, chain_id, etc...
Used in:
branches start from the value, and then may include multiple subtree branches to embed it The first branch must have dataType KeyValue Following branches must have dataType SubTree
MessageKey is the key for message *index* in a given queue
Op represents one hash in a chain of hashes. An operation takes the output of the last level and returns a hash for the next level: Op(last) => Operation(prefix + last + sufix) A simple left/right hash would simply set prefix=left or suffix=right and leave the other blank. However, one could also represent the a Patricia trie proof by setting prefix to the rlp encoding of all nodes before the branch we select, and suffix to all those after the one we select.
Used in:
Used in: ,
chain_id is which chain this queue is associated with
Used in:
ReceiptValue is stored under a MessageKey in the RECEIPT queue
0 is success, others are application-defined errors
contains result on success, optional info on error
SendValue is stored under a MessageKey in the SEND queue
use kind instead of type to avoid keyword conflict
StateKey is a key for the head/tail of a given queue
both encode into one byte with varint encoding never clash with 8 byte message indexes
Used in:
StateValue is the type stored under a StateKey