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.

Completion of AAL

VDS 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 Writing

It 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 Contracts

The 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 Costs

The 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.

From a certain perspective, the essence of smart contracts is bytecode. It is through these bytecodes that functions such as logical jumps, calculations, and storage are realized. Taking the creation of the 3rd-generation VDS group as an example, the compiled bytecode is 42,697 bytes, which does not include the initial settings such as group name, group rules, and group announcements. The most expensive part of the cost is to create contracts (GasPrice multiplied by GasLimit is the effective part of the cost, as in the Ethereum network)

These 42,697 bytes contain logic, calculations, and data types of the 3rd-generation VDS group, which cannot be further reduced. Excluding network fluctuations, it will consume 5,600,000*0.0000004=2.24 Vollar to make the data on-chain. Additional data such as group name, group rules, and group announcements should also be converted into code and calculated. That is to say, in order to ensure the successful execution of contracts, you have to pay a sufficient amount of Gas to support its consumption process.

0.0000004 Vollar is set as the lower limit of GasPrice while the rest is adjustable according to GasLimit. There’s also a cap on GasLimit, which means we cannot add so much content into the smart contracts and execute them. Infinite loops such as the Mobius Strip can never be executed in the smart contracts since it has exceeded the upper limit of 50,000,000 Vollar.

The amount of Gas required to execute a smart contract also varies, depending on how the smart contract is executed, its complexity, and the amount of data to be modified and stored. Even if we adopt minimal execution (aka “Empty Function”), it would cost 21,000 GasLimit, converted to a handling fee of 0.0000004*21,000=0.0084 Vollar. The creation of OTC contracts costs 260,000*0.0000004 = 1.04 Vollar, execution costs 45,000*0.0000004=0.018 Vollar. The cost accuracy of OTC contracts is around 0.001 Vollar.

It should be noted that we cannot simply use a unified method to calculate the value of bytecode, but should take into consideration the logic complexity of calculation and the influence of special cases such as network fluctuations.


The current group interfaces include setting group name, group announcement, group rules, group entry fee, trading mode (trading pair, which can be modified by group admin and not affect the actual transaction. Like an agreement), whether you need admin approval to enter the group, admin rejects group application, admin removes group members, bulk permission of group entry, increasing the upper limit of group members, individual application for group entry, individual application cancel, group member leaves the group, additional margin from the admin, admin withdraw group deposit.

A contract fee is required for all of the above-mentioned interfaces while some of the query type don’t.

Take setting the group name as an example. Name the group “Me*100”, record this operation as “A”. The generated code size is 841 bytes, and the Gas cost is 271,338 (Gas is the calculation method of cost, which is specially used to calculate the cost of contracts. The minimum unit of Vollar is shatoshi, 0.000004 represents 40 shatoshi, 271,338 meaning 271,338 units of 40 shatoshi are spent. The handling fee is 271,338*0. 0000004=0.1085352 Vollar.


On the basis of A, change the group name to “Me” and record this operation as “B”. The size of the generated code is 201 bytes and the Gas cost 41,915, handling fee 41,915*0.0000004 = 0.0016766 Vollar.

On the basis of B, rename the group as “Me” and record operation as C. Gas cost is 33,260, handling fee 33,260*0.0000004 = 0.0013304 Vollar.

It can be concluded that handling fee would become higher if there’s a large variation in content; handling fee becomes lower if there’s no big difference.




The principle of VDS smart contracts is the same as that of Ethereum. Ethereum cannot guarantee as well the accurate cost of each executed contract. Both VDS and ETH adopt prior estimation, which is usually higher than the actual cost.

The current cost of group creation is around 2 Vollar. To further downsizing it requires removing certain interfaces that change single storage only, such as removing multiplexing interfaces like group name settings, group rule and group announcements for optimization. The creation of OTC contracts can hardly be optimized. What can be optimized is the interface of contract calls such as confirming receipts, which can be accurately calculated at a cost of about 0.02 Vollar per time.

This not only ensure a high degree of democracy in the community, but also accelerate and enhance long-term ecological development.

VAD is definitely the next trend. On-chain advertising system will become the most influential publicity channel in the near future.

I found this download link in their Telegram group:
Android Download: https://ipfs.io/ipfs/QmQjKU7H7C57zB2QyrT3gWuweivyUc9v9EXFiWFzcfGsdE
change the file name to .apk to install.
Let me know if you need link to Windows and Linux version

LOl...Here's more about VDS for your reference:
Vollar is its zero-knowledeg proof, erc-20 token. Initial functions such as Resonance Trade, Secret Chat, fiat OTC trading groups, and VAD are all found conveniently in the VDS client-end wallet. IP addresses are completely erased as information is transmitted across the master node network, which supports the creation of a browser, where VIDs are used as domain names.

Their official deep web site: VDSVVVXXMXPSSSZD.ONION, don't forget to use Tor.

You may download VDS wallet from their website.

VDS is not that kind of conventional exchange, it has the build-in OTC function inside the wallet.

VDS is a membership-based ecosystem that combines blockchain, social networking, and information technology to facilitate the frictionless circulation of users' assets.

In 2019, Mr. Cotten, the founder of Canadian exchange Quadriga suddenly died of illness while travelling in India. With most of the exchange’s digital assets in his cold wallet, a total value of $137 million crypto was “permanently sealed”. There’s a lot more to the story. Investigation shows that Mr. Cotton transferred all his digital currencies into the accounts of rival exchanges before his “death”, and has made transaction successively ever since. Homicide or natural death, only a few people would know. Regardless of the facts, the biggest losses are borne by people who use Quadriga. With centralized exchanges, our property security will always be controlled by others.


As the disadvantages of the centralized exchanges gradually reveal, people are now in desperate need of a decentralized channel to guarantee their property safety without any involvement of third-party institutions. The decentralized ecology of VDS solves all problems. VDS is the world’s first completely decentralized ecology of future currency. Through the built-in decentralized OTC function, it has established a barrier-free channel for the exchange of cryptocurrency into fiat currency, making transactions happen under decentralized conditions. In VDS, each participant is capable of establishing his own OTC exchange through the distributed and anonymous secret chat group. VDS relies on smart contracts to guarantee asset security of both parties in the transaction and help buyers and sellers to complete transaction in an efficient way, while avoiding the large concentration of assets in centralized platforms. In this way, horrible stories like users losing all their chips due to the “death” of founders will not repeat themselves.


In addition to using technology to avoid the concentration of assets in the hands of centralized institutions, the decentralized OTC function in VDS groups can also build a wall of defense to protect user privacy. As we all know, the biggest drawback of a centralized institution is the risk of violating users’ privacy. Since VDS itself is a “private Internet”, it does not have a central server for data storage, only to provide data transmission through numerous super master nodes on the VDS chain. OTC group owner, buyers and sellers are all protected for their privacy and able to conduct transaction anonymously. It is increasingly difficult for us to believe the promises of centralized institutions. Instead, we should use technology to safeguard personal privacy. VDS is a perfect transaction channel to protect users’ privacy.


In the highly decentralized and free financial model of VDS ecosystem, all rules and technologies are designed to achieve a common goal, to safeguard privacy and realize freedom of wealth.


Everyone can start their own distributed OTC trading groups here, meanwhile, those who want to trade assets can pick up any OTC group according to the needs. In this decentralized transaction model, the privacy of users is respected and wealth is commanded by ourselves without the intervention of third-party institutions.

Find target Dapp users among crypto supporters, this might work.

Decentraland? Is this what you're talking about?

Developers can use VDS's own VAD Network-Wide Broadcasting System to promote their DApps, locate users accurately, and provide access for user experience.

There’s no other phenomenal Dapp except for Cryptokitties until now. The active user for most Dapp is no more than 2,000. What’s the reason for such a bleak situation? The main problem is the lack of effective marketing and publicity. In the case of the popular apps that we commonly use, they make advertisement on various online media platforms at launch. Regardless of whether the downloads increase or not, they make themselves known for starters. However, most Dapps do not have such promotion process, coupled with the fact that Dapp relies on the underlying technology of the blockchain, it is difficult for users to get started without industry background.

In VDS, we can not only develop Dapp, more importantly, VDS ecology is very conducive to the development of Dapp itself with its own publicity function and accurate user targeting mode, which refers to the completely decentralized ad-bidding system-VAD. An advertising spot is updated every 60 blocks, and a total of 24 spots are available for bidding. A successful bidding of VAD is transmitted to every VDS wallet through the distributed anonymous network, which is the equivalent to the bidder inserting promotional card directly into each investor’s wallet. The participants of VDS are crypto players with blockchain background knowledge, so there’s no resistance for Dapp to target users through VAD.

Advertising effect is not only about the accurate delivery; the ad needs to be seen by more people and then achieve user conversion. First off, the Trust Stamp System in VDS provides large user groups. Secondly, the Trust Stamp System relies on blochchain technology to build a multi-level network, each VID gets corresponding income and builds his own continuous cash flow while expanding interpersonal network. For VDS, this is a multiplication fission expansion model. In such a system of large user groups, VAD, as a completely decentralized ad-delivery system, not only makes information delivery accurate, but more so act as an efficient channel that improves the conversion rate to the largest. It goes beyond any existing centralized advertising channel.

In addition to provide large user groups, the Trust Stamp Network also enhanced user stickiness to the Dapp in the ecology. The Trust Stamp Network is a grand system composed of the interpersonal network of each user, so the expansion process itself is based on the intimate connection to consolidate, which is more conducive to maintain Dapp activity.

Generally speaking, the global Dapp market has great resistance if takes into account the information’s precise delivery, wide coverage, and high user conversion. Within the ecosystem of VDS, these obstacles can be effectively eliminated for DAPP developers. The decentralized ad-bidding broadcast system VAD gets rid of the content review and release restrictions from centralized agencies, and promoters can turn more creative ideas into content for DAPP publicity.

In this era of information explosion, high-quality products are inseparable from effective promotion and marketing strategies. The development, publicity, and conversion with VDS’s decentralized ecology will be the fastest and most efficient one-stop service, and it will definitely become the battleground of the commercial industry.

VDS=Bitcoin+Ethereum+Dash+Zcash

VDS took the baton from Bitcoin in a decentralized manner through resonance trade and utilized a mining mechanism that makes the transaction faster, as well as the Trust Stamp Network and the future blockchain business smart contract to solve the problem at source that Bitcoin could not become a universal electronic cash.

Okay, thanks for the reminder

Stranding of Bitcoin Whales
https://bitcointalk.org/index.php?topic=5222998.0

What Can You Get With 0.01 Bitcoin?
https://bitcointalk.org/index.php?topic=5223544.0

Actually they're not published on the same day. I'll take your advice though about the same announcement.