On-chain or Off-chain?
This question will be at the core of future software engineering.
Just a few days ago the Raiden Network blessed us with the developer preview for their state channel implementation. This technology is super exciting and one of several important projects that bring scalability solutions to Ethereum. Raiden does this in particular by offloading on-chain transactions and giving folks the tools to communicate off-chain. While these words may sound complex to you I promise that 80%+ of the complexity here has been undertaken by the Raiden team. Major kuddos to them! To explain this on-chain/off-chain paradigm, as well as the tradeoffs, I’ll break down the concepts of state and give an explanation of how the Raiden network gives us an example of off-chain benefits. So let’s start by talking about the reason blockchain technology itself is important.
Universal Acceptance of State
If you’re tired of reading about and/or understand this concept already please skip this section, I personally love it too much to not talk about it.
Blockchains provide us with Distributed Ledger Technology (DLT). This term is easier to understand if we break those words down a little.
Distributed
A distributed system is one that shares all of its information with any one participant and without regard for who, everyone is an equal participant. In addition, every participant is able to access all information, and able is an important distinction because not every participant needs all of the information but it’s there whenever they want it. A fully distributed system then is one that has a transparent network protocol which gives every participant a high degree of confidence that all information has been made available. Read that three times then wiggle your nose.
Ledger
Ledgers are much easier to understand because we’ve been using them in one way, shape, or form, since our species began writing. Ledgers are nothing more than a record of what is… or state. Hopefully, if you haven’t already, you can wrap your head around the concept of state with these few sentences. An accounting ledger, for instance, keeps track of where money is allocated, the state of money.
If you look at your bank account balance and see $1 then the state, or location, of that value is in your bank account.
Says who?
Well, the bank.
Who told the bank?
Whichever person or organization sent a message, either electronically through a direct transfer or through a signed check or handing over a government backed bill, to the bank saying that $1 is yours.
How does the bank know the state of that $1 is in that other person or organization’s ownership in the first place?
Because the physical (check) or electronic (direct transfer) message is backed by another bank or institution your bank trusts.
How does the bank….
let’s stop there.
Distributed Ledger Technology
At this point you can see that there is a lot of trust between a number of people and organizations that make traditional accounting ledgers work. So what happens when you have value outside of this traditional network of trusted “nodes” so to speak? Generally it’s worthless until you bring it in to the network. Skills, for instance, are worthless unless you generate currency with them. This not only requires that you have access to a trusted network, but also that you access the specific network that will adequately recognize the value you wish to trade. Is all of this trust necessary though?
If we recall our distributed system from earlier, we’re reminded that this system provides every participant a high degree of confidence that all information has been made available. Well, if ALL information has been made availabe, then you no longer NEED a trusted “node” to keep track of the ledger. The same ledger exists in every node, including yours, and every other single node is confident in the fact they also have the ledger. Therefore, you have a universal acceptance of state.
Final Authority
Now that we’re confident in our ability to have all information available in this distributed system we can be confident in the changes handed to us. Anytime a participant wants to change something it will go through every single one of us and we’ll all agree to the change through the stated protocol. Think of our agreement as the final authority. This sounds great but presents one small problem; sending every single change to every single participant requires every single participant to record every single change. This process has a limit, even in the digital world.
To solve this problem we need to think about what we use as a final authority in our conventional, trusted framework. When we make big moves with our assets such as buying a house, buying a car, or signing some major agreement, we have an unbiased third party witness of some sort, like a notary. This mechanism provides you and your counter-party a high degree of confidence that the trusted network will recognize this change of state.
When we go to the grocery store though, or buy food at a restaraunt, do we have a notary following us around? How often do we actually use the third party mechanism in a trusted network? Not very often, because it’d immediately become very expensive and cumbersome. Our final authority for our day to day transfers is simply… a signature.
If sending changes to a distributed system is equivalent to a third party witness, then what is the equivalent to sending changes with just a signature? The answer is off-chain transactions.
Private keys and off-chain deals
Now you may be asking, if we send transactions off chain, how do the other people verify I sent a valid transaction without using the blockchain? I thought the whole crux of the distributed system is that everyone has access to all information? Without that you don’t have a suitable value-tracking system right?
It’s not that this logic is wrong, it’s just that we have to look at the whole thing through a different lens. One element we didn’t go into detail over yet is how the nodes in a distributed system know they’ve received a valid change request, or to put it differently, a valid transaction.
The process of creating a valid transaction involves cryptography using public/private key pairs. This is where we get the name cryptocurrency. To put it simply, in the cryptographic scheme used by blockchains, every public key has exactly one matching private key and vice versa. We use the public key as our public address in this system and the private key as our unique signature that no one knows, hence private. In addition, any transaction “signed” by a private key is proven to be sent by the associated public address.
Hopefully that short explanation is enough to give you an understanding of how we create transactions without even using the blockchain. The process of creating a valid transaction is independent of using the blockchain to record that transaction. So what does that do for us? How do we change the final authority mechanism in a distributed system to reduce the workload and increase scalability in this way?
Tying it together
We now have the learning blocks in place to build upon our understanding of state channels and a project like the Raiden network. One thing we learned in the previous section is that we can actually create a transaction that WILL change the state in our distributed ledger IF we sent it. In addition, two sections ago we learned that sending all changes to the blockchain for a final authority approval is cumbersome and akin to having a notary follow us around all day errday. (Errday was purposeful there because it’s funny.)
So, now that the wheels are turning, let’s put together a scalable solution to the blockchain bottleneck. If you know how bank checks work then this should be easy, if I have somehow crossed a generational boundary by mentioning checks and you don’t know how they work then you should follow this wikipedia link that will explain checks. (Which is also funny to me.)
Say you want to send some asset tokenized on the Ethereum network to another party. By tokenized I mean you have successfully represented your asset on Ethereum, today it’s ERC20 tokens and tomorrow it’s a better mechanism. This other party is also in tune to this revolutionary DLT and is therefore willing to accept your asset as a token. You know there will be several trades back and forth regarding this asset and would like to both reduce transaction cost so as to not pay gas on the main network for every trade and you also want to do it rapidly to avoid the blockchain bottleneck. How do we make this work?
The Raiden network’s state channels allow you to capture the state of your asset from Ethereum’s main network by “depositing” it in a direct channel with your counter-party. This network understands the underlying cryptographic functions that verify transactions signed by your private key. Since we know that posting changes to the blockchain is a separate process from sending verifiable changes, you can send a signed transaction without posting it to the main network. This is just like sending a signed check that can’t bounce, it’s not the actual asset being passed on the main network, it’s a verifiable representation of your intent to transfer this asset.
Your counter-party, who has agreed to the initial state of this asset by entering the state channel with you, now has a signed transaction that WILL move this asset should the change be posted to the main network. Knowing that all information on the blockchain is available, and possessing a signed transaction from your trading partner, provides the necessary confidence that you can now proceed as if the state change has actually occurred on the main network. The ability to do this is repeatable, millions of times, without ever talking to the blockchain.
What’s the catch?
If I sent and received checks from you, what is my incentive? Throwing all trust and ethics aside, my incentive is to keep all of the transactions that show you sent me assets and toss all of the ones where I sent you assets. In true game theory form however, you have the same exact incentive. The risk lies in the ability for both parties to post the final state to the final authority… Ethereum mainnet.
Currently Raiden’s developer tool allows for a settlement timeout period that can be defined when opening a network channel. When one party chooses to close out, the other party has the settlement timeout window to also finalize and close from their end. At that point the final state goes to the final authority.
This only scratches a very thin top layer of the surface. This says nothing abount trading among other parties indirectly connected to you throughout the network as well as how this will impact state changes well beyond tokens. Majoolr is actively designing with Raiden as yet another tool in our soon to be delivered toolbox. If you need security consultation, reviews, or smart contracts then reach out to us or our partners. Just like Ethereum itself, Raiden is only the beginning of a beautiful technological revolution.
