The Open Network

party generating a random shared secret and sending it to the other party.
After that, a channel identier is derived from the shared secret combined
with some additional data (such as the sender's and recipient's addresses),
for instance by hashing, and that identier is used as the rst 256 bits of
UDP datagrams carrying data encrypted with the aid of that shared secret.
3.1.6. Channel as a tunnel identier. In general, a channel, or chan-
nel identier simply selects a way of processing an inbound UDP datagram,
known to the receiver. If the channel is the receiver's abstract address, the
processing is done as outlined in 3.1.3 or 3.1.4; if the channel is an estab-
82

---

3.1. Abstract Datagram Network Layer
lished point-to-point channel discussed in 3.1.5, the processing consists in
decrypting the datagram with the aid of the shared secret as explained in
loc. cit., and so on.
In particular, a channel identier can actually select a tunnel, when
the immediate recipient simply forwards the received message to somebody
elsethe actual recipient or another proxy. Some encryption or decryption
steps (reminiscent of onion routing [6] or even garlic routing
31
) might be
done along the way, and another channel identier might be used for re-
encrypted forwarded packets (for example, a peer-to-peer channel could be
employed to forward the packet to the next recipient on the path).
In this way, some support for tunneling and proxyingsomewhat sim-
ilar to that provided by the TOR or I
2
P
projectscan be added on the level
of the TON Abstract Datagram Network Layer, without aecting the func-
tionality of all higher-level TON network protocols, which would be agnostic
of such an addition. This opportunity is exploited by the TON Proxy service
(cf. 4.1.10).
3.1.7. Zero channel and the bootstrap problem. Normally, a TON
ADNL node will have some neighbor table, containing information about
other known nodes, such as their abstract addresses and their preimages (i.e.,
public keys) and their IP addresses and UDP ports. Then it will gradually
extend this table by using information learned from these known nodes as
answers to special queries, and sometimes prune obsolete records.
However, when a TON ADNL node just starts up, it may happen that it
does not know any other node, and can learn only the IP address and UDP
port of a node, but not its abstract address. This happens, for example, if
a light client is not able to access any of the previously cached nodes and
any nodes hardcoded into the software, and must ask the user to enter an IP
address or a DNS domain of a node, to be resolved through DNS.
In this case, the node will send packets to a special zero channel of the
node in question. This does not require knowledge of the recipient's public
key (but the message should still contain the sender's identity and signature),
so the message is transferred without encryption. It should be normally used
only to obtain an identity (maybe a one-time identity created especially for
this purpose) of the receiver, and then to start communicating in a safer way.
Once at least one node is known, it is easy to populate the neighbor
table and routing table by more entries, learning them from answers to
31
https://geti2p.net/en/docs/how/garlic-routing
83

---

3.2. TON DHT: Kademlia-like Distributed Hash Table
special queries sent to the already known nodes.
Not all nodes are required to process datagrams sent to the zero channel,
but those used to bootstrap light clients should support this feature.
3.1.8. TCP-like stream protocol over ADNL. The ADNL, being an un-
reliable (small-size) datagram protocol based on 256-bit abstract addresses,
can be used as a base for more sophisticated network protocols. One can
build, for example, a TCP-like stream protocol, using ADNL as an abstract
replacement for IP. However, most components of the TON Project do not
need such a stream protocol.
3.1.9. RLDP, or Reliable Large Datagram Protocol over ADNL. A
reliable arbitrary-size datagram protocol built upon the ADNL, called RLDP,
is used instead of a TCP-like protocol. This reliable datagram protocol can
be employed, for instance, to send RPC queries to remote hosts and receive
answers from them (cf. 4.1.5).
3.2 TON DHT: Kademlia-like Distributed Hash Table
The TON Distributed Hash Table (DHT) plays a crucial role in the net-
working part of the TON Project, being used to locate other nodes in the
network. For example, a client wanting to commit a transaction into a shard-
chain might want to nd a validator or a collator of that shardchain, or at
least some node that might relay the client's transaction to a collator. This
can be done by looking up a special key in the TON DHT. Another impor-
tant application of the TON DHT is that it can be used to quickly populate
a new node's neighbor table (cf. 3.1.7), simply by looking up a random key,
or the new node's address. If a node uses proxying and tunneling for its in-
bound datagrams, it publishes the tunnel identier and its entry point (e.g.,
IP address and UDP port) in the TON DHT; then all nodes wishing to send
datagrams to that node will obtain this contact information from the DHT
rst.
The TON DHT is a member of the family of Kademlia-like distributed
hash tables [10].
3.2.1. Keys of the TON DHT. The keys of the TON DHT are simply 256-
bit integers. In most cases, they are computed as sha256 of a TL-serialized
object (cf. 2.2.5), called preimage of the key, or key description. In some
cases, the abstract addresses of the TON Network nodes (cf. 3.1.1) can also
84

---

3.2. TON DHT: Kademlia-like Distributed Hash Table
be used as keys of the TON DHT, because they are also 256-bit, and they are
also hashes of TL-serialized objects. For example, if a node is not afraid of
publishing its IP address, it can be found by anybody who knows its abstract
address by simply looking up that address as a key in the DHT.
3.2.2. Values of the DHT. The values assigned to these 256-bit keys are
essentially arbitrary byte strings of limited length. The interpretation of
such byte strings is determined by the preimage of the corresponding key; it
is usually known both by the node that looks up the key, and by the node
that stores the key.
3.2.3. Nodes of the DHT. Semi-permanent network identities. The
key-value mapping of the TON DHT is kept on the nodes of the DHT
essentially, all members of the TON Network. To this end, any node of the
TON Network (perhaps with the exception of some very light nodes), apart
from any number of ephemeral and permanent abstract addresses described
in 3.1.1, has at least one semi-permanent address, which identies it as a
member of the TON DHT. This semi-permanent or DHT address should not
to be changed too often, otherwise other nodes would be unable to locate the
keys they are looking for. If a node does not want to reveal its true identity,
it generates a separate abstract address to be used only for the purpose of