Preliminary calculations in TREMISS BlockChain is an essential part of the ecosystem. Preliminary computations create a template that defines how the “NodeTr” in “TreSupervisor” should process information during block generation. Therefore, the pattern is completely defined before any message information arrives to generate a block. The use of preliminary calculations ensures confidentiality, at the same time dramatically increasing the speed of information processing to create a block.
There are two stages in creating a TREMISS block. First, “NodeTr” performs an intensive preliminary calculation, as described above, creating a unique template that determines how the information or messages of the block will be processed. When messages arrive, “NodeTr” work together to process messages in real time according to this unique template, a process that takes less than 1/30 of the precomputation time. TreSupervisor cannot affect the integrity of the consensus mechanism, since all aspects of the production of blocks are independently predetermined in a strict, verifiable and unchanging manner. After generating the block, “TreSupervisor” is dissolved, and “NodeTr” become available for placement in the new random “TreSupervisor”. After creation, block data is transmitted to each “NodeTr” in the next “TreSupervisor”. As soon as the next active “TreSupervisor” has received the block data, the data is then transmitted to the remaining “NodeTr” on the network. This sequence sets the priority for communication with the next “TreSupervisor” responsible for block generation, ensuring efficient block distribution.
At any time in the network there will be tens to hundreds of “NodeTr” at different stages of the preliminary calculation. These preliminary calculations overlap in a cascade. Consequently, network bandwidth increases with the addition of more “NodeTr” to the network, forming more “TreSupervisor”. This allows the platform to linearly scale its capacity with the addition of more nodes. Increasing the number of “NodeTr” leads to increased network resilience.
The consensus protocol TREMISS BlockChain is designed to simplify anonymous and scalable solutions, exchanging messages and payments through a chain of blocks. The TREMISS BlockChain negotiation protocol allows you to create a robust, reliable platform that can meet any application requirements for BlockChain.
Each “NodeTr” in “TreSupervisor” performs the following operations in a consistent TREMISS protocol:
a) Before any transactions become known, “NodeTr” defines a pattern containing commits in the message slots for transactions. The template determines, but does not disclose, the order in which each transaction will be processed in a block, and how transactions will be opened by “NodeTr” in “TreSupervisor”.
b) Regardless, the “NodeTr” in the group negotiates and fixes transactions without knowing the contents of the transactions, and transfers this commitment to all the other “NodeTr” groups.
c) As “TreSupervisor”, “NodeTr” open all transactions together in a given order, revealing their contents.
d) When TreSupervisor agrees that all transactions are valid and the Comments have been made to process transactions correctly, the nodes again transmit these Comments to all other nodes. Then “NodeTr” performs all transactions. Each “TreSupervisor” independently generates and transmits a block, which must be identical to the block created by all the other “NodeTr” in “TreSupervisor”.
TREMISS BlockChain consensus has an advantage over other consensus mechanisms that each “NodeTr” participating in “TreSupervisor” provides a brief proof that it has correctly processed transactions and publishes this evidence as part of a block.
As a result, the output block is the product of a valid input.
Any disagreement leads to the fact that the wrong proof is attributed to an inappropriate “NodeTr”, which disables the identification of this “NodeTr” in the network.
A simplified payment transaction in the system begins with an account.
Bob sends Alice an invoice containing the recipient's address (where she should send the money).
This address is the image (the output of the hash function) that Bob had previously generated from a random prototype (the secret hash, which is the input to the hash function).
After receiving the target image (address), Alice sends a payment transaction to the system.
This transaction contains the image (secret het) of the token belonging to it, as well as the image (address) from Bob’s account.
The system checks whether the sent (secret) Alice pre-image is valid and whether it exists in the ledger, and then transfers the specified amount from Alice's token to the image (address) of Bob (address).
After successfully processing the transaction, the system returns a confirmation check to Alice, which she can share with Bob, who confirms that the transaction was completed correctly.
This receipt serves as proof that the transaction is correctly recorded in the block, by indicating the Merkle path in the block of these tokens.
This alone is sufficient evidence that the transfer was correct, and therefore the tokens now belong to Bob.
However, both parties (Alice or Bob) can freely check TREMISS BlockChain and check the presence in the corresponding block of the target image (address) and the correct number.
TREMISS’s unique architecture and payment processing mechanisms offer three advantages over traditional approaches:
- User privacy is protected by limited information available on the network.
-Security is greatly enhanced by providing tokens instead of wallets.
- Transaction processing is faster, since hash-based ownership can be completed in a fraction of the time it takes to digitally sign on BlockChain's traditional platforms.
As others have said, when comparing the digital signatures characteristic of traditional BlockChain platforms with the hash function-based digital signatures used in the TREMISS platform, “each signature scheme uses a cryptographic hash function; Hash-based signatures are no longer used. ”
Finally, unlike digital signatures, hashes are protected from quantum computing capabilities.
Tremiss uses a new approach to the information contained in the blocks.
Each block contains nothing more than unordered lists of past and new addresses to which tokens have been assigned by the transactions of this block.
Analyzing the whole chain of blocks, the observer cannot connect the parties involved in the operation or the peculiarities of the transaction with each other (i.e. how many were sent).
As a result, we can only conclude that in a particular block a set of tokens was assigned in an unrelated way to new addresses from old addresses.
Both in the block and in the nodes, the data is stored as a binary radical tree in combination with the Merkle tree.
This structure allows you to quickly search and rephrase the root in the nodes, as well as generate evidence that checks the existence of the token in the block.
This is achieved by simply opening the hash of the root block, the token and all intermediate non-leaf data blocks.
As a result, the transcripts can be generated and used for verification instead of requiring all the data of the corresponding block referring to the transaction of interest.
The processing of tokens in the TREMISS platform has some unique attributes.
The processing of tokens in most of the traditional BlockChain systems today is based on a wallet. In the TREMISS protocol, the token processing is based on a token, that is, the token remains static, while a private Hesh is required to confirm ownership.
These secret hashes are stored outside the chain and change when the ownership of the token is assigned to the new owner.
TREMISS protects individual tokens, not the entire wallet.
Each token owned by a user is protected by knowledge of a separate secret hash, which means that even if an attacker successfully executes a brute force attack, only one token from the user can be stolen.
TREMISS blocks do not contain any information about transactions, that is, about the sender, recipient and amount.
Instead, a block from a chain of TREMISS blocks contains assignments of tokens to addresses belonging to the recipient and previous addresses belonging to the payer.
Moreover, in BlockChain there is no information linking the payer and the recipient, which means that there is no connectedness in the chain.
NodeTr is a component of TREMISS BlockChain involved in block generation and network support, as well as a network microserver. Similarly, NodeTr is a token storage and miner for generating tokens with a embedded TREMISS algorithm.
NodeTr can work in three modes:
1.Maining on the CPU and joining “TreSupervisor” with the CPU processing power
2.Mining as a holder of tokens and participating in the TREMISS BlockChain voting on “TreSupervisor”
3. Full mining is a part of the calculation on the CPU and as the holder of the tokens.
The TREMISS algorithm is designed to work only on the CPU and the corresponding PC infrastructure.
To mine a token on a TREMISS BlockChain, you do not need the combined power pools, as the generation of blocks occurs directly in “TreSupervisor”.