Whenever blockchains make it into a conversation, one of the most common questions is how decentralized a specific blockchain is. Many purists view it as a statement of the blockchain’s security, which has long overshadowed a much-needed conversation on transaction speed.
And all this is quite ironic, as decentralization and transaction speed are related. Luckily, demand for smart contracts spanning various use cases has steadily risen, meaning that traffic on blockchains is also going up in the longer timeframe.
We have people trying to stake, trade derivatives, mint NFTs, play games, build in the metaverse and do lots of other stuff that spawns multiple transactions. Consequently, we can no longer afford to neglect blockchain transaction speed for Web3 projects, so let’s define it and discuss the major related factors:
What is Transaction Speed?
Transaction speed refers to the time it takes from initiating a transaction until it is confirmed on a blockchain. But while this sounds as simple as how to quickly get a piece of data from one point to another, the reality is that blockchain transaction speed is a little more complicated than, say, copying a movie or a song from your laptop to your flash drive.
It’s also trickier than transferring data from one PC to another on a basic network like your workplace’s intranet. So let’s break it down further:
Why is it difficult to increase blockchain transaction speed?
When it comes to blockchains, the network involves a distributed ledger. Therefore, every participating computer (node) records what has happened on the entire network, and they all have to agree. Lately, alternative consensus mechanisms have tried to work around this for greater efficiency.
Some chains use proof-of-stake, while VeChain and Xodexothers use proof-of-authority in comparison to Bitcoin’s proof-of-work consensus mechanism. Still, the bottom line is, several computers have to agree before an event is finalized.
This is part of what makes blockchains different from the server-client networks used by banks, conventional payment facilities. In the case of these conventional centralized systems, one central computer usually agrees that one of the computers in the lower ranks has processed a piece of data (carried out a transaction).
Not every computer in that network has to agree on what happened elsewhere. Instead, they’ll get an updated record from the central computer, depending on their permissions.
So how can blockchains be made faster?
Several blockchains already claim to be super fast; Solana can reach 50,000 TPS while Ripple can do 15,000 TPS. When compared to Ethereum’s 20 TPS and Bitcoin’s 7 TPS, one would wonder why Bitcoin and Ethereum are quite popular.
Simple. While there are numerous ways to increase transaction speed, most come with some trade-offs. Let’s explain:
Increasing block size
In this context, a block can be viewed as a collection of transactions. Blockchains typically have a maximum amount of data they allow in a single block, and once one is full, the other pending transactions will be put in the next one.
Accordingly, some would suggest increasing the block size, but this makes it harder for some participants to keep track of larger blocks being generated in real time since that would require more computing resources.
This greater barrier to participation jeopardizes decentralization and security. Additionally, increasing block size would make performing Distributed Denial-of-Service (DDoS) attacks easier. The reasoning is that since different participants mine/generate blocks, if a participant works on a larger block, it’s easier to flood that participant with spam transactions.
Increasing block size is also a temporary fix that sets a precedent for more increases later, as its effects may not last. And there’s also the issue of how it can complicate later updates. These were some of the arguments made when some factions wanted to increase the Bitcoin blockchain’s block size to achieve a speed higher than 7 TPS.
Reducing block time
Block time is the time taken to produce and add a new block to the blockchain. Decreasing block time increases the likelihood of having orphan blocks. This is a scenario where a block is completed, but you can’t find its preceding block to attach it and continue a coherent sequence. Eventually, some transactions would be discarded or get confirmed much later.
Dispersing traffic
Traffic is the number of people attempting to make a transaction. Dispersing traffic is one of the most promising approaches to speeding up transactions. You can relieve a blockchain of some of its workload as it is processed by a sidechain that doesn’t need to have the entire record of the main blockchain or even use the same consensus mechanism.
However, many sidechains have fewer participants and aren’t very secure. And even for those fairly secure, there’s still a limit to how many transactions they can process in a given unit of time. Sidechains also require intricate setups involving bridges and transfers that aren’t actual transfers but rather erasing value on one end and reflecting it on another.
Lastly, sidechains aren’t usually packaged as something built into the chain for everyone to use automatically. Instead, you create a smart contract and then embed the option to connect to the sidechain. Then, the end-user has to opt in.
Ultimately, as more sidechains pop up and scale faster than the inevitable increase in traffic with more services connecting to them, end users will gradually feel things being faster and smoother.
Managing gas fees
A gas fee is what you pay for a transaction. It’s also a big part of how validators get paid. On blockchains like Ethereum, you can spend more gas for a faster transaction, but of course, this can lead to bidding wars. Imagine multiple transactions initiated at about the same time, only for many users to readjust the gas. This can slow things down as some people’s transactions are pushed further to the back of the queue.
It also leaves many bitter as they start to feel like a good user experience is only for the rich once the average gas fee increases during high-traffic periods. Ethereum developers have attempted to manage gas fees with initiatives like EIP1559 that burn some of the gas paid, but this only makes gas fees more predictable.
It doesn’t massively reduce the average gas required but reduces the amount by which it fluctuates. Nonetheless, one by-product of this effort is a slight, occasional increase in transaction speed, particularly in those high-traffic periods where transacting would be expected to be much slower and more expensive.
What happens if transaction speed isn’t improved?
- People can make losses if they are trading and fail to buy or sell at the desired price because a transaction is delayed while the price of the asset/commodity changes considerably.
- Bidding wars continue, and efforts like minting an NFT become less profitable since you’ll pay more to mint one, yet there’s a limit to how much money people are willing to pay for it.
- DAO votes could take longer to be completed.
- Occasionally, you may have to repeat a transaction.
- Other efforts like lending, borrowing and liquidity provision for DEXs become unattractive since you might have to pay a lot for the transaction that initiates a loan or some other service.
Most blockchains are yet to be truly tested. In fact, even VISA which claims to be able to process 24,000 transactions per second usually handles an average of 150 million transactions per day, which is about 1,736.11 transactions per second.
For most of these blockchains, we might never find out whether their TPS is accurate if demand and usage doesn’t go up faster than they are working to scale their platforms. But generally, if transaction speed isn’t improved, things are either slower or more expensive, which drives people away and impedes blockchain technology adoption.
How SparqNet is solving this problem
SparqNet is an SDK toolchain that enables users to build fast and reliable blockchain infrastructure using C++ and will eventually support other languages, all in an environment that isn’t VM-reliant.
SparqNet supports up to 400,000 transactions per second — the fastest blockchain, period. Furthermore, its internal bridging facilitates sub-second finality when subnets within the Sparq network transfer data amongst themselves.
And as for external bridging, SparqNet takes 15–30 seconds to process a roundtrip, with plenty of upside further down the road. All processing is performed in a decentralized manner, and SparqNet is platform-agnostic, allowing Avalanche, Ethereum, Solana and other blockchains to tap into its infrastructure.
With SparqNet live now, users can cache their dApps’ databases and rest assured that the storage is decentralized and the protocol optimizes the whole process to ensure the lowest latency when these resources are needed.
SparqNet also improves some capabilities associated with EVM-compatible networks, such as the automation provided by smart contracts. How? Take an arbitrage situation, for instance. To take advantage of it on a blockchain, you need to initiate a number of transactions, which immediately puts you at the mercy of the blockchain’s transaction speed.
On the contrary, SparqNet facilitates arbitrage bots underpinned by smart contracts that can call each other and set trades in motion without on-chain transactions but instead act on predefined thresholds. Such approaches help solve some of the low transaction speed outcomes mentioned above.
There is plenty more that SparqNet supports in various sectors like multiplayer gaming, video rendering, ecommerce, supply chain and logistics, among other use cases.
So on that note, if you’re an innovator or entrepreneur interested in comprehensive, cross-platform blockchain solutions, come build the future, come build on SparqNet!
Follow SparqNet today!
Website: https://sparq.network
Twitter: https://twitter.com/SparqNet
Telegram: https://t.me/SparqOfficial
Telegram Announcements: https://t.me/s/Sparq_News
Medium: https://medium.com/@SparqNet
LinkedIn: https://www.linkedin.com/company/sparq-network
