[ad_1]
Many readers by now have seen our coding tutorials on how to code your own blockchain, how to code your own proof of work, and how to set up a P2P network. After reading these tutorials, there you are, confident in your blockchain mastery and eager to tell everyone all about your newfound knowledge at your next meetup!
But then you walk up to the water cooler and hear a conversation like this:
“Payment channels are the next big thing!”
“I’m pretty skeptical of the Bitcoin Lightning Network. While payment channels sound great in concept, how on earth are they going to solve the traveling salesman problem at that kind of network scale? Side chains are where it’s at!”
“You might be right. State channels are pretty cool. Maintaining turing completeness on both the main and side chains gives a lot of functionality and scaling flexibility.”
What on earth are they talking about? Don’t worry! We’re going to help you out. In this article, we’ll walk you through all the latest buzz words and concepts in advanced blockchain development, but keep the details at a manageable level.
By the end of this post, you’ll be able to freely participate in conversations like the above. This is not a coding tutorial, as we’ll just be presenting important concepts at a high level. However, we may follow up with programming tutorials on these ideas. This article will be helpful to both programmers and non-programmers alike. Let’s get going!
Here are the ideas we’ll tackle and build on in this article:
- Byzantine fault tolerance
- Smart contracts
- Turing completeness
- Delegated Proof of Stake
- State channels / Side chains
- Plasma
- Payment channels
Byzantine Fault Tolerance
Byzantine fault tolerance (BFT) is what keeps the blockchain fundamentally secure. For simplicity, let’s say there were 100 nodes in a blockchain network (there are currently about 10,500 full Bitcoin nodes in the world). What happens when one node wants to tamper with the latest block and say other Bitcoin users sent him a whole bunch of Bitcoin when they really didn’t?
The system needs to be fault tolerant and be able to override this malicious node and agree on the correct state of the blockchain.
The term originated from the “Byzantine Generals Problem”. Let’s take a quick look at it:
In this scenario, the yellow camps need to coordinate to attack the central enemy city. But they need to agree on a time to attack. To do this, the camps need to clandestinely send messengers through the enemy city to tell another camp when to attack.
Not only does the receiving camp need to receive the message, it needs to send back a messenger so the sending camp knows the receiving camp got the message. The receiving camp needs to know the sending camp got the message acknowledging the receiving camp got the original message. You can see this cycle goes on forever!
Throw in another wrinkle: what if there is a traitor camp that intentionally does not send a messenger, or sends a messenger with the wrong information?
In the days before computers, this “Byzantine Generals Problem” was unsolvable. Luckily today, we have computers and distributed systems. The solution to the Byzantine Generals Problem in blockchain is Proof of Work.
Our Proof of Work tutorial talks about it in depth, but the best explanation might come from Satoshi Nakamoto himself. If the camps above start receiving messages that don’t agree, they rely on executing a Proof of Work. The Proof of Work is sufficiently complicated and requires significant computing power. Once one camp solves the Proof of Work, it broadcasts the results to the other camps. This message is now accepted in a chain of messages and the competing messages are dropped by the other camps.
If the solving camp tampered with the data, the hashed chain would be quickly identified by the other camps as faulty and rejected in favor of the next solving camp. This provides a disincentive for the initial camp to cheat, since they will have wasted a bunch of energy to solve the Proof of Work and gotten no benefit from it.
Imagine over several hours, the camps produced a chain of messages that each required intensive Proof of Work. This means that the majority of the camps had to agree on this chain of messages and each camp can confidently trust the final outcome. It’s important to note here that Proof of Work does not care about the message itself, only that the nodes agreed to the final message. This majority network consensus keeps it secure and provides a solution to the Byzantine Generals Problem, leading to Byzantine Fault Tolerance.
Smart Contracts & Turing Completeness
Let’s switch gears quickly before we get back to talking about trust mechanisms. We’ll define what a “smart contract” is. The first blockchain that was popularized is obviously the Bitcoin blockchain. But the functionality of Bitcoin is very limited. All it can do is record transaction information. It’s only useful to keep track of the fact that Alice sent Bob 1 Bitcoin.
What if we wanted some richer logic? What if instead of Alice just simply sending Bob 1 Bitcoin, we could program in logic that says “Alice and Bob place a sports bet. If the Cleveland Cavaliers ever lose to the Toronto Raptors in a playoff series, take 1 Bitcoin from Alice’s wallet and transfer it to Bob’s”.
How awesome would that kind of functionality be? We could program in that logic, have it sit on the blockchain and Bob can rest comfortably knowing he can safely place that bet and Alice will be forced to pay the 1 Bitcoin if the Raptors ever beat the Cavs, and Alice can rest comfortably knowing she’ll never have to pay.
This is exactly what Ethereum is. You can think of it as a programmable Bitcoin. Smart contracts are little programming functions that sit on the Ethereum blockchain. You invoke a smart contract by calling the contract (or function) address and the arguments you send it will produce a deterministic result based on the logic of the function.
A sample Ethereum smart contract function looks like this:
function transfer(address _to, uint256 _value) {
require(balanceOf[msg.sender] >= _value && balanceOf[_to] + _value >= balanceOf[_to]);
balanceOf[msg.sender] -= _value;
balanceOf[_to] += _value;
}
This function does a simple check to transfer tokens from Alice to Bob. The function signature takes in Bob’s wallet address and an amount to transfer. The require statement ensures Alice has enough Ether (Ethereum’s currency) to give Bob. Then the function subtracts that amount from Alice’s wallet and adds the same amount to Bob’s wallet.
Pretty straight forward right? This is a smart contract in its simplest form. But there is a world of possibilities for smart contracts from creating healthcare applications (what we do at Coral Health) to making collectible digital asset based games like Cryptokitties.
Turing Completeness
When people say Ethereum is “Turing Complete” it means that a fully featured programming language is available on the Ethereum blockchain. The code we wrote above is written in a language called Solidity, which is the specific smart contract language to Ethereum.
By contrast, the Bitcoin blockchain is not Turing complete since it has little to no ability for data manipulation. It has no ability for a user to deploy if else or goto statements. This is a bit of a simplification but anytime you hear someone say something is “Turing complete” you can do a quick check to see if there is functionality for data changes, memory changes and if/else statements. If there is, that’s usually what they mean.
Now that we’ve tackled a few of these definitions let’s move back to trust considerations of the blockchain.
Delegated Proof of Stake (DPOS)
If you want a deeper look at Proof of Stake check out our detailed POS post. In short, while Proof of Work is an effective mechanism to secure the blockchain and provides a trustless consensus paradigm, it’s extremely energy intensive because of all the computing power required to solve hash problems. Also, while it was meant to be decentralized, it’s actually becoming more centralized as miners consolidate and massive mining setups eat up larger shares of winning blocks.
Delegated Proof of Stake (DPOS) aims to solve this. Initially conceived by Dan Larimer, instead of using hardware to solve hashes, he proposed that people in the network vote for “witnesses”. These witnesses are responsible for keeping the network secure and each of these witnesses puts some amount of digital currency in escrow.
The witnesses who put more funds in escrow have a greater chance of mining (or minting) the next block. The incentives line up nicely here. There are only a few witnesses and they get paid to be witnesses, so they are incentivized to not cheat. If they do cheat and get caught, they not only get voted out in favor of the next eagerly awaiting witness, they lose all the funds they had in escrow.
Many people believe this is the future of the blockchain. It maintains network security and allows for scalability. The biggest criticism is that it heavily favors those with more funds as smaller holders have no chance of becoming witnesses. But the reality is, smaller players have no hope of participating in Proof of Work either, as mining from your own laptop at home is no longer a reality. Smaller players get outcompeted by bigger players who have massive mining rigs. STEEM and EOS are examples of DPOS blockchains. Even Ethereum is moving to POS with its Casper project.
State Channels / Side Chains
So far we’ve been talking about all-or-nothing approaches. Pure decentralization vs. central servers, Proof of Work vs. Proof of Stake. Just like everything else in life, hybrid ideas might be superior to binary ones. Blockchain developers are quickly realizing this.
As we’ve talked about, writing to the blockchain is slow and expensive. This is because every node in the entire network needs to verify and slurp in the whole blockchain and all the data it contains. Executing a large smart contract on a blockchain can be prohibitively expensive, and doing things like storing images on blockchains is economically infeasible.
What if we could run heavy computations in a more centralized fashion, say on a single server, and then periodically integrate the results onto the main blockchain for posterity. We temporarily expose some vulnerability while the parallel server runs the heavy computation, but we get a massive benefit in that we don’t have to run the computation on chain, and simply need to store the results for future verification. This is the general premise behind Truebit. We won’t get into all the details of Truebit but there is a concept of challengers, who check to see the computations that were made have high fidelity.
This is what, at its core, state channels are. Imagine we wanted to play a game of Starcraft and have a smart contract that pays 1 ETH to the winner. It would be ridiculous for each participant to have to write on the main Ethereum network each time a Zergling was killed by a Zealot, or when a Command Center was upgraded to an Orbital Command. The gas cost (Ethereum gas, not Starcraft gas) and time for each transaction would be prohibitive.
Instead, what if the game was played in its own “channel”? Each time a player made a move, the state of the game is signed by each player. After an epic battle where the Protoss player takes out the remaining Zerg forces and forces a gg, the final state of the game (Protoss wins) is sent to a smart contract on the main chain. This neutral smart contract, known as a Judge, waits a while to see if the Zerg player disputes the outcome. If the Zerg player doesn’t, the Protoss player is paid the 1 ETH.
Instead of having to record thousands of transactions that occurred during the game on the main chain, all the transactions are done off chain and only the final state is recorded on chain.
Similarly, a side chain is a separate blockchain that runs in parallel to the main chain. The term is usually used in relation to another currency that’s pegged to the currency of the main chain. For example, staying with the Starcraft motif, say we had an in-game currency called Minerals (oh wait, we do!). We could allow players to peg their Ether (or ETH) to purchase more Minerals in-game. So we reserve some ETH on the main chain, and peg, say 500 Minerals to 1 ETH.
Then the player can spend their 500 Minerals in-game however they wish. Given the rapid rate at which Minerals can be spent and earned, Mineral-based transactions only happen on the side chain.
What’s really cool is that this architecture is fractal. We can then have a side chain of the Mineral chain to represent another scarce in-game asset. We can then make a side chain of that scarce in-game asset, and so on. There is no limit to how many side chains and levels of side chains we can have!
Plasma, a project by Ethereum, uses this side chain concept. It encourages transactions to happen on side chains (or child chains). An authority governs each of the child chains. If the authority starts acting maliciously, anyone on the child chain can quit the child chain and take back their pegged assets on the main chain. It’s in its early stages of development but shows a lot of promise in handling some of Ethereum’s scalability issues.
Payment Channels
Lastly, we’ll talk about payment channels. They’re an extension of state channels and side chains. Let’s say Alice wants to send Bob 1 Bitcoin but speed and transaction costs are important to them so they want to run this transaction off chain.
They open up a communication line between them called a “payment channel”. 1) Alice sends Bob the 1 Bitcoin. Turns out, Alice only owed Bob 0.5 Bitcoin so 2) Bob sends Alice back 0.5 Bitcoin. Then Bob takes Alice on a weekend getaway. Alice picks up the tab so 3) Bob reimburses Alice another 0.1 Bitcoin.
Instead of recording these 3 separate transactions on the main chain, we just record the final state of the payment channel to the main chain.
Another key idea of the payment channel is that Alice and Bob don’t need to open up a channel directly between them every time they want to transact.
Alice can access Bob transitively through Pete, who has a payment channel opened with both Alice and Bob.
You can imagine in theory, the idea of payment channels really becomes powerful when you have a rich network of participants. Every node can access every other node without being directly connected to them. The system is able to determine the quickest path between two nodes who want to connect.
There are many critics of payment channels. Finding the quickest path between unconnected nodes is no trivial exercise. This is a classic “traveling salesman” problem that has been worked on by top computer scientists for decades. Critics argue that it is highly unlikely payment channels like Bitcoin’s Lightning and Ethereum’s Raiden will work as expected in practice due to complexities like the traveling salesman problem. The key for you is just to know that these projects and potential solutions to blockchain scalability issues exist. Many of the smartest minds in the industry are working actively to bring them to life.
Summing Up
Congratulations! You’ve just educated yourself on the most common advanced topics in blockchain that you’ll hear about. By understanding these concepts, you have a firmer grasp on the fundamental tradeoffs and latest research on the blockchain than most industry “experts”! Better yet, next time you hear your colleagues around the water cooler talking about state channels, the Lightning Network and Byzantine fault tolerance, not only will you know what they’re talking about but you might be able to teach them a thing or two!
In this article, we took a different approach from our regular coding tutorials. We felt it was important for you to conceptually understand these advanced topics in blockchain development.
[ad_2]
This article has been published from the source link without modifications to the text. Only the headline has been changed.
