State Channels for Dummies: Part 3
Multi-Hop Transactions / Hub-and-Spoke Channels
Before we get started, if you have not read my first article on payment channels — Counterfactual for Dummies: Part 1 — Payment Channels, you should definitely give it a look over as we’re going to be building on what we learned there. For those interested, here’s a demo and implementation of a one-way payment channel using Metamask and IPFS Pubsub.
The payment channels framework outlined in the previous article pertains to one-way and bi-directional payment between two parties where the only way to transact with someone is to open a channel directly to them. At scale, a picture of all the channels ever opened would look something like this:
Now, while this might be beautiful and geometric, it is highly highly inefficient - we can do better.
Routed Payment Channels
Enter routed networks, where everyone can transact with one another through a common connections (mediators). This leaves us with much fewer needed connections in our network:
And this is great, because we don’t have to eat the cost of opening and closing all of those channels between our peers on-chain. We simply have longer-lived channels that we can leverage throughout the network that we can let others leverage while collecting fees. One thing to note is that in order to create a route between two nodes — there must be a path in which each node has at least as much staked in their channel as the amount being transferred. Here is an example of a valid and invalid route between two nodes (A, E) who want to transmit 3 ETH in the above network.
Now, one can make the argument that the fees might exceed the cost of having a direct connection to another member of the network — if this is the case, there will be new nodes that come online to fill that gap so that they may capitalize on this fact. As time goes on, the network will self-optimize based on the most cost-effective paths, encouraging lower fees.
Now this routing is certainly an improvement, but how do we make sure that the guy in the middle doesn’t steal all the money that we’re asking him to forward to the other people he knows? An accepted way of doing this is by using a mechanism known as a ‘hashlock’, these will sometimes be abbreviated as ‘HLC’ or ‘HTLC’.
Hashlocks
Let’s take the simple example where Jerry want to send 1 ETH to Kramer, but Newman is their only common connection in the payment network. In this scenario, we are performing a ‘mediated transfer’ where Jerry is the ‘initiator’ and Kramer is the ‘target’.
If you already know what a hash is, skip this paragraph. For those not familiar, a hashing function is not like encryption — when you hash something, you cannot get the thing hashed or the ‘pre-image’ back from the hashed value. Hashing functions are one-way — you can get the same hash from the same ‘pre-image’, which makes it suitable for comparing files to see if they are identical. A morbid example people often give is comparing hashing to turning a cow into a burger — you can get to the burger from the cow, but you cannot reconstruct the cow from the burger. On that note, feel free to learn more about SHA256 hashes here!
To facilitate this mediated transfer, the following steps would take place [taken from Bitcoin Wiki]:
- Kramer generates a random number and generates its SHA256 hash. Kramer gives that hash to Jerry.
- Jerry uses his payment channel to Newman to pay him 1 ETH, but he adds the hash Kramer gave him to the payment along with an extra condition: in order for Newman to claim the payment, he has to provide the data which was used to produce that hash.
- Newman uses his payment channel to Kramer to pay Kramer 1 ETH, and Newman adds a copy of the same condition that Jerry put on the payment he gave Newman.
- Kramer has the original data that was used to produce the hash (called a pre-image), so Kramer can use it to finalize his payment and fully receive the payment from Newman. By doing so, Kramer necessarily makes the pre-image available to Newman (because Kramer’s payment is dependent on Newman getting paid by Jerry).
- Newman uses the pre-image to finalize his payment from Jerry.
tl;dr — Jerry gives Newman an IOU and Newman gives Kramer an IOU which is contingent on Jerry’s IOU being fulfilled. Basically, we make this chain of IOUs and walk it back from the target to the initiator whence the payment is then transmitted through the network.
So, these ‘hashlocks’ enable an initiator to send funds to a target through one or more mediators with a series of forward-looking promises. Once the series of forward promises has been created and the initiator has paid, the money will make its way through the network to the target. This is roughly how the Bitcoin Lightning Network functions at this time.
Note: For purposes of the example, there are no transaction fees here that are being awarded to Newman for serving as the intermediary. This is an implementation detail which can be included with each transaction along the chain of mediators based upon the fees they are interested in collecting.
As these networks grow, we can expect there to be nodes which are more popular than others that can support more valuable transactions across their channels. An apt analogy would be traveling between your house and a friend’s:
- Start on your neighborhood street (small # vehicles, slow)
- Get on a major road (medium # vehicles, fast)
- Get on a highway (high # vehicles, fastest)
- Get off onto another major road (medium # vehicles, fast)
- End on your friend’s neighborhood street (small # vehicles, slow)
And it is a similar sort of behavior that will encourage the formation of what we refer to as ‘Hub-and-Spoke’ networks.
Hub-and-Spoke Payment Channels
In a Hub-and-Spoke network, everyone can transact with one another through a common connection (hub). This leaves us with a much cleaner looking network from our simple routed network:
People will often dissent to the idea of hub-and-spoke networks, claiming that they are centralized. This is certainly true in the case where you can’t circumvent the hub and are beholden to them, but in this network you can open channels to other nodes or alternative hubs at any time —providing optionality in the network. And these networks will evolve in such a fashion where there will be a number of hubs throughout the network:
This development of hub-and-spoke networks for payments channels is currently underway by SpankChain, Nathan Ginnever (Finality Labs), and Arjun Bhuptani (Connext).
Part 4: Virtual Channels
Those listed above are enabling this sort of network with what are known as ‘Virtual Channels’. We’ll be diving in to Virtual Channels in part four of this series, so stay tuned!
In the meantime, if you have any projects leveraging state channels, I’d love to see your implementation and how you’re approaching things. And if there’s something about this that I can improve, please don’t hesitate to let me know in the comments section, here. Lastly, if you’ve gained something from this article, I am but a social media noob and would greatly appreciate you sharing this to your network. Here’s the link to do so:
https://medium.com/@eolszewski/state-channels-for-dummies-part-3-10b25f6c08b
Further Reading
- Raiden’s Documentation
- Connext’s Documentation
- Finality Labs’ Paper on “Hub-and-Spoke Cryptographic Payment Channels”
Special thanks to Nathan Ginnever and the Connext team for chatting with me about what they are doing in this space!
