Byteball's network structure
From the point of view of node function, Byteball network nodes can be divided into relay nodes, hub nodes, broadcast nodes (Oracle), witness nodes (Witness), and wallet nodes (Wallet):
*Relay: Responsible for forwarding the unit to the node connected to it, storing the entire Byteball blockchain database, but it does not save any private key and does not send any unit;
*Hub: Provides an end-to-end encrypted message transmission channel for devices connected to it, such as sending and receiving private assets, multi-signature transactions, chat messages, etc. Other functions are the same as relay nodes. The default Hub address is wss://byteball.org/bb;
*Broadcast Node (Oracle): Responsible for continuously broadcasting data to the Byteball network, the data can be time, price, or even Bitcoin transactions;
*Witness: responsible for sending a unit at a fixed address without interruption, and any node that satisfies this condition may become a witness;
*Wallet node: responsible for interacting with users, sending and receiving transactions, messages, etc.
The following figure shows a schematic diagram of the Byteball network structure :
Light node and its verification process
From the perspective of whether or not the complete blockchain data is stored, the nodes can also be divided into full nodes and light nodes, and the entire node stores the complete blockchain data, while the light nodes do not. Users can choose whether to use a full node or a light node when installing the wallet. The light node only stores those units associated with its address, it needs to download the required data from the full node, the request condition includes the list of witnesses it trusts and the address it cares about.
Jump list: Suppose the MCI of the ball directly on the main chain is i i . If i mod 10 = 0 imod10=0 , then the ball has a jump list ( skiplist_balls), the value in the jump list points to the previous ball; for the i i mantissa each having a 0 0 , a skip list is a value corresponding MCI; skip list is maintained equal MCI mantissa 0 0 closest to the case of the same number of I I MCI, such as I = 3000 I = At 3000 o'clock, the corresponding jump list is [ 2990 , 2900 , 2000 ] [ 2990 , 2900 , 2000 ] .
Jump Distance: For the MCI value in the jump list, the difference between it and the MCI value of the current ball is called the jump distance.
Recent ball: The ball closest to the current time known to the current node ( last_ball), each unit must contain its most recent known ball when it is sent.
The whole node receives the witness list and the attention address sent by the light node, and searches the database of its storage unit for the unit related to the light node attention address. At the same time, for each relevant unit, the whole node constructs a chain of evidence, and the construction method is as follows:
*Backtracking along the main chain, when the light node has been collected for the majority of the witnesses in the given witness list ( this is the process of finding a witness ), the units on these main chains are recorded, recorded as a unit set C C ;
*Selecting the unit with the earliest time in the unit set C C (which is also the smallest unit of MCI), and obtaining it last_ball;
*From last_ballthis unit, backtracking along the main chain until the inclusion of the contained skiplist_ballsball stops, recording the balls on these main chains, recorded as the ball set B B ;
*Use skiplist_ballsto continue backtracking along the main chain and jump to skiplist_ballsthe ball with the largest jump distance ( this is the process of continuously accelerating the jump );
*Repeat step 4 to reduce the jump distance when the next jump exceeds the target unit ( this is the process of slowing down the jump. In the extreme case, no skiplist_ballsbacktracking is used , only the parent unit is used for backtracking ) until the target unit stops.
For light nodes, the chain of evidence given by the whole node is credible for two main reasons:
*The units at the beginning of the chain of evidence contain units issued by witnesses trusted by the light node;
*The connections in the chain of evidence use parent_units(find the witness process), last_ball, skiplist_balls, , parent_balls.
Therefore, through the chain of evidence, the light node can determine whether a unit is valid.
End-to-end encrypted channel
The hub node Hub is used to provide a reliable end-to-end encrypted data channel between different user devices, somewhat similar to a mail server. The Hub provides a store-and-forward service for user devices, and user devices can choose to connect to different Hubs. The user device connects to the Hub using websocket and uses TLS encryption. Once the Hub receives a message addressed to a device address, it will forward it immediately, and delete the message after successful forwarding.
The device address is used to identify the user device, and thus receives messages sent by other devices, similar to the email address. The device address is different from the wallet address and can use the same wallet address on different devices. Each device saves a permanent private key, and its corresponding public key is hashed and BASE32 encoded to obtain the device address. To distinguish it from the wallet address, the device address adds 0 as the identifier at its beginning (0 itself is not a BASE32 character). The full device address also includes the name of the hub, for example (DEVICEADDRESS@hubname.com). When switching to a different Hub, 
Assume that the device that sent the message is recorded as the device senderreceiving the message receiver, and receiverthe connected Hub is hub. Then, when senderyou want receiverto communicate with it, it needs to do the following:
*(sender)Modify its Hub address to (hub)be all connected by default wss://byteball.org/bb;
*(sender)The (receiver)paired, two-dimensional code scan may be used, matching string, or use (byteball://)starting link.
End-to-end encryption (ECDH+AES) and digital signature (ECDSA) are used for communication between all devices. As the only intermediary in the communication, the Hub cannot view or modify the message content. To improve the security of forwarding, the device generates a temporary private key and uploads the corresponding public key to the Hub connected to it. At the same time, the device can periodically change the temporary private key and public key.
Therefore, (sender)when (receiver)sending a message, it needs to complete the following steps:
*And (hub) connection;
*Temporary public key (hub) obtained from (receiver);
*Generate a one-time key pair;
*(receiver) Generating an ECDH key based on the one-time private key and the temporary public key;
*AES encryption of messages using ECDH keys;
*Add a one-time public key;
*Sign the entire message with the device private key;
*Send a message to (hub);
For example (receiver), it first needs to verify the signature of the message, and then use senderthe one-time public key and the local temporary private key to decrypt the message to obtain the content of the message.
The Hub-based device end-to-end encrypted message channel can be used for communication between devices, and messages sent between devices are not stored in the Byteball database. Users can use this channel to send encrypted text messages, multi-signature transactions, privacy assets (such as blackbytes), and more.