Comparison Between EVM, Solana Runtime, MoveVM

Intro

We believe Move language has the potential to become the most widely adopted smart contract language from various perspectives and one of the reason is the design of its Virtual Machine (VM).

Therefore, we will discuss the differences between EVM and Move VM, while touching upon some features of Solana Runtime to give you a deeper understanding of the difference between them.

Lastly, a reminder that this article might be difficult for readers who are not familiar with blockchain technology. TL;DR of all this, Move VM combines the advantages of EVM and Solana, making it an excellent choice! Now, let’s dive into the main content…

1. EVM

Everyone should be familiar to EVM, as most blockchains nowadays are EVM compatible. There are two reasons for this:

1. Directly adopting EVM eliminates the requirements to redevelop the application layer.
2. Attracting projects that have already developed smart contracts using Solidity to deploy on the new blockchain. Which will also attract both investors and users. As the number of users grows, on-chain activities increase, leading to a higher demand for the native token (for gas fees).

The design of data structure is simple enough in EVM. Smart contracts act as both databases and backend logic. In addition to EOA (externally owned accounts) storing the amount of native tokens held, data for other assets is stored in the corresponding smart contracts.

For example, the USDC contract records the amount of USDC held by a particular address (database) and the interface for who has the ability to mint(backend). When Alice transfers 100 USDC to Bob, the contract subtracts 100 from the balance of Alice’s address and adds 100 to Bob’s balance.

The mapping in smart contracts is like a database.

Advantages

It is user-friendly for both frontend and backend developers. Once the data storage and logic of the contracts are defined on the blockchain, the frontend is able to interact with contracts with just calling an API, and the rest is up to the EVM to perform.

Interaction between contracts is also easy. As long as you know the interface and address of the contract, you can call smart contract functions from another smart contract. It can be said that a major reason for EVM and Solidity flourishing into such a large-scale ecosystem is their developer-friendly character.

Disadvantages

Although the binding of the database and backend logic is intuitive, have you ever thought about its drawbacks?

(1) Storing too much same logic on the blockchain

Suppose Alice and Bob each deploy an ERC20 contract. The similar or identical logic is stored on the chain twice, resulting in very inefficient space utilization. Although EVM has the delegateCall feature and some people have been advocating for the use of Diamond contracts, it doesn’t guarantee widespread adoption.

So ,how many ERC20 and ERC721 logics are now redundantly stored on the chain? It gives me goosebumps just thinking about it.

(2) Inability to parallelize processing

Since contract operations do not need to handle data storage, the EVM does not know which data on the chain will be modified before execution. Everything is only clear after execution, which prevents EVM from parallelizing processing. Otherwise, there would be data race issues, i.e., when two transactions attempt to modify the same data simultaneously, it could lead to strange results.

That’s why Ethereum transactions must be sorted and settled one by one. As for the high gas fees caused by sorting transactions based on gas price, I won’t go into detail here. All I can say is that it’s not friendly to poor people like me!

(3) Security issues

Are you sure the tokens and NFTs you hold are safe? Have you ever looked at the smart contract contents? Those who read the article up to this point likely won’t bother to look at the contract details, and it’s even more unlikely for other users to do so.

You might think that everyone is just inheriting OpenZeppelin’s ERC20 and ERC721 contracts, and as long as the contract is implemented, the correct transfer and authorization methods are ensured, right? In fact, ERC20 and ERC721 only define the interfaces (IERC20, IERC721) and do not strictly specify the logic.

So when implementing ERC20, you can change _transfer to “when transferring money to someone else, their assets will be halved,” and it’s easy — just an override. Although this flexibility is interesting in some aspects and can create some fun tokens, it’s not interesting when it comes to “assets.”

Whether what you hold is an asset or game points depends on whether the contract strictly enforces the behavior that assets should have.

Going back to the initial question, will you really take the time to carefully examine the smart contract content?

2. Solana Runtime

Next, let’s talk about Solana. Apart from the POH (Proof of History), which just seems to be some kind of PoS, it’s the Runtime design of Solana that really shine.

It separates logic program and data storage to the greatest extent possible.

Program — The essence of Solana

The “Program” itself is stateless. It is pure logic. Like a water pipe, data flows in and then flows to other places, and the pipe remains unchanged. On the other hand, “Accounts” are storage that serve as the inputs and store the outputs of corresponding “Program”.

Thus, the Solana blockchain appears to consist of “function” and “memory.” When sending a transaction, you need to tell the Runtime which functions are called and which memories are being accessed. If an account doesn’t exist, it needs to be allocated.

And because Programs can be reused, most of the time, there’s no need to deploy new Programs. The existing ones on the chain are sufficient. You just need to set up the Accounts for the Programs to access.

SPL-Token

The main assets on Solana are SPL-Tokens, where SPL stands for Solana Program Library.

The Solana team has developed and deployed a series of Programs, just like you can use functions starting with std:: when writing in C or Rust. Token Program, for example, is one of the Programs in SPL, and the assets processed by this Program are called SPL-Tokens.

Issuing tokens on Solana is quite simple. You only need to do two things:

1. Create a Mint Account under the Token Program to record the token’s name, total supply, and other information.
2. For anyone who wants to obtain the token, they just need to create a Token Account, recording which token they want to receive.

The process goes like this: If Alice wants to transfer 100 tokens to Bob, she tells the Runtime, “I want to call the Token Program.” Then she provides the Mint Account for that token and both her and Bob’s Token Accounts to the Runtime. After the block confirmation, Alice’s Token Account will have its balance reduced by 100, and Bob’s will increase by 100.

Solana Token Program

Advantages

(1) Parallel processing, high TPS

The Runtime knows all the Accounts that will be used in a transaction before processing it (because you have to tell it), so if two transactions don’t access the same Account, they can be processed in parallel. This is one of the reasons why Solana’s TPS can be so high.

(2) No need to rewrite logic

There’s no need to rewrite logic most of the time, because you can combine the Programs in the SPL to create cool and complex things.

(3) Not easily overridden

Since the logic of the assets is shared, as long as you confirm that your token is an SPL-Token, you can be sure that it operates as a basic asset should, without appearing or disappearing out of thin air.

Disadvantages

(1) Although it sounds simple, in reality, Solana development is not easy

Just collecting all the Accounts needed for a transaction is enough to keep you busy. If you want to develop a Program that requires other Programs, you’ll need CPI or PDA. We not going to discuss the details here, but you can tell from name of Solana podcast series, Chewing Glass, that it is not easy to develop on Solana, including frontends or smart contracts.

(2) Account and private key management issues

There is also a management issue with SPL-Tokens.

On Ethereum, a single address can hold multiple tokens, as mentioned earlier, with the number of tokens being recorded in each ERC20 contract. However, under the SPL-Token architecture, a separate Account is required to store each token. If you hold ten tokens, you have ten accounts and private keys to manage, which is like carrying ten keys when going out — quite cumbersome.

There is actually a solution to this problem: search for ATA (Associated Token Account). In short, it’s a method to associate each Token Account with your main account. However, this still requires some additional computation and the intelligence of engineers.

3. Move VM

The protagonist of this article finally appears.

Solana’s SPL-Token seems to be a design with few problems, and although EVM’s ERC20 appears to have several issues, it has been in use for years, and people are having fun with various DeFi applications.

Can Move and Move-VM break through and become the most suitable language and architecture for managing on-chain assets? Instead of relying on my prediction, let’s take a look at a proposal from Solana’s official website:

The content is roughly as follows:

1. The EVM system, which cannot be parallelized, is disparaged according to convention.
2. It mentions that the Move language allows for parallelizable account processing.
3. It acknowledges that the Move VM handles cross-module invocations more efficiently.

In the end, the proposal attempts to define a way to embed the Move VM such that:

1. Cross-module invocations within Move do not require the runtime’s cross-program runtime checks
2. Move programs can leverage functionality in other Solana programs and vice versa
3. Solana’s runtime parallelism is exposed to batches of Move and non-Move transactions

This means that Solana wants to integrate MoveVM into its Runtime and support the development and deployment of modules using the Move language. It’s worth noting that each language and architecture has its supporters. It’s an accomplishment for Move to be praised by competitors, but to make competitors understand its advantages and collaborate — that’s truly extraordinary!

Alright, let’s get back to the main topic about Move.

We can’t avoid mentioning… the relationship between Move and Rust

Move is largely inspired by Rust, inheriting many of Rust’s excellent features while specializing for the needs of blockchain.

Initially, I wasn’t very comfortable with this specialized language. Solana developed purely in Rust seems great, so why create a slightly different language that causes confusion for developers (for example, changing “fn” to “fun” — where’s the fun in that…)?

In fact, there are advantages to this approach because the operation of blockchain nodes is not like running a program on a regular computer. In a blockchain, anyone can deploy programs or contracts on the chain for everyone to use, so there must be a manager to regulate them.

Developing with a general-purpose language like Rust would require additional programs for management, which is the role of the Solana Runtime. However, coordinating these programs consumes extra computational power and requires developers to pay attention to the Runtime’s mechanisms and rules.

What about Move? Move, like Solidity, has a corresponding VM and a set of OpCode, so essentially, after compilation and deployment on the chain, programs can interact seamlessly without the need for additional coordination programs. In simple terms, the ability to interact well with other modules is already internalized in their “genes” during compilation.

According to Solana’s official website, Solana’s program management is similar to the way dynamic languages like Python are handled, while Move is more like a static language like Java, self-restricting through a domain-specified approach.

Unlike Solidity and EVM, Move also supports parallelization because the data is primarily stored under the Account. At this point, let’s have a brief summary:

Move VM combines the advantages of EVM and Solana Runtime, and on top of the account-based foundation, it eliminates the account management method like ATA.

Finally… we can explain in detail why Move is so powerful.

Generics

Generic and Trait are very powerful features of Move. Simply put, you can implement operations for any type with a certain characteristic, and this operation can be applied to any type with this characteristic, whether it is a type defined by someone else or a type to be defined in the future.

More specifically, you can implement area calculation operations for any type that can define length and width. In the future, when someone defines a data type with length and width, they can also use your defined area calculation. What’s the use of this feature?

You can create a universal logic operation and applying such features to asset definitions is particularly suitable. Move can define the operations needed for assets around the Coin type.

In this way, it is similar to Solana’s SPL-Token, directly setting a logical standard for Tokens or Coins to ensure asset security. Users can easily check whether their assets belong to a certain specification (remember the disadvantage of Solidity, where you might lose out if you don’t look at the contract?).

Take Aptos as an example; by checking if the assets you hold are of the type 0x1::coin::CoinStore<?>, you can know that the assets are regulated by the standard module 0x1::coin.

What does the above string (0x1::coin::CoinStore<T>) mean? This is about Resources.

Resources

Move believes that data under an account is sacred and inviolable. Assets under an account are the resources you own, called Resources. Each Resource has a Key, such as the 0x1::coin::CoinStore<T> in the previous example, which will only exist once under the same account. Using generics, this type can be extended to various coins, such as <USD> and <JPY>, allowing multiple coins to exist under your account, but these coins all follow the same specification because Move VM stipulates that only the 0x1::coin module can operate 0x1::coin::CoinStore<T>.

This Key string contains complete specification information. 0x1 is the Account address where the standard module is stored, and coin is the module that stipulates the coin specification. CoinStore is the type defined in this module, which stores how much coin you have. Only the 0x1::coin module can operate the types defined under it. The following two diagrams illustrate the difference between Solidity and Move in storing data.

The assets are recorded in the smart contract.

The assets are really under the account of the holder.

Account address as the primary key, aiding parallelization

As you can see, unlike Solidity, Move does not put the contract address at the first level of retrieval but starts with the account address. This design can help with parallelization, as mentioned earlier.

Rigorous tree structure

At first glance, it seems more similar to Solana, but Solana does not have such a rigorous tree structure. Each account address is like scattered memory addresses in a computer, basically uncorrelated, and needs to be organized by Runtime and other programs. In Move, the Key and Resources structure achieves an effect similar to Solana ATA, and it is built-in, without the need to invoke the ATA Program.

Conclusion

Move has the advantage of specialized languages like Solidity, with simple and pure module interactions, and also absorbs the parallelization advantage of Solana’s account-based approach. It’s truly excellent.

Author

Greg Shen is the Co-founder of Bucket Protocol and InJoy Labs. With extensive experience as a full-stack developer and BUIDLER, Greg is a dedicated blockchain developer with a passion for innovation and continuous learning.