Just the other week, you may have had difficulty getting transactions through on the Ethereum mainnet. In case you were unaware, this was due to the launch of a new exchange called FCoin which decided that it would list coins based upon however many deposits each coin had on the exchange. This basically translates to listing the coins of whichever users launched the most effective Sybil attack.

And it only took one application to cripple the entire Ethereum ecosystem. I feel like I’ve heard this before…

I’ll never understand why it wasn’t called CryptoDoges…

And people were surprised by this, lambasting Ethereum’s inability to handle this sort of traffic, even though the community never claimed that it could. To cite Vlad Zamfir:

Ethereum isn’t safe or scalable. It is immature experimental tech. Don’t rely on it for mission critical apps unless absolutely necessary!

But the fact of the matter is that Ethereum has the lion’s share of developers in the space and people ARE going to building more and more on top of it. And as more of these decentralized applications come online, the network is going to get increasingly congested. Fees paid to miners will skyrocket, many decentralized applications will be unable to pay these higher fees, and the overall user experience of using Ethereum will degrade.

And this is problematic, because decentralized solutions have been tried in the past and failed as users would often flock to the most centralized solutions, to cite John Backus. This tendency of users will likely lend itself to increased usage of platforms which have compromised on decentralization for scalability reasons (a la EOS and Stellar). And as someone who has been in the space for a few years now, this is certainly painful for me to say, but it is important to recognize the bias due to my idealism.

Now, one can argue that scalability solutions such as Casper and Sharding are on the way, which will solve these scalability issues we are facing, but these solutions are highly highly experimental and untested. On top of this, PoS and Sharding have been on the table and discussed since before Ethereum was even launched at Devcon 0 — these are hard problems. And at a recent talk by Vitalik, Karl, and Justin, it was stated that Casper and Sharding would be rolled out in three phases the first of which might be rolled out in 2019, the second of which might be rolled out in 2020, and the last of which might be rolled out in 2021. And given the unofficial Ethereum mantra of ‘Things are taking longer than we expected’, I would be willing to bet we’ve got about five years to figure out how to mitigate network congestion in the meantime with second-layer scaling solutions.

Now, most any second-layer scaling solutions that apply to Ethereum will be applicable to any other smart-contract supporting blockchain for the fact that these solutions are a plugin / add-on the the existing platform rather than a change to the protocol itself. And it will be essential that decentralized application developers leverage these as they launch or publish their products. If these sort of solutions are not integrated effectively (specifically relating to Ethereum), we can imagine a network attempting to carry the burden of 1000x the cryptokitty traffic as more and more applications (Like Augur) begin to launch.

In terms of these second-layer scaling solutions, two seem to have become crowd favorites: state channels and Plasma — I view Plasma as a kind of state channel (non-unanimous and regularly notarized to chain), so I’ll be providing a high-level view of state channels with a side-note on plasma.

A general definition of state channels can be taken from the Counterfactual Whitepaper (which you should read) by the L4 Ventures team.

State channels enhance blockchain performance by taking state-modifying operations off of a blockchain and executing them directly between defined sets of participants. Payment channels were the first type of state channel to be described, using off-chain interactions to modify ownership of locked Bitcoin, thereby allowing users to make “off-chain payments” to each other. The term “state channels” generalizes this approach beyond payments, encompassing all types of blockchain state modification which operate within a security paradigm comparable to that of the payment channel.

A basic real-world example of a state channel could be playing poker at a casino. When you enter the casino, you put down a certain amount of money for chips — this can be thought of as our ‘state deposit’. Inside, when you’re playing at the table, everyone is watching each other and insuring that they are all playing by the rules.

If someone is caught not playing by the rules, they can be punished accordingly to the rules of the casino that they agreed to when cashing in their state deposit. As long as everyone at the poker table is in agreement that everyone is playing by the rules, the game progresses and everyone’s chip stacks will be updated to reflect this. The point at which someone is wanting to cash out or ‘settle’, they will simply take their chips back to the teller and convert them in to the representative amount of their local currency.

The main thing to capture here is that a state channel works through the agreement of a group on a set of on-chain rules that they each stake some amount of value against. After doing so, the group can interact between one-another, but require that they all agree to everything that happens between all members before anything else is done (it is kind of like they made a mini-blockchain between themselves where every action performed is a block and it needs 100% consensus).

It is with this kind of structure that we may leverage Ethereum solely as the settlement and arbitration layer of our decentralized applications — minimizing its usage. Now, there are not a ton of applications that I am aware of leveraging state channels at present (Funfair has “fate channels”), but I highly encourage you to check out some of the work that is being done by Spankchain and Counterfactual to provide a general framework for integrating these into your applications.

As an added note, I’ve spoken with the Counterfactual team and they are in some of the final stages of testing their first release of their Generalized State Channel framework. It will likely be available on their Github page once released and I look forward to building an example application on it and detailing my experience in a later post here.

Regarding Plasma, you can think of it as a state channel where the work is happening on a side-chain vs. off-chain and where the nodes will be responsible for driving consensus. These chains will be smaller than the base-chain (where you put your state deposit) and therefore easier to attack if they leverage any consensus protocol driven by the aggregation of resources — computational power (in the case of PoW) or tokens (in the case of PoS). It is for this reason that I assert that side-chains will only really be able to mitigate these attacks via POA (Identity staking), sacrificing anonymity for security. And given that a number of the first applications launching on Ethereum will relate to betting and gambling — I cannot see users being very willing to give up their anonymity in those cases. It is for this reason why I’m advocating for general state channel solutions over Plasma.

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/idealism-and-how-to-scale-ethereum-now-e5545cae7db0

Find me on Twitter or Github!