Everscale vs. Aptos: Comparison of scalability and decentralization design

Everscale vs. Aptos: Comparison of scalability and decentralization design

Everscale — a fifth generation blockchain

The crypto industry has already been for a while with us, and innovations are inevitably moving to the corporate and government sectors. With the increased demand for remittance payment systems and integrations with central banks and governments, blockchain technology is going far beyond DeFi and NFTs.

However, with all of the variety of multichain ecosystems, there is huge demand from the corporate world to have a decentralized, scalable solution capable of performing fifty or one hundred thousand transactions per second (estimated amount of transactions in an average country including massive peaks of usage) in a trustless way with low latency and high security.

Those are the capabilities of a fifth-generation blockchain, which is what Everscale is. At the same time, the Aptos mainnet was launched recently, and we’d like to dive deeper into the technical details and consider the theoretical and practical performance of the network.

Aptos is not a blockchain in the classic sense

To put it simply, Aptos is a product of an acceleration of a single (one-shard) blockchain. In fact, Aptos doesn’t have any blocks. Instead, there is a sequential processing of incoming messages that consistently changes the state on all nodes. That’s how finality on Aptos can be described. Broadly speaking, Aptos is a finality algorithm rather than a classic blockchain.

How does it work?

The finality is divided into separate stages. The network receives messages and sorts them. After that, all validators receive the sorted messages and change the state on all nodes. In that way, Aptos is more of a hybrid blockchain than a classic one. That’s because state changes are made not by the propagation of finalized blocks, but by paralleled deterministic finalization on local nodes.

There are no blocks in a classical sense. First, incoming messages are sorted out, and all validators come to a consensus in what order it should be applied. Afterward, state changes are being applied, and a consensus with the final state is confirmed in the end.

We can compare this with a CPU design. CPUs work in a pretty similar way — there are some commands that can be executed in parallel. CPUs try to predict the upcoming commands, and if a small piece of code doesn’t require the result of a previous code, all these commands can be done in parallel.

In other words, compliers optimize software to achieve such parallel execution in CPUs’ computations, and there’s simply no need to put sticks in the wheels and create software that would affect the parallel execution of a CPU. But there is a fundamental difference in a blockchain.

In a public chain, it is easy to build types of smart contracts that would affect many accounts and make parallel execution impossible.

This design is highly vulnerable for a public chain, as it’s all based on the assumption that nodes cannot alter their behavior during finalization process and follow the correct algorithm at all finality stages. In a real-time environment, it’s impossible to predict the exact behavior of users. The architecture and security of any decentralized system is built around the negative assumption that any nodes can be malicious but not more than 50% in total, and how we can prevent an attack. This is fundamentally important, especially because Aptos’s deterministic predictable approach is the key element in its design.

Parallel execution of transactions is possible only from real applications. But If someone wanted to spam the network, they would send transactions that affect many accounts in it. Theoretically, using a deep technical analysis, it’s possible to organize an attack and slow a chain or even halt it.

Transactions per second and the network’s speed

Block-STM is the core concept of accelerating the blockchain — this approach calculates state changes by executing transactions in parallel with further resolving of write conflicts.

Media sources and articles say this approach accelerates Aptos up to 160,000 transactions per second. However, according to the Aptos whitepaper, modeling and tests show only 8–16 times acceleration compared to sequential transaction processing, which is in reality 200–500 transactions per second (general transactions from real applications but not specialized small or artificial transactions) for any single chain as practice shows.

Even if we consider the maximum values (500 x 16 = 8,000 transactions per second), this is far from even one workchain performance on Everscale (up to 15,000 tps on each workchain) that’s achieved by multithreaded computations.

Scaling of a blockchain

Everscale can be scaled infinitely by adding more validators and workchains. That’s why our architecture allows us to scale on demand when it requires more computations. This design can also be considered as a dynamic sharding.

As for Aptos, it’s a single chain with parallel execution if transactions allow to do so. The design simply doesn’t provide for sharding. It’s not clear how it will be implemented with the current architecture. Meanwhile, Everscale is capable of both data and computational sharding and it’s already in production in a real-time environment.

Decentralization

Speaking of Aptos chain, all signatures collected are weighted without max factor restrictions, which leads to reducing decentralization (similar to EOS delegated Proof-of-Stake). That means validators get rewards for staking the maximum amount of tokens. The most profitable way is to run a single validator with the maximum stake. This naturally leads to centralization of the network.

Everscale has max factor restrictions. It’s simply not possible to validate with a maximum stake; if a participant wants to earn more rewards for validation, then more validators/nodes are required.

Concept of development on the Aptos blockchain

Aptos has its own programming language Move — inspired by Rust: Move, which is a new smart contract language for the crypto developers community. However, the most popular smart contract language with a big developers community is Solidity. For us, it is a controversial decision. A lack of tools and the need to learn a new language is a huge barrier for developers who want to join the Aptos ecosystem.

Development on Everscale

Why do we need to create a new language and tools for formal verification when we already have a proven one? You can write Everscale smart contracts using the following languages: C, C++ and Solidity, and get almost automated formal verification due to the framework developed by Everscale community members.

Summary

Aptos can be considered as a greatly accelerated single chain, and it is several times faster than a normal non-sharded blockchain. However, any single chain design eventually has its limits.

Regarding the acceleration of a single chain, Aptos developed a finality algorithm based on a sequential and parallel processing, but the impossibility of scaling and potential wide vector of attacks lead to slowing of the network and an impasse in terms of substantial growth. A reasonable question arises:

“Is it a fifth generation blockchain or another attempt to build a better Ethereum?”

Read More