Can Ardor reach Visa Scale Blockchain?
Dispelling some myths around blockchain scalability
Lightspeed is finite, and this is a bummer, but we’ll get to that in a moment.
But let’s start with Visa. Many blockchain scaling discussions these days start with Visa’s 2000 TPS myth. More precisely, what this statement means is that at peak usage 2000 Visa cards are swiped every second around the world, and somehow most transactions are processed correctly and without cheating. The discussion then continues as to how we can scale a blockchain to the same levels as Visa. I say you are barking up the wrong tree.
Disclaimer, I never worked for Visa, and I’m not familiar with how the global Visa network really works. However, I do possess one of these credit card terminals used by my wife’s aesthetic clinic.
Let me describe how the process works where I leave. When a credit card is swiped, two things happen (1) the total amount of the deal is validated against a central database of credit card balances. I’m quite sure this database is not even managed by Visa itself (2) the transaction is stored in the memory of the credit card terminal.
Then, sometime overnight, the terminal wakes up and broadcasts all the daily transactions of all credit card types to a central clearinghouse. In Israel this clearing house is managed by a company named Shva. Shva sorts all the transactions submitted by all local terminals and redirects the Visa deals to the Visa database, Mastercard to Mastercard and so on. On the other direction each credit card company updates Shva with an up to date balances of the cards and also, with a list of blacklisted cards, this list is also uploaded to the terminal. The next day validation works against this central database managed by Shva; the credit card terminal never connects directly to Visa.
Shva is one of these monopolistic dinosaurs that blockchain aims to replace. The whole process is arcane, unbelievably, the communication between the terminals and Shva still uses a 14,400 baud dialup modem and if the terminal itself loses its memory during the day, the deals will never get credited to the merchant.
You might say, Israel is not the most advanced country with regards to communication infrastructure. I assume that in some countries this works more efficiently but surely in others it works less. What I’m saying is that there is no reason to compare blockchain scale to Visa scale since Visa does not have any central database that processes 2000 TPS. I assume the Visa network is separate into multiple hubs dealing with their local databases.
I assume that if I swipe my Israeli credit card in say, Korea, the local merchant has a way to validate my eligibility to buy, perhaps using a global database or a redirect to the Israeli database (I don’t know). But, Visa Korea surely does not store and does not care about all the transactions I made while in Israel.
Now that we cleared this out, let’s get back to the speed of light. Internet communication is not faster than the speed of light at 300,000 KM/Second (the perimeter of the earth is 40,000 KM). Therefore the fastest theoretical speed of sending a transaction between two sides of the world, say, US and China, is longer than (40000 / 2) / 300000 = 0.0667 Seconds.
In practice however, internet communication is much slower since every TCP/IP packet has to be routed through multiple communication junctions. First it needs to reach the local ISP then the national cyber optic line then the internet backbone routers, then its destination through the destination ISP. You can run a “tracert google.com” command on your Windows workstation to see how it works. It is fair to assume that over 20% of the transactions will take more than a second to propagate between nodes on different sides of the world.
Now let’s look at the claims about 2000 TPS or even 100,000 TPS with blockchain. Recall that in a blockchain network, every node has to process every transaction and every block to reach the same state independently. We call this consensus, and it is the main promise of the blockchain so not something we would like to compromise on using various semi-centralized solutions or off chain transactions.
So what would happen in practice to a 1000 TPS blockchain? For the sake of discussion, assume that transactions are distributed uniformly 1 every millisecond. This is of course not the case, and what would happen in practice are huge peaks in transaction generation (of perhaps 10K TPS) followed by low periods, which make things even worse.
Let’s assume that a node in China and a node in the US solves a hash of a block at roughly the same time. At this moment there are surely transactions which are either unknown to the Chinese node or unknown to the US node. So these blocks do not contain the same transactions and will, therefore, cause the blockchain to fork. These will be massive blocks, so it will take several seconds until the Chinese node receives the US block and vice versa. During this time 1000’s of new transactions are submitted to the network. One of these nodes will have to switch to the other’s fork which means it will need to undo a massive number of transactions from its block and load a massive number of transactions from the other node’s block. During this time yet more transactions are submitted and perhaps more blocks generated. It’s hard to see how this type of network will ever reach consensus about the order of transactions and blocks.
DAG users, your case is different but not necessarily better since on each node transactions will build upon other transactions for several levels, these are transactions which remote nodes did not see yet, and when they see it, they’ll possibly receive it in a different order. This will create massive differences between the graphs that each node maintains that I don’t see any way to settle without some central management, see more about this.
Semi-centralized solutions like DPOS will only get you so far. Since at some point the blockchain will need to reach a consensus about which new delegates to elect and will run into similar forking problems.
Whenever you run into someone who promises more than 1000 TPS, ask them to provide you an official loadtest result.
Furthermore, a 1000 TPS blockchain will generate huge bloat. Assuming 500 bytes per transaction, 500K of data is generated every second, 30MB per minute. If we consider Bitcoin’s 10 minutes block time this means average block size of 300MB, about 300 times more than current blocks. And this accumulates to over 43GB of data per day or 15.7TB a year. Clearly unsustainable.
To summarize, the “Visa network” processing is not comparable to a blockchain, and a blockchain as we know it will never reach sustainable 1000 TPS in a real global blockchain deployment (Some teams claim to reach it under lab conditions for a short period of time)
But most applications don’t need 1000 TPS. In essence the problem is that today’s blockchains are Jack of all trades, if you are interested in blockchain voting, your node will still process and permanently store all the identity management, asset exchange, ico transactions, iot sensor data, social network messages and every other transaction ever submitted to the blockchain even if you don’t care about them. This is the main problem that the industry needs to solve.
The Ardor platform aims to solve these problems. Our unique parent-child chain architecture allows us to separate each application into its own child chain, and only store the few transactions which are important to the POS consensus algorithm in the blockchain forever. All other transactions can be removed (pruned) and nodes will only track the recent state created by them.
Furthermore, this architecture allows nodes to focus on specific child chains. This way, we no longer require every node to process every transaction. Instead we can split the blockchain network into sub-nets each responsible for its own child chains. Then like the Visa network does today, we can scale globally.