EVM vs PolkaVM

Introduction

While PolkaVM strives for maximum Ethereum compatibility, several fundamental design decisions create necessary divergences from the EVM. These differences represent trade-offs that enhance performance and resource management while maintaining accessibility for Solidity developers.

Core Virtual Machine Architecture

The most significant departure from Ethereum comes from PolkaVM's foundation itself. Rather than implementing the EVM, PolkaVM utilizes a RISC-V instruction set. For most Solidity developers, this architectural change remains transparent thanks to the Revive compiler's complete Solidity support, including inline assembler functionality.

graph TD
    subgraph "Ethereum Path"
        EthCompile["Standard Solidity Compiler"] --> EVM_Bytecode["EVM Bytecode"]
        EVM_Bytecode --> EVM["Stack-based EVM"]
        EVM --> EthExecution["Contract Execution"]
    end

    subgraph "PolkaVM Path"
        ReviveCompile["Revive Compiler"] --> RISCV_Bytecode["RISC-V Format Bytecode"]
        RISCV_Bytecode --> PolkaVM["RISC-V Based PolkaVM"]
        PolkaVM --> PolkaExecution["Contract Execution"]
    end

    EthExecution -.-> DifferencesNote["Key Differences:
    - Instruction Set Architecture
    - Bytecode Format
    - Runtime Behavior"]
    PolkaExecution -.-> DifferencesNote

However, this architectural difference becomes relevant in specific scenarios. Tools that attempt to download and inspect contract bytecode will fail, as they expect EVM bytecode rather than PolkaVM's RISC-V format. Most applications typically pass bytecode as an opaque blob, making this a non-issue for standard use cases.

This primarily affects contracts using EXTCODECOPY to manipulate code at runtime. A contract encounters problems specifically when it uses EXTCODECOPY to copy contract code into memory and then attempts to mutate it. This pattern is not possible in standard Solidity and requires dropping down to YUL assembly. An example would be a factory contract written in assembly that constructs and instantiates new contracts by generating code at runtime. Such contracts are rare in practice.

PolkaVM offers an elegant alternative through its on-chain constructors, enabling contract instantiation without runtime code modification, making this pattern unnecessary. This architectural difference also impacts how contract deployment works more broadly, as discussed in the Contract Deployment section.

High-Level Architecture Comparison

Feature	Ethereum Virtual Machine (EVM)	PolkaVM
Instruction Set	Stack-based architecture	RISC-V instruction set
Bytecode Format	EVM bytecode	RISC-V format
Contract Size Limit	24KB code size limit	Contract-specific memory limits
Compiler	Solidity Compiler	Revive Compiler
Inline Assembly	Supported	Supported with the compatibility layer
Code Introspection	Supported via EXTCODECOPY	Limited support, alternative via on-chain constructors
Resource Metering	Single gas metric	Multi-dimensional
Runtime Code Modification	Supported	Limited, with alternatives
Contract Instantiation	Standard deployment	On-chain constructors for flexible instantiation

Gas Model

Ethereum's resource model relies on a single metric: gas, which serves as the universal unit for measuring computational costs. Each operation on the network consumes a specific amount of gas. Most platforms aiming for Ethereum compatibility typically adopt identical gas values to ensure seamless integration.

The significant changes to Ethereum's gas model will be outlined in the following sections.

Dynamic Gas Value Scaling

Instead of adhering to Ethereum's fixed gas values, PolkaVM implements benchmark-based pricing that better reflects its improved execution performance. This makes instructions cheaper relative to I/O-bound operations but requires developers to avoid hardcoding gas values, particularly in cross-contract calls.

Multi-Dimensional Resource Metering

Moving beyond Ethereum's single gas metric, PolkaVM meters three distinct resources:

• ref_time - equivalent to traditional gas, measuring computation time
• proof_size - tracks state proof size for validator verification
• storage_deposit - manages state bloat through a deposit system

All three resources can be limited at the transaction level, just like gas on Ethereum. The Ethereum RPC proxy maps all three dimensions into the single gas dimension, ensuring everything behaves as expected for users.

These resources can also be limited when making cross-contract calls, which is essential for security when interacting with untrusted contracts. However, Solidity only allows specifying gas_limit for cross-contract calls. The gas_limit is most similar to Polkadots ref_time_limit, but the Revive compiler doesn't supply any imposed gas_limit for cross-contract calls for two key reasons:

• Semantic differences - gas_limit and ref_time_limit are not semantically identical; blindly passing EVM gas as ref_time_limit can lead to unexpected behavior
• Incomplete protection - the other two resources (proof_size and storage_deposit) would remain uncapped anyway, making it insufficient to prevent malicious callees from performing DOS attacks

When resources are "uncapped" in cross-contract calls, they remain constrained by transaction-specified limits, preventing abuse of the transaction signer.

Note

The runtime will provide a special precompile, allowing cross-contract calls with limits specified for all weight dimensions in the future.

All gas-related opcodes like GAS or GAS_LIMIT return only the ref_time value as it's the closest match to traditional gas. Extended APIs will be provided through precompiles to make full use of all resources, including cross-contract calls with all three resources specified.

Memory Management

The EVM and the PolkaVM take fundamentally different approaches to memory constraints:

Feature	Ethereum Virtual Machine (EVM)	PolkaVM
Memory Constraints	Indirect control via gas costs	Hard memory limits per contract
Cost Model	Increasing gas curve with allocation size	Fixed costs separated from execution gas
Memory Limits	Soft limits through prohibitive gas costs	Hard fixed limits per contract
Pricing Efficiency	Potential overcharging for memory	More efficient through separation of concerns
Contract Nesting	Limited by available gas	Limited by constant memory per contract
Memory Metering	Dynamic based on total allocation	Static limits per contract instance
Future Improvements	Incremental gas cost updates	Potential dynamic metering for deeper nesting
Cross-Contract Calls	Handled through gas forwarding	Requires careful boundary limit implementation

The architecture establishes a constant memory limit per contract, which is the basis for calculating maximum contract nesting depth. This calculation assumes worst-case memory usage for each nested contract, resulting in a straightforward but conservative limit that operates independently of actual memory consumption. Future iterations may introduce dynamic memory metering, allowing deeper nesting depths for contracts with smaller memory footprints. However, such an enhancement would require careful implementation of cross-contract boundary limits before API stabilization, as it would introduce an additional resource metric to the system.

Current Memory Limits

The following table depicts memory-related limits at the time of writing:

Limit	Maximum
Call stack depth	5
Event topics	4
Event data payload size (including topics)	416 bytes
Storage value size	416 bytes
Transient storage variables	128 uint values
Immutable variables	16 uint values
Contract code blob size	~100 kilobytes

Note

Limits might be increased in the future. To guarantee existing contracts work as expected, limits will never be decreased.

Account Management - Existential Deposit

Ethereum and Polkadot handle account persistence differently, affecting state management and contract interactions:

Account Management Comparison

Feature	Ethereum Approach	PolkaVM/Polkadot Approach
Account Persistence	Accounts persist indefinitely, even with zero balance	Requires existential deposit (ED) to maintain account
Minimum Balance	None	ED required
Account Deletion	Accounts remain in state	Accounts below ED are automatically deleted
Contract Accounts	Exist indefinitely	Must maintain ED
Balance Reporting	Reports full balance	Reports ED-adjusted balance via Ethereum RPC
New Account Transfers	Standard transfer	Includes ED automatically with extra fee cost
Contract-to-Contract	Direct transfers	ED drawn from transaction signer, not sending contract
State Management	Potential bloat from zero-balance accounts	Optimized with auto-deletion of dust accounts

This difference introduces potential compatibility challenges for Ethereum-based contracts and tools, particularly wallets. To mitigate this, PolkaVM implements several transparent adjustments:

• Balance queries via Ethereum RPC automatically deduct the ED, ensuring reported balances match spendable amounts
• Account balance checks through EVM opcodes reflect the ED-adjusted balance
• Transfers to new accounts automatically include the ED (x + ED), with the extra cost incorporated into transaction fees

• Contract-to-contract transfers handle ED requirements by:

• Drawing ED from the transaction signer instead of the sending contract

• Keeping transfer amounts transparent for contract logic
• Treating ED like other storage deposit costs

This approach ensures that Ethereum contracts work without modifications while maintaining Polkadot's optimized state management.

Contract Deployment

For most users deploying contracts (like ERC-20 tokens), contract deployment works seamlessly without requiring special steps. However, when using advanced patterns like factory contracts that dynamically create other contracts at runtime, you'll need to understand PolkaVM's unique deployment model.

In the PolkaVM, contract deployment follows a fundamentally different model from EVM. The EVM allows contracts to be deployed with a single transaction, where the contract code is bundled with the deployment transaction. In contrast, PolkaVM has a different process for contract instantiation.

• Code must be pre-uploaded - unlike EVM, where contract code is bundled within the deploying contract, PolkaVM requires all contract bytecode to be uploaded to the chain before instantiation
• Factory pattern limitations - the common EVM pattern, where contracts dynamically create other contracts, will fail with a CodeNotFound error unless the dependent contract code was previously uploaded
• Separate upload and instantiation - this creates a two-step process where developers must first upload all contract code, then instantiate relationships between contracts

This architecture impacts several common EVM patterns and requires developers to adapt their deployment strategies accordingly. Factory contracts must be modified to work with pre-uploaded code rather than embedding bytecode, and runtime code generation is not supported due to PolkaVM's RISC-V bytecode format. The specific behavior of contract creation opcodes is detailed in the YUL IR Translation section.

When migrating EVM projects to PolkaVM, developers should identify all contracts that will be instantiated at runtime and ensure they are pre-uploaded to the chain before any instantiation attempts.

Solidity and YUL IR Translation Incompatibilities

While PolkaVM maintains high-level compatibility with Solidity, several low-level differences exist in the translation of YUL IR and specific Solidity constructs. These differences are particularly relevant for developers working with assembly code or utilizing advanced contract patterns.

Contract Code Structure

PolkaVM's contract runtime does not differentiate between runtime code and deploy (constructor) code. Instead, both are emitted into a single PolkaVM contract code blob and live on-chain. Therefore, in EVM terminology, the deploy code equals the runtime code.

In constructor code, the codesize instruction returns the call data size instead of the actual code blob size, which differs from standard EVM behavior.

Solidity-Specific Differences

Solidity constructs behave differently under PolkaVM:

• address.creationCode - returns the bytecode keccak256 hash instead of the actual creation code, reflecting PolkaVM's hash-based code referencing system

YUL Function Translation Differences

The following YUL functions exhibit notable behavioral differences in PolkaVM:

• Memory Operations:

  • mload, mstore, msize, mcopy - PolkaVM preserves memory layout but implements several constraints:
    • EVM linear heap memory is emulated using a fixed 64KB byte buffer, limiting maximum contract memory usage
    • Accessing memory offsets larger than the buffer size traps the contract with an OutOfBound error
    • Compiler optimizations may eliminate unused memory operations, potentially causing msize to differ from EVM behavior

• Call Data Operations:

  • calldataload, calldatacopy - in constructor code, the offset parameter is ignored and these functions always return 0, diverging from EVM behavior where call data represents constructor arguments

• Code Operations:

  • codecopy - only supported within constructor code, reflecting PolkaVM's different approach to code handling and the unified code blob structure

• Control Flow:

  • invalid - traps the contract execution but does not consume remaining gas, unlike EVM where it consumes all available gas

• Cross-Contract Calls:

  • call, delegatecall, staticall - these functions ignore supplied gas limits and forward all remaining resources due to PolkaVM's multi-dimensional resource model. This creates important security implications:

    • Contract authors must implement reentrancy protection since gas stipends don't provide protection
    • The compiler detects address payable.{send,transfer} patterns and disables call reentrancy as a protective heuristic
    • Using address payable.{send,transfer} is already deprecated; PolkaVM will provide dedicated precompiles for safe balance transfers

    Warning

    The 2300 gas stipend that is provided by solc for address payable.{send, transfer} calls offers no reentrancy protection in PolkaVM. While the compiler attempts to detect and mitigate this pattern, developers should avoid these deprecated functions.

• Contract Creation:

  • create, create2 - contract instantiation works fundamentally differently in PolkaVM. Instead of supplying deploy code concatenated with constructor arguments, the runtime expects:

    1. A buffer containing the code hash to deploy
    2. The constructor arguments buffer

    PolkaVM translates dataoffset and datasize instructions to handle contract hashes instead of contract code, enabling seamless use of the new keyword in Solidity. However, this translation may fail for contracts creating other contracts within assembly blocks.

    Warning

    Avoid using create family opcodes for manual deployment crafting in assembly blocks. This pattern is discouraged due to translation complexity and offers no gas savings benefits in PolkaVM.

• Data Operations:

  • dataoffset - returns the contract hash instead of code offset, aligning with PolkaVM's hash-based code referencing
  • datasize - returns the constant contract hash size (32 bytes) rather than variable code size

• Resource Queries:

  • gas, gaslimit - return only the ref_time component of PolkaVM's multi-dimensional weight system, providing the closest analog to traditional gas measurements

• Blockchain State:

  • prevrandao, difficulty - both translate to a constant value of 2500000000000000, as PolkaVM doesn't implement Ethereum's difficulty adjustment or randomness mechanisms

Unsupported Operations

Several EVM operations are not supported in PolkaVM and produce compile-time errors:

• pc, extcodecopy - these operations are EVM-specific and have no equivalent functionality in PolkaVM's RISC-V architecture
• blobhash, blobbasefee - related to Ethereum's rollup model and blob data handling, these operations are unnecessary given Polkadot's superior rollup architecture
• extcodecopy, selfdestruct - these deprecated operations are not supported and generate compile-time errors

Compilation Pipeline Considerations

PolkaVM processes YUL IR exclusively, meaning all contracts exhibit behavior consistent with Solidity's via-ir compilation mode. Developers familiar with the legacy compilation pipeline should expect IR-based codegen behavior when working with PolkaVM contracts.

Memory Pointer Limitations

YUL functions accepting memory buffer offset pointers or size arguments are limited by PolkaVM's 32-bit pointer size. Supplying values above 2^32-1 will trap the contract immediately. The Solidity compiler typically generates valid memory references, making this primarily a concern for low-level assembly code.

These incompatibilities reflect the fundamental architectural differences between EVM and PolkaVM while maintaining high-level Solidity compatibility. Most developers using standard Solidity patterns will encounter no issues, but those working with assembly code or advanced contract patterns should carefully review these differences during migration.

Last update: May 29, 2025
| Created: May 29, 2025