This is the second in a two-part series on the mechanics of MakerDAO, POA Network, their native assets (dai and xDai), and state channels. If you have not yet read part one, we encourage you to do so before reading this article. Part one can be found here. In this series, we explain the fundamental mechanics of Ethereum’s most popular crypto-collateralized stablecoin and the methodology by which POA Network and state channels improve the transactability of Ethereum-based assets such as the dai stablecoin.

If you enjoy this article or have any feedback or comments, we welcome your opinion. Please join the discussion in our Telegram group here.


While part one in this series explained the theory behind MakerDAO, POA Network, and their native assets, this section will take a more hands-on approach, explaining state channels and their practical usage.

Firstly, it is important to understand the difference between a state channel and a sidechain. While both state channels and sidechains have the same end-goal of scalability, they each take very different approaches.

Sidechains

As the name implies, a sidechain is a blockchain that operates alongside another (called the main chain) and is connected via two (or more) smart contracts (with at least one on each chain). These smart contracts lock up assets on one blockchain and issue them on the other, allowing them to pass back and forth between chains so as to make use of each’s features as desired.

Note that sidechains frequently use different consensus algorithms than their main chains in order to increase transaction throughput and that their security and immutability are separate and distinct to the that of the main chains.

State Channels

Much like sidechains, state channels require that a quantity of on-chain assets be locked up; unlike in a state channel, the assets are not then issued on a separate blockchain. Once on-chain assets are locked, the involved parties may then transact among themselves by signing transactions that can be submitted to the blockchain at a later date. As each new transaction has a nonce — the same way transactions on a blockchain have a nonce — state channel transactions have a provable topology which can be reconciled with the blockchain at a later time agreed upon by both parties.

By moving transactions off a blockchain and processing them in bulk at a later stage, significant improvements are made in both speed (as transactions are not limited by block time) and cost (as only two on-chain transactions need to occur for a state channel to be opened and closed).

It is important to note that the same cryptographic proofs that secure a blockchain also apply to state channels so—while open state channel transactions lack proof of work or any other consensus algorithm—the security of their transactions are comparable to that of an on-chain transaction.


Mike Ryan’s Chess Project

Mike Ryan is a software developer and information technology operations consultant specialized in building cloud infrastructure. On weekends, he likes to experiment with new technologies and sees Ethereum as an exciting sandbox for developers with an interest in blockchain.

Mike started developing on Ethereum last year when he built a Python library for Request Network’s API; he later launched SendCrypto Bot — a peer-to-peer (P2P) payments application that supports ether, dai, and various ERC-20 tokens on Twitter, Slack, Reddit, and Telegram.

On March 31, Mike announced his xDai-based chess project via Twitter and immediately caught the attention of Pink Sky Group. We quickly put out “Thinking Fifteen Moves Ahead: MakerDAO, xDai, and POA Network” and reached out to Mike to walk us through his project.

Here’s how it works:

  1. Alice and Bob create a new state channel on the xDai sidechain to play a game of chess, each sending their wager to the new channel.
  2. The game starts with a random state hash upon which both players agree before starting the game.
  3. Alice makes her move and the new hash is calculated by hashing the value of her move in Forsyth–Edwards Notation (FEN)—a shorthand designed to describe the movements of chess pieces—with the existing hash. For example, if Alice opens by moving her King’s pawn forward by two ranks, the input for the new hash will be current hash + e4.
  4. Alice sends a “State Change Proposal” to Bob, containing her move in FEN (e4), and the newly calculated state hash.
  5. Bob repeats the hashing calculation in step 3 in order to ensure that the move is valid before progressing the game.
  6. If the new hash calculated by Bob is the same as the one sent by Alice, he sends a “State Change Accepted” message to Alice and makes his move; if the hash does not match, he sends a “State Change Rejected” message and the game is aborted.
  7. The game continues until it is aborted or one player wins, in which case the players close the state channel and the winner collects their earnings.

The Endgame: Fostering Adoption

While there are a few bugs to work out — such as how to prevent a player from refusing a valid State Change Proposal— Mike’s chess project represents a compelling use of two important scaling solutions (state channels and sidechains) and a fun, simple use case for an important decentralized finance tool (xDai). More importantly, the project takes the industry one step closer to wider blockchain adoption and consumer appeal.

As is the case with many new blockchain technologies, Pink Sky Group expects the adoption of decentralized finance to begin with gaming. As evidenced by the ERC-721 token standard—which was popularized by CryptoKitties and paved the way for new technologies and use cases—blockchain-based gaming presents a fun and low-risk sandbox in which developers like Mike can build, fostering blockchain adoption step-by-step as the market broadens its appeal.

If you would like to learn more about the capabilities and use cases of state channels, Mike recommends Counterfactual’s resources, which can be found here.


NB: This article may contain terms with which you may not be familiar. Pink Sky Group maintains a glossary of blockchain-specific technical terminology for your convenience, which can be found here.

Important Disclaimer:

Information is Opinion and Provided “AS IS.” The information provided herein is the opinion of Pink Sky Group. Certain information has been provided to Pink Sky Group by other third parties. Pink Sky Group has relied on information provided to it by such parties that it has not independently verified. Pink Sky Group cannot guarantee the accuracy of any such information and does not represent that such information is accurate or complete.

All expressions of opinion reflect the judgment of the authors as of the date of publication and are subject to change. Pink Sky Group is under no obligation to revise or update any statements herein for any reason or to notify you of any such change, revision or update.

Information does not Constitute Investment, Tax, Estate Planning or other Professional Advice. Information on this page should not be construed as investment, tax, estate planning or other professional advice. Pink Sky Group is not acting as an investment or other professional adviser or otherwise making any recommendation as to any investor’s decision to invest in any security, industry, strategy or other financial instrument. Users should consult their own professional advisers regarding their own specific investment, legal or tax situation before making any investment, engaging in any tax or estate planning strategy or otherwise acting on any information provided herein.

Forward Looking Statements. This post contains forward looking statements based on Pink Sky Group’s expectations and beliefs. Those statements are sometimes indicated by words such as “expects,” “believes,” “will” and similar expressions. Any statements that refer to expectations, beliefs or characterizations of future events or circumstances, including any underlying assumptions, are forward looking statements. Such statements are not guarantees of future performance and are subject to certain risks, uncertainties and assumptions that are difficult to predict. Actual events or circumstances could differ materially and adversely from those expressed or implied in any forward looking statements as a result of various factors.