Share on Twitter
Share on Facebook
Share on Reddit
Share via Email
Share on LinkedIn
Share via RSS
Share on Google+

State channel scaling solution Trinity has released its March bi-weekly reports, sharing technical development in addition to the team’s perspective on industry discussions surrounding Layer 2 scaling solutions. The first bi-weekly report may be found here, and the second bi-weekly report may be found here.

Trinity recently outlined its plan to integrate its state channel technology directly into the neo-gui wallet, with later support planned for light wallets via neo-cli RPC nodes. This is hoped to “make micropayments more light and convenient” and “promotes the mass adoption of crypto payment.”

Development Progress

Work began on the state channel architecture, with the message structure being defined and a channel message flow created in neo-gui. This takes the form of a basic but operational API interface for opening state channels, performing transactions, and closing channels from within the wallet.

The initial report included an image guide for performing these functions. Trinity encourages neo-gui users to view and test the interface by downloading trinity-neo-gui from Github. Installation instructions for both Windows and Mac users have been included and may be found in the report.

The team noted that neo-gui stores its data in key-value format using LevelDB, unlike Trinity which uses the document database MongoDB. To overcome this difference, it adapted its MongoDB database, which stores information on state channels, to LevelDB where it can then synchronize with NEO nodes. This is intended to maintain consistency and reduce a given state channel’s dependency on the underlying database.

Trinity also began work on its communication mechanisms, responsible for handling interaction between wallets and gateways. A long connection is established over TCP, which is maintained through the use of a keepalive mechanism. Inter-communication between the wallet and gateway is handled via RPC, acting as the basis for all functions such as opening and closing channels or performing transactions.

Layer 2 Insights

As part of its second bi-weekly report for March, the Trinity team shared its thoughts on Layer 2 scaling solutions as they currently stand. It explored the centralization concerns attributed to state channel networks, such as Bitcoin’s Lightning Network, and considers the application of sidechains.

Network Risks

Trinity noted concerns regarding the centralization and instability risks posed by some Lightning Network nodes having large numbers of channels open. If such a node was to go down, many channels would be affected which could have an adverse effect on the network.

The team posits that these risks are negated through a combination of channel deposits, dynamic routing between nodes, and the use of revocable sequence maturity contracts (RSMC). Channel deposits provide a ceiling on the number of channels and allow for penalties in the event of malicious broadcasts, and RSMC provides a window of time where transactions may be reversed.

Sidechains

Trinity weighed in on sidechains, an alternate Layer 2 scaling solution popularized by Ethereum’s Plasma. Sidechains are secondary to the main chain, where transactions must still be broadcast and settled, but use their own consensus mechanisms and network structure. By having multiple chains running in parallel, more transactions can be processed, though due to the blockchain structure each individual chain still faces scaling issues.

Trinity did not provide its thoughts on the advantages or disadvantages of each approach and instead noted its belief that state channels and sidechains should be complementary. The team provided an example; sidechains could be used to protect state channels when one party of a channel is offline.

Future Direction

To conclude its reports, Trinity reiterated its focus on the user experience of its scaling solution. Although the team is currently in the implementation stage of the protocol, they hope to ensure the adoption of Layer 2 by providing a well-integrated solution. This is the driving factor behind its decision to develop trinity-neo-gui, which aims to reduce the boundary between Layer 2 and Layer 1, the underlying blockchain.

Trinity encourages both users and developers to share their experiences or desired functionality on the issues page of the Github repository.