Investing in blockchain companies over the past couple of years, I’ve realized how little I know and how new the category is for venture investors. For fear of becoming dumb money, I went back to ‘school’ with a cryptography friend last week who schooled me in some basics on BTC, Byzantine Fault Tolerance, and distributed consensus protocols such as Paxos and Raft (employed on DLT such as Tendermint). We discussed everything in layman’s terms, and I’ll be publishing the key takeaways from our crypto tech meetups on Medium. We’re ambitiously hoping for once a month right now. I’ll attempt to summarize some of our first ‘class’ here.
We explored the many ways distributed consensus could be used in cryptography and distributed computing. Raft is pretty great, but there may be other alternatives out there (for example: there’s a fully BFT-version of Raft called Tangaora that resolves faults that Raft has with some Byzantine problems).
BTC will eventually break. The ‘math problem’ that Proof of Work is supposed to solve, gets harder and harder, in response to supply and demand of miners/transactions. If things ever slow down, and there are 2 standard deviations of time that occur since the last block was processed, then the math problem gets easier to get to the ‘reward’ (i.e. new bitcoins minted to pay the miners for processing the transaction by undertaking the PoW math). But if the math stays at peak difficulty, we don’t ever get to the reward. The miners can’t mine. As a result, transactions stop. Certainly new currency created/unlocked stops too, but the bigger issue here is nobody mines and thus no transactions can occur. However, if there’s consistent demand for transaction throughput, the math gets harder and harder to compute — until we reach the aggregate supply of all possible mining (due to difficulty of the hash problem to solve). It just gets too hard to solve with existing computing power. This is why the electrical consumption of BTC is ridiculous: we need more and more compute to keep up with how difficult it is to mine.
The problem with Lightning Network and state channels is that it artificially pushes the Aggregate Supply of bitcoin mining out to the right. In other words, it makes the market believe the supply curve is at a different point than it actually is. This leads to some serious economic problems. What happens when the lightning channels have to ‘settle up the bill’ at the end of a payment / transaction series, and it can’t process the ‘net’ transaction results onto the BTC blockchain, due to strangled throughput?
Eventually, bitcoin breaks. That’s what I took away from our chat yesterday.
Economic Analysis of State Channels and Lightning vs. BTC Supply Issues
Quick diagram to explain the messed up faux-equilibrium created by Lightning
Ceteris Paribus, the market for BTC is like any other monetary market. There is a natural equilibrium of (Q1, P1) where BTC’s current supply meets its current monetary demand.
Lightning and State Channels allow you render transactions faster than otherwise because they effectively debit and credit off the chain and settle transactions later (when the payment channel is closed or there is a dispute in the case of lightning).
This moves S1 to S2 as it effectively increases the amount of currency available/accessible for transactions. It is basically like an increase in M1 Money while keeping M0 Money static.
This increase in supply makes it easier to acquire and use BTC — basically the point of Lightning. It moves then the equilibrium point to (Q2, P2).
The lower spot price, but higher transaction volume, messages to the market that BTC is undervalued (lots of transactions but it’s not super expensive), its structural issues have been solved with lightning/state channels, or both.
But in reality the real money supply of BTC is not accelerating at the same rate that S2 is moving away from S1. In fact BTC’s natural rate of expansion is slowing down due to its mining problems.
As a result, there will come a day where Lightning or the other currencies are unable to economically render transactions. The following will happen:
Short Term:
- Equilibrium will move to (Q1,P3) as demand has been shifting out but the natural supply remains static. This equates to a stark rise in the immediate price of BTC while the transaction volume drops due to the difficulty in mining.
Medium / Long Term:
- Mining ceases to be economically viable/possible. This equates to you being unable to render transactions, meaning demand ceases. Losses are equal to the integral of the rectangle whose top right side is (Q1,P3). AKA this sucks.
- Note that if the above happens immediately for some reason (you hit a “brick wall” rather than a sandbag going 100mph) then you’re talking about either losses of the same integral at (best case) (Q2,P1) or (worst case) (Q2, P3). This depends largely on how popular the currency is when it dies. AKA: This really really sucks or Mortgage Backed Security crisis, 2018+ edition.
RAFT’s
We talked about centralized rules sitting on every node in the network and that it’s these rules that are important, not the autonomous calculations of PoW math problems that the nodes carry out in BTC, for example. The rules of coming to quorum/consensus enable zero knowledge proofs to verify that all nodes are in compliance with said rules. Here’s a good non-technical overview that I found helpful in understanding how RAFT’s work.
For an example, we have a series of workers who have a set of rules about lifting, carrying, and setting down boxes (boxes represent transactions and workers represent nodes). There are clear rules in the employee handbook about the lifting, carrying, and setting down, and about the weight of the crates being carried. Without knowing the contents of each crate, you know the weight should be X. If the weight varies from X, I, as a worker node, can call bullshit on whoever the ‘leader worker node’ is in the group and say ‘you’re breaking the rules — I challenge you’. If another worker verifies that my calling BS on the last leader node is valid — i.e. by picking up the crate and realizing the weight is off, then I become the new leader node and I’m the new enforcer of the rules (though others could challenge me at any point). Basically, it’s the rule-set that is important here, rather than any individual node. In Star Trek, the Borg hive mind is important — not each individual drone.
Resistance is futile — nodes do not matter, only the central set of rules; We are the Borg.
Huge thanks to Andy Manoske for his help with this article and for his patience as a teacher!