Skip to content

OLVM description

M.Bo edited this page Nov 11, 2021 · 4 revisions

Brief diagram



The main idea behind the OLVM (OneLedger Virtual Machine) is to execute the same bytecode as in the ethereum blockchain network but on the OneLedger protocol side. This will give an opportunity to develop and deploy smart contracts on the OneLedger network the same way they exist on the ethereum network. The protocol will support smart contracts such as NFTs (ERC-721, ERC-1155), ERC-20, DEFI, OpenSea exchange contract or fully customized smart contracts.

EVM Interpreter

By default it is used as the go-ethereum interpreter, but it could be changed to: Sputnik, EVMC and other EVM compatible. WASM not supported at the go-ethereum right now (07.04.2021)

Unsupported opcodes

Right now it is only unsupported by the ecrecover function (could be supported in future) for ed25519, and it is only supported with secp256k1. As in the OneLedger protocol we are using ed25519.

DDoS protection

DDoS protection is initially covered by the gas multipliers in accordance with opcodes and has right now the max limit of the gas (21kk). This value could be configurable. Also the whole calculation in the block protected by the block.maxBytes and block.MaxGas.

Address compatibility

Address hash is fully compatible as the generated address from the ed25519 has the same length (20 bytes). There are no changes to the internal OLVM logic inside.

Performed tests

  • smart contract address rewrite - protected by the setting nonce of 1;

  • nonce correctness incrementation;

  • smart contract gas consumption;

  • Rarible, ERC20, reverts, fallbacks contracts were deployed and worked like a charm;

  • node disconnection and after the reconnection to the chain to check the correct state update;

  • api endpoints workability;

  • OLVM out of gas calculation;

  • load testing;

What features OneLedger could offer with the help of smart contracts

  • cheap gas for execution of the transactions;

  • speed of the transactions with the help of tendermint and it’s validators;

  • we could extended with own opcodes and functionality to create for example the bridge codes to the ether chain;

  • to write an own logics without redeploying nodes;

  • always to be in sync with go-ethereum OLVM and apply a new features;

  • no nonce queue, it completely neglected, all management done by tendermint mempool by itself;