Network Specs

Node Address Format Description

The Caduceus Metaverse Protocol node address follows the libp2p network address format protocol, and the multaddr component is used to resolve the address, for example:

/ip4/127.0.0.1/tcp/6666/p2p/QmQZn3pZCcuEf34FSvucqkvVJEvfzpNjQTk17HS6CYMR35'

The address starts with "/" and its segments separated by "/" with, in most cases, the segments are as follows:

First segment: IP protocol version or DNS resolution protocol version. ip4 stands for IPv4, ip6 stands for IPv6; dns4 corresponds to IPv4 version DNS service, dns6 corresponds to IPv6 version DNS service Second segment: IP address or domain name, need to correspond to the first segment Third segment: communication network protocol, tcp is used by default Fourth segment: listening port Fifth segment: fixed agreement, please do not change, fixed as "p2p" The above are just examples of node addresses in the most common scenarios. In complex network scenarios (such as the need to use relay node, NAT penetration, etc),the address format will be slightly different.



The message data before encryption is composed of 8-bits byte indicating data length + 1- bit byte as data compression flag + actual data, for example:

[00000007801057105......80858372]

Suppose this is a network message data to be sent, where: The first 8-bits [000000078] indicate the length of the data to be sent. When the receiver receives the data, if the received data length is less than this value, it will try to continue to read the data until the full length of data is received or the reception fails. The 9th bit, [0] or [1] is the data compression flag bit. If it is 1, the receiver will decompress the received data after receiving the complete data to get the final data result. Remaining bits, [1057105……80858372] are the original data to be sent (compressed or uncompressed data). Whether to compress should correspond to the 9th bit compression flag. The compression/decompression is done using the GZip toolkit.

The P2P network of the Caduceus Metaverse Protocol is implemented and improved based on libp2p and the network address of the node follows the libp2p address format protocol.

Automatic Discovery Automatic node discovery and automatic connection functions can be realised through the seed node settings. By default, each online node can serve as the seed node of other nodes to provide network discovery services. This way, the automatic networking mechanism of the Caduceus Metaverse Protocol is realised.

Network Broadcasting and Gossip Caduceus Metaverse Protocol uses the message broadcast / subscribe function implemented by the improved libp2p-gossip-pubsub. It can ensure that the broadcast message can finally reach all nodes online. In the multi-chain scenario, each chain on the node enjoys an independent GossipPubSub service and through precise control of each Gossip routing table, the broadcast data isolation between multiple chains can be realized, ensuring that the broadcast data is only in the nodes in the chain. This is the certainty of spread. It is precisely this that allows all chains of the Caduceus Metaverse Protocol to share an underlying P2P network.

Network Capacity The Caduceus Metaverse Protocol can theoretically realise the online networking of tens of thousands or more nodes at the same time, supporting a maximum of 100k transactions per second across all nodes.

Caduceus Metaverse Protocol can provide NAT penetration, proxy forwarding and other scenarios in complex network environment solution support.