Ethereum & Wischain Differences

There are several technical distinctions between the Ethereum mainnet's Ethereum Virtual Machine (EVM) and the modified zkEVM design employed by Wischain. Below, we outline these differences as they pertain to Wischain and Wischain Sepolia.

For open-source contributors and infrastructure builders, our team is available for additional support and inquiries.

Key Takeaway for Developers

For most Solidity developers, these technical details will not significantly impact your development experience on Wischain.

EVM Opcodes

Opcode	Solidity Equivalent	Wischain Behavior
BLOCKHASH	block.blockhash	Returns `keccak(chain_id
COINBASE	block.coinbase	Returns the address of the pre-deployed fee vault contract. See Wischain Contracts.
DIFFICULTY / PREVRANDAO	block.difficulty	Returns 0.
SELFDESTRUCT	selfdestruct	Disabled; transactions will revert if this opcode is encountered.

Note: Opcodes related to EIP-4844, such as BLOBHASH and BLOBBASEFEE, are not currently supported on Wischain. Additionally, access to the Beacon Chain block root via EIP-4788 is also unavailable.

Wischain supports the Cancun EVM target and the latest Solidity version, which is 0.8.26.

EVM Precompiles

Currently, Wischain does not support several precompiles, specifically the RIPEMD-160 (address 0x3), blake2f (address 0x9), and point evaluation (address 0x0A). Any attempts to call these unsupported precompiled contracts will result in a transaction revert. We aim to enable these precompiles in future hard forks.

The modexp precompile is supported but is limited to inputs of size less than or equal to 32 bytes (i.e., u256). The ecPairing precompile is available but has a limit of 4 points (sets, pairs), reduced from the usual 6.

The following precompiles are fully supported: ecRecover, identity, ecAdd, and ecMul.

Precompile Limits

Due to the fixed size of zkEVM circuits, there are upper limits on the number of calls that can be made to some precompiles. Transactions exceeding these limits will not revert but will be skipped by the sequencer if they cannot fit into the circuit space. For more details, please refer to the Circuit Capacity Checker.

Precompile / Opcode	Limit
keccak256	3157
ecRecover	119
modexp	23
ecAdd	50
ecMul	50
ecPairing	2

State Account Enhancements

In the current implementation of the State Account object, two additional fields have been introduced: PoseidonCodehash and CodeSize.

go

type StateAccount struct {
  Nonce            uint64
  Balance          *big.Int
  Root             common.Hash // Merkle root of the storage trie
  KeccakCodeHash   []byte // Keccak codehash
  // Added fields
  PoseidonCodeHash []byte // Poseidon codehash
  CodeSize         uint64
}

Code Hash Management

Wischain maintains two types of code hashes for each contract bytecode: the Keccak hash and the Poseidon hash. The KeccakCodeHash is preserved for compatibility with the EXTCODEHASH opcode, while the PoseidonCodeHash is utilized to verify the correctness of bytecode loaded in the zkEVM, where Poseidon hashing offers superior efficiency.

Code Size Optimization

To optimize the verification process for EXTCODESIZE, we avoid loading the entire contract data into the zkEVM, which is resource-intensive. Instead, the contract size is stored during contract creation, allowing us to verify this opcode using a storage proof instead of the complete contract code.

Dynamic Block Time

To enhance the throughput of the Wischain network, we introduced a dynamic block time in the Curie upgrade. During periods of congestion, a block will be sealed once the transaction count reaches the circuit limit, rather than adhering to a fixed 3-second interval. However, during normal operations, blocks will still be sealed at 3-second intervals to ensure a consistent user experience.

Transaction Ordering Mechanism

Similar to Ethereum, the Wischain sequencer prioritizes executable transactions based on their associated "tip" (priority fee). Typically, transactions will be included in the next block in descending order of their tips. However, as with Ethereum, this ordering is not guaranteed by the protocol, and some blocks may diverge from this order. During times of low mempool congestion, the sequencer may process transactions on a first-come-first-served basis, allowing some lower-tip transactions to be included before higher-tip ones in the same block.

Reorganizations and Finality

Following the DarwinV2 upgrade, the maximum reorganization depth has been established at 17 blocks. Transaction ordering should remain stable beyond this threshold, but the only absolute guarantee is that transactions will be finalized once proof is submitted to Layer 1.

Future EIPs

Wischain continuously monitors emerging Ethereum Improvement Proposals (EIPs) and will adopt them as appropriate. For further information, feel free to reach out via our community forum or on the Wischain Discord.

Transaction Fees Structure

The fees associated with Wischain transactions consist of two components:

1. L2 Gas Fee: This fee is similar to that of Layer 1, calculated as L2_gas_price * L2_gas_used, which covers the following costs:

   • L2 sequencer execution and storage costs

   • Validity proof verification and finalization costs on Layer 1

   • Prover costs

2. L1 Data Fee: This is an additional fee imposed on L2-initiated transactions but not on those initiated from Layer 1. This fee accounts for the cost of transmitting data to Layer 1 for data availability purposes. As we roll up transaction data to Layer 1, the L1 rollup fee is determined based on the size of the transaction data.