Judging from the 2025 roadmap released by Polkadot, PolkaVM is undoubtedly one of the most important technological updates, and one of the first to be deployed and applied is the support for Solidity on Westend's Asset Hub. The first thing you need to understand is that this implementation is not the previous Frontier, which is widely used on Moonbeam and other parallel chains that support EVM, but runs Solidity code on the new RISC-V-based PVM. For many DApp and smart contract developers, this will be an excellent way to enter and understand Polkadot 2.0 . Due to the large developer base of Solidity, it will also bring a lot of developers to Polkadot 2.0, allowing everyone to see the powerful and efficient execution efficiency of PVM. Let's first look at its basic principles and technical architecture. Our smart contract solution includes the following components:

revive pallet

This is the blockchain module that executes smart contracts. It adds a bunch of external functions and a runtime API like any other pallet. However, it also adds logic that allows the blockchain to handle Ethereum-style transactions. These special transactions are not submitted directly to the chain. Although this is theoretically possible. The source code can be viewed under this directory:

🔗https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/revive pallet

Instead, users (wallets, Dapps, etc.) connect to a proxy server deployed with the blockchain node. This proxy emulates the Ethereum Json RPC, which means it exposes the Ethereum JSON RPC interface as a server and connects to the node as a network client. It repackages Ethereum transactions into a special dispatchable file while keeping the payload intact . Decoding Ethereum transactions and converting them into something pallet-revive can understand depends on the above logic. By submitting the payload of Ethereum transactions verbatim to the block, we can easily adapt tools (such as block explorers) that do not need to handle different transaction formats.

The choice to use a standalone proxy was intentional: adding new endpoints to the node binary requires other clients to implement them . That's why we chose an approach that doesn't require any changes to clients.

PolkaVM

This is the most obvious change we have made compared to competing technologies. Instead of using the EVM to execute contracts, we use a new custom virtual machine . Currently, we include a PolkaVM interpreter in the runtime itself. A later update will provide a full PolkaVM JIT running inside the client. Note that we will still keep the interpreter available so that we can use the most appropriate backend for each workload. For example, for contract calls that only execute very little code, the interpreter will still be faster because it can start executing code immediately (lazy interpretation). If you need to know the details, you can check out the source code of the project:

🔗 https://github.com/paritytech/polkavm

The two fundamental differences from the EVM are:

Register Machine

The EVM is a stack machine. This means that arguments to functions are passed on an infinite stack. PolkaVM is based on RISC-V, which is a register machine. This means that it passes arguments in a finite set of registers. The main benefit of this is that since these are register machines, it makes the translation step to the underlying hardware much more efficient. We carefully chose the number of registers to make them smaller than the notoriously register-starved x86-64 instruction set. Letting us reduce the NP-hard register allocation problem to a simple 1-to-1 mapping is the secret to PolkaVM's fast compile times.

Reduce word length

The EVM uses a word size of 256 bits. This means that every arithmetic operation has to be performed on these large numbers. This makes any meaningful numeric operation very slow as it has to be converted into many native instructions. PolkaVM uses a word size of 64 bits, which is natively supported by the underlying hardware. That said, when converting Solidity contracts through YUL (#Revive), we still get 256-bit arithmetic because YUL is too low-level to automatically convert integer types. However, it is entirely possible to write contracts in different languages and call them seamlessly from Solidity. We envision a system where the business logic is written in Solidity, but the underlying architecture is written in a faster language, something like Python, with most of the heavy lifting done by C modules.

Revive

In order to run Solidity on PolkaVM, we need to compile it to RISC-V. For this, we need a compiler. It works by using the original solc compiler and then recompiling its intermediate representation (YUL) output to RISC-V. The benefit of doing this is that it is a much smaller task than implementing a full Solidity compiler. By choosing this approach, we support all the quirks and weirdness of Solidity and all its different versions. The project's address is https://github.com/paritytech/revive, and those who need to know the details can go to view the project's source code.

Remix

Remix is the most popular tool for developing Solidity, it is web-based and allows us to develop, debug and deploy contracts at any time. Polkadot also provides its own version of the chain, https://remix.polkadot.io, which can be accessed through this website. The reason we maintain a fork of REMIX is that the main change compared to the original version is that we need to change the compiler, so we changed REMIX to use the backend for compilation instead of the in-browser compiler. This is necessary because our LLVM-based revive is too heavy for the browser.

Development Practice

After understanding the whole principle, we can practice and see how to complete the development, deployment and testing of the contract . We can refer to this document:

🔗 https://contracts.polkadot.io/

Development and testing environment

First of all, the Revive pallet has been integrated into the Westend asset hub , so you can develop and test directly on it.

Of course, you can also build your own local test environment, which makes it easier to view backend logs and understand error messages.

1. Download the polkadot sdk code and compile the Kitchensink node

2. Start the node

3. Compile Eth RPC Proxy separately

4. Start the RPC service

When all the above services are started, the normal substrate service will be on port 9944, and Eth will use port 8545.

Solidity Contract

First, we can try the Solidity contract. You can use Remix to develop it directly. In Environment, there is a default westend configuration. If you use the local environment for testing, you can add the customize configuration.

This will allow us to interact with the Eth RPC service we started earlier. Of course, if you are developing a complex Dapp application, you can use other frameworks. Here we recommend that you use Typescript and Viem to experiment. We can refer to the test code that comes with the revive pallet:

🔗 https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/revive/rpc/examples/js

It also has a version using the Rust language, in a parallel directory. A simplified version of the code for deploying a contract is as follows:

1. First we initialize a wallet client.

2. How to use abi and bytecode to deploy a smart contract. Here we choose a simple contract in examples , piggyBank . It should be noted that the bytecode here is the code compiled into polkavm .

3. Call a read function.

4. Send a transaction to update this value in the contract.

5. After the transaction is completed, check again to see if the value has been updated.

Writing contracts directly in Rust

In addition to using Solidity, we can also use other languages to write contracts, compile them into polkavm code and deploy them directly. Here we refer to https://github.com/paritytech/rust-contract-template.

By deploying the polkaVM contract directly, we don’t need to use Eth RPC. Once the contract is compiled, we can use revive’s upload method to upload the contract to the chain.

After the call is successful, we can find the hash of the code in the browser event. For example, in my example, the hash value is 0x9bef6d3f29397e4994d96657375674096379ba850c31f8c7b950a6f9c13a238d

The next step is to instantiate the contract and call the Instantiate method of revive.

Here you will encounter an account unmapped error. You need to call the account map method before you can deploy the contract and call it.

Then try instantiation again and it will succeed.

Let's record some contract addresses. It is a standard Eth address. In this deployment, the contract address is 0xce58c0af740d49e573998ce92c9147565604d321.

Finally, we call the call method of revive and fill in the contract address instantiated previously. In this way, we have completed the development, deployment and testing of a PolkaVM contract.

Continuous build

After completing the basic environment construction and development process, you can complete more complex business logic. In general, polkaVM is still in its early stages. If you encounter problems or want to help complete some functions or fix bugs, you can actively submit PRs to these repos.

I believe that with the gradual delivery of the functions of Polkadot 2.0 in 2025 , the usage scenarios and scope of PolkaVM will become increasingly broad, and start-up projects can also make technical preparations in advance and be ready to develop safe and efficient products on JAM.