1. Introduction
Smart contract execution within the Polkadot ecosystem continues to evolve as developers explore ways to combine Ethereum development familiarity with the flexibility of Substrate-based runtime environments.
One direction being explored is the Revive smart contract framework, which introduces a dual virtual machine architecture designed to support both Ethereum-compatible execution and alternative execution environments built on modern virtual machine designs.
This approach aims to allow developers to maintain familiar Solidity workflows while also enabling experimentation with more performance-oriented execution models.
This article examines the structure of this architecture, focusing on pallet-revive and the dual backend model that combines Ethereum-compatible execution with a RISC-V-based virtual machine environment.
2. Ethereum-Compatible Tooling and Development Interfaces
Polkadot smart contract infrastructure increasingly supports compatibility with the Ethereum development ecosystem. Runtimes that expose Ethereum-style JSON-RPC interfaces allow many existing developer tools to interact with smart contracts deployed on those networks.
Source: Polkadot Docs
This compatibility layer enables developers to reuse existing tooling for contract interaction, testing, and deployment.
2.1 Middleware and Library Integration
When a runtime exposes Ethereum-compatible RPC endpoints, developers can interact with smart contracts using widely adopted libraries and frameworks.
Client libraries such as Ethers.js, Web3.js, Viem, Web3.py and Wagmi can interact with networks through JSON-RPC endpoints that follow Ethereum conventions.
Development frameworks such as Hardhat and Foundry can be used for compiling, testing, and deploying Solidity contracts when the runtime provides the necessary compatibility layers.
Common token standards such as ERC-20 and ERC-721 can also be implemented in Solidity-based environments, although the exact behaviour ultimately depends on how the runtime implements EVM compatibility.
The REVM (Rust EVM) backend provides an implementation of the Ethereum Virtual Machine written in Rust. This allows Ethereum bytecode produced by Solidity compilers to execute within an EVM-compatible environment without modification.
3. Dual Virtual Machine Architecture: REVM and PVM
One of the distinguishing aspects of the Revive architecture is its exploration of multiple execution environments. Rather than relying on a single virtual machine, the framework supports different backends that allow developers to balance compatibility with performance depending on application requirements.
Source: Polkadot Docs
3.1 REVM: Ethereum-Compatible Execution
The REVM backend provides an execution environment compatible with the Ethereum Virtual Machine model. It processes standard Ethereum bytecode and follows the same general execution structure used in EVM environments, including deterministic state transitions.
This compatibility layer allows developers who are already familiar with Ethereum tooling to deploy Solidity-based applications without needing to rewrite their smart contracts for a completely different execution environment.
For teams migrating from Ethereum development workflows, this backend provides a familiar entry point into the Polkadot ecosystem.
3.2 PVM: RISC-V Based Execution Environment
The second execution environment explored within the Revive architecture is the PVM (Polkadot Virtual Machine), which is designed around a RISC-V-based architecture.
Unlike the stack-based execution model used by the Ethereum Virtual Machine, RISC-V virtual machines typically use a register-based architecture, which more closely resembles modern processor design and can provide advantages for certain computational workloads.
Within this environment, smart contract logic may be compiled into RISC-V compatible bytecode. Tooling such as the resolc compiler aims to allow Solidity code to target alternative execution environments beyond traditional EVM bytecode.
This approach enables experimentation with execution environments that prioritise efficiency while still allowing developers to work with familiar programming languages.
3.3 Inter-VM Interaction
When multiple execution environments exist within the same runtime, external systems need to interact with the network through consistent interfaces.
In architectures such as Revive, both execution backends can operate behind a unified RPC interface. This allows wallets, developer tools, and monitoring infrastructure to interact with the network without needing to distinguish between execution environments.
This design also allows developers to explore hybrid deployment strategies where different components of an application may use different execution environments depending on performance or compatibility requirements.
4. Ecosystem Interoperability and XCM
One of the defining features of the Polkadot ecosystem is its ability to support communication between chains. This is achieved through Cross-Consensus Messaging (XCM).
Source: wiki.polkadot.com
XCM allows chains within the Polkadot ecosystem to send instructions and messages to one another in a trust-minimised way.
4.1 Runtime Interfaces and Cross-Chain Interaction
To allow smart contracts to interact with runtime functionality and other chains, runtimes may expose specialised interfaces that bridge smart contract environments with native Substrate logic.
These interfaces can enable several capabilities.
Smart contracts may initiate cross-chain asset transfers through mechanisms implemented by the runtime using XCM.
Contracts may also trigger remote logic execution on other chains by sending messages through the XCM protocol.
In environments that support multiple execution layers, runtime interfaces can also enable interaction between EVM-compatible environments and other execution environments present within the runtime.
5. Conclusion
The Revive architecture explores how Polkadot can support both Ethereum-compatible development workflows and alternative execution environments designed for greater flexibility.
By supporting multiple execution backends, the framework allows developers to choose execution environments based on the needs of their application while maintaining access to familiar tooling.
Combined with Polkadot’s interoperability model through XCM, this architecture provides a flexible environment for building decentralised applications that can interact across multiple chains.
For developers entering the ecosystem, understanding these execution environments is an important step toward building applications that can take advantage of Polkadot’s multichain architecture.