The Open Network

parties who expect a lot of money transfers between them. However, if one
needs to transfer money only once or twice to a particular recipient, creating
a payment channel with her would be impractical. Among other things, this
would imply freezing a signicant amount of money in the payment channel,
and would require at least two blockchain transactions anyway.
5.2.2. Payment channel networks, or lightning networks. Payment
channel networks overcome the limitations of payment channels by enabling
money transfers along chains of payment channels. If A wants to transfer
money to E, she does not need to establish a payment channel with E. It
would be sucient to have a chain of payment channels linking A with E
through several intermediate nodessay, four payment channels: from A to
B
, from B to C, from C to D and from D to E.
5.2.3. Overview of payment channel networks. Recall that a payment
channel network, known also as a lightning network, consists of a collection
of participating nodes, some of which have established long-lived payment
channels between them. We will see in a moment that these payment channels
will have to be smart in the sense of 5.1.7. When a participating node A
wants to transfer money to any other participating node E, she tries to nd
a path linking A to E inside the payment channel network. When such a
path is found, she performs a chain money transfer along this path.
118

---

5.2. Payment Channel Network, or Lightning Network
5.2.4. Chain money transfers. Suppose that there is a chain of payment
channels from A to B, from B to C, from C to D, and from D to E. Suppose,
further, that A wants to transfer x coins to E.
A simplistic approach would be to transfer x coins to B along the existing
payment channel, and ask him to forward the money further to C. However,
it is not evident why B would not simply take the money for himself. There-
fore, one must employ a more sophisticated approach, not requiring all parties
involved to trust each other.
This can be achieved as follows. A generates a large random number u
and computes its hash v = Hash(u). Then she creates a promise to pay
x
coins to B if a number u with hash v is presented (cf. 5.1.7), inside her
payment channel with B. This promise contains v, but not u, which is still
kept secret.
After that, B creates a similar promise to C in their payment channel. He
is not afraid to give such a promise, because he is aware of the existence of a
similar promise given to him by A. If C ever presents a solution of the hash
problem to collect x coins promised by B, then B will immediately submit
this solution to A to collect x coins from A.
Then similar promises of C to D and of D to E are created. When
the promises are all in place, A triggers the transfer by communicating the
solution u to all parties involvedor just to E.
Some minor details are omitted in this description. For example, these
promises must have dierent expiration times, and the amount promised
might slightly dier along the chain (B might promise only x −  coins to
C
, where  is a small pre-agreed transit fee). We ignore such details for the
time being, because they are not too relevant for understanding how payment
channels work and how they can be implemented in TON.
5.2.5. Virtual payment channels inside a chain of payment channels.
Now suppose that A and E expect to make a lot of payments to each other.
They might create a new payment channel between them in the blockchain,
but this would still be quite expensive, because some funds would be locked in
this payment channel. Another option would be to use chain money transfers
described in 5.2.4 for each payment. However, this would involve a lot of
network activity and a lot of transactions in the virtual blockchains of all
payment channels involved.
An alternative is to create a virtual payment channel inside the chain
linking A to E in the payment channel network. For this, A and E create
119

---

5.2. Payment Channel Network, or Lightning Network
a (virtual) blockchain for their payments, as if they were going to create a
payment channel in the blockchain. However, instead of creating a payment
channel smart contract in the blockchain, they ask all intermediate payment
channelsthose linking A to B, B to C, etc.to create simple payment
channels inside them, bound to the virtual blockchain created by A and E
(cf. 5.1.10). In other words, now a promise to transfer money according
to the nal settlement between A and E exists inside every intermediate
payment channel.
If the virtual payment channel is unidirectional, such promises can be
implemented quite easily, because the nal imbalance δ is going to be non-
positive, so simple payment channels can be created inside intermediate pay-
ment channels in the same order as described in 5.2.4. Their expiration
times can also be set in the same way.
If the virtual payment channel is bidirectional, the situation is slightly
more complicated. In that case, one should split the promise to transfer δ
coins according to the nal settlement into two half-promises, as explained
in 5.1.10: to transfer δ
−
= max(0, −δ)
coins in the forward direction, and to
transfer δ
+
= max(0, δ)
in the backward direction. These half-promises can
be created in the intermediate payment channels independently, one chain
of half-promises in the direction from A to E, and the other chain in the
opposite direction.
5.2.6. Finding paths in the lightning network. One point remains
undiscussed so far: how will A and E nd a path connecting them in the
payment network? If the payment network is not too large, an OSPF-like
protocol can be used: all nodes of the payment network create an overlay
network (cf. 3.3.17), and then every node propagates all available link (i.e.,