Introduction of Super Nodes Project
The main target of distributed super nodes is to solve the scalability problem for the DPOS nodes on the parent blockchain. Since BigBang Core is a block system with multiple branches, the nodes participating in DPOS need to synchronously generate blocks for all valuable branches. With the increase of the number of app branches, the burden of block-generation nodes will become more and more. Single server cannot meet the scalability requirements of the system. Thus, the distributed super nodes occur as an effective solution.
Among the distributed super node projects, the main roles are categorized into ROOT node server and branch node server according to different businesses.1
The ROOT node server is mainly in charge of consensus negotiation, parent blockchain generation, parent blockchain data management, branch node management, etc. The ROOT node server stores the data related to the block signature key, which is used for consensus negotiation and parent blockchain generation. The ROOT node server is connected to the BigBang Core network, running DPOS negotiation on the security parent blockchain, as well as data exchange with other branch nodes in the super nodes. The ROOT node server relates to the other ROOT node servers on other super nodes through P2P (SOCKET API), or to ordinary nodes through P2P (socket API). The ROOT node server only stores the data for checking the security parent blockchain, and the app branch data is processed by the branch node server. The branch node server is connected to the ROOT node server by SOCKET API or MQ to exchange information such as security beacons and data management.
Branch node servers are specially used to organize the block data of app branch chain. Each branch node server is only in charge of one or several branch chain data. Also, two branch node servers cannot oversee same branch chain data. The branch node server is connected to the ROOT node server through SOCKET API or MQ to receive and process security beacons and manage data. The branch node server connects with the corresponding branch nodes of other super nodes through P2P (SOCKET API) (the ROOT node server gets the connection address of the opposite branch node through the handshake negotiation with the opposite ROOT node server and distributes the connection address to the branch node). When DPOS negotiates that the current ROOT node is selected as the block-generation node, the ROOT node server constructs a new block in the parent blockchain and pushes the generated block contextual data of the branch chain to each branch node server. After each branch node server constructs own branch chain new block data and signs (the branch node keeps the relevant data of the block generation signing key), the branch node broadcasts the whole network by itself.
Super nodes and the connecting among super nodes
Super nodes connect each other through P2P (SOCKET API) mode, including ROOT node with ROOT node, and branch node with branch node of the corresponding management branch. ROOT node and branch node can use P2P (SOCKET API) or MQ mode to communicate.
The interactive data between ROOT node and branch node mainly includes generated block contextual data, such as beacon, height, DPOS address table of selected node and others. The interactive data also includes branch node connection information of the opposite end node (super node or ordinary node), containing security beacon. Only the branch nodes negotiated by two ROOT nodes can connect each other, which enhances the security of branch nodes.
ROOT node is responsible for managing the branch nodes. By connecting ROOT node through RPC, the configuration information of the branch nodes can be added or deleted (or configure the branch node information in the configuration file). The configuration information contains the address information of the branch node and the branch chain information of managed by the branch node, etc. Branch node actively connects ROOT node, and the ROOT node uses the address information of the configured branch node to authorize the branch node connection. Only configured branch node address can connect to ROOT node and provide basic security authentication. The branch node can synchronize the branch chain information needing management from ROOT node, and ROOT node would synchronize to branch node once the branch configuration changes.
1 Connect through PSP (SOCKET API) mode
2 Connect through MQ mode
The connecting relationship between super node and ordinary node
Ordinary nodes provide all data management for the whole chain, containing consensus negotiation, parent blockchain data management, branch chain data management, etc. Ordinary nodes need connecting with all nodes in super nodes, including ROOT nodes and branch nodes. Ordinary node would connect the ROOT nodes of super nodes firstly and get all branch note connecting address and branch chain information they managed through handshake negotiation. While in the handshake stage, ordinary node would tell ROOT node that it is a ordinary node, the parent blockchain and the branch chain are on the same node, and all branch nodes of the super nodes need connect this node and view the node as corresponding branch node.
The connecting way between super nodes and LWS/RPC client
1 The connecting relationship between RPC client and super nodes
Both ROOT node and branch node provide RPC interface. RPC clients can connect and do command operations. Each node can import wallet address and perform wallet-related operations.
2 The connecting relationship between LWS client and super nodes
There can be multiple LWS that provide services around one super node. Every LWS provides partial branch services and must connect the ROOT node of super node and synchronize parent blockchain data. Meanwhile LWS needs connecting with the branch node server, which is corresponded to the branch chain managed by it, to synchronize corresponding branch chain data.
ROOT node oversees the LWS server, which can be added or deleted by RPC, and configure the branch chain information managed by the LWS server. The LWS server needs the configuration of the address of the ROOT node server, and actively connects to the ROOT node server. Only with the address information of the LWS server configured on the ROOT node, the LWS server can connect to the ROOT node server. the ROOT node server would synchronize the LWS distribution tables, which is LWS tables and the respective managed branch chain information, with the LWS server for redirection once the LWS client connects.
LWS client selects any LWS server to connect and requests to subscribe the branch chain data. If there is data from that branch chain on the server, corresponding services would be provided. Otherwise, a failure message would be returned, coming along with the redirected LWS server address of the corresponding branch chain. LWS client can also request to obtain the LWS distribution table and connect the corresponding LWS server according to the LWS distribution table.
