Cryptocurrencies first emerged in 2008, with the introduction of Bitcoin by Satoshi Nakamoto. The idea to create a distributed, decentralized network of payments was revolutionary, and quickly began picking up both followers and investors. Fear of this new unknown and its potential to disrupt existing financial systems sparked massive regulation in many countries, such as the US, while others, such as Russia, widely accepted the new system. Soon other developers followed Satoshi, creating the currencies now known as Ethereum, XRP and others. Many compare the cryptocurrency revolution to the early days of the internet, and envision massive adoption and use by the majority of the population in the future.

Cryptocurrency - what is the problem?

The benefits of cryptocurrencies are clear: we wish to create a payment method that removes the middleman (mostly banks), allowing us to process immediate and secure transactions. For that matter all cryptocurrencies implement a ledger. The ledger is maintained mostly by miners who trade computing power for a commission. This approach grants cryptocurrencies secure and trustworthy transactions, while introducing their biggest problem when it comes to scaling.

Handling the ledger requires significant computing power. Bitcoin manages 8 transactions per second, and Bitcoin cash manages a little over 60. This does not even come close to touching the staggering 24,000 transactions per second offered by larger, more established providers like Visa. This discrepancy is due to the time it takes a miner to calculate a cryptographic hash needed for the ledger to act as a public securely distributed registry for transactions.

PCN - Today’s Answer to the scale issue

Making fast payments at scale remains a challenge. In recent years we experienced the adoption of a new technology, sitting as a layer on top of the ledger (for example on top of Bitcoin’s Blockchain). This technology is called Payment Channel Networks (PCNs). One of the big names in this technology is the Lightning Network. This technology is designed to make the ledger more scalable, allowing peer to peer infinite transaction flow with restrictions set by the connection between them. For example, payments must be routed on paths with sufficient funds, and funds cannot be added like bandwidth on a standard connection, without reestablishing the channel with fresh funds. As payments flow over a single channel (link) in the same direction, the channel eventually becomes depleted and cannot support further payments in that direction.

Let us say I’m node A and I wish to transfer 5 coins to node B, with whom I have established a PCN, where each of us have inserted 5 coins.

After the transfer is completed the network would look like this:

Now, if I wish to transfer B more funds, the network will act as a bottleneck, and the PCN will have to be closed, write the current balance to Blockchain, and will only reopen with sufficient funds to accommodate the new transfer. Such balanced transfer rates will lead to migration of similar funds from side to side, allowing the network to support transactions indefinitely. Unfortunately, this is very far removed from realistic real world situations.

If we look at a more elaborate network, having every edge represent a PCN, where nodes can transfer funds to any other node in a route crossing multiple PCNs, then each of these edges can become a bottleneck stopping payments attempting to go through that route.

Let’s assume I’m the green node and I wish to transfer 10 coins to the blue node. If I use shortest path routing, I have two options, both with distance of two hops. However, neither will support the transaction, since the second PCN on both paths cannot support 10 coins being passed.

Why is it not good enough?

Many studies in recent years have tried to approach this problem with algorithms designed to create a balanced network, trying to maximize the number of transactions before writing to the ledger is inevitable. These solutions must tackle finding the most efficient routes, load balancing and splitting payments, keeping the network balanced and supporting the maximum possible number of transactions. We see implementations of shortest path routing, Landmark routing, Waterfilling and so on. Load balancing and splitting payments are introduced in more recent studies, making the network even more balanced and dynamic.

The most state of the art solutions we have today can achieve an average of 7-8 transactions before writing to the ledger. This is due to the fact that real world payments are done asymmetrically, making the network inherently unbalanced. Reaching 24,000 transactions per second rate seems a very difficult task indeed.

So what can we do to maximize network efficiency?

If we look 20 years back, downloading files was done via a single server, and also didn’t scale. Then along came BitTorrent, which offered a new solution. If we try to combine similar aspects of these two ideas, we can create a layer on top of PCN, where people who owe money will be “seeds” and people who own money will be “peers”, having the network hold a balance for each person.

Positive balance correlates to owing money, hence I should accept payment requests sent to me by people who are waiting for payments according to my balance. Negative balance correlates to having money, hence I will “look” for nearby payers, and send them payment requests. Atomicity of intertwined payments is important here to allow reliability. Taking a lazy approach of transaction fulfilment means that after a specified amount of time, I would have made some amount of transactions, changing my balance periodically. Many payments may cancel each other out, and in the worst case scenario, I would end up using the same direct transaction pathway as the original system, but with the added time of having search for a payer.

Payers Broadcast an LSA-like message, stating their status to enable the creation of a payment network.

Node A (upper left) sends an LSA-like message with its information and amount offered. Every node receiving this message would add this information to the network topology it holds. Once node B (upper right) asks for payment, it knows node A offers 10 coins and would be able to send the request (locking and response mechanisms are required here and are not discussed).

Node B (blue node) sends a request message for payment of 5 coins, distributing it through the network to nearest payers (green nodes) he recognizes through the topology he built for himself.

I believe an approach which creates a topology much like BitTorrent, which benefits from lazy transaction fulfilment and secures a balance stating each node’s status on the network, will minimize the required writing to the ledger while maintaining a relatively balanced network. Instead of looking at each payment separately, for example a transaction from A to B, look at a group of intertwined transactions that are being executed simultaneously and periodically. This also employs the distributed approach mechanism – every user can transfer or receive money from every other user, changing their balance accordingly, while the actual funds seem like they’re flowing from A to B, having the network do the heavy lifting of fulfilling the payment in a distributed way behind the scenes. No user balance can be changed from positive to negative and vice versa (having 0 be a limit that shall not be passed), unless the user is the initiator of a transaction (for example by applying a new transaction – having to pay someone and changing its own balance accordingly).


The advantages of this new system are clear – transactions can be made in a lazy approach, saving computing time and allowing a significant number of transactions to be executed at once, potentially canceling each other out. Writing to the ledger will be done much less often, thereby resolving one of the biggest problems with our current system. With that being said, the challenge to keep a secure intertwined payment network, allowing safe parallel payments, plus the added price of creating an extra layer on top of PCN,  is demanding. Further research is needed to assess whether these new burdens are worthwhile, and whether this new system could be the key to surpassing Visa's 24,000 transaction rate.

Article submitted by Ben Goldschmidt

Find him at