Introduction

Vision Virtual Machine (VVM)

Vision Virtual Machine (VVM) is a lightweight, Turing complete virtual machine developed for the Vision's ecosystem. Its goal is to provide millions of global developers with a custom-built blockchain system that is efficient, convenient, stable, secure and scalable.

VVM connects seamlessly with the existing development ecosystem and supports DPOS. VVM is initially compatible with the EVM environment so that instead of learning a new programming language, developers can develop, debug, and compile smart contracts in a Remix environment using Solidity and other languages. Once you’ve built and uploaded your smart contract to Vision’s mainnet, it will be executed on the VVM of the SR node to be isolated from external connections.

Furthermore, VVM employs the concept of Photon. Different from the gas mechanism on Ethereum’s EVM, transaction operations or smart contracts on VVM are free, consuming no tokens. Technically, the total token holding does not restrict executable computation capacity on VVM.

Features of VVM

1. Lightweight

VVM adopts a lightweight architecture with the aim of reducing resource consumption to guarantee system performance.

2. Stability and security

With a meticulous design paradigm and fine-grained underlying operation code, VVM can guarantee the preciseness of every step of a computation, diminishing ambiguity to the largest extent. Out of security reasons, transfers and smart contract running cost only photon points, not VS, which exempts Vision from being attacked similarly to Ethereum for its mode of gas consumption. Stability of photon consumption is achieved while the cost of each computational step is fixed.

3. Compatibility

Currently, VVM is compatible with EVM and will be with more mainstream VMs in the future. Thereby, all smart contracts on EVM are executable on VVM. By connecting seamlessly to existing development ecosystem, higher efficiency can be achieved by developers. Needless to learn a new programming language, they can use mainstream programming languages for smart contracts such as Solidity to develop, debug and compile smart contracts in the Remix environment, which greatly reduces development costs.

4. Developer-friendly

Thanks to VVM’s photon setup, development costs are reduced and developers can focus on the logic of their contract code. VVM also offers all-in-one interfaces for contract deployment, triggering and viewing, for the convenience of developers. The following interfaces are available in Vision Wallet-CLI:

• deploycontract(password, contractAddress, ABI, code, data, value)

• triggercontract(password, contractAddress, selector, data, value)

• getcontract(contractAddress) Developers can call these interfaces to deploy, trigger or check smart contracts.

Flowchart of Vision Virtual Machine

The above flowchart shows how VVM works: Compilation of Vision smart contract→execution and computing engines of VM→Interoperation service layer for external interfaces

Put simply, the flow is as follows:

• Currently, VVM is compatible mainly with Solidity. The compiler translates Solidity smart contract into bytecode readable and executable on VVM.

• A virtual machine processes data through opcode, which is equivalent to operating a logic of a stack-based finite state machine.

• VVM accesses blockchain data and invokes External Data Interface through the Interoperation layer.

Internal Transactions

Background

Internal Transactions represent all transactions that have occurred in a smart contract call. Some important information included in the transaction are sender/receiver address in a token/vs transfer transaction, vs/token amount, and transfer status. Users can check all information about Internal Transactions in an internalTransaction list, which contains all transactions in a single triggerSmartContract or createSmartContract call.

Internal Transaction Information Structure

message InternalTransaction {
  bytes hash = 1;
  // the one send vs or token via function
  bytes caller_address = 2;
  // the one recieve vs or token via function
  bytes transferTo_address = 3;
  message CallValueInfo {
    // vs or token value
    int64 callValue = 1;
    // tokenId, vs should be empty
    string tokenId = 2;
  }
  repeated CallValueInfo callValueInfo = 4;
  bytes note = 5;
  bool rejected = 6;
}

Parameter	Description
hash	Hash is a unique identifier for an internal transaction. There should not exist the same hash across all Internal Transactions or transactions.
caller_address	The address to send VS or VRC10 token.
transferTo_address	The address to receive VS or VRC10 token.
CallValueInfo	Indicates the amount and type of asset and VS transfer. It could be a list of pairs. callvalue：The amount of VS or VRC10 token; tokenID：the VRC10 tokenID. An empty value represents vs.
note	Note can have 3 types of values, which are call, create, and suicide, which represent the internal transaction type. Call: Internal Transaction which happened within a contract call contract case. Create: Internal Transaction which happened within a contract create contract case. Suicide: Internal Transaction which happened within a contract self destruct case.
rejected	Rejected is a boolean value of either true or false. For true, the internal transaction is rejected and not executed. For false, the internal transaction is successfully executed.