Supercontract Lifecycle
Any SC lifecycle contains the next steps:
- Preparation;
- The main steps of execution;
- Obtaining results and rewarding.
- End of SC
Preparation
To work with any SC, you need a Drive. When it will be done the owner must have some SC file with *.wat extension that will be uploaded to the Drive. When the file is uploaded on a Drive and downloaded by Storage Replicator Nodes the client can deploy it.
The main steps of execution
Deploy
SC should be deployed before it can be executed. The client should make a new deploy transaction that notifies Blockchain and executors about the new SC. Further, this SC will be compiled from the *.wat file to *.wasm file and can be invoked and executed by executors' VM.
Execution
Note
In current realization, all SC operations are sent only from the SC account.
When the file becomes the new SC, the client can start its execution. The client should indicate what function should be executed and approximately count the GAS for this operation. GAS is a fee for executing the SC. If the function requires some parameters, the owner must pass them. In case there is not enough mosaics during the SC execution,the SC will be terminated with the corresponding error.
Identification
In the moment when any DFMS user starts the execution of some SC functions, a new operation's ID is assigned for all operations. This ID is used by the user to get information about execution and result of the execution. In other words, this ID joins all operations from one execution in one group.
More details about the SC execution
One of the important instruments for developing SC is the availability of init function and the primary constructor of the SC execution.
For example, if there is a necessity to call a set of functions before calling a particular function, then they can be called in an external init function. It allows initialization once for the current execution process. This is convenient for initializing the SC function for the first time. Be careful because this init function will be called every execute transaction, but once in the frame of one the execute transaction.
Another important function is the constructor. If an external function calls the constructor function, which includes the necessary set of functions, then constructor will be called once in the life of the SC. In other words, this function will be called once while this SC exists for the current Drive. Other invocations will be ignored. Examples of using are mosaic creation, first SC initialization and configuration, that must be done once during SC life.
Results obtaining and rewarding
When executors finish running func they have to find an overall result. To do so, they should sign the result after the end of execution. If the executor result doesn't match with the result of the main executor (see consensus), it doesn't sign the end transaction. In case when some executor doesn't have the execution result it can be downloaded from another executor (this is a paid operation).
After collecting enough signatures all Drive participants get the reward for the completed work.
Anyone who is interested in the execution results of SC func can get a list of files by the execute transaction hash which started SC execution. The results of executions are available as files on the Drive (supercontracts folder).
End of SC
SC exists as long as Drive exists. The SC executing will be impossible if the Drive is unavailable for any reason. The Drive owner can deactivate any SC any time if there are some reasons for it. After deactivation, the execution of SC will be impossible.