This article summarizes a technical paper on scaling blockchains. I do not disaggregate the entire work, but I definitely get under the hood. So if you do not have the time, spoiler alert!
“Here is the takeaway. Blockchains must be massively more scalable than the current tech that supports Bitcoin. We start scaling slowly or quickly. And if we choose the latter, it will “require fundamental protocol redesign.””
If you choose to read on, you will see the aforementioned again.
Ready?
As the classic joke goes, what do you get when you mix the Initiative for CyrpoCurrencies and Contracts (IC3), Cornell, Jacobs – Cornell Tech, University of Minnesota-Duluth (UMD), ETH-Zurich, Berkeley, and National University of Singapore (NUS)?
Believe it or not, the correct answer is not more degrees than a thermometer. You actually get a paper with the lofty title “On Scaling Decentralized Blockchains.”
With sponsors such as the National Science Fellowship, a Packard Fellowship, a Sloan Fellowship, two Google Faculty Research Awards, and a VMWare Research Award, this group definitely checks all the boxes. And with the recent activity of the two largest sponsors of IC3 , IBM and Digital Asset Holdings, one can see that the prescriptions found within will not fall on deaf ears. The paper is well thought out and well paced, and if you really dig the nitty gritty of the blockchain debate, it is certainly worth the read. (Here. ) If you do not want to plow through it, please allow me.
The conversation starts with a description regarding the timely question of how the Bitcoin blockchain can sustain the increased interest. As the authors state, “The current trend of ever increasing block sizes on Bitcoin portends a potential problem where the system will reach its maximum capacity to clear transactions , probably by 2017.” And as those of us in the cyrpto community know, the lines have been drawn and the discourse is raging. Agreed, the system must mature, onward.
In a section titled “Bitcoin Scalability Today: A Reality Check,” the group analyzes some of the key metrics in the system that serve as scaling constraints. I will go through these as they relate to the conclusions later in the piece.
+ Maximum Throughput – The maximum rate at which the blockchain can confirm transactions. Currently it is 3.3-7 transactions/sec.
+ Latency – The time necessary for a transaction to confirm. Currently, roughly 10 minutes.
(Note: The sum of these first two points is significant as speaking in terms of transaction speed, not settlement speed, “Visa credit card confirms a transaction within seconds, and processes 2000 transactions/sec on average.”)
+ Bootstrap time – The time it takes a new node to download and process the history necessary to validate the current system state. They put this at roughly four days (averaged over 5 fresh t2.medium Amazon EC2 nodes connected running the most recent master software).
+Cost per Confirmed Transaction (CPCT) – The paper extends these costs out and arrives at a range of between $1.4-$2.9 of which electricity related to mining makes up 57% of the cost. They also mention “If de facto Bitcoin throughput is assumed, the CPCT is as high as $6.2.” This sounded odd. The calculations are long and arduous, but they do pencil out.
Now that we have covered the high points in terms of bottlenecks, let’s take a peek at some options for scalability. In regards to this section, the authors state, “We organize our discussion around a decomposition of the Bitcoin system into a set of abstraction layers that we call planes. Ordered in a hierarchy of dependency from bottom to top, the five planes we consider are the Network, Consensus, Storage, View, and Side Planes.”
To bring this synopsis home, we will define the planes.
+ Network Plane- This is to propagate transaction messages. By the authoring group’s measurements, this plane does not fully utilize underlying network bandwidth.
+ Consensus Plane- This plane is “to designate a globally accepted set of transactions for processing, as well as a total or partial order on these transactions.” In abstract, “this plane ingests messages from the Network Plane and outputs transactions for the insertion into the system ledger.” The ways to improve this plane are by, improving proof-of-work protocols, utilizing proof of stake, exploring consortium consensus, implementing sharding (splitting up the task of consensus among concurrently operating nodes), and finally the delegation of trust and a hierarchy of sidechains.
+ Storage Plane – The Storage Pane serves as a “global memory that stores and provides availability for authenticated data produced by the Consensus Plane.” Technical considerations certainly exist, but they suggest perhaps starting the optimization of this plane by reviewing Distributed Hast Tables (DHT).
+ View Plane – “A view is a data structure derived from the full ledger whose state is obtained by applying all transactions.” The group suggests two approaches to views. One of which is founded increasing availability the other, lowering cost.
+ Side Plane + Basically sidechains. The suggest a deeper dive into the trade-offs associated with building efficient, scalable, privacy-preserving protocols in this space.
Here is the takeaway. Blockchains must be massively more scalable than the current tech that supports Bitcoin. We can scale slowly or quickly. And if we choose the latter, it will “require fundamental protocol redesign.”
And the implementation debate rages on….
Featured image from Shutterstock.
