Basic system contract successfully registered
The basic (parent) system contract, that is used to register system contracts for operation types, updating versions, and the operation parameter table of contents, was successfully registered and activated within the system.
It would be impossible to begin working with transaction-type contracts, maintain them, and monitor versions without starting with the fundamental contract.
One of the most crucial phases in preparing to deploy the network is launching and testing system contracts. It is also required to begin open testing and sequentially check the execution of various types of operations.
The network provides separate types of operations for different tasks. Each operation is carried out by its system contract's current, at the time of execution, version.
For example, registering a new system user summons the register type's system contract. There are also distinct transaction types for:
- updates to the user's personal profile
- sending a message through the messaging system
- Creating and updating a group or company
- creating and updating an object
- publications of public group news items
- user authentication
- personal digital signature registration
- document and image registration
- user system rewards
- document signing between users
- reputation updates
- creating links
- transfers between users of financial or other assets
and other operations, of which there are more than 20 types in total.
Contracts in the system can be of two types: system and user. Transaction type contracts are system-only.
The contracts source code can be open-source or encrypted.
Contracts are written in the elixir/erlang programming languages.
There are specific criteria for the blocks to be selected for each transaction type.
Only system worker blocks are suitable for some types of operations; for others, blocks from system users are required, which must meet certain criteria depending on the type of operation:
- block lifespan from the moment of creation
- the reputation of the block's creator
- the time since the block's creator registered in the system
- the number of block confirmations since creation
As well as other criteria.
A transaction that performs an operation must also meet the following criteria:
- the transaction's block count
- the percentage of blocks validated in a single transaction
- the percentage of block validation confirmations
- the number of transactions in a single operation
- the number of nodes involved in the transaction
- the time it takes to complete the transaction
As well as other criteria
The higher the criteria for blocks and transactions, the more expensive the blocks and transaction fees are, and hence the greater the reward for the creator of each block.
The user who creates the operation can configure the block requirements for specific types of operations.
Need Support? Create a Ticket.
Create ticket