Trinity Biweekly Report — — Late March
1. Complete the Level DB adaptation. Migrate the status channel data operation interface from mongo DB to adapt to level DB. Maintain consistency of the data interface and weaken the dependency of the state channel on the underlying database.
2. Define long connection communication between wallet and gateway. Wallet establishes a stable long connection through TCP and gateway, which, as a server, will maintain the reliability of the connection through ‘keep alive’ mechanism .
3. Define the overall architecture of the state channel. Define the state channel message structure and create the channel message flow in the C# environment, and define the API interface. GUI will realize the interaction with the background state channel through these API interfaces.
4. Reuse the core function interface in the neo core. Identify the reusable functional interfaces in the neo core according to the requirements of the status channel, and complete the construction of multi-sig addresses, transactions and contracts, in order to obtain relevant information from the underlying chain.
During the development of Trinity, there are also many related studies in the whole industry. Since the torch passing activity of the lightning network by the end of last year, people have built more trust in the Lightning Network — the number of channels and the amount of deposit have begun to increase, which has brought new opportunities for the development of the layer2 network, especially the state channel technology. If you look back from this point, it is worth noting that from the beginning of BIP, to the launch of the Lightning Network until its development to the present stage, the Lightning Network has gone through a long process. It is undeniable that Lightning Network has made outstanding contributions to the state channel, but it is still controversial due to problems such as unfriendly experience, routing node status, and node revenue ratio. At present, the scaling-themed layer2 network is diverse, and most of them focus on the concept of decentralization, general state channel, and technical architecture. Here are the opinions from the core developers of Trinity:
1. Centralized System and Decentralization
People have seen concerns in the lightning network that some nodes have more than 100 channels and questioned that channel technology is not in line with the concept of decentralization. This may be due to the lack of understanding of the details of the channel technology. It seems true that too many channels in a node might be unpleasant, because people worry about whether this node will swallow the deposit in the channel. However, they have forgotten that RSMC itself has the nature of revocable sequence maturity. Anyone who broadcasts the transactions in the channel on the chain has a time window instead of getting funds immediately; any malicious broadcast will cause a penalty transaction on the chain, even if it is a node with many channels. This mechanism makes nodes difficult to commit crimes even they have conspired funds for a long time.
Will nodes with many channels bring instability to the entire channel network? The accurate answer is yes. If nodes with majority channels in a network go down, it will inevitably affect the entire network. But will this kind of extreme case happen? The possibility is very low. We know that the channel deposit is needed in the channel. This determines the number of nodes to be reconstructed and sets a ceiling for the number of channels along with it. In addition, processing transactions in the channel will inevitably occupy the computing resources of the node, and the hardware of the node will also limit the number of channels. In this dynamic system, peer nodes will select stable nodes, or node that processes transactions faster to establish channels with. This will inevitably result in multiple competing nodes with a large number of channels. One of these nodes goes down, other nodes get routed so that channel payments can still be made smoothly. If we can look at the topology of the Lightning Network, the cluster is more like a honeycomb, and the number of nodes with many channels is relatively small.
2. Payment Channels and Generalized State Channels
Payment channels have always been considered the primary stage of state channels. This is not entirely true.
First, people often equate the payment concept of the currency with that in the state channel. In fact, the concept of payment in the channel should be extended to transaction, and all the operations we perform on the chain rely on transactions. Any request made to the chain is a transaction. It is only in the current context that more transactions are the transfer of tokens, which equalizes transactions with payments.
The essence of state channel technology is to move the transactions that occur on the chain off the chain safely, and the off-chain transactions are equivalent to the transactions on the chain. The off-chain transactions can be broadcast on the chain at any time. The focus here is guarantee the security of moving on-chain assets into the state channel and the fairness of transactions when the channel is closed. Therefore, the payment function of the channel is the infrastructure and a standard of considering the security of the state channel.
Second, the transfer of tokens (which we often call payment) is the most widely used application at this stage. Tokens are effective media for value transfer. The free and efficient circulation of tokens is the soul of the blockchain that affects real economic life. So, whether it is now or in the future, payment will always be accompanied by blockchain technology as well as state channels.
Generalized state channel is undoubtedly the direction of channel technology development. It will extend the application of channel technology indefinitely — more business scenarios can be carried out off the chain. From the emergence of each theory and technology to their maturity and perfection rely on continuous exploration in various fields and directions. We are still on the way.
3. Side Chains and State Channels
The side chain, represented by plasma, is a technology widely mentioned in the second layer network besides state channels. The side chain is flexible and convenient in expanding the main chain business. After the completion of the transaction from side chains to the main chain, side chains then can expand the business of the main chain indefinitely.
Similar to state channels, side-chain architect also needs to ensure that all transactions occurring on the side chain are broadcast to the main chain and executed by the main chain. The difference is that side chains have strong blockchain attributes, such as distributed ledger structure, decentralized consensus algorithms, peer-to-peer network, etc. And due to the fact that the side chain is still a blockchain, it still faces the problem of scaling.
State channels and side chains should also be complementary. If side chains can be introduced in plasma, so can state channels. In some cases, side chains are used to protect state channels when one party of a channel is off-line.
The future Layer 2 network is not composed of one or several isolated technologies, but a combination of various technologies. No matter which technologies will be integrated, they all provide support to the application layer.
Trinity and its Direction
In addition to the implementation of the state channel protocol itself, Trinity pays more attention to the user experience when the protocol applied. Recently, we entered into the development of trinity-neo-gui, and hope this will better integrate the layer1 and layer 2 networks. With various applications in the Neo ecosystem, Trinity will bring layer 2 network into a solid ground for business integration.
At present, we quantify all the items to be developed in form of issues on github. We welcome the community to improve the trinity-neo-gui development through user stories by pulling issues onto Trinity repo.