Consensus Execution Contracts Overview
Basic Concept of Consensus Execution ContractsA consensus execution contract is also known as the smart contract in the blockchain industry. However, VDS team found the term too marketing-oriented, since so far we have not figured not how smart the contract programming technology is, it is just a consensus preset program formed through code editing in a decentralized distributed network. In the practical spirit of scientific exploration, we believe it is more appropriate to rename smart contracts to consensus execution contracts, which reflect the essence of this decentralized consensus agreement, and also remove the barriers to understanding the term when human beings combine blockchain technology with Artificial Intelligence Technology in the future.
Consensus execution contracts can be applied to a wide range of industries, such as finance, education, administrative systems, the Internet of things, and online entertainment. By means of pre-editing code in a specific distributed network, a script is implemented without any third-party intervention to reach the consensus of all parties involved in the protocol through blockchain technology. It can guarantee the safe, stable and fair execution of the rights and interests of all contracts participants.
Consensus execution contracts have accelerated the landing of various applications for the development of blockchain industry, and inspired more developers’ active participation. It has revolutionized the actual product experience of blockchain technology. All credits stem from the outstanding contribution of the Ethereum team, which has opened a new door for the entire industry.
Basic Structure and Integration Points
EVM IntegrationThe Ethereum Virtual Machine (EVM) adopts 256-bit machine code. It is a stack-based virtual machined used to execute Ethereum’s consensus execution contracts. Since EVM is designed for the Ethereum system, the Ethereum Account Model is used for value transmission. VDS chain is designed based on the Bitcoin UTXO model. On the one hand, it is to realize the resonance trade function of VDS, aka the one-way cross-chain exchange function of Bitcoin to VDS, where two different Bitcoin and VDS addresses can be generated with the same set of private key. On the other hand, VDS team believes the underlying transaction structure of Bitcoin is more stable and reliable after 10 years of social practice. Therefore, VDS uses the Account Abstraction Layer to convert the UTXO model into an account model that can be executed by the EVM. In addition, VDS added an interface based on the account model, so that EVM can read information directly on the VDS chain. It should be noted that the account abstraction layer can hide the deployment details of certain specific functions and establish a division of concerns for enhancing interoperability and platform independence.
In the Bitcoin system, only after the verification of the Script Sig and Script Pub Key can the corresponding transaction output be spent.
For example, Script Sig usually locks a transaction output to a Bitcoin address (public key hash). Only when the setting conditions of Script Sig and Script Pub Key match will the combined script display the result as true (system return value 1), so that the corresponding transaction output will be spent.
We value the timeliness of the execution in the distributed system of VDS and therefore added OP_CREATE and OP_CALL operators to the Script Sig. When VDS system detects the operator, the nodes of the entire network will execute the transaction. In this way, the role of Bitcoin script is more about sending relevant data to EVM than just being a coding language. Just as Ethereum runs consensus execution contracts, EVM changes the states of contracts triggered by OP_CREATE and OP_CALL operators in their respective state databases.
Considering the easy use of the consensus execution contracts on the VDS chain, it is necessary to verify the data that triggers the contracts and the public-key hash of the data source.
To prevent UTXO from taking up too much of the VDS chain, the transaction outputs of OP_CREATE and OP_CALL are also designed as consumable, and the output of OP_CALL can send funds for other contracts or public key hash addresses.
First, for the consensus execution contracts created on the VDS chain, the system generates a transaction hash for the contract call. The newly issued contract has an initial balance of 0 (contracts with non-zero initial balances are not supported). VDS uses OP_CALL operator to create the transaction output so as to send money. The output script of the contract sending fund is similar to:
1: the version of the VM
10000: gas limit for the transaction
100: gas price in Qtum satoshis
0xF012: data to send to the contract (usually using the solidity ABI)
0x1452b22265803b201ac1f8bb25840cb70afe3303:
ripemd-160 hash of the contract txid OP_CALL
This script is not complicated, and OP_CALL does most of the required work. VDS defines the specific transaction cost (not considering out-of-gas) as the Output Value, which is Gas Limit. The specific Gas mechanism will be discussed in subsequent chapters. When the above output script is added to the blockchain, the output establishes a corresponding relationship with the contract’s account and is reflected in the contract’s balance. The balance can be interpreted as the sum of available contract costs.
The standard public-key hash output is used for the basic flow of contract transactions, and the flow of transactions between contracts is generally consistent. In addition, transactions can also be made through P2SH and non-standard transactions. When the current contract needs to be traded with another contract or public-key hash address, the output available in the contract account will be consumed. This consumed part of the output is used for transaction verification in the VDS network, which has to exist. We call it the Expected Contract Transactions. Since the Expected Contract Transactions occur while the miners instead of users validating and executing the transactions, it will not be broadcasted over the entire network.
The main principle of the Expected Contract Transactions is achieved through OP_SPEND code. OP_CREATE and OP_CALL have two modes of operation and are executed by EVM when the operator acts as an output script. When the operator acts as an input script, EVM will not be executed (otherwise it will cause repeated execution), in which case OP_CREATE and OP_CALL will be treated as instruction-free operations. OP_CREATE and OP_CALL receive transaction hash passed by OP_SPEND and return 1 or 0 (spendable or un-spendable). This shows the importance of OP_SPEND in the entire Expected Contract Transactions. Specifically, when OP_SPEND passes transaction hash to OP_CREATE and OP_CALL, OP_CREATE and OP_CALL will compare whether this hash exists in the list of Expected Contract Transactions. If it exists, return 1 to spend; otherwise return 0, meaning un-spendable. This logic indirectly provides a complete and safe way to ensure the contract funds be used only by the contract, in accordance with the output of common UTXO transactions.
When the EVM contracts send funds to the public-key hash address or another contract, a new transaction will be established. Using the Consensus-critical coin picking algorithm, the most suitable transaction output will be selected from the available output pool of the contracts. The selected transaction output will be used as the input script to execute a single OP_SPEND, the output is the target address of the funds, and the remaining funds will be sent back to the contracts while changing the output available for consumption. Then, this transaction hash will be added to the Expected Contract Transactions list. The transaction will be added to the block immediately after it is executed. When the miners on the chain have verified and executed this transaction, the Expected Contract Transactions list will be traversed again. The hash will get deleted from the list after verification correct. In this way, using OP_SPEND can effectively prevent the use of hard-coded hash to change the cost of the output.
The VDS account abstraction layer allows EVM to make money transactions with other contracts and even public-key hash addresses without paying too much attention to coin-picking, just knowing the balance in the contracts. In this way, only a few modifications to the ethereum consensus execution contracts are needed to meet the VDS contracts operation requirements.
In other words, the consensus execution contracts running on the Ethereum chain can also be applied to VDS chain.
Completion of AALVDS chain is designed based on Bitcoin UTXO model. The common consensus execution contracts platforms use the account model. Since the contracts as an entity requires a network identifier, which is the address of the contracts, so the operation and management of consensus execution contracts can be conducted through this address. Account Abstraction Layer (AAL) is added to the VDS chain model design, which is used to convert the UTXO model into an account model that can be executed by the contract.
The account model for the virtual machine is relatively simple for developers of consensus execution contracts. It supports the query of contracts balance and can also send money for other contracts. Although these operations seem very simple and basic, all transactions in the VDS chain use the Bitcoin scripting language, and it is more complicated than expected to be realized in the account abstraction layer of VDS chain based on Bitcoin UTXO model. Therefore, AAL has expanded on this basis and added three new operators:
OP_CREATE is used to perform the creation of smart contracts, pass the bytecode transferred by the transaction to the contract storage database of the virtual machine, and generate a contract account.
OP_CALL is used to transfer the relevant data and address info needed for contract call, and to execute the contract code (this operator can also send money for consensus execution contracts)
OP_SPEND takes the hash of the current contract ID as the input transaction HASH, or the transaction HASH sent to the contract’s UTXO, and then uses OP_SPEND as a spending instruction to build a transaction script.
Contract Use and On-chain Process
Contracts WritingIt is currently possible to use Solidity language to write consensus execution contracts.
Use solidity remix or other Solidity IDE for code writing and compilation.
solidity remix（
https://remix.ethereum.org/）It is recommended to use homestead mode to compile.
It is recommended to use solidity version 0.4.24 (Other versions may result in errors or failures).
Solidity reference (
https://solidity.readthedocs.io/en)
Bytecode and ABI will be obtained after compilation.
Compile and Deploy ContractsThe operation of vdsd smart contracts
Test environment run variables
vdsd -txindex=1 -logevents=1 -record-log-opcodes=1 -regtest=1
>Contract testing is performed in the test environment. It is recommended to test after 440th block height.
Refund and Revert of abnormal contract events are completed at 440th block height
Deploy contracts commands are:```vds-cli deploycontract bytecode ABI parameters```
- bytecode (string, required) contract bytecode.
- ABI (string, required) ABI String must be JSON formatted.
- parameters (string, required) a JSON array of parameters.
This function is used for the execution of the contract’s constructor with incoming parameters to obtain the ByteCode that is ultimately used for deployment.
(This method is to associate bytecode with ABI and store it locally for recording, where the internal method can be called to return relevant bytecode)
```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```
- bytecode (string, required) contract bytecode.
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
Return: txid, sender, sender’s hash160, contract address
Check if the command is executed:```vds-cli gettransactionreceipt txid```
The return value of txid for non-contract transactions is empty
Return: the relevant information of txid on the chain this time* - BlockHash: Block Hash
* - blockNumber: Block Height
* - transactionHash: transaction hash
* - transactionIndex: location identifier of the transaction block
* - hash160 from sender’s address
* - to the contract address of the recipient, the contract transaction is created at
00000000000000000000000000000
* - cumulativeGasUsed: Cumulative use of Gas
* - gasUsed: the actual use of Gas
* - contractAddress: contract address
* - excepted: if there’s any error
* - exceptedMessage: error message
It should be noted that if the excepted field is not None, the contract execution fails. Although transactions are checkable on the chain, it does not indicate a successful contract execution, that is to say, the handling fee for execution will not be returned. It is only refundable when the internal contracts enter into revert method, not assert method.
Contracts Call```vds-cli addcontract name contractaddress ABI decription```
- name (string required) contract name.
- contractaddress (string required) contract address.
- ABI (string, required) ABI String must be JSON formatted.
- description (string, optional) The description to this contract.
This function is used to add the contracts ABI to the local database.
```vds-cli getcontractinfo contractaddress```
- contractaddress (string required) contract address.
This function gets information about the contracts that have been added.
```vds-cli callcontractfunc contractaddress function parameters```
- contractaddress (string, required) The contract address that will receive the funds and data.
- function (string, required) The contract function.
- parameters (string, required) a JSON array of parameters.
This function will return the execution result when calling the normal constant method, calling contract data operation method will return the hexadecimal format string of the operation script.
```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```
- contractaddress (string, required) The contract address that will receive the funds and data.
- datahex (string, required) data to send.
- amount (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
This function is used to send the contract operation script to the specified contract and make it recorded on the blockchain.
Check contract execution results
```vds-cli gettransaction txid```
This command is used to view the confirmation times of the current wallet transactions.
```vds-cli gettransactionreceipt txid```
This command is used to check the execution results of contract creation and transaction call, see whether there are exceptions thrown and the actual GAS consumed.
`${datadir}/vmExecLogs.json` will record contract calls on the blockchain. This file will serve as the external interface for contract events.
Contract Call Interfaces* Create contract interface: createcontract
* Deploy contract interface: deploycontract
* Add ABI interface: addcontract
* Contract call with fund operation interface: sendtocontract
* Read contract interface: callcontractfunc
* Acquire contract transaction execution interface: gettransactionreceipt
Contract Operating CostsThe running costs of creating contracts are estimations, there’s no guarantee of 100% execution success because gas limit has a usage limit of 50,000,000, and contracts exceeding this limit will cause failure. Change is adopted on the VDS chain, that is to say, even if you send lots of gas, the miners will not use them all, they will return the remaining part. So, don’t worry about spending too much gas.
The general cost of creating contracts takes Byte Code size multiplied by 300 as gas limit, minimum gas price is 0.0000004, gas price multiplied by gas limit is the cost of creating contracts.
As for the implementation of certain contract, the required gas is an estimation, which cannot guarantee a 100% success to make it on the chain due to network congestion. To avoid misleading, developers should verify the results by yourselves.
