One of the hardest things when it comes to transaction layers is “scaling”. Of course, the word transaction here does not entirely represent monetary transactions but on the broad spectrum - the movement of any form of data.
So we are looking at social networks, banking systems, investment protocols, gaming systems, and so on. Scaling these systems can be a pain in the ass, at least from what we've known through history, there's always a day where networks are congested and users remain stuck and frustrated.
Who is to blame?
As a user, it's quite easy to call out the management for their poor services, which I understand. But at the same time, unless the system mentioned is well “compensated” yet poorly functioning, then there's no reason to cast the blame on the management for its inability to handle spikes in traffic.
Scaling Blockchains For Better Business Operations
The business world is changing, there is numerous evidence that blockchain with crypto is making its way into the financial world. With this development comes the inevitable - mass adoption of blockchain tech for business management and scaling.
The only problem?
Blockchain is a great tech for business data management but sadly, it's a terrible choice for scaling, at least in its current form.
You're tempted to ask the question - why?
Well, the major reason blockchain is a terrible choice for businesses demanding a technology of scale is that blockchain battles two primary forms of scaling problems namely - business and technology scale.
What is scaling in business?
Scaling in business often refers to the ability of a company to handle growth, expanding its operations without a proportional increase in costs. This can involve increasing production, customer base, or revenue. GPT
One would expect that growth in customer base would reduce the cost of running a business but this isn't quite true with blockchain technology. Ethereum is one of the popular blockchains we can use as an example of chains with extreme business scaling flaws.
For any business building on the Ethereum blockchain, there's the risk of facing backlash when you experience growth because whilst you, as a business may not face the cost - this all will be forced on your users using the chain as a settlement layer for their operations with your business.
What is scaling in technology?
Scaling in technology commonly refers to the ability of a system or application to handle a growing amount of work, typically measured in terms of users, transactions, or data volume. Scalability is crucial for ensuring performance as a platform or user base expands. GPT
Technology scale is often a business-side cost given that the average user has no business with the heat felt by the system. Why does this happen in the first place?
Well, it all boils down to “memory” or should we call it “storage”? Sounds more fancy.
Each data that passes to or through a network needs a place to stay - storage.
For the Bitcoin network for example, there's the max block size of 1MB, so what would happen if bitcoin was used as a network to store video files? How would we go about effectively storing a video file potentially over 1GB in size in a 1MB block?
Obviously that would not work. So while bitcoin isn't designed for video files, hence nobody is trying to fit that in - to the best of my knowledge, there's still the monetary transaction flaws that cause a load of transactions to remain unconfirmed by the network. This is usually left in what is called the “mempool” until it is later reverted to the sender as “failed” if not picked by a miner going forward.
So in an event where there's a spike in transactions, the Bitcoin network would have numerous transactions pending and failing - really just bad for business.
Now - imagine bringing both scaling flaws together - this is blockchain in summary.
A blockchain network would face the combination of tech and business scaling problems in an event of mass adoption, leaving a toil on business leveraging it and users as well.
Recently, reports from cointelegraph.com highlighted a network outage on Arbitrum on December 15 - which lasted for about 78 mins.
Ethereum layer-2 network Arbitrum One has experienced an outage on December 15 for approximately 78 minutes.
The Arbitrum One network stalled at 10:29 am ET (13:29 UTC), according to an alert issued by the network's status page.
The sequencer “stalled” at 10:29 am ET (13:29 UTC) during a “significant surge in network traffic,” according to an alert that was posted to Arbitrum's official status page. At 5:58 pm UTC, Arbitrum’s block explorer, Arbiscan, showed that some blocks were being produced. However, they appeared to be only processing two transactions in each block.
Some users took to X (Twitter) to speculate about whether the outage was caused by inscriptions, as this would explain the small number of transactions in each block. This was later confirmed by the team.
Fuckin inscriptions stalled a network for 78 mins, how much of business value could actually be lost in such time frame?
Building layer 2s for Layer 1s to combat network outages
All the layer 2s I've ever heard of has been a centralized shit often just “pretending” to be “directly” serving a specific layer 1 blockchain when in reality it could quite comfortably function independently.
But what if we could build a true layer 2, and even layer 3, 4 and 5?
All serving just one purpose: being a backup chain for the previous layers.
In theory, this may be very straightforward but in practice it's expected to be a lot more complex.
Basically, each layer 1 address would have a corresponding layer 2 address whose balance would practically be a mirror of the layer 1.
Say I have 1 ETH on the layer 1
I would also have a 1:1 backed layer 2 version of the ETH I have in layer 2.
So if I move my ETH on layer 1, I would at the same time be granting my ETH on layer 2 to be moved.
Surely, all other layers except layer 1 could be slightly “centralized”, there could be a transaction delay between updates as well.
This reduces the chances of both networks facing outages or worse, layer 2 confirming a transaction that has no chain proof on layer 1.
In practice, when a transaction is initiated, there's a constant flow of communications between layer 1 and layer 2. So when a transaction is made via layer 1, its status can change between pending, rejected, accepted or confirmed on layer 2.
In an event where layer 1 faces an outage, the same transaction could be initiated on layer 2, note that given the delay between balance updates between layer 1 and 2, these tokens would still be present for moving on layer 2.
So a user could initiate the same transaction on layer 2 with the hash of the already initiated transaction on layer 1.
This ensures that the user doesn't spend the same crypto twice and that the previously generated transaction does not get reverted to the user's address.
So if layer 1 has a network outage, layer 2 could get the transactions pending on layer 1 processed on layer 2, enabling users and businesses to get a constant flow of services.
Some security measures will however need to be in place.
For example, the layer 2 generated transaction would be locked in until the layer 1 version reaches finality.
The transaction will become irreversible on layer 1 as the status should have changed to “confirmed on layer 2”.
Businesses can choose to accept these layer 2 transactions as valid whilst waiting for confirmation on layer 1.
Flaws?
The funds on layer 2 received by the other user or business will not be movable until the finality of the layer 1 version of the transaction.
So in theory, a layer 2 transaction cannot be initiated until there's a valid layer one transaction.
The hash of the layer 1 transaction is required to finalize a transaction on layer 2. This hash is typically posted to layer 2 autonomously when any layer 1 transaction is added to the chain, enabling the autonomous change of balance.
So in an event where the layer 1 network is facing usage spikes, the hash could be used to get the transactions added to the layer 2 chain to avoid a blockage in business operations or value flow.
There could be numerous other flaws to this that could pose a huge risk to end users and the blockchain as a whole, however, it could also be enhanced to attain the scale of delivery needed to make blockchains more efficient.