EVM in Ethereal
EtherealNetwork native application model is aiming for high performance by splitting its modifiable state across multiple accounts. While this allows EtherealNetwork to process transactions in parallel on a single shard, it also introduces complications for ordinary DApps developers. Additionally, many dApps already rely on Solidity and the Ethereum technology stack. These two reasons slow down the adoption of non-EVM ecosystems.
For the developer's convenience, we at EtherealNetwork introduced a full hybrid of Solana (eBPF) VM and Ethereum VM.
Learn more about deploying a simple smart contract on EtherealNetwork EVM or how to move your dapps from Ethereum to EtherealNetwork.
EtherealNetwork chain supports EVM transaction execution via wrapping it into a regular native transaction with an instruction invoking EVM Program. To provide full compatibility to EVM dApps and other wallets/tools built on the Ethereum stack, EtherealNetwork node supports Ethereum JSON-RPC API. For that reason, the nodes create virtual EVM blocks that contain all the EVM transactions processed by the network and are available via ETH RPC methods (eth_getBlockByNumber
, and etc)).
For more information about EVM RPC visit evm-rpc page.
Please note, EtherealNetwork network does not create empty EVM blocks. Instead, it creates blocks on-demand, when there is an EVM transaction(s) processed by the network. Thus, expect EVM blocks to have different time gaps in between (in the case of low network activity). For this reason, do not rely on block.number
as the source of time, use block.timestamp
instead.
EVM transaction finality
In classic PoW chains (Bitcoin, Ethereum 1.0) a block (with its transactions) becomes final (aka irreversible) after waiting for some number of blocks created on top of it (block confirmations). In PoS chains, finality is usually achieved by waiting for 2/3 of the stake to vote on a block, either by other block producers building their blocks on top or by various asynchronous voting protocols.
EtherealNetwork EVM Space inherits its finality characteristics from the Native Space. Under normal conditions, apps and clients may expect to get an optimistic confirmation in ~1.2 seconds.
For the developer's convenience, the response of the eth_getBlockByNumber
RPC method (and similar) is extended with a flag isFinalized
to signal that the respective Native block (containing EVM transactions) got finalized.
Transfer native XZO to EVM
In order to transfer XZO from the Native Space to the EVM Space, use EtherealCLI. Note: The EVM Space accounts XZO in nano lamports (10^18), so when you transfer for example, 5 lamports, your balance will be reported as 5*10^9
Usage:
Transfer Native chain token to EVM world
USAGE:
FLAGS:
-h, --help Prints help information
--lamports Amount in lamports
ARGS:
<EVM_ADDRESS> Receiver address in EVM
<AMOUNT> Amount in XZO
Example:
Result after transaction processing:
[2020-12-26T15:03:01Z INFO evm_utils] Loading keypair from: /home/user/.config/Ethereal/id.json
Transaction signature = 5d3eP741NYgemyM4CLmXuTEcP8f8w7QxfZ5vBxorqenEtNeSHWMFpkwtyi1meFKHVNXzDD3NbvFCExjZH79gEMKk
To make sure that balance was updated, you can request it using rpc:
Transfer token from EVM back to native
For transferring tokens back to native chain, we have a special precompiled contract, that deployed at address:
0x56454c41532D434841494e000000000053574150
With following interface:
native_recipient
is 32byte address of EtherealNetwork Native account. To swap XZO, one should create a transaction to the address: 0x56454c41532D434841494e000000000053574150
with value
specified in the transaction. This transaction then can be sent to EVM Bridge, that will wrap it to native transaction.
Metamask support
In our integration, we support Metamask. In order to use it, simply follow our metamask official instruction to add any public EVM Bridge as a custom network.
Network Details
Last updated