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 timeproof_size
- tracks state proof size for validator verificationstorage_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
andref_time_limit
are not semantically identical; blindly passing EVM gas asref_time_limit
can lead to unexpected behavior - Incomplete protection - the other two resources (
proof_size
andstorage_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 return0
, 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:- A buffer containing the code hash to deploy
- The constructor arguments buffer
PolkaVM translates
dataoffset
anddatasize
instructions to handle contract hashes instead of contract code, enabling seamless use of thenew
keyword in Solidity. However, this translation may fail for contracts creating other contracts withinassembly
blocks.Warning
Avoid using
create
family opcodes for manual deployment crafting inassembly
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 referencingdatasize
- returns the constant contract hash size (32 bytes) rather than variable code size
-
Resource Queries:
gas
,gaslimit
- return only theref_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 of2500000000000000
, 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 architectureblobhash
,blobbasefee
- related to Ethereum's rollup model and blob data handling, these operations are unnecessary given Polkadot's superior rollup architectureextcodecopy
,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.
| Created: June 13, 2025