Published 25 June 2019

Concept of Smart Contracts Architecture

Architecture description


Smart contract is a program code that allows you to automate business process and represent it in the form of logically connected mathematical operations. In Credits platform, smart contract is a Java code presented in the form of byte-code. Smart contract is a set of classes, methods and properties of that class that allows you to apply object-oriented programming during the architecture development.

Smart contract execution implies execution of its methods. The following methods should be distinguished:
1. Method constructor(). This method initializes smart contract upon its first deployment in blockchain;
2. Method payable(). This method enables automatic processing of incoming to the smart contract address payments & transfers.;
3. Methods get...(). A set of methods to get the state of a smart contract. Execution of these methods doesn’t entail change of a smart contract state and can be executed on any node with the use of Credits platform API.

Some transactions can store other information besides byte-code in USRFLD field.

Execution of a smart contract is an initialization of smart contract methods. Trusted Nodes of the current round process and execute smart contract and the execution is parallel on all Trusted Nodes, after which  the obtained solution is verified according to BFT algorithm and decision is made whether to add new smart contract states to the blockchain.

Types of Transactions

There are 5 types of transactions in Credits platform:
1. Deploy transaction. It serves for initial deployment of the transaction code in the blockchain, its initiation with the method constructor().
2. Start transaction. The transactions contains sorted list of smart contract methods and corresponding set of parameters. Every start transaction should have corresponding new state after the execution of the smart contract. This transaction can be made with user’s wallet, initiator of the smart contract execution, and with the smart contract execution as well (i.e. smart-gen transaction).
3. NewState transaction. After smart contract execution its news state is stored in NewState Transaction. Each such transaction stores the link to corresponding Start transaction in the field USRFLD1 (block number, block hash, transaction ID).Distinguishing features of this transaction is that the fields “Sender” and “Receiver” are the same and store smart contract address. Logically, this means transmission of a new state to itself.
4. Smart-gen Transaction. A transaction generated during smart contract execution that has smart contract address as “Sender” address. Every transaction that has smart contract address as “Sender” address should have separate mechanism of signing and signature verification, because it’s not possible to store private key in a smart contract for security reasons. These transactions are signed by the Trusted Nodes of the round and for signature verification an additional link to the block is added in the fields USRFLD. Block structure contains a list of Trusted Nodes public key, with which signature verification is possible.
5. Ordinary transaction. This is ordinary transaction containing transfer amount in the field “amount”. With this transaction it’s possible to send with the smart contract address as “Receiver”. Mechanism is implemented with automatic execution of payable() method.









Smart contract deployment

Smart contract initialization

Smart contract state

Transactions generated by a smart contract

Transfer of funds to smart contract with ordinary transaction


ID is pubkey of the wallet of smart contract owner

ID is pubkey of the sender’s wallet that initiated smart contract execution

ID of smart contract states. It begins with 1 and increases by 1 with each new transaction sent from smart contract pubkey


ID is pubkey of the wallet of the transaction sender

Sender (public key or index)

pubkey or ID of  the wallet of smart contract owner

pubkey or ID wallet initiator (smart contract can be an initiator)

pubkey or ID of the smart contract itself

pubkey or ID of a smart contract

pubkey or ID of the sender wallet

Reciever (Public key or index)

pubkey or ID of a smart contract

pubkey or ID of a smart contract

pubkey or ID of the smart contract itself

pubkey or ID of a smart contract

pubkey or ID of the receiver wallet


If > 0 initiate method constructor, and then payable

If > 0 initiate method “payable”, and then smart contract methods

Always set to 0

Transaction Amount

An amount transferred to smart contract (processed by the method payable)


Maximum possible fee for processing transactions by consensus. It’s set by smart contract owner.

Maximum amount that can be spent on smart contract execution. It’s set by the smart contract initiator.

Maximum amount that can be frozen on the balance for smart contract execution. It’s set automatically before smart contract execution.

Maximum amount that can be taken from a smart contract for processing of a transaction. It’s set set by the smart contract logic.

Maximum fee that can be spent by the sender for processing a transaction by consensus. It’s set by the sender.







Amount of  USRFLD


For wallet senders: 1

For smart contract senders: 2





Smart contract bytecode

List of methods and arguments

Changed smart contract byte code (new state)

Link to “start”L 

1. Block number

2.Block hash

3.Transaction ID




For wallet senders: n/a


For smart contract senders: Link to “newstate: 

1. Block number

2.Block hash

3.Transaction ID

Link to “newstate: 

1. Block number

2.Block hash

3.Transaction ID






Rewards amount (distributed between all Trusted Nodes from USRFLD1)




Signed by PrivKey of the smart contract owner

For wallet senders: signed by PrivKey of smart contract initiator

For smart contract senders: Signed by PrivKey of all Trusted Nodes of the round where the transaction was initiated

Signed by PrivKey of all Trusted Nodes from USRFLD1

Signed by PrivKey of all Trusted Nodes from the list of the block in USRFLD0

Signed by sender’s PrivKey


Written by consensus before adding to the block. (Deploy consist of 2 stages: 1)byte code placement 2)initialization through “state” mechanism)

Written by consensus

Fee transferred to Trusted Nodes of the round where the state was added to the block

Fee transferred to Trusted Nodes of the round where transaction was added to the block

Written by consensus before adding to the block

Table 1: Types of Transaction in Credits platform

Process of Smart Contract Execution

Smart contract execution is initiated with special Start transaction that contains sender address (32 byte public key or 4 byte index), smart contract address (32 byte public key or 4 byte index), transaction amount in coins (can have value 0), it also can contain the list of called smart contract methods and transferred arguments
Process of smart contract execution. when the round begins, Trusted Nodes receive transaction packets and packets of smart contracts new states along with round table. Packets with smart contracts new states are received from the Trusted Nodes of the previous round where smart contracts were executed. By the beginning of the current Trusted Nodes can receive packets with transactions and packets with smart contracts new states from different previous rounds.
Packet with “new states” is similar to packet with “transaction”, but differs in additional information: it’s signed by all Trusted Nodes of the round and contains number of the round where smart contract execution was initiated.
Based on the received data and the data from blockchain DB, Trusted Nodes forms a queue for execution of smart contracts for the current round and then execute them in the formed order.
During smart contract execution process new transactions can be generated, with which transfer of funds and launch of smart other smart contracts happens.
When all Trusted Nodes finished execution of all smart contracts, there’s an additional consensus on all new states of smart contracts and newly generated transactions. When consensus finishes, a new packet with new states is formed and the list of current Trusted Nodes is requested (from the last rounds table).
During consensus the protocol assigns a delegate that distributed the packet with new states to all Trusted Nodes for adding them to the block.
Thus, round finishes with generating a new block. Trusted Nodes continue processing smart contract according to the formed queue. After processing is finished, smart contract new states are sent to the Trusted Nodes of the current round for adding them to the blockchain.
During the processing of input data, Trusted nodes perform the following:
1. Queue actualization of smart contracts execution and their execution;
2. Generation of a new block which includes transactions processed during the round as well as packets with new states received from Trusted Nodes of previous rounds.
Adding information about smart contract initiation to the queue ensures correct sequential execution of the same smart contract in the following rounds. This guarantees that smart contracts will be executed in a strict order based on the previous states. Each next initiation of the smart contract is done strictly after the previous initiation had finished and new state is recorded in the smart contract.
As soon as Writing Node formed a block, it distributed the queues of smart contracts execution to the next Trusted Nodes along with the new round table.
Smart contract execution is not connected with the generation of a block during the round and continues until its full completion on all Trusted Nodes. Once executions of smart contracts finishes, there’s another consensus for smart contract new states, after which the result is signed by digital signature of all Trusted Nodes that have participated in that consensus.

Queue of Smart Contracts Execution

Before executing smart contracts, Trusted Nodes should actualize execution queue based on blockchain DB, received packets with transactions and packets with new states.
After queue actualization, smart contracts are moved to execution queue which ensures sequential execution of the smart contracts. The necessary conditions for proper consensus on the new states of the smart contracts are requirements for the same initial states, the same execution queue and the same results of the smart contracts execution on all Trusted Nodes of the round.



Round number

Start Transaction (main fields)




i- k

sender_id1; contract_id1;

execute: ([methods*([args*]]))


In the round R(i-k) contract contract_id1 was initiated. During the round network should ensure the contact hasn’t been executed and the block (i-k) doesn’t have its executed state. Verification is made with the algorithm of execution queue actualization




sender_id2; contract_id2; execute: ([methods*([args*]]))


During the round R(i-m)  smart contract contract_id2 was added to the execution queue, but due to certain reasons wasn’t executed in that round. It should be considered as “to be executed asap” (possible solution could be that Main Node can set a mandatory requirement for that smart contract execution in the current round)





execute: ([methods*([args*]]))


Current Round. Start transaction was received for contract_id3 smart contract, and Trusted Nodes of the current round can execute it first, because there’s no information that it’s already being executed at the moment.





execute: ([methods*([args*]]))


Current Round. Another start transaction was received for contract_id3 smart contract, but it is to be executed after the transaction #3.






Table 2: Example of smart contracts execution queue on execution stage.

Initial formation of the smart contracts execution queue occurs based on blockchain DB and is actualized with each new block (Fig.1).


Fig.1 Actualization of the execution queue

By scanning the blockchain from the very first block, it’s possible to determine the exact round of the smart contract execution. For example, transaction1 triggered execution of the smart contract contract_ID1, and transaction2 recorded new state. This way, smart contract execution started in the round, where the block containing transaction1 was generated, and finished in the round where the block with transaction2 was generated.

If a node becomes Trusted, packets with transactions (can contain new Start transactions) and packets with new states (can contain new start transactions, new changed states) are added to the actualization process of the execution queue.
Smart contracts execution on Trusted Nodes is shown with details on the Figure 2. It’s seen that Trusted Nodes participate in the consensus procedure 2 times:
1. Consensus for block generation. In this consensus a new block is generated which then is distributed throughout the network, Writing Node collects new hashes from other nodes and forms new round table.
2. Consensus for the generation of the packets with new states. This process finishes after all Trusted Nodes execute all smart contracts according to the queue.


Fig.2: Execution of smart contracts on Trusted Nodes

Sample of queue formation is provided on sequence diagram (Fig. 3):
1. During blockchain scan Start transactions “start1-3” were detected which are added to the queue.
2. Then, new transactions with the states “NewState1-2” are found. Matching start transactions (“Start1-2”) are found in the queue and then removed from it.
3. After search through the blockchain is finished (the last read transaction “NewState2”), same search occurs through the packets with new states and packets with transactions. Same rules are applied: upon detection of “Start” transaction, recording is made to the queue, and upon detection “NewState” transaction the corresponding recording is removed from the queue.


Fig. 3: Sample of execution queue actualization

As a result, when all sources of transactions are searched, the node begins smart contract execution according to the actualized execution queue.

Function for indexing smart contract addresses

Smart contracts have functions that allows you to operate with addresses’ indexes (4 bytes) the same way as with public key. A caching mechanism is used for operations with smart contract and public keys indexes. First bit of public key index has the value 0, First bit of smart contract index has the value 1 respectively.
Note: this way it’s impossible to determine by a public key whether it’s an address of a smart contract or a wallet. This is possible only through public key index.

Generation of a new transaction by a smart contract

New type of transaction where the sender address (or sender index) is the address of a smart contract.
When smart contract generates a new transaction (“start” or “smart-gen”) its address is written to the sender address (public key or index), and the transaction is signed by all Trusted Nodes of the round where the smart contract was triggered. Information about the signing nodes is written to the field “USRFLD”.
Triggering smart contract from another smart contract is implemented with the use of mechanism for generation of transactions from a smart contract. If a smart contract has to execute another smart contract or recursively trigger itself, it forms new Start transaction with the necessary parameters.

Function for signing transaction generated by a smart contract

A function for signing transaction by all Trusted Nodes of the round with adding transaction to the block in another round. Signature verification ensures the transaction is signed by Trusted Node from the list contained in the block which the transaction field USRFLD is referring to.


Smart Contract Wait Function for Other Smart Contract to execute

A function that allows you to trigger one smart contract from the other and wait for its execution is implemented

Smart Contract Deploy Function

Smart contract deployment is implemented with deploy transaction in 2 stages:
1. Placement in the blockchain of deploy transaction with non initialized smart contract byte code;
2. Smart contract initialization through execution of constructor() method. If the deploy transaction field value had the value more than 0, payable() method should be called right after initialization, after which new initialized smart contract state should be saved with NewState transaction.

Method Constructor() Implementation

During smart contract deployment, single call of constructor() method is ensured after not initialized transaction is written to the blockchain.
After calling constructor() method, method payable() is to be called in the same round if the amount field value differs from 0.

Method payable() Implementation

Method payable() allows you to trigger smart contract code by transferring to it certain amount of funds in the field amount. This function is triggered automatically during smart contract verification, but before calling smart contract methods.
Deploy transaction is an exception to this, in which method payable() is called after initializing method constructor().

Signing new state of a smart contract

Signing smart contract (Signature of Trusted Nodes or Writing Node), signing new start transaction generated by a smart contract.
New start transaction is generated and signed by Trusted Nodes of the round where smart contracts were triggered.

Getting smart contract state by an external system

Smart contract methods are divided into 2 main types (see Table 3)

Table 3: Types of smart contract methods


Method type



Methods that don’t change smart contract state, but allows getting their current state.


Methods that change smart contract state. Triggered only on Trusted Nodes of the round

Reserve funds for the smart contract duration (“Freeze”)

At the beginning of the smart contract execution, it should have certain amount of funds that will allow it to be executed with the computational power of Trusted Nodes.
Possible situation where at the moment of triggering a smart contract, it had necessary funds, but after its initiation they were sent to other wallet, thus, leaving the smart contract without necessary funds. To prevent this situation smart contract reserves the necessary funds that will allow its successful execution.

Transferring transaction state through the API

smart contract functions provided through the API (wallet has the ability to get current state)
Following functions are implemented to allow the wallet to get transaction state:
In progress. Transaction is sent for processing, but wasn’t added to the block yet
Accepted. Transaction is added to the block
Rejected. Transaction wasn’t added to the block, If it is added to the list of the transactions being processed in the round, but it’s not in the generated block.

Following methods are implemented in the API:
- get smart contract states to implement getters
- Get InnerID (Wallet Transaction ID)
- Get transaction state
- transfer of methods parameters of a variant type smart contracts

Balance calculation

By balance calculation final result consist of three components:
1) Summation result of incoming and outcoming funds from wallet public key;
2) Amount of fees for execution of transactions (field “Fee”);
3) Rewards to the nodes that were executing smart contracts;

Consensus Function for smart contract new states

After all smart contracts from execution queue are executed, a vector of new smart contract states is formed and consensus is held.
After consensus a packet with changed states is formed which is signed by all Trusted Nodes and sent to the current round to be added in the block.

Formation of execution queue based on blockchain database

Operation principle (if different smart contracts are triggered, they’re executed in parallel):
1 smart contract “contract_ID1” is deployed on the blockchain. Transaction “1” is the result of smart contract deployment
2 To trigger smart contract, start transaction “start contract_ID1” is generated which has as its parameters a set of methods to be executed in the smart contract and set of arguments for those methods
3 Nodes that are to trigger smart contract, go through consensus procedure and after start transaction is added to the block, they begin to form a queue
3.1 Chain of transactions from the moment of smart contract deploy is restored
3.2 Search for start transaction is initiated. First found start transaction is added to the execution queue and assigned status “Running”
3.3 The next start transaction is added to the execution queue with the status “Waiting”
3.4 In a similar way all blockchain is searched through till the last block. As soon as the transaction with the new state appears, start transaction matching the one in USRFLD2 of NewState transaction is found. A pair of Start transaction and end state indicates that the smart contract is executed and recording can be removed from the queue.
3.5 As a result there can be no recordings which means all smart contracts were processed earlier and there are no new requests. Otherwise, each Trusted Node of the round begins execution of a smart contract placed first in the queue. In this case there’s no need to save intermediate smart contract state. Final smart contract state which will be formed after execution of all tasks from the queue will be added to the block.
After execution of all smart contracts, there’s another consensus and smart contracts states are gathered to the packet with changed states which is sent to the current round (to the Trusted Nodes from the last received round table).

Terms and Abbreviations

Smart contract- computer algorithm designed to conclude and maintain commercial contracts in blockchain technology

Execution queue - a table stored on the node which determines the execution order of smart contracts. Records are added upon the appearance of start transactions in the blockchain. They are removed as soon as there is corresponding NewState transaction in the blockchain.

Smart Contract State -  it’s a Java byte code which is changed with the execution of any methods or when smart contract internal values are changed


Start transaction is a transaction which has smart contract address to be executed in the field “Sender”. It can contain a list of methods and arguments which are to be transferred to the smart contract for execution

Deploy transaction is a transaction that contains smart contract address in the “receiver” field and byte code of the smart contract in the field USRFLD1. By execution of deploy transaction, smart contract is added to the blockchain.

Packet with “changed states” is a set of new states of the smart contracts which were executed during the round. They are signed by all nodes of the round and sent by a delegate to all Trusted Nodes of the current round.

Votes 0, average rating 0