The concept of TREVAL in GONT

Greetings, colleagues! Today we are talking about the concept of TREVAL in GONT. We will tell you what is it, how it functions and what is the novelty and complexity of the GONT approach.

What is TREVAL?

We have mentioned this concept in our articles many times. And before we start talking about the specifics of TREVAL in GONT, you need to understand what it is.

TREVAL = TRansaction EVALution

A more extensive interpretation of the concept: treval = evaluation + evolution.

The canonical understanding of the transaction from Ethereum

Transaction as a function call:

Here, the general scheme is that an external account will pass arguments to a function and the EVM will direct that call to the appropriate contract and execute the function, granted the appropriate amount of Ether and gas are supplied. As a consequence, every transaction in Ethereum can be considered a function call. The function calls and transactions in Ethereum comply with PoS, which has a faster resolution time than the Bitcoin blockchain that relies on PoW. The security level of this process verified by the network is also very high.

Understanding of the transaction in GONT

We consider the transaction as an evolution of the transaction state(Transaction State Evalution) through a sequence of virtual machines.The novelty and complexity of the GONT approach is the need to correctly reproduce the state of the machine and the state of the transaction during the entire evolution period (all routing transactions are carried out through all VMs). This is an additional innovation and additional complexity, which leads to EVM sharding (the basic approach of GONT). In this case, several events are possible to confirm the transaction (TRCommit). The transaction must be confirmed at the output of each core. One gVM core can execute several transactions to the Commit state in one work cycle, but this is only Commit in this given core.We need to achieve the state of Commit in the entire TREVAL channel.

Total COMMIT:

TOTAL COMMIT = {COMMIT (gVM1)} AND {COMMIT (gVM2)} AND ..
{COMMIT (gVM_N)}

When the state of the total COMMIT is reached, the transaction can be written to the BC. In this case, the routing channel TR can pass through a hundred different VMs.As you progress through TREVAL CHANNEL, the transaction can also be reset depending on various unfavorable conditions for the transaction. One of the main conditions in the current Ethereum is the lack of gas to execute the transaction. There can be more events in the GONT TREVAL CHANNEL (Traps – exceptions, Events, Interrupts):

The concept of adaptive consensus

Current consensus in Ethereum:

What does it mean for the outcome of EVM to be deterministic? It is essential for each node to reach the identical final state given the same input for a contract method. Otherwise, each node that executes the contract code to validate the transaction would end with different results and no consensus would be possible. This is the deterministic nature of EVM that allows every node to reach consensus on execution of a contract and the same final state of accounts. The nodes executing a contract are similar to cogs synchronized to move inside of a clock, as they work in a harmonious fashion and reach the matching final state. A contract can also refer to other contracts, but it cannot directly access the internal storage of another contract. Every contract runs in a dedicated and private instance of the EVM where it only has access to some input data, its internal storage, the code of other contracts on the blockchain, and various blockchain parameters such as recent block hashes. Every full node on the network executes the contract code simultaneously for each transaction. When a node is validating a block, transactions are executed sequentially, in the order specified by the block. This is necessary because a block might contain multiple transactions that call the same contract, and the current state of a contract might depend on state modified by previous references during the code execution. Executing contract code is relatively expensive, so when nodes receive a block, they only do a basic check on the transactions: Does the sending account have enough Ether to pay for gas? Does the transaction have a valid signature? Then, mining nodes perform the relatively expensive task of executing the transaction, including it in a block, and collecting the transaction fee as a reward. When a full node recieves a block, it executes the transactions in the block to independently verify the security and integrity of the transactions to be included in the blockchain.

GONT interprets the consensus more extensively.

1) EVMs remain deterministic and run the same contract code, but the data for the calculations may be different. Here, the algebra of ontological proximity of data enters into action to calculate the “consensus coefficient”.

After all, our goal is to prove that the service gas of this VM is relevant for these data (it is ontologically close), and the work of the gas, for which the owner (developer) of the service will receive a fee, was committed.

2) The owner of the service can decide to start a consensus not on all network leaders, but only on those chosen by him. Ultimately, it is up to the user of the service to decide what level of consensus they need for sufficient quality and reliability.

Thank you for attention! Stay tuned.
GONT