Channel Transaction Processing
The channel transaction task comes from the TP (Trinity Off-chain Protocol) message. In order to better understand the message processing flow and working mode of the task, this section starts from the basic characteristics, mutual exclusion, orderliness of state channel transactions, and creates and forms the conventions that the Trinity system needs to follow. These conventions will be a fundamental criterion for the design of the Trinity system architecture.
Below are the basic characteristics of state channel transactions:
• State channel transactions require one or several mutex to guarantee the synchronization of transactions on both sides;
• A transaction with the signature by both parties is a valid transaction (VT);
• The trigger condition of the on-going transaction is: the previous transaction is a valid transaction (VT);
• Semi-valid transactions (SVT) require re-signature, otherwise channel transactions will be blocked;
• The benchmark balance of the n transaction is the channel balance of both parties after the completion of the n-1 transaction;
• The n valid transaction and the n+1 transaction are considered to be the same transaction (in the case that the network communication sequence may result in packet loss);
• The latest transaction can punish all other transactions (except for the transactions to close channels fast and the previous transaction);
• Channel transactions should be aggregatable (to improve the performance and throughput of channel transactions).
Simple Mathematical Model of the Channel Transactions:
As it is shown in the graph, only one transaction at one time will be acknowledged and performed by both peers. To guarantee the mutually exclusiveness, Trinity observe rules in the following convention:
• Two parties of the channel and their respective roles：Founder Peer and Partner Peer；
• One transaction has a sole identifier (denoted by nonce)；
• Classify channel transactions：special transactions and general transactions；
◦ Special transactions: creating channels (nonce=1) and swift settlement of the transactions in the channel (nonce=0).
◦ General transactions: other transactions (RSMC / HTLC): nonce >= 2.
• Founder peer generate a solely identifier and a serial number for every transaction.
• Partner peer verify, negotiate and reset the sole identifier.
During the transaction, the MCR saves transaction data from both peers into FIFO message list, and the WCR read, verify and sign the transaction before sending it out to the other peer.
Trinity Telegram Channel: https://t.me/TrinityStateChannels
Official Website: https://trinity.tech/#/
Trinity Github: https://github.com/trinity-project
