Technological features of UWIM

Technological innovation

UWIM — A network distributed cryptographic platform for convenient creation, use and accounting of decentralized applications (smart contracts).

We put the idea of ​​a perfect data and system functions centralization and decentralization balance as the core of our technology. The system development, upgrading and updating are made by the company, but the validation, control and decision-making (consent or disagreement) with the updates are decentralized and are determined only by the platform participants.

The UWIM platform architecture was designed, taking into account a large number of custom tokens with specific smart contracts. UWIM is based on its own blockchain technology as an independent software product that is not a fork of Bitcoin.

Decentralized part

The platform sustainability and transparency are achieved by blockchain technology (distributed data registry) with its own modified version of the Proof Of Stake consensus (decision-making model between participants).

All data is distributed between servers (The source code of the nodes is freely available). Any network participant can deploy one of the nodes types (a full node — with the entire history of network operations, the ability to validate blocks and all the JSON-RPC API functionality, a light node — with the JSON-RPC API functionality). A full node can become a validator when requirements are fulfilled and participate in the main consensus.

The network can include an unlimited number of tokens, smart contracts and participants (addresses) and can be easily controlled by the participants.

Own node assemblies were created for further platform optimization and development

Technological features

Data storage and encryption

Leveldb with an open license is used to optimize the volume and fast access to the necessary data (Technology for large amounts of non-relational data storage of the key>value format).

Access to the network participants data is obtained using a hierarchically generated BIP39 key. Addresses for each participant are divided into three types using the bech32 format: main address (uw prefix), smart contract address (sc prefix), node address (nd prefix).

Then the participants exchange data by sending messages to the node and sign the messages with their secret key. The data goes through primary validation on the node that received the message, it is sent to all validators, combined into blocks and sent to consensus. Hashing is done using sha256 encoding.

Several levels of data validation were created in the node core for complete verification and elimination of errors from the moment it arrives at the node until the moment of consensus.

Consensus

The modified version of the ProofOfStake consensus implies making decisions depending on the number of coins on the validator nd address (or nd + sc, depending on the presence of a smart contract for delegation) and the total number of validators.

Each node constantly accepts transactions from network participants, the data goes to the initial pool for processing that eliminates data overflow and consensus delay. Then a node validates the transaction based on its own blockchain and makes a decision: to approve or immediately reject the transaction. Accepted transactions are immediately sent to other network validators, the list of which is automatically loaded from the main or other nodes.

Nodes that have received the status of a validator take part in the consensus at the same time with data obtaining: Validators become a proposer (proposer is a validator that offers data for consideration) in a predetermined order. If the block is accepted, the proposer receives a reward. Reward data has its own type of transaction. The proposer adds a reward transaction that is validated along with the rest when a block is sent to consensus.

Each round of consensus occurs in the following order:

1) Proposer creates a block based on its own pool of incoming transactions (own and others), signs and sends it to other validators. Having received a block, other validators save it to their temporary memory. If the proposer has not submitted a block, the system collectively assigns him penalties. Proposer also adds a transaction to the block with its own reward for the correct block creation (All reward transactions come from the Genesis address if funds are available on it).

2) Validators analyze blocks based on their data and respond to other validators about acceptance or rejection.

3) Each validator evaluates the answers of the others according to two criteria (The total number of validators balances that voted FOR must be at least 66%, and the number of validators who voted FOR must be at least 50%). If both requirements are met, each validator sends a block for the record and execution of all transactions.

4) Each validator analyzes metrics, clears temporary memory and prepares for a new round

Contracts

In addition to ordinary addresses, the system may contain smart contracts that have their own logic and RAM. Both logic and memory of contracts are also used in a decentralized way (stored in an identical state on all nodes).

Smart contracts are divided into main groups: Contracts to support system development and user contracts.

Contracts are added exclusively through the centralized node (More details in the “Centralized part” section). The contract can accept a transaction and then, based on its own logic, perform a number of calculations and multiple sending of transactions. Each contract is represented by a separate application on the nodes. All the results of contract operations are sent to a consensus after execution for confirmation by other participants and for the inability of code or memory data modification.

There is a main token in the system, and many participants tokens can be created. The token itself is similarly a smart contract and has an owner (address). The owner can use the balance of the smart contract but cannot change the terms of the contract directly in the blockchain. Also, in some cases, the owner can cancel ownership of the smart contract. In that case, their signature will not be accepted by validators when processing transactions.

There is a fee for any transaction calculated in the main token. The fee depends on the current network load. It is possible to increase and decrease the fee to slow down or speed up transactions. The validator that offered the block with this transaction takes all fees.

The exchange between tokens is carried out through a smart exchange contract: A “liquidity pool” is created for each pair of the main and user tokens. The pool determines the exchange ratio. Additionally, two liquidity pools are applied when exchanging a user token for another user token (from each pair).

Each node has a gateway for sending and receiving data (API) in JSON-RPC format. Any network participant can connect their own IT solutions to the blockchain via the API and link their own smart contract with their centralized product, depending on their own needs.

The implementation of a node can be in different programming languages ​​and for various operating systems.

Centralized part

The centralized part of the project is a convenient user interface for UWIM blockchain. The source code of the centralized part is the property of the company and is not distributed.

A user can store and use tokens presented in the blockchain by other participants in the personal account. Besides, a graphical interface helps to work with smart contracts presented in the blockchain and create standard templates for tokens and smart contracts.

Any network user can attach one of their tokens to the address in their account. The label and issue (which cannot be changed in the future), the name and other data (which can be changed in the future through transactions) are determined. In addition, a user determines the type when creating a token (personal — a token that is controlled only by the creator; team — requires the signatures of a certain number of participants; nft — a unique instance token managed by only one participant. Besides, each token has an owner card and a token card. The cards data is updated through the owner’s transactions (Details are described below in the “Token Market” section). Tokens are divided into standards, depending on the data in the cards. Various smart contracts can be added to tokens depending on the token standard. The created token / smart contract is uploaded to the general network and becomes decentralized and accessible to everyone after monitoring and security systems passing. A user will be able to supplement a token with new nodes in the process of development, but all initial parts become unchanged and directly dependent on the initial conditions.

Сustom coins and smart contracts creation to order and their integration into the business

If a user (person or company) wants to implement non-standard solutions (token / smart contract / API / application), they can use the company services. This process starts with an application in their account and verification. An SDK will be developed for this situation, and advanced solutions will be created on its basis.