NEP: 7 Title: Triggers for NeoContract Author: Erik Zhang <[email protected]> Type: Standard Status: Final Created: 2017-10-16
Trigger is a mechanism for triggering execution for smart contracts. This NEP defines four different kinds of triggers, they are Verification, VerificationR, Application and ApplicationR.
A blockchain that provides smart contract system should provide multiple triggers for the smart contracts running on it, makes them to function in different contexts.
Currently, we have two kinds of triggers in NeoContract: Verification and Application. These two triggers make smart contracts able to verify the transactions and modify the states of the blockchain.
But there is no way for smart contracts to refuse a transfer, or to modify the states of the blockchain while accepting a transfer. We need two new triggers to do it: VerificationR and ApplicationR.
We define four kinds of triggers: Verification, VerificationR, Application and ApplicationR.
The Verification trigger indicates that the contract is being invoked as a verification function. The verification function can accept multiple parameters, and should return a boolean value that indicates the validity of the transaction or block.
The entry point of the contract will be invoked if the contract is triggered by Verification:
main(...);
The entry point of the contract must be able to handle this type of invocation.
The VerificationR trigger indicates that the contract is being invoked as a verification function because it is specified as a target of an output of the transaction. The verification function accepts no parameter, and should return a boolean value that indicates the validity of the transaction.
The entry point of the contract will be invoked if the contract is triggered by VerificationR:
main("receiving", new object[0]);
The receiving function should have the following signature:
public bool receiving()
The receiving function will be invoked automatically when a contract is receiving assets from a transfer.
The Application trigger indicates that the contract is being invoked as an application function. The application function can accept multiple parameters, change the states of the blockchain, and return any type of value.
The contract can have any form of entry point, but we recommend that all contracts should have the following entry point:
public byte[] main(string operation, params object[] args)
The functions can be invoked by creating an InvocationTransaction.
The ApplicationR trigger indicates that the default function received of the contract is being invoked because it is specified as a target of an output of the transaction. The received function accepts no parameter, changes the states of the blockchain, and returns any type of value.
The entry point of the contract will be invoked if the contract is triggered by ApplicationR:
main("received", new object[0]);
The received function should have the following signature:
public byte[] received()
The received function will be invoked automatically when a contract is receiving assets from a transfer.
Any old contract that didn't implement the receiving and received function will lead to a FAULT VM state when triggered by VerificationR or ApplicationR. So any transfers to old contracts will be rejected and no state will be changed.