Crypto Market Commentary
17 June 2019
Doc's Daily Commentary
On 6/14 Doc conducted the first “House of Pain” coaching session, which is posted in the “Trade School” archive. Let me know if you have any interest in being a participant.
Our most recent “ReadySetLive” session from 6/13 is listed below.
Mind Of Mav
A brief history of scaling blockchains
When Bitcoin first launched in 2009 it became clear that, by design, it traded off transaction speed for decentralization and security.
Each block contained ~1mb of transactions. It took about 10 minutes to produce each new block. And it took another 45–60 minutes before you were sure your transaction had made it through.
The philosophy behind Bitcoin’s decentralized vision drives the tradeoffs that define proof-of-work. The 10 minute latency and small block sizes are enforced constraints that make it possible for a node running on a laptop in Kathmandu to have a chance of finding a block.
You wanted it to be possible for anyone, fighting through network latency and old specs to be able to maintain the integrity of the network.
The point was that we achieved decentralisation & security by ensuring that anyone can process transactions.
This came at a limit to how many transactions we could ask the network to process. Bitcoin aimed for ~20 transactions per second (tps), and in reality achieved about ~4 tps.
Scaling through simple parameter tweaks
Naturally, the first family of scalability solutions evolved around the idea that we could just stuff each block with more transactions.
To do this, we could simply make blocks bigger. Or, we could make each transaction smaller.
Examples of such implementations were Litecoin and Bitcoin Cash which hard-forked from Bitcoin to with smaller transactions and larger blocks, respectively. In practice, these efforts yielded 2–10x tps optimizations.
The fundamental issue with these scaling solutions was that each change required a hard fork. This required the community to rally behind the new chains and subsequently led to limited adoption. There’s also a practical upper limit to how much we can tweak these dials while still insuring decentralization ..
Scaling through off-chain computation
The next round of solutions came about the realization that not all transactions are equally important.
For example, processing a land deed agreement is likely more consequential than paying a friend back for dinner.
Many transactions types, like micropayments, can be processed off-chain. The main chain could be a settlement layer. For example, you can process 20k transactions in a state channel or a side chain as quickly as you wish. Then, verifying them on-chain in bulk, just takes a single transaction [pictured below].
Doing things off chain reduces computation and storage load on the main chain. At the same time, it still gives you the benefits of on-chain reconciliation for transactions, over time.
Examples of such implementations include Lightning network, Bitcoin’s off-chain transaction compute solution, which theoretically resolves more than 1M tps. There’s also Raiden. which provides payment state channels on top of Ethereum, and theoretically processes more than 100M tps. And notably, there’s Plasma, which spawn child chains from the main blockchain, theoretically handling an infinite tps.
Some issues with doing things off-chain were that i) you were offloading these off-chain computations to centralized services and ii) as a result, you couldn’t get the security guarantee of an entire ecosystem maintaining the network & adhering to an immutable security protocol.
Scaling through on-chain sharding
Additional solutions came about the insight that transactions cluster around different social communities.
For example, transactions occurring within a shipping network in Singapore, vs. an eCommerce marketplace in Mexico, vs. freelancer community in Berlin, won’t often overlap.
It made sense to adopt a traditional database concept of sharding. Where, within one blockchain, you can have different computing resources, nodes, handle different transactions in parallel.
In theory, transactions are often contained in network clusters and are easy to parallelize.
Examples of such implementations include Zilliqa, which developed a complex sharding algorithm.
In practice, parallelization is very difficult. The challenges span from how to securely allocate transactions per node, to ensuring data availability among nodes, to resolving network asynchronicity issues…
A simple edge case where there is a transaction C in node C, which depends on a transaction A in node A and a transaction B in node B, which in turn has other dependencies, compounded with the reality of network latencies… becomes difficult to resolve.
And many more solutions…
The list for brilliant, blockchain scalability solutions spans on. From blockchains that look less like chains and more like directed acyclic graphs [pictured above], to faster consensus algorithms like PoS, PoA, specifically mutations of federated BFTs and delegated BFTs that guarantee faster block finality & production… users now have a plethora of solutions to choose from.
The challenge going forward might be around adoption.
Aside from canonical chains like Bitcoin, Ethereum, and Eos, the majority of blockchains remain severely underutilized.
Going forward, each chain in the ecosystem will need to find product market fit, given the scaling tradeoffs they have made.
The important point here is that blockchains do scale.
The future is a disparate ecosystem of blockchains, where adoption will be very tribal.
The Blockchain Scaling Trilemma diagram helps us picture what this future ecosystem might look like.
The Trilemma posits that there is no silver bullet solution for scaling blockchains. At best, two out of the three criteria of scalability, security, versus decentralization can be satisfied.
Each blockchain solution will always make some degree of tradeoffs that’s informed by its intended use cases and audience.
In many ways, we’re already seeing these decisions become more formal and well understood by the community:
Bitcoin & Ethereum 1.0 optimizes security & decentralization: as previously mentioned
Ethereum 2.0 optimizes scale and security: As, Vitalik confirms in this talk Eth 2.0 is about “targeting people who are building many, different small scale applications that can all talk to each other on top of Ethereum’s homogenous layer”. It is also about “ensuring lots of transactions”.
IPFS optimizes scale and decentralization: IFPS trades off security (or rather consistency) aspects, like transaction ordering, for faster data transmission and a fully decentralized network. This works for its particular use case of transfering files and videos.
EOS optimizes scale and security: Its delegated PoS means that token holders democratically elect a central team to represent their interests, which strays away from pure decentralization.
In the future, each chain might continue to fall somewhere on the trilemma diagram. The best blockchains will be the ones that are highly customized for their use cases.
Blockchain adoption is also fundamentally tribal.
We’re already seeing that Ethereum is doing better in the west, as it is democratic and censorship resistant, which is quite a western notion.
But if you look over in Asia, EOS is the protocol that’s getting significant traction. This is due to cultural reasons, local marketing advantages, and basic human nature to put our resources towards something we understand and whatever most reflects our cultural ideologies.
I posit that in a future where, for our daily needs are fulfilled by blockchain solutions, we’ll likely adopt many individual chains. These chains will also be different across major geographic regions.
If you’ve made it this far, you might observe that scaling blockchains won’t be the main challenge in the future.
The protocols themselves have already done a good job of scaling, making trilemma tradeoffs that make sense for their particular use cases.
But at the end of the day, all of these chains will all need to talk to each other.
Going forward, overcoming blockchain interoperability may be a more pressing issue.
Scalability as a side effect of interoperability
Let’s consider how this might be achieved through the Polkadot network:
A single blockchain gains the ability to horizontally scale itself once it joins the Polkadot network.
After a chain reaches peak capacity, it can create a new instance of itself and thus parallelize execution.
This new chain connects to the ecosystem by default, enjoying the benefits of shared security and interoperability of the network.
To the user, nothing has occured. Behind the scenes, a single business will be able to horizontally scale itself in minimal time, ad infinitum.
It’s the beginning of a bright decentralised future. It remains to be seen if the biggest problems we face today will even matter ten years from now as blockchain technology continues to evolve and overlap itself. Truly, it’s a fascinating process to watch unfold.
Press the "Connect" Button Below to Join Our Discord Community!
Please DM us with your email address if you are a full OMNIA member and want to be given full Discord privileges.
An Update Regarding Our Portfolio
We are pleased to share with you our Community Portfolio V3!
Add your own voice to our portfolio by clicking here.
We intend on this portfolio being balanced between the Three Pillars of the Token Economy & Interchain:
Crypto, STOs, and DeFi projects
We will also make a concerted effort to draw from community involvement and make this portfolio community driven.
Here’s our past portfolios for reference:
RSC Managed Portfolio (V2)
RSC Unmanaged Altcoin Portfolio (V2)
RSC Managed Portfolio (V1)