The concept of smart contracts was raised back in 1994 by a scholar and cryptographer named Nick Szabo, it was recognized back then that decentralized ledgers can be made to function as automated self- executing contracts. In recent years, it has enlarged its scope of function to concepts that the management and transfer of virtual assets on a blockchain and conflict free exchange of value that eliminates intermediaries. As the whole industry continues to mature, it is expected that its functions will be extended to cover many requirements that currently exists.

Under this condition, contracts may be morphed into computer readable code, stored, replicated on the system and supervised by the network of computers that run the blockchain. This would also result in ledger feedback such as transferring money and receiving the product or service.

What are Smart Contracts?

Smart contracts basically enable the exchange money, property, shares, or anything of value in a transparent, conflict-free and disinter-mediated way. More so, smart contracts not only define the rules and penalties around an agreement in the same way that a traditional contract does, but also automatically enforce those obligations. In the ZoroChain architecture that is based on Neo, the main module that handles the creation and management of smart contracts is the Application Engine.

We think on chain operations should not be confined to simple smart contracts, so we chose to use Application Contracts, a concept that replaces traditional smart contracts, these application contracts run on the Application Engine and they are the application chain’s operation entry point. Application engine in contrast with a smart contract virtual machine needs to have a richer interface to provide satisfactory scalability for the application while supporting complex applications, needs to support synchronous computing to meet single-chain TPS performance requirements, and also it needs to support the rapid conclusion of a chain consensus to meet the RS performance requirements.

An application chain of ZoroChain is based on .NetCore to extend the NEO VM to support the requirements of complex application logic on the chain. ZoroChain’s application chain adopts a computation hierarchy; the complex computation extension of .NetCore will produce an on chain operation output, which is submitted as an input to the NEO Virtual Machine，and conducts an onchain internode consensus to satisfy the TPS and RS requirements , while at the same time .NetCore’s input will be synchronized on the chain, other nodes can based on .NetCore’s onchain operation output will perform verification and identify and punish nodes that cheat on their .NetCore output activity.

Technical Software Development Highlights of Application Engine

Applicationengine

Executionengine, executionengine, inherited from the Virtual Machine module, is responsible for the operation mechanism of the smart contract virtual machine.

Applicationengine combines the operation interface of State class data in LEVELDB to construct the operating environment of a Neo blockchain virtual machine.

Below is a snapshot of its method

Construct Function

Create the basic environment required for a virtual machine to run, including the script trigger type, script container such as transactions, gas paid for running the script, and whether gas consumption is not checked.

Script Trigger Type

Divided into verification and application, the former is called Authentication trigger, the latter is transaction call trigger. Since the contract triggered by authentication is the authentication process of the UTXO model, it is executed before the transaction is written to the block, and if the contract returns false or an exception occurs, the transaction is not written to that particular block.

Gas Paid For Running the Script

Running a contract script requires a certain amount of gas as system consumption, and this incoming parameter indicates that the transaction initiator paid for the execution of the contract gas. When the authentication is triggered, the incoming gas is zero when the authentication trigger and the InvokeScript trigger are triggered.

During the process of running the script it is checked to confirm if the remaining gas is enough, and if not enough, the execution is interrupted and an error is returned

Do not check gas consumption can be set to true, in this case gas balance is not checked.

Execute

Running a loaded contract script: Run the bytecode here and check the consumption of gas before running.

Run

Create a virtual machine execution environment to run the script, and modifications to the data during operation are not saved to the blockchain.