Trinity, a state channel scaling solution building for NEO, has released two bi-weekly reports covering its development progress in June. The team continued work on the design of its transaction systems and began work on a NEO token trading contract.
Early June Development
The first bi-weekly report from Trinity noted the project’s current focus on the transaction mechanisms. Trinity outlined a problem related to TCP transmissions, referring to communication between two parties where multiple messages need to be sent to ensure transactions are valid and secure.
The team explained that there existed a discrepancy between the efficiency of sending or processing transactions, which was particularly noticeable when a large number of transactions were being sent on a regular basis between the two parties. This would cause messages to accumulate in the TCP receive buffer.
If the buffer overflowed, some messages could be lost, resulting in a failure. Trinity resolved this issue by including a customized packet header for messages which specifies the data length of each message. This allows the message recipient to ensure they have obtained all transaction data.
Trinity also completed the verification process of these transaction messages. Each party will verify the information sent by other parties, checking data such as the balance redistribution and transaction sequence. Following confirmation of transaction data, the counterparty signature information can be verified, allowing the validity of the transfers to be confirmed.
Finally, the team began testing its revocable sequence maturity contracts (RSMC). More information on the function of these contracts may be found here.
Late June Development
In late June, Trinity began the implementation of its hash time locked contract. Various transaction types required for the HTLC have been successfully implemented, which together ensure that transactions are sent reliably and securely. With HTLC, if the payment is not confirmed by the recipient by providing cryptographic proof of payment, the funds may be retrieved by the sender.
The team also began work on a NEO token trading contract. Unlike typical NEP-5 assets, NEO currently uses the UTXO transaction model. To allow NEO to be traded, Trinity needs to retrieve inputs and outputs from both sides of the state channel, allowing a trading contract to be established. These contracts are settled on-chain when the channel is closed, which may be done by agreement between both parties or upon the detection of malicious activity by one party.
Trinity concluded its second report with a message for the NEO community:
“Since the beginning of this year, [the] Trinity team has been working on the development of trinity-neo-gui, adding more possibilities of scaling to NEO and enriching the community as a whole. We believe that every solid step will make a difference in the future. Stay tuned to our latest progress and welcome to participate in technology construction [sic].”