Blog • Web3 era challenges for blockchain techn...

Web3 era challenges for blockchain technology and possible solutions

Sep 22 • 7 min read

Why Web3 and blockchain are inextricably bound

Web3 is the concept of developing the internet using blockchain technology and tokenizing everything that can exist online. Since the web is closely intertwined with assets from the real economy, almost anything can be tokenized, whether it’s an artist’s original work or the right to own a piece of real estate.

Spoiler

Let’s clarify something right away: Web3 is a term formulated by one person and today is commonly used only within the crypto community. The term “Web3” was proposed by Gavin Wood, co-founder of Ethereum, who also founded the Polkadot project and Web3 Foundation. The term “Web3,” proposed by Wood in 2014, is different from the concepts of Web 3.0 and semantic web, which appeared much earlier — at the end of the twentieth century.

Transactions conducted with tokens and cryptocurrencies are recorded in distributed registries. Many projects developing data recording in distributed registries today use a data structure in the form of a directed acyclic graph, the nodes of which are blocks that store information about previous blocks and transactions made since the previous block was conceived. This data structure, as you might have guessed, is called a blockchain.

Web3 applications must run fast, rely on distributed computing, provide security for the average user, and guarantee the integrity and truthfulness of the recorded data. Distributed computing and data will eliminate the need to concentrate computing power in the hands of a small group of tech giants like Google or Amazon, to whom users today inevitably entrust the storage and processing of their own data, including private data.

Considering all of the above, we can formulate a requirement for a Web3 platform capable of ensuring the smooth functioning of the world wide web network in its third iteration. It should be a distributed network with the highest level of security, an impregnable transaction validation algorithm, maximum decentralization, and unprecedented throughput. Many existing blockchain projects seeking to lead the technology race to Web3 are unfortunately facing the problem of low network throughput capacity, which hinders further development of the ecosystem.

That said, there is no guarantee that the Web3 era will ever arrive. However, the predictions of experts in one technical field or another often come true. Today, there is hardly a person alive who dreams of returning to the Web 1.0 era (the term was given retrospectively to the pre-dot-com-boom internet after creation of the term Web 2.0, which describes the Internet in its current form).

For the purposes of this article, we will assume that Web3 will eventually replace the second version of the web, that developers of solutions existing today will be forced to reformat their products to fit the new realities, and that the internet will belong equally to each of its users, rather than to a few centralized players in the IT market.

What’s happening in practice?

Below, we are going to evaluate several Layer 1 (L1) blockchains, considering pairs of highly loaded decentralized applications that work reasonably well simulating the work of other applications built for Web3.

Uniswap on Ethereum: the first large-scale Web3 application in the DeFi realm

Let’s start with Uniswap, a decentralized exchange (DEX) for spot trading cryptocurrencies and tokens with an Automated Market Maker (AMM) system. Today, Uniswap operates on EVM-compatible blockchains. Initially, the DEX was developed on the Ethereum protocol, the first distributed network with smart contracts. It was smart contracts that made it possible to develop products with complex logic like Uniswap. This is a fully decentralized exchange whose logic is written solely on smart contracts.

The Ethereum Virtual Machine (EVM) is responsible for the execution of smart contract code in the Ethereum blockchain. The architecture of this virtual machine was described back in 2014. The Ethereum Virtual Machine supports the construction of networks capable of executing only synchronous code, which leads to scalability problems for Ethereum.

The developers of the most popular Layer 1 blockchain see the solution to Ethereum’s scalability problem in Layer 2 (L2) chains. These are essentially sidechains (separate blockchains) built on the basis of the Ethereum protocol and its virtual machine. Communication with the underlying network occurs through bridges, which can be a target for hacker attacks. In general, using third-party networks, transferring funds through bridges, and the necessity of storing multiple currencies to pay commissions on different networks do not add up to a quality user experience.

But let’s return to Uniswap. Ethereum’s network throughput problem leads to users competing to add a transaction into a new block by offering more and more gas to validators. In addition, the protocol itself raises the base fee if the amount of gas (read as number of transactions) filling the block exceeds a certain limit.

As a consequence, when the network is subjected to high loads, for example, during a frenzy of demand for a coin traded on Uniswap, Ethereum users face a situation where $20 or more in ETH is required to include a transaction in a block. And all of this occurs today, during the “crypto winter,” when activity on the networks is generally low. In bull market conditions, the network fee on Ethereum is consistently high. This problem will become more and more acute in the future as the number of users in the ecosystem grows and the value of ETH itself rises.

What if Web3 does come and trading on Uniswap is as widespread as trading securities on the traditional stock market? Ethereum’s synchronous architecture has a time limit for creating a new block of 12 seconds and it also restricts the maximum amount of gas included in each block. What if a million Uniswap users wanted to buy some digital asset at once? This would pose the risk of blocking all other transactions on the network, and remember, Ethereum transactions are not limited to trading on Uniswap.

dYdX: reasons for moving from Ethereum to a proprietary blockchain on Cosmos

Another example of a highly loaded application is the decentralized derivatives trading platform dYdX. Its developers faced even more obstacles in creating a high-quality decentralized application based on the Ethereum blockchain.

In addition to dealing with low throughput capacity and high fees charged as EVM fees, dYdX requires high block finalization speeds to reflect real-time changes in order books. The transitional solution was to use StarkWare’s L2 blockchain, which, as later became clear, cannot fully meet the needs of a decentralized exchange with high trading volume.

The fourth version of the dYdX protocol involves moving the entire architecture to a proprietary blockchain built on the Tendermint core of the Cosmos project. The Tendermint core and the Cosmos SDK developer toolkit make it possible to build narrowly focused blockchains by laying down the application logic at the blockchain level. The consensus mechanism, however, remains the standard one described in the Tendermint core. All applications in the Cosmos ecosystem are thus deployed as separate blockchains with the ability to interact with each other.

The address format helps to tell which blockchain the address belongs to:

ATOM: cosmos1mzfzfe57tyj6m4f8j5dv98qqaurjn39v92k6tg
AKASH: akash17vz8hvg96lddwawdfygvu89ua4v7qgd6y39jvvv
OSMOSIS: osmo12ndfvm5pmpl0w9gpz7qep5q44exfkz8ulywz4a

And the dYdX blockchain will soon be available as well.

What are the disadvantages of the dYdX transition to Cosmos?

This heterogeneous approach increases the overall throughput of the whole ecosystem, as each application runs on its own blockchain, but it has its disadvantages:

The security of each blockchain depends on the number and quality of validators in each particular blockchain;
- Allowing invalid blocks in one blockchain can compromise the security of other blockchains and the security of the entire ecosystem;
- The Cosmos project has yet to address this issue. One option is to rent validator capacity from the core network, Cosmos Hub;
- The Cosmos blockchain itself has no additional functionality, and the Cosmos blockchain coin (ATOM) has value based largely on faith in the future of the project and its ecosystem.
Validator fees are paid in native blockchain coins, which can negatively impact the user experience. Want to use a decentralized exchange for spot trading and liquidity pools on Osmosis? Every transaction will require payment of fees in the OSMO coin. The same awaits dYdX and other future ecosystem applications.
The Tendermint core does not allow for sharding of computational power between validators. This means that transaction validation in every single blockchain in the Cosmos ecosystem happens in a synchronous manner. As a result, during load spikes within a single application (and we’ve already mentioned what throughput capacity may be required during the Web3 era: hundreds of thousands of transactions per second), the entire blockchain will slow down.

As we can see, the Cosmos project decided to take a path that differs from the Ethereum one. Instead of smart contracts with freely programmable logic hosted on a single network, the Cosmos ecosystem consists of multiple blockchains, each implementing its own business logic. Would such a solution be suitable for providing a stable Web3 experience? Given the disadvantages listed above, it is highly unlikely.

Asynchronous execution – the solution for blockchains in the Web3 era

Cosmos is not the only network with a heterogeneous nature (Polkadot is another well-known example), and Ethereum is far from the only network with smart contracts. However, all of them lack one thing: parallelization of the load across validators for asynchronous execution of smart contract code or blockchain program code. It is desirable that this feature is built in at the protocol level and in the virtual machine, if there is a need to implement smart contracts, so that all future applications are written according to the asynchronous approach.

By now, you’re probably thinking that building Web3-enabled applications requires a distributed network with a huge throughput capacity intrinsically available at the protocol level. And you likely think that such a network should somehow work asynchronously, distributing the load among several or several hundred validator groups.

In such a case, there would be no need to limit the block size or regulate demand. The stability and speed of such an asynchronous blockchain would not deteriorate due to large numbers of users, and the experience of interacting with applications deployed on such a distributed network would almost be similar in quality to the best centralized Web2 products.

Asynchronous blockchains on Threaded Virtual Machine (TVM): architecture for Web3

As developers of decentralized applications on Everscale and Venom, we will be writing about these networks running on Threaded Virtual Machine (TVM). There is another asynchronous network where the TON Virtual Machine — a previous iteration of TVM — is responsible for executing the smart contract code. This network is known to many as Telegram Open Network (TON). In principle, some of the theses about Everscale and Venom will be valid for this blockchain as well.

We have already covered the possibilities of asynchronous blockchains built on TVM. In addition, we wrote about the peculiarities of developing smart contracts in the Threaded Solidity language, which is compiled into TVM instructions.

A brief summary of the features of the TVM-based Everscale and Venom networks:

All entities on the blockchain are smart contracts;
Smart contract code should be concise, ideally describing a single action in the network, so the network would look like runtime for microservice (smart contract) interactions;
Smart contracts interact by exchanging messages. Receipt of a valid message results in the execution of the smart contract code;
Execution of the smart contract code generates a transaction;
Smart contracts are dynamically distributed across computing threads;
Each thread is assigned its own set of validators;
Transactions from different threads are collected by different validator groups into different blocks asynchronously;
The maximum number of threads in a single Workchain is 256 today and 65,536 in the future;
TVM-networks are heterogeneous: one Masterchain (Workchain -1) preserves the network state of many Workchains (most smart contracts describing the logic of decentralized applications are deposited into Workchains);
The maximum number of Workchains is 232;
Smart contracts from different Workchains freely exchange messages with each other.

As a result, we have a distributed network capable of handling millions of transactions per second. The only drawback here is that developing contracts for an asynchronous architecture is more complex and more demanding than for synchronous networks like Ethereum.

Workchains can be flexibly configured to act as separate blockchains, like the Zones in Cosmos. And TVM allows you to write freely programmable smart contracts whose code will be executed at high speed and efficiency due to the architecture of the virtual machine itself.

Block finalization times can reach sub-second values — all flexibly configurable by settings stored in Masterchain contracts. In addition, the speed of block finalization is positively impacted by an improved consensus algorithm, Soft Majority Fault Tolerance (SMFT), which speeds up consensus by assuming that most validators are honest and functioning normally most of the time. The new consensus algorithm, however, has no impact on the security of the network and does not add any vulnerabilities.

All of the above leads to a fast, scalable, secure Layer 1 solution whose functionality can be quickly and easily improved following decentralized votes.

With this set of characteristics, the Everscale and Venom networks are suitable for developing Web3 applications that can process transactions from any number of users seamlessly, quickly, and consistently.

Are there any asynchronous competitors to Uniswap and dYdX?

Yes, today Everscale has applications that can partially demonstrate the potential of asynchronous networks (the full potential will only be realized with a serious increase in the number of users). Computing tracks are divided and merged depending on the current load on the network.

The animation below demonstrates a step-by-step representation of interaction between a Web3 application and the Everscale network:

The application sends an external message to the network;
The message invokes the business logic of a smart contract (in practice, this results in a chain of smart contract code execution);
Smart contracts are deployed in the Everscale network;
The ever refreshing state of the network is downloaded by the nodes;
The node software transforms the smart contract code into TVM instructions that are executed by the latter;
The TVM returns new data to be recorded into the network;
The node sends the new state to other nodes as part of the validation process.

One example of such an application is FlatQube, a decentralized exchange for spot trading and decentralized liquidity pools. Its logic is fully described in smart contracts capable of asynchronous interaction with other contracts.

Recall the hypothetical situation we posed above: “What if a million Uniswap users want to buy a digital asset at one time? This would risk blocking all other transactions on the network.” With FlatQube, such a problem would not arise. A single FlatQube trading pair is a smart contract. If a huge number of messages conveyed to this contract arrives in the queue, it can remain the only one in its thread. Then a whole dedicated group of validators will be allocated to process transactions for trading in this pair, the computing power of which will be quite enough to process requests of any number of traders.

And most importantly, processing transactions in this computational thread will have no negative effect on transactions from other threads: no slowdown of the network, no increase in fees, no delays in execution or getting stuck in the mempool.

There is also Gravix, a decentralized derivatives trading platform that runs on the Venom blockchain. With high blockchain finalization rates and overall network bandwidth, Gravix supports on-chain orderbook updates.

This is the benefit of today’s efficient L1 solution: developers don’t need to develop their own blockchain with SDK or think about L2 solutions, cross-chain bridges, and the like. It’s enough to learn how to write asynchronous smart contracts and understand the architecture of an asynchronous heterogeneous decentralized network to build flexible, easily scalable applications whose security is guaranteed by the distributed protocol of Everscale or Venom.

Web3 applications: not just DeFi

If we talk about Web3 as the next generation of the internet as a whole, we should also pay attention to services familiar to people who are not immersed in crypto topics.

An example of such a service would be regular email. The use of email services in the Web2 era carries risks, the main one being, of course, hacking of the centralized servers of the companies to which we entrust the storage of our personal correspondence. In addition, the companies themselves are now free to provide your mail messages on demand. This situation is aggravated by the fact that this request can be forged and your correspondence could easily fall into the hands not of law enforcement agencies, but of a scammer, who for one reason or another may benefit from the possession of information from your emails.

The only architecture for truly secure email is an application deployed in a distributed network with end-to-end encryption.

Needless to say, the audience for such an application could number in the tens of millions of users, both corporate and private. Of course, maintaining the stable and fast operation of such a decentralized solution requires a network with outstanding scalability.

In the Everscale ecosystem, a decentralized email service with encryption already exists: Qamon. Like the others described above, this service is built entirely on smart contracts: it is essentially a mail service for communication between accounts in the Everscale network. We will tell you more about Qamon in the coming articles.

Conclusion

The advent of the Web3 era has the potential to dramatically change the current landscape of power distribution between players in the L1 blockchain field. We believe that the future lies in asynchronous, scalable, fast, decentralized, and secure networks. We invite you to check out our developments on Github: there you will find not only developments in decentralized applications, but also useful tools for developers working on TVM-compliant blockchains.

We also encourage you to dive into the world of modern decentralized networks and try to write your first smart contract on Threaded Solidity. Progress is inevitable!