- Jul 19, 2019
- 21
- 3
Consensus Execution Contracts Overview
Basic Concept of Consensus Execution Contracts
A 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 Integration
The 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.
Read more:
https://ipfs.io/ipfs/ QmTLcdYMegMYMwxMDgpTriYb6h6SEi5bggNpCdQwGEjE3a
Basic Concept of Consensus Execution Contracts
A 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 Integration
The 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.
Read more:
https://ipfs.io/ipfs/ QmTLcdYMegMYMwxMDgpTriYb6h6SEi5bggNpCdQwGEjE3a
Last edited:
