Greetings, colleagues! In today’s article we are talking about the execution model of contract in GONT. We will tell you about the general approach to the development of this model, about the options for its implementation, as well as answer the question of what a GONT contract is. We will also discuss sigs and web services and tell you what Bactions and Actions are. Have a productive reading!
General approach to the development of execution model of a contract code
Implementation options:
- Without LLVM (simple compiler).
- With LLVM (complex optimizing compiler, as for Solidity).At first let’s consider the option without LLVM and without entering a functional GOL language.
An implementation without LLVM is a simple compiler. In fact, this is an ELF file generator for execution in the gVM core.GONT implements and maintains both full backward compatibility with Ethereum (Solidity contracts) and its own contract model.
1. Contract
What is a GONT contract?
This is a collection (any number) of transactions (TR) from the descriptions on the GONT Tree. The contract is always in the state of one of the TR, and then goes into the next TR under the influence of external parameters. This model is similar to “The smart contract language in ZILLIQA“.
2. God-given contract evolution
GONT Smart contract can be viewed as an evolution between the essential states of a program contract (the evolution of meanings). Evolution in the usual, native way follows from the meaning of economic activity that the contract describes. This contract definition derives from the method of entering AlGas into the GONT.
When you enter AlGas, any transaction turns into a processor instruction (gVM core). It is one of many global gas instructions. At the same time, the instruction itself describes some meaning set by the user.
Transactions are entered through the oracle tree “GONT Tree”. In the visual mode, the user can select the “meanings of the program” on GONT Tree and set the evolution of the contract. In fact, these are FSM (Finite State Machine) programs in exact terms.
3. Sig
As contract passes through the stages, a sig is formed. This sig is an object of consensus on Blockchain. Consensus can be entered in different ways. The sig gives the object for the comparison formula on different miners.
GONT Tree is an ontology of transaction meanings. The contract program is transitions between states of senses under the influence of external conditions.
The advantage of the GONT approach lies in the possibility of “visual” (simple) programming without deep expertise in the contract writing language.
4. Model of the contract
Scheme:
Execution model of a single contract instruction
Pre-Exec model
After the current instruction has been executed and the Commit state has been reached, the sig should be expanded (by self-modification) in order to specify the next instruction where the state will go. Physically, this instruction is added to the sig, but with the flags “Pre-Commit” and “Pre-Exec”. This means that the instruction has not yet been executed and has not been confirmed. After that, the state of the sig can be saved in the Blockchain block.
After resuming the execution of the sig (at any time), this instruction will be executed and similarly expanded with the new instruction.
5. Sigs and Web Services
GONT offers an approach for implementing Web services when it comes to interacting with the BC.
During normal operation, the site implements a huge number of states that the MVC controller fulfills. Not all of them should be “mirrored” in the blockchain. When starting a web service, the states important for the blockchain should be considered separately.
At the same time, the web service is considered as a state machine (FSM + set of states + evolution model), which “flow” among themselves under the influence of user behavior. Not all site states can have any value in writing them to the global BC.
The sig describes the evolution of the microservice state from the start of its local Genesis, that is, the block (the start of microservice operation), constantly self-modifying itself (self-modification of the sig with gVM core) by adding a new state to the end (according to the evolution model).
The concept of trusted sig of the service
As the Actions and Bactions are executed, the service completes the service’s curve. The sig must be synchronized on the service side (OFF-Chain side) with the sig stored in the Blockchain block. After verification and synchronization (according to one of the algorithms), the sig can be considered trusted and ready for the next command.
6. Bactions and Actions
General methodology for all GONT Web services (not only for the GONT-Elections service).
State Machine – Site states machine.
It is possible to execute a large variety of user actions on the site – i.e Actions. However, these actions have significant semantic peaks and should be reflected in the blockchain (important transactions). At the same time, it is necessary to align the site state machine and the corresponding blockchain service of the site. It is necessary to build a correct display of the site on the blockchain.
Our approach is matched with the Buterin approach in Plasma [plasma.io]. We are building a consensus model for nested blockchains.Implementation via GONT VMTo reduce resource consumption, GONT VM is not running continuously. In fact, the GONT VM turns on, performs new transactions and shuts down. In this case, the last state of the GONT VM is stored in the service sig (it is also the local GONT BlockChain).BActions = Blockchain Actions
Bactions – user actions for Blockchain.Thus, we come to the model of the evolution of states.Example of the evolution model for ElectionsBActions:
- INIT
- Registration
- Vote {Vote options}
- Stamp
- Writeback
Evolution:
Each BAction has a dedicated unique address in GONT Space.
Conclusion:
When developing any new service, it is necessary to clearly state Evolution and Actions. Evolution is realized through a smart service contract in the GONT VM core.
Thank you for attention! Good luck!
GONT