How to Achieve Very Low Latency in Tezos - Arthur Breitman
The Tezos co-founder and early architect explores the challenge of latency, and suggests solutions to get latency on Tezos down to 'negligible levels'.
750 words, 4 minute read
In a video presentation published to his YouTube channel, Tezos co-founder and early architect Arthur Breitman explores the challenge of latency, and suggests solutions to get latency on Tezos down to ‘negligible levels’. While Breitman identifies throughput as the most pressing issue facing Tezos as it scales, there no reason why latency can’t be addressed too, without compromising decentralization.
Throughput and latency explained:
Throughput is your broad processing power. It’s how many transactions per second you are able to process. Latency is how long it takes between the moment a user creates a transaction, to the moment that transaction is included in a chain.
To take a car analogy. If you have a car factory, it could be that your car factory is producing a car every 10 minutes, but it still takes a few days to assemble the car. And that’s because there’s a whole pipeline inside the factory that processes many cars at once.
One solution to increasing the speed of a blockchain is to go by majority consensus, rather than unanimous consensus:
[…] If you have all the participants, all the validators, or a very large statistically significant sample of the validators come in and say, ‘yep. We’ve seen the block. It’s all right’, if you have this information, there’s no reason why you can’t proceed very quickly.
If you don’t have [that information], if all of a sudden it looks like, ‘well, I only have a fraction of the validators here’. You wait. You don’t produce blocks. What’s really interesting about this algorithm is that that lets you go very, very fast. You can have very short block time, and if you’re wrong, if you’ve made unrealistic assumptions about the network, it doesn’t matter. The network will slow down to accommodate the pace at which it can actually go.
Very low block times can create problems, though. In the spirit of decentralization, it’s important that the blockchain is open to participants all over the world, on slow as well as fast connections. An ultra-fast block time might disenfranchise users with slower connections:
[…] So are there trade offs here? […] Can we just set the block time to 0.0001 second? Well, no, not so fast. In a decentralized system, it’s possible for some nodes to be offline some of the time, to leave and join the network. And you want to be able to reward people from being live and notice when people are not live.
But if you’re making your blocks as fast as possible, whoever happens to be the slowest in your network, and they don’t have to be slow in absolute terms, […but] they’re never going to be included in blocks because blocks will say, ‘oh, I have two thirds of my network. I can proceed’. […] And then we now have a smaller pool of validators and then one third gets dropped, and [again] a third gets dropped, until you end up with a single person in a single data center.
So, on Tezos, how can we reconcile the need to be inclusive with the demand for better speed?
In a system like Tezos, you know who the next block producer is going to be. […] If you know who the next block producer is going to be, and you want to inject a transaction, you can go directly to that block producer. You can say, ‘here’s my transaction, can you sign a receipt saying that yes, it will be included in the next block?’
[…] It is a very neat solution which gives you latencies way below 400 milliseconds, below a hundred milliseconds. It’s really directly how long it takes you to talk to the leader of the next round. And that’s probably the shortest latency you can possibly have.
In summary:
Right now the main focus for core development on Tezos has been primarily around throughput, but latency is definitely next on the list. Getting latency down to a few seconds [is] a way to have really good UX while still preserving the decentralization of the network, which is important. These networks are only meaningful insofar as they’re really decentralized.
You can watch Arthur Breitman’s full video presentation at the top of this page, and more videos are available on his YouTube channel.