Byteball's current problems and suggestions for improvement directions

Byteball is a new digital asset platform based on DAG technology. It not only supports P2P payment, but also supports smart contracts, oracles, privacy assets, ICO and other functions. Byteball's wallet is designed to be very powerful and user-friendly. However, through careful study of Byteball, it will be found that there are certain defects in the design and implementation. If these problems are solved well, Byteball will be among the mainstream digital asset platforms.

**Network performance problem
A recent test of the byteball main network gives three conclusions:

(1) The transaction processing speed can only reach about 15 TPS;
(2) The network is vulnerable to DOS attacks, and a large number of bursty malicious transactions block the network and reduce the transaction processing speed of the network;
(3) As the number of transactions increases, the transaction confirmation time can be kept stable.

The DAG base chain, the stress test is quite disappointing, which obviously does not give full play to the advantages of DAG technology. Different from the traditional blockchain transaction processing speed is limited by the block size, the transaction processing speed of the Byteball network may be related to the code execution speed, network transmission delay, hardware processing capability and the like. Founder Tony acknowledged in the Slack channel that a large number of SQL operations in the byteball code implementation increased processing latency, which may be an important reason for the performance of the byteball processing.

• So, can you optimize the database design and SQL operations of the byteball?

DAG is the underlying data structure of Byteball, and its corresponding data should naturally be stored using the graph database. This requires redesigning the Byteball database and rewriting the underlying code of the Byteball. At the same time, you need a high-performance serverless embedded graph database, such as leveldb based on leveldb. One of the biggest benefits of using a graph database is that it can reduce a large number of SQL multi-table join queries and simplify multi-level backtracking operations when validating transactions, thereby improving its processing performance.

**Hub node problem
In a Byteball network, a Hub node is a backbone node in the network, which forms a P2P network between them, and other nodes need to communicate with each other through them. Multiple Hubs can exist in the entire network, and users can freely choose the Hub they want to access. It should be noted here that the Relay node has similar functions as the Hub node, but does not provide an end-to-end information encryption service. In the following discussion, the Hub/Relay node is collectively referred to as a Hub node unless otherwise specified.

From a technical point of view, the Hub node is based on a full-node wallet and provides some additional data forwarding capabilities. From a data storage perspective: the light wallet does not save the complete ledger data; the full-node wallet and the witness save the complete ledger data, but only for their own use; only the Hub node saves the complete ledger data, and with other The nodes are shared.

Imagine if the Hub node does evil, it can refuse to provide Byteball network access services for other nodes such as the wallet connected to it, and refuse to broadcast and share transaction data for them. There is also an extreme case where if all witness nodes are connected to the same Hub node, then it will become the overlord in the entire network. If other Hub nodes cannot obtain the service of the Hub node, all transactions broadcast by other Hub nodes cannot be confirmed by the network. This means that those Hub nodes are not working properly.

The Hub node plays an important role in the validity, reliability and security of the ledger data. However, under the current implementation of Byteball, the Hub node is completely free of revenue incentives, and at the same time bear the corresponding server expenses. In fact, the main use of the entire network is the official Hub node (wss://byteball.org/bb/).

*So, should the Hub node playing such an important role be given economic incentives and limit some of its power?

The purpose of designing economic incentives is to make more people willing to run Hub nodes and provide fairer and more efficient services for the entire network. At the same time, in order to relatively restrict the power of the Hub node, it is recommended to enhance the status of the witness node and the whole node wallet in the network structure, that is, they can form a P2P network.

** Witness's question
Witnesses is used by Byteball to achieve a consensus across the network. Witnesses continue to send transactions to confirm transactions with other users. Byteball's request to witnesses is: a well-known user or institution in the real world to ensure that it has a good reputation. Once the witnesses commit evil acts, then he will be discredited. The requirements are so strict, but the witness can only get a small fee. Who would like to put their reputation on a digital asset platform like Byteball? The current reality is that most of the witness nodes are in the hands of founder Tony.

One of the basic ideas of Byteball's consensus mechanism is to select a main chain, all units can be ordered according to this main chain, thus solving the double flower problem. In terms of image, this main chain is similar to a highway, and other branches connected to the main chain are provincial roads. In this way, network processing efficiency can be greatly improved. Byteball chooses the main chain by means of witnesses, and the transactions on the main chain are recognized by most witnesses. Of course, there are other ways to choose the main chain, such as using the POW method. The most popular xdag adopts this idea.

• So, can Byteball's consensus mechanism evolve into a POS-based witness mechanism?

This means that the list of witnesses is not fixed and is not manually selected by the user. The Witness List is generated by means of POS, generating a list of witnesses at regular intervals and building a consensus based on this. In POS, users with more assets are more inclined to maintain the normal operation of the network.

** fee problem
The transaction fee in Byteball is divided into two parts, one for the witness and the other for the subunit.

The transaction fee assigned to the witness is called payload commission, which is proportional to the number of bytes occupied by the transaction storage content. However, in reality, the size of the transaction storage content is no different for the witness. What the witness needs to do is to continuously generate the transaction unit.

The transaction fee assigned to a subunit is called a header commission, which is basically a fixed value. It is designed to allow users to choose the newly created trading unit as much as possible so that the width of the DAG is not too large. In fact, it is very doubtful that ordinary users receive a small amount of handling fees. Although user behavior contributes to the confirmation of the transaction unit, it is usually an even issue. Nodes such as the Hub that carry the heavy responsibility of the network are not motivated. As for limiting the width of the DAG, it is entirely possible to give the newly generated node a higher weight when selecting the parent node.

• So, is it possible to redesign the fee structure and assign it to nodes that maintain the normal operation of the network?

Above we discussed the incentives for the Hub node, the part of the fee that should be added to the Hub node; at the same time, the part assigned to the sub-unit is removed, and the better parent node selection algorithm is substituted.