Can Git Solve Blockchain Scalability?
Whenever I read about Bitcoin scalability problems I feel baffled. Tens of thousands computers in the network, and we only get three transactions per second? Paypal manages 115 tps. Visa 2,000 tps on average. 3 tps cannot seemingly be right.
But it is and the reason is delays over the network when building a consensus. Any node can mine the next block, and it needs time to reach everybody else. A blockchain is literally a chain of blocks, i.e. a linear structure, so it’s important that every node has exactly the same blocks in exactly the same order. Bitcoin mines a block every ten minutes on average, so the size of a block determines the effective number of transactions per second.
If we try to ignore the network delays we are asking for problems. What would happen if the mining network was allowed to spit out new blocks as fast as it wanted to? For instance, as fast as a new transaction becomes available? At the very least, we would see inefficiency. Some nodes would inevitably mine blocks at nearly the same time, effectively causing forks. These forks would not last, since the longest branch always wins, and the shorter branches are always discarded. But it’s pretty clear that the higher block mining rate does not translate into higher transaction rate. Network delays are a real issue.
Since there is nothing we can do with the network propagation speed, maybe we can tweak the very structure of the blockchain? Obviously, the linearity represents a problem. What if we let it branch out? What if we allow concurrently mined blocks to legally exist on the ledger forever? How would that work?
First thing to notice is that a ledger represents a history, and a history has to be linear. We cannot allow our branches to continue spreading out forever because otherwise we will never figure out what happened when. This means that every once in awhile, our branches need to converge. For example, once every hour, the network would need to take transactions from all parallel branches, and issue a ‘merge block’: a block that references all parallel branches and serves as a foundation for new blocks. A merge block will have exactly the same network propagation problem, but since it will happen relatively infrequently, the average transaction rate of the mining network will go significantly up.
Second, we need to deal with the double spend problem that could manifest itself in parallel branches. The same money could be spent twice in two branches, which defeats the purpose of the ledger. Perhaps, the easiest way to deal with it is to change the structure of a transaction. A typical bitcoin transaction combines a number of input transactions and output addresses. So if Bob sent you 2 BTC in transaction t1, and Alice sent you 3 BTC in transaction t2, you will need to refer both transactions t1 and t2 when paying 4 BTC to Carol. This is a mathematically elegant way to organize things, but for the purpose of payments an account balance based system would be easier to scale: every transaction becomes (payer_address, payee_address, amount, payer_balance, payee_balance). If we have that, we can simply devise a deterministic way to keep all transactions with a given payer_address in the same branch, and thus make sure we are not allowed to overspend what we had at the last merge block.
Let’s get back to the title of this post. Why Git? Well, interestingly enough, Git has a lot of similarities with a blockchain. Just like blocks in a blockchain, every commit in Git refers its parents. Just like in a blockchain, a commit hash in Git is based in part on hashes of its parents. But unlike a blockchain, Git allows multiple parents for a commit, which makes this a perfect vehicle for merge blocks. Now of course, Git is based on SHA-1 hash, for which collisions were recently discovered. But the Git team is already working on a plan for a fix.
To sum this hypothetical crypto up: it uses Git to store blocks, it uses Git branches to increase transaction throughput, it relies on account balance system, and it uses Git merge commits to periodically bring branches together. Anything else? See my thoughts on open source commits as a proof of work system.
