Trinity protocol

The system is based on three types of users: (i) solver (PoW); (ii) holder (PoS); and (iii) publisher (PoA). None of those could act as another which is achieved by cryptographic and technical methods. The following describes how the blockchain operation is divided by those nodes. Note, none of the types can form the blockchain independently.


PoW solver is responsible for the generation of new k-blocks. Main requirements: (i) access to the Internet; (ii) storage (required to store the blockchain structure); (iii) computational power for hashing. The solver is recursively calculating nonces for new k-block generation according to the set of predefined rules (difficulty, batch number, hash links validity). Each k-block is distributed
through the network in a broadcast way after its generation. Each node is checking its validity based on locally stored data and add it to local blockchain storage if valid. Conventional Nakamoto consensus protocol is used for the blockchain construction.
The solver’s main aim is to generate the block and obtain the resulting award for the computational expenses. k-block contains its solver’s public key . The rewards are calculated dynamically. The selection of the hashing function does not affect the overall system operation directly. The TestNet utilized for performance evaluation uses SHA-256, but this choice is temporal since modern ASICs can easily calculate it.


PoS holder is a node holding a reasonable amount of coins. The node can prove hive eligibility to become a holder based on the protocol. Key SKHK is a shared key distributed between a set of holders based on the Lagrange interpolation formula. The corresponding PKHK is known to any node. The Resident node is responsible for SKHK generation and a group of
holders forms a Private Key Generator (PKG). Holders are systematically executing the protocol to verify who has the right to distribute the publication keys during this system operation state. This interval is set to 100 k-blocks in TestNet. The Leading PoS (LPoS) selection results are then stored as statistic blocks andmay be verified using the protocol. Next, LPoS is generating the publication secret key after the k-block retrieval. The publication public key is calculated based on the k-block ID (hash sum). The secret key and the corresponding shares are calculated based on the protocol. The shares are then distributed to PoA publishers selected for the publishing of the microblocks related to this k-block. The intermediate execution results are stored in the static
block and could be verified later on. The holder gets a reward for participation in the publication key generation process.


PoA publishers are involved in the microblock publishing process. Each microblock should be verified by a coalition of grouped PoA publishers. In order to retrieve a new k-block, PoA publisher is requesting the LPoS the key share correlated with this k-block. Next, PoA generates the microblock payload (array of transactions) and forwards it to the other PoAs in the coalition. After the necessary number of PoAs have signed the payload (according to threshold schema). Therefore, the microblock data becomes validated by k PoA nodes in the system, and their participation may be verified later on The PoA rewards are based on participation in the verification procedure.