TPS, or “transactions per second,” is one of the most talked-about data points in blockchain. Journalists rank different blockchains using it. Policy makers speculate over it. Twitter degens go to war over it.
It’s a metric of how much work blockchains can actually manage, and a high TPS rate helps make transacting over a blockchain more desirable than using traditional financial rails. What makes Stellar optimal for payments is in part due to its competitive TPS rate. Maintaining that rate, and even improving upon it, has long been a focus of the Stellar community.
Stellar is not currently limited by TPS. The network’s maximum rate is set at 200 TPS, though that could be raised by the community were validators to vote for it. And though transactions occasionally reach that 200 TPS rate, the blockchain is still able to resolve transactions waiting for validation within a few seconds — just, you know, not right at that very second.
But as always, Stellar still reaches for the stars. It’s always preferable for the technology to be able to handle more data flows than it needs to, which is why so many core releases and protocol upgrades center around increasing transaction speed capabilities. One of those releases, 19.4.0, introduced Pull Mode, a feature that all validators started using after release 19.7.0. These releases prepared the network for a major protocol upgrade to increase network capacity.
It’s important that all validators understand what these releases set out to accomplish. That way, they can verify that the release actually accomplished its goal, and offer improvements or point-out flaws. So let's dive into how Pull Mode was designed, and how it helps improve Stellar’s TPS.
If you’re more of a visual learner, you can also watch SDF engineer Hidenori Shinohara’s presentation on Pull Mode from Meridian last year:
Transaction propagation
There’s a lot of complexity in the Stellar Consensus Protocol (if you don’t understand how it works, I highly recommend you read the white paper before continuing). But tl;dr: network validators must all keep track of a complete historical record of every operation that’s occurred on the Stellar network in order to keep things running. They must also reach agreement with each other in order to — you guessed it — validate a new transaction and close the ledger.
To do this, validators need to tell each other about transactions. They do that via something called “transaction broadcasting,” which is also sometimes referred to as transaction “multicasting,” or “flooding.” Don’t be mistaken — though broadcasting implies a central entity is sending data to everyone else, that’s not what happens here. Instead, each node is broadcasting data about transactions to other nodes in the network, with no one node being the central disseminator of information.
Because there isn’t just one node broadcasting information about transactions, power is decentralized. Decentralization is a good thing, because it means that no one node has the power to block transactions. The downside, however, is that there’s an excessive amount of redundant information being disseminated between nodes. There are so many nodes telling each other about transactions, that sometimes a single node is told about a transaction over 30 times.
Redundancy can help make a system stable, but that level of redundancy is unnecessary. It takes an excessive amount of CPU, memory, and bandwidth to function, which slows down the network’s speed. In other words, transaction broadcasting was a limiting factor on Stellar’s TPS before core release 19.7.0 mandated Pull Mode for all validators.
Wait - so what is Pull Mode?
Imagine you want to send someone that you don’t know all that well yet — maybe an office colleague at your new job — a gift for their birthday. You don’t know if they already have the cute little squishmallow you want to buy them in their stuffed animal stash. You’re not even sure if they like oversized stuffed animals at all. So what do you do?
You ask a few questions before you go out and buy that squishmallow and give it to them.
That’s the concept behind Pull Mode: “ask before you send.” Though it seems pretty obvious to humans, it’s not so obvious to validators on a decentralized network. But after the implementation of Pull Mode, validators started sending each other a representation of a transaction to check whether a validator already knows about it before sending the transaction itself.
That representation of the transaction is a hash: a shortened notation for the transaction that’s used in this context because it takes less computing power to transmit and read. The transaction itself is then only sent if the receiving node doesn’t already have a record of it, and if it accepts the request.
Pull Mode was tested in Stellar Supercluster, a simulation platform designed by SDF to evaluate changes to Stellar Core. You can read more about how it’s designed here. In short, it simulates a distributed network within a few computers, but with more sophistication than running a simple test on just a laptop. It’s designed to be an environment for testing how code will behave on Mainnet, without directly pushing it to Mainnet and risking any disruption.
Pull Mode was tested three ways: in a version of Stellar Supercuster meant to behave like a realistic network, in a version of Stellar Supercluster with other potential configurations, and a version that permitted limit testing, flooding the network with transactions until it breaks to determine an absolute maximum TPS.
Though Stellar Supercluster results are all relative — i.e., they can be compared to other simulations done in Stellar Supercluster, but not to the Mainnet or other public blockchains — the results showed Pull Mode increasing the maximum TPS by 72%. This is likely because Pull Mode decreases the computational power necessary to validate a transaction.
Keeping tabs
So, what should you do with this information? Well, like I said, Pull Mode is already live — it was introduced last fall, and turned on for all validator nodes with a core release last week. That means if you run a validator node, your node is using Pull Mode. And if you’re simply transacting on the network or building on top of it, you’re simply reaping the benefits (Congrats. Also, you’re welcome!).
But a thriving blockchain community isn’t passive. It’s important to stay engaged with upgrades, so when you’re looking at the code, you actually understand what it accomplishes. Because of Pull Mode, for example, you should see that running a node requires less bandwidth, memory and CPU than before.
Have ideas on how to improve Pull Mode, or other aspects of Stellar Core? Reach out with feedback on Github.
