EVM in Velas

Velas native application model is aiming for high performance by splitting its modifiable state across multiple accounts. While this allows Velas 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 Velas introduced a full hybrid of Solana (eBPF) VM and Ethereum VM.

movedapps

Learn more about deploying a simple smart contract on Velas EVM or how to move your dapps from Ethereum to Velas.

Velas 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, velas 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, Velas 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.

Velas 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.

> curl --data '{"method":"eth_getBlockByNumber","params":["0x1ABCD", false],"id":1,"jsonrpc":"2.0"}' -H "Content-Type: application/json" -X POST https://api.velas.com

{
  "jsonrpc": "2.0",
  "result": {
    "difficulty": "0x0",
    "extraData": "0x56656c61732045564d20636f6d7061746962696c697479206c617965722e7632",
    "gasLimit": "0x11e1a300",
    "gasUsed": "0x44f18",
    "hash": "0x2ac1b4e4dd5e31e38d2e4fd909550c2272c16b585c3bc07225557caacdf30fc9",
    "isFinalized": true,
    "logsBloom": "0x00001000000000000000000000000000000000000000000100000000000000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000020000000000000000000000000000000000000000000000000000000800000804000000000000000000001",
    "miner": "0x0000000000000000000000000000000000000000",
    "mixHash": "0x4d1cf4cdc757eca724b14d4e426888e5633356fd0934f9495d4124c371c47627",
    "nonce": "0x0000000001a1053a",
    "number": "0x1abcd",
    "parentHash": "0x5642145d0d6993339f14d2f0d46e620de073a73dc5c3d2ad0056243c494fc3a6",
    "receiptsRoot": "0xf2cd14b48abc6cc48c95bc5dd530a16f6790faa38d86f9ed5430f066627ccd94",
    "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "size": "0x100",
    "stateRoot": "0x111e7ae6a6e7ef5155975d06c4ab572c5b220a23c46078fb04248c1fced1c629",
    "timestamp": "0x6147f78c",
    "totalDifficulty": "0x0",
    "transactions": [
      "0xb18892b9832d675baa70d89390909f937c289d6a6a37ad291e281b4b07c3c3ea"
    ],
    "transactionsRoot": "0x827d7721b8337fc40fee3c6a10c02bc2ecebd748d00824a30b3ef7d998ac2483",
    "uncles": []
  },
  "id": 1
}

Transfer native VLX to EVM

In order to transfer VLX from the Native Space to the EVM Space, use velas CLI. Note: The EVM Space accounts VLX in nano lamports (10^18), so when you transfer for example, 5 lamports, your balance will be reported as 5*10^9

Usage:

> velas evm transfer-to-evm --help

velas-evm-transfer-to-evm
Transfer Native chain token to EVM world

USAGE:
    velas evm transfer-to-evm [FLAGS] [OPTIONS] [ARGS]

FLAGS:
    -h, --help                           Prints help information
        --lamports                       Amount in lamports
ARGS:
    <EVM_ADDRESS>    Receiver address in EVM
    <AMOUNT>         Amount in VLX

Example:

> velas evm transfer-to-evm 0x9Edb9E0B88Dbf2a29aE121a657e1860aEceaA53D 5

Result after transaction processing:

[2020-12-26T15:03:01Z INFO  evm_utils] Loading keypair from: /home/user/.config/velas/id.json
Transaction signature = 5d3eP741NYgemyM4CLmXuTEcP8f8w7QxfZ5vBxorqenEtNeSHWMFpkwtyi1meFKHVNXzDD3NbvFCExjZH79gEMKk

To make sure that balance was updated, you can request it using rpc:

curl -s -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x9Edb9E0B88Dbf2a29aE121a657e1860aEceaA53D", "latest"],"id":1}' -H "Content-Type: application/json" http://127.0.0.1:8899                
{"jsonrpc":"2.0","result":"0x12a05f200","id":1}

0x12a05f200 is a hex representation of 5*10^9

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:

pragma solidity ^0.6.0;

interface TransferToNative {
  function transferToNative(bytes32 native_recipient) virtual external payable;
}

native_recipient is 32byte address of Velas Native account. To swap VLX, 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

chain_id	Network Name	rpc	explorer
106	Velas Mainnet	https://evmexplorer.velas.com/rpc	https://evmexplorer.velas.com
111	Velas Testnet	https://evmexplorer.testnet.velas.com/rpc	https://evmexplorer.testnet.velas.com
5705	Velas Devnet	https://evmexplorer.devnet.velas.com/rpc	https://evmexplorer.devnet.velas.com

EVM transaction finality​

Transfer native VLX to EVM​

Transfer token from EVM back to native​

Metamask support​

Network Details​

EVM transaction finality

Transfer native VLX to EVM

Transfer token from EVM back to native

Metamask support

Network Details