Asynchronous smart contracts allow for the execution of multiple transactions simultaneously without waiting for the previous transactions to complete. At present, Ethereum Virtual Machine (EVM) is the most popular standard for developing smart contracts today. A significant limitation of the EVM is that smart contracts are strictly synchronous, negatively impacting the network’s ability to scale. Maintaining strict compatibility with the EVM standard and toolchain prevents the industry from questioning some of its basic paradigms.
So, a move towards the concept of asynchronous smart contracts could significantly improve the scalability of the network and open up new possibilities for decentralized applications. This article will explore the potential of asynchronous smart contracts and their implications for the blockchain industry.
- Ethereum Virtual Machine (EVM) and smart contracts
- Compatibility versus disruption
- The limitations of EVM
- Asynchronous smart contracts: An example
- The world is becoming asynchronous
- Evolving towards asynchronous blockchains
- Rethinking smart contracts
- The shift towards asynchronous smart contracts is imminent
- Frequently asked questions
- About the author
Ethereum Virtual Machine (EVM) and smart contracts
The Ethereum Virtual Machine (EVM) is the most popular standard for developing smart contracts on most modern blockchains. The EVM introduced a new generation of developers to a decentralized software stack, allowing them to create trustless apps. Without smart contracts, it would not be possible to develop financial applications like Uniswap and Compound, where users can deposit actual money without fear that the app developer can access or abuse their funds.
The EVM is bigger than just Ethereum. The EVM standard and its software development toolchain that relies on novel programming languages like Solidity are frequently adopted by blockchains other than Ethereum mainnet. Moreover, the Ethereum ecosystem currently has the largest number of smart contract developers. Other blockchains attempt to acquire some of Ethereum’s market share by remaining EVM-compatible, allowing users, developers, and products to transition easily.
For example, six additional L1 blockchains beyond Ethereum — like Polygon, Avalanche, BNB Chain, and Fantom — support The DeFi protocol Sushi. This wouldn’t be feasible unless the smart contract code could seamlessly transition between chains with practically zero modification. Each one of these six blockchains is naturally EVM-compatible.
Compatibility versus disruption
Creators always deal with the following tradeoff when developing a new generation of decentralized infrastructure. Either remain compatible with previous generation technologies and stifle innovation. Or grow the industry in new directions but pay the price for re-educating the developer community. Either way, disruption is painful and always comes with a cost.
Interestingly enough, when Ethereum’s creators considered this tradeoff, they could have chosen to remain compatible with Bitcoin’s limited smart contracts. Contrary to popular belief, Ethereum didn’t invent programmable smart contracts. Bitcoin has already supported programmable scripts. However, those are limited in nature and are not Turing-complete.
When Ethereum’s creators considered the disruption tradeoff, they chose to break apart and innovate, giving us the first Turing-complete smart contract environment. The Ethereum ecosystem paid a hefty cost for this incompatibility decision. It had to re-onboard blockchain developers onto an entirely different software stack that was not Bitcoin-compatible.
The limitations of EVM
As newer blockchains are introduced, Ethereum’s architecture is now the conservative older generation threatening to hold back progress. Maintaining strict compatibility with the EVM standard and toolchain prevents the industry from questioning some of the basic paradigms on which EVM was based.
One of these main limitations of the EVM is that smart contracts are strictly synchronous. This limitation has a profound negative effect on the network’s ability to scale.
What does synchronicity mean exactly? Consider that smart contract A interacts with a different smart contract B and then with another smart contract C. We often see this behavior in DeFi, where multiple smart contracts interact as different “Lego” blocks of a larger protocol stack. In a synchronous environment, all three interactions will be processed atomically as part of a single transaction.
Asynchronous smart contracts: An example
Consider a user that wants to add ETH/USD liquidity to the Uniswap DEX protocol. The user will find themselves using the WETH smart contract to wrap ETH into the ERC20-compatible WETH. Then, they would utilize the USDC smart contract to transfer USD. And finally, use the Uniswap smart contract to combine the two as a liquidity provider and mint new LP tokens accordingly. All of this happens in the course of a single transaction.
Note that unrelated parties independently developed the three smart contracts, WETH, USDC, and Uniswap, for purposes other than this specific flow.
Benefits of synchronicity
The benefit of synchronicity and the single transaction paradigm is that this entire interaction is very easy to reason about as a single atomic operation. The transaction in the liquidity provider user story is made of three steps. If one of the later steps fails for whatever reason, for example, minting the LP tokens, the entire transaction will revert, and the initial steps will also roll back automatically. This means that the user will not suddenly find themselves mid-way with WETH tokens that they would have to unwrap manually back to ETH.
Limitations of synchronicity
The negative effect of synchronicity is congestion since computations cannot run in parallel. Let’s return to our liquidity provider example above. Even though the three smart contracts, WETH, USDC, and Uniswap, are seemingly unrelated, the entire blockchain platform must block and wait until their unrelated state is retrieved in full and the computation completes.
Otherwise, the computation result may be influenced, and the operation will no longer be atomic. This behavior undermines basic scaling practices like sharding since unrelated data can no longer be handled in parallel by placing it in different unrelated shards.
As the number of contracts and users grows exponentially, the inability to parallelize computations becomes the main limiting factor in network growth. Unfortunately, there is no way to resolve this issue without breaking the entire EVM model.
The world is becoming asynchronous
The evolution from synchronous systems to asynchronous ones can be seen in almost every aspect of computer science. Most systems start in their early years as strictly synchronous because this model is much easier to implement and understand. At some point, scalability triumphs over simplicity, and systems evolve to become asynchronous in order to grow.
Most operating systems, for example, began as synchronous systems that could only handle a single task at a time. You may recall historic names like MS-DOS, originally designed to run a single program. Of course, this made sense at the time. The interface was based on a command line, where the user only typed a new command after completing the previous one.
This serial and synchronous way of doing things was no longer relevant when newer graphical operating systems, such as MS Windows, were released. Suddenly, users wanted to do multiple things at once. So operating had to evolve and become asynchronous. Today, every modern operating system, either for desktops with Mac, Linux, and Windows or mobiles with iOS and Android, is fully asynchronous to support multitasking efficiently.
Another good example is databases. Programmers designed the first generation of databases assuming data was small enough to fit in one place. This paved the way for query languages like SQL, which are extremely powerful and flexible. But, these languages only flourish under the assumption that all data is readily available and is processed synchronously so that the system remains consistent. As datasets inevitably grew and could no longer fit in one place, we saw an industry shift into big data and NoSQL. Today, modern database architectures are distributed with a strong emphasis on asynchronous actions. As such, processing can take place in parallel on different unrelated shards.
Evolving towards asynchronous blockchains
In the coming years, we expect to see the demand for blockchain transitioning into mass adoption. The number of blockchain users will increase from several million to billions. And the transaction rate will grow from several dozens of transactions per second (today’s Ethereum) to millions per second. Under these requirements, the traditional synchronous paradigm will no longer hold.
Traditional databases struggled to store every Facebook post, tweet, and chat on social media, and the industry had to shift toward big data. Similarly, blockchains must shift to a different paradigm.
The Open Network (TON) is an example of a next-generation blockchain. It is among the first blockchains to fully support asynchronous smart contracts. On TON, when smart contract A interacts with smart contract B, it sends an asynchronous message. This message is processed in a separate transaction, allowing computations to be fully parallelized. This architecture was inspired by a different system that today processes millions of transactions per second for almost a billion users — the Telegram instant messenger.
This model, implemented by the TON Virtual Machine (TVM), makes TVM smart contracts incompatible with existing EVM smart contracts. A new programming language, FunC, was therefore created to replace Ethereum’s Solidity, allowing developers to harness this new paradigm effectively.
Rethinking smart contracts
This paradigm shift requires smart contract developers to readjust the way they think. Designing distributed systems for smart contracts is similar to data scientists’ shift when transitioning from concentrated SQL databases to distributed big data architectures. This is much more than just a different API; it’s a new way of thinking.
As usual, the benefits of scaling do not come without a cost. Writing asynchronous smart contracts brings a new set of challenges for developers. Returning again to our liquidity provider example, the three steps of the operation will be processed as three separate transactions. These will no longer revert automatically when one of the actions fails. The smart contract developer under the new paradigm has additional responsibility. They must roll back actions manually when operations fail mid-way before the entire flow completes.
The shift towards asynchronous systems in the blockchain is inevitable. We will not be able to scale to the next billion users on synchronous systems like the EVM. Smart contract developers will eventually have to shift; otherwise, blockchain will remain a playground for a select few, as it is today.
The shift towards asynchronous smart contracts is imminent
The EVM has played a significant role in developing smart contracts on modern blockchains. It has allowed the creation of fully trustless apps, such as DeFi protocols. However, the strict synchronous nature of smart contracts on the EVM has become a bottleneck for the network’s scalability.
As newer blockchains are introduced, it’s important to question the basic paradigms on which the EVM was based. By introducing asynchronous smart contracts, we can greatly improve the scalability of the network and open up new possibilities for decentralized applications.
Frequently asked questions
Are smart contracts asynchronous?
Is Ethereum synchronous or asynchronous?
Is Solidity synchronous or asynchronous?
Is Bitcoin synchronous or asynchronous?
Is blockchain synchronous or asynchronous?
About the author
Tal Kol is a founder of Orbs Network. He’s a passionate blockchain developer, open source advocate, and a contributor to the TON ecosystem. He is also one of the main developers for TONcoin Fund. For Tal’s work on TON, follow on GitHub. For Tal’s personal work, follow on GitHub.
Disclaimer
In line with the Trust Project guidelines, the educational content on this website is offered in good faith and for general information purposes only. BeInCrypto prioritizes providing high-quality information, taking the time to research and create informative content for readers. While partners may reward the company with commissions for placements in articles, these commissions do not influence the unbiased, honest, and helpful content creation process. Any action taken by the reader based on this information is strictly at their own risk. Please note that our Terms and Conditions, Privacy Policy, and Disclaimers have been updated.
