This document is the specification for the sub-protocol that supports on-demand availability of the index necessary for clients to lookup transactions by their hash.
The canonical transaction index network is a Kademlia DHT that uses the Portal Wire Protocol to establish an overlay network on top of the Discovery v5 protocol.
The canonical transaction index consists of a mapping from transaction hash to the canonical block hash within which the transaction was included and the index of the transaction within the set of transactions executed within that block.
- Transaction Index Entry
- Transaction index entries can be retrieved by transaction hash.
The canonical transaction index network uses the stock XOR distance metric defined in the portal wire protocol specification.
The canonical transaction index network uses the SHA256 Content ID derivation function from the portal wire protocol specification.
The Portal wire protocol is used as wire protocol for the canonical transaction index network.
As specified in the Protocol identifiers section of the Portal wire protocol, the protocol
field in the TALKREQ
message MUST contain the value of 0x500D
.
The canonical transaction index network supports the following protocol messages:
Ping
-Pong
Find Nodes
-Nodes
Find Content
-Found Content
Offer
-Accept
In the canonical transaction index network the custom_payload
field of the Ping
and Pong
messages. The first packet between another client MUST be Type 0: Client Info, Radius, and Capabilities Payload. Then upgraded to the latest payload supported by both of the clients.
List of currently supported payloads, by latest to oldest.
The canonical transaction index network uses the standard routing table structure from the Portal Wire Protocol.
The canonical transaction index network includes one additional piece of node state that should be tracked. Nodes must track the data_radius
from the Ping and Pong messages for other nodes in the network. This value is a 256 bit integer and represents the data that a node is "interested" in. We define the following function to determine whether node in the network should be interested in a piece of content.
interested(node, content) = distance(node.id, content.id) <= node.radius
A node is expected to maintain radius
information for each node in its local node table. A node's radius
value may fluctuate as the contents of its local key-value store change.
A node should track their own radius value and provide this value in all Ping or Pong messages it sends to other nodes.
transaction_index_key := Container(transaction-hash: Bytes32)
selector := 0x00
content_key := selector + SSZ.encode(transaction_index_key)
content := TODO: block hash & merkle proof against header.transactions_trie