OLVM description
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.
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)
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 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 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.
-
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;
-
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;