Trinity Biweekly Report —Early January
Development Progress
（Jan 1st — 15th）
The core development team has been enhancing performance and making adaptations to the underlying chains. Our team has tested existing two versions of state channels, optimized two functions, and improved the update of the bottom-layer design.
Trinity-ETH
1. Design lightweight Trinity framework, integrate redundant parts in neo-trinity and eth-trinity to make Trinity more generalized. Micro-service software design architecture is used for layered architecture and modular design in Trinity to achieve scalability and reusability.
2. According to the access frequency of transaction data, sharding is used for storage to improve data access efficiency. In the channel transaction, the integrity and consistency of the data needs to be confirmed. When a new transaction is initiated, it is necessary to check and update the latest transaction information. The previous data is stored in the database in real time and one has to look through all elements in the database to find the data needed each time. With the growing amount of transaction, this traversal time becomes a problem. For this reason, we cache the data with high access frequency, and store the transaction in the database after the transaction is confirmed by at least 3 transactions, thereby improving the data processing efficiency.
3. Optimize eth-trinity for Constantinople. Our team plans to upgrade eth-trinity to match EIP 1014, paving the way for the generalized state channel of Trinity. EIP 1014 helps to promote the scaling solution based on state channels and off-chain transactions.
Trinity-NEO
1. Increasing sustainability of transactions. All the transactions in the channel depend on the network, which however experience network anomaly, congestion or flash. These network problems will cause sending timeout or transaction lost when using state channels, resulting in disparity of the both signatures and other information and breaking the continuity of processing new transactions. By introducing re-sign process, we optimized transaction procedure. Both parties of the transaction have to validate the previous transaction information before proceeding to the next one. If there is information discrepancy, they need to re-sign the transaction and then continue with the next. The re-sign process ensured the consistency of the transaction data of both sides and the continuity of the whole process as well.
We have various tools for users to test and experience. Our road of development never ends. We will invite more community members and developers to join us into further development and test. Thank you all for your continuous support!
Trinity Telegram Channel: https://t.me/TrinityStateChannels
Official Website: https://trinity.tech/#/
Trinity Github: https://github.com/trinity-project
