TREMISS BlockChain main blocks.

All connections in the TREMISS platform go through the “Xtre” protocol developed by us.
The “Xtre” protocol is an advanced SCTP (Stream Control Transmission Protocol) protocol, it uses multi-threading, cryptography, the protocol uses mixed networks in conjunction with a distributed ledger to create a confidential block chain.

TreSupervisor is a temporary entity in TREMISS BlockChain. “TreSupervisor” allows you to send messages in both directions anonymously. “TreSupervisor” are temporary, they exist only for the duration of the block for which they are responsible.
TreSupervisor uses a consistent protocol to verify and authenticate operations that anonymize each encrypted message, independently agree to process all messages before decryption, and then independently decrypt and process each message.
After generating the block, “TreSupervisor” is dissolved.

NodeTr is an integral part of TREMISS BlockChain involved in block generation and network support, and is also a microserver network. NodeTr is also a storage for tokens and a miner for generating tokens with the embedded Tremiss algorithm.
NodeTr is also a TREMISS BlockChain wallet.
NodeTr can work in three modes:
1. Mining 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.

TremissSupervisorMachine is a virtual machine executing the code of smart contracts, tokens issued on the basis of TREMISS BlockChain, decentralized applications, calculations of the "BIG DATE" class.
TremissSupervisorMachine - has its own language for implementing the broadest functions and capabilities, the core of the TremissSupervisorMachine language is OTP / Elixir.

Алгоритм TREMISS - являеться разработкой команды Tremiss Blockchain Technologies Ltd., и является квантово устойчивый алгоритм шифрования TREMISS BlockChain. В основу нашей разработки лежит работа Daniel J. Bernstein, Daira Hopwood, Andreas Hülsing, Tanja Lange,Ruben Niederhagen, Louiza Papachristodoulou, Michael Schneider,Peter Schwabe, and Zooko Wilcox-O’Hearn "SPHINCS: practical stateless hash-based signatures".

Principles of interaction in TREMISS BlockChain.

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.
Equipment requirement:
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”.

Safety principles in TREMISS BlockChain.

Unlike other platforms, the consensus in TREMISS BlockChain is not vulnerable to attack by 51%. Any liquid "NodeTr" protects the team consensus. A completely fraudulent TreSupervisor can only provide evidence for transactions submitted by TreSupervisor users in one round. Since, “TreSupervisor” cannot create fake transactions in its favor, as well as valid evidence for fake transactions. Fully fraudulent “TreSupervisor” is impossible - the attack should be limited to changing the order of transactions, de-anonymization of transactions or the inability to provide evidence, that is, to falsify an error. The consensus algorithms in the BlockChain space were primarily hampered by bandwidth limitations. Blocks must be distributed to most of the system before completeness is implemented. Even a small block requires exponentially more bandwidth than its file size for transmission over the network. In the agreed BlockChain protocol, Tremiss, “TreSupervisor” reaches the final score with short proofs that are optimally distributed through the network. As a result, the TREMISS BlockChain consensus mechanism gets evidence in read fractions of a second.

The attackers can not affect the work of “TreSupervisor”, because “TreSupervisor” is constantly moving, unpredictable, and collected every time from different “NodeTr”. As the size of the network increases, the likelihood that the “TreSupervisor” node will affect the completion of the block increases, so the main compromise solution for creating a flexible block is the size of “TreSupervisor”. We have programmatically limited the size of “TreSupervisor” it will not consist of more than 75 “NodeTr”.

The TREMISS platform was designed to encourage NodeTr to follow protocol rules. Failure to do so results in a shutdown for all “NodeTr” containing malicious or non-productive nodes. The protocol also offers significant flexibility when dealing with network failures. The set of valid “NodeTr” is known, since they must be selected to join the network. Since “TreSupervisor” is located in a cascade, the failure of any one “TreSupervisor” can be easily mitigated by the next “TreSupervisor” in the cascade. Successful interruption of block generation will require disabling all scheduled “TreSupervisor” and this is not possible, since “TreSupervisor” is automatically generated from “NodeTr” and randomly.

The egalitarian properties achieved in the TREMISS BlockChain are extremely advantageous from other mechanisms of consensus. In particular, a large computing power or a large share of the node does not give an advantage to this node over others in this platform. Successful completion of a block is a cryptographically protected group calculation, similar to the proof of useful work. You can consider transaction processing as mining, where work is not wasted, but directly corresponds to the provision of platform properties.
Consequently, any unforeseen algorithmic improvements, new ASIC designs, or other designs do not advantage one team or node over another. In addition, each node is treated in the same way, and each automatically checks the accuracy of all other nodes.

Within the framework of the TREISS protocol, resistance to sibil attacks is created by using verifiable inter-node real-time performance testing, breakdowns and selections. All elections on the TREMISS platform will use cryptographically protected, verified by “NodeTr” end-to-end election protocols.