Protocol congestion is a perennial problem in the blockchain ecosystem. Various measures have been implemented to avert congestion, but most struggle to offer a long-term solution.
Protocols have tried increasing their block size to increase the number of transactions they can hold and decreasing block production time to increase block generation. Though these measures worked in the short-term, they soon reached their limit. Thus, nearly all existing protocols cannot compare their transaction rates to those of centralized platforms.
The blockchain ecosystem has experienced transaction delays, massive transaction fees, and other inconveniences as a result of congestion within blockchain protocols.
Now, protocols like Aelf are out to change this narrative.
This article explores the congestion issue in the blockchain system, specifically on the Ethereum and EOS protocols. It also explores why Aelf will not be affected by the problem of congestion.
More Users = More Transactions
According to a report by Deloitte, blockchain is changing the business landscape, causing industries to adjust their operations based on the solutions it offers. This is also being seen in governments. The report also highlights that blockchain is yet to reach its full potential.
Blockchain is growing significantly, and one of the best examples of this is the congestion in Ethereum. Back in 2017, one of the first signs of future congestion was the d’App, CryptoKitties, which caused massive congestion in the Ethereum network- at one point resulting in a six-fold increase in total network requests.
These furry kittens were the source of great delays on the Ethereum network upon release | Source
It is also worth noting, that during the peak bull run in 2017, Bitcoin also suffered from a massively congested network and transaction time delays. The situation got so bad, some transactions took over two weeks to complete!
The delays were caused because Ethereum could only meet 15 transactions per second (tps) at the time. Even without CryptoKitties, the platform was eventually going to suffer massive delays as more people used their protocol.
Ethereum is now living the congested future of its platform as Tether transactions load its network with numerous requests that often leads to delays in the Ethereum Network. Despite increasing their block capacity by about 25%, it is not enough to meet the growing number of transactions on their platform.
Attempts Towards Greater Scalability
Over at EOS, things are not going as planned.
The protocol is among the networks that ushered in blockchain 3.0 promising faster transaction rates. This was achieved as EOS outperformed Ethereum and Bitcoin in transaction rates.
However, because of their network set up, their platform weakness was exposed in 2019 as EOS experienced a massive delay caused by a specialized Denial-of-Service (DoS) attack.
DoS attacks are successful when the targeted platform is flooded with numerous transaction requests; thus, legitimate requests cannot be processed in a good time. This can be further specialized when attackers use Distributed-Denial-of-Service, which specifically targets a single network or server, thus rendering the platform ineffective faster.
For EOS, their network weakness was exposed as the attack targeted the blockchain layer. The attacker posted so many deferred transactions that when the time came to process them (deferred are given priority over new transactions) that no new transactions could be processed The attack produced numerous trash transactions that made valid transactions useless. The attack was made via a d’App hosted on EOS.
Because the issue was not addressed since January, another attempt to slow down the network was successfully made. The plan was likely carried out to determine the limitations of the EOS network.
An airdrop was planned on the EOS network, where users would be rewarded with tokens if they frequently transferred EOS tokens into and out of the EOS network. The airdrop event created congestion because of the number of transactions being generated on the EOS network.
The congestion created on EOS on both instances can be attributed to the function of deferring transactions to a later time. This allows attackers to technically block other transactions for the period it will take to process all their ‘deferred’ transactions.
Aelf’s Simple Brilliance
Ethereum and EOS are both suffering congestion as a result of the growing number of transactions daily. These protocols are also likely to suffer congestion from planned attacks on their network.
Aelf drew lessons from both EOS and Ethereum to develop a platform that solves the issue of scalability.
On the issue of transaction rates, Aelf created a platform that achieves high tps. The tps are performed on-chain, and this is created through separation and specialization. Aelf’s protocol separates transactional data and computational dependency, which significantly impacts their tps.
Furthermore, Aelf implements parallel data processing through the separation of transactional data. This helps Aelf achieve even high tps on-chain.
The separation of transactional data is done using side chains. Aelf implements a branched-chain network as opposed to the single-chain system that is in use by both EOS and Ethereum. The branched-chain network allows Aelf to dedicate each side chain to a particular transaction type.
Aelf achieves its side chain specialization by using a “one chain to one type of contract” system. Therefore, one side chain can only process requests from one type of contract only. This makes the Aelf system highly specialized while still maintaining a simple structure.
Moreover, within the dedicated side chain, other side chains can be formed depending on the demand and needs of the network. This system resembles partitioning or sharding in database architecture and is known as “Tree Branch side chain extension” in the Aelf ecosystem.
The” Tree Branch side chain extension” acts as an emergency overflow system that protects Aelf from congestion by creating other side chains that can process transactions in case transaction requests outweigh Aelf’s capacity at the time.
A visual example of Aelf’s ‘Tree Branch’ | Source
Aelf’s side chains communicate through the main chain in the form of a Merkle tree root. Communication between the side chains is not direct. The information must pass through the filtering system of the mainchain to determine whether the data can be passed from one side chain to the other. The filtering process is based on the protocol’s guidelines.
These implementations deter deferred transactions, which makes it impossible for planned attacks to slow down the network through numerous “fake” transactions.
With Aelf’s set up, they are ahead in terms of scalability and security and, thus, a worthy choice for setting up a d’App.
Having seen the limitations of EOS and Ethereum, it is clear that their congestion problems are inevitable. Aelf remains the only platform that is immune to network congestion. The use of a side chain set up to isolate and categorize transactions is a simple yet brilliant idea implemented by the Aelf team, which assures Aelf of scalability throughout its lifetime. Aelf may have cemented themselves in blockchain history through its platform.
For more information of Aelf's platform, please follow this link.
#Aelf #DPoS #Blockchain #ParallelProcessing $ELF
Disclaimer: Please only take this information as my OWN opinion and should not be regarded as financial advice in any situation. Please remember to DYOR before making any decisions.
♂️ Hi, my name’s Sal.
If you found this article useful and would like to view my other work please be sure to clap and follow me on medium and LinkedIn!😎
No comments:
Post a Comment