Partnered With:

Swarm launched a new version of the client to improve the stability of the host network

Read this article in 6 Minutes

The Bee team has been working hard to identify key issues in the Ethereum Swarm distributed storage system and has made key changes in v1.3.0. This correction signals the formal move of Ethereum Swarm into system automation to ensure good service for user

The Swarm is Moving On (or: Don't Fall Behind)

Elad Nachmias, Ethereum Swarm

Eternal, 0x22D, BlockBeats

Over the past few months, the Bee team has been trying to find key problems in Swarm's distributed storage system. As promised in a previous blog post, Bee made a key change in v1.3.0 to exclude nodes that are not connected to a stable blockchain network. This revision signals that we will move forward with system automation to ensure good service for users.

As a node operator, you need to verify that your nodes are configured correctly and that the nodes are accessible over the public Internet. It is also necessary to verify the accessibility of the node propagation address on the Internet.

Prior to Bee's v1.3.0 release, it was clear that the number of equivalent nodes responding to the new chain synchronization protocol was between 5-15%.

Now, those numbers may have been misleading. This doesn't mean that 5-15% of the people are in sync, but that only 5-15% of the people respond to the message. Therefore, a more rigorous assumption is that only 5-15% of the nodes in the entire network actually update nodes and establish stable connections to the blockchain network.

What's next for Ethereum Swarm?

The Bee team is working to collect more data and attempt multiple iterations to bring greater stability to the main network. In the next release cycle (Bee V1.4.0), Ethereum Swarm will circumvent unreachable nodes in the core protocol: the Bee team has determined that a large number of nodes are not publicly available and cannot accept incoming connections. For example, after NAT without port forwarding enabled, many nodes in the network are "unreachable" and they cause network topology imbalances.

Node Connectivity data as of 05.11.2021

This poses a serious problem for Kademlia's design because it builds so-called "concave neighborhoods," which are essentially asymmetric neighborhoods. Because the nodes are inaccessible, the asymmetry cannot be resolved. This causes various synchronization and retrieval protocols to fail, which can be difficult to resolve without relay nodes or minimal configuration contracts with other nodes.Starting with Bee V1.4.0, if your node is unreachable, it will stop receiving messages on the core protocol.

As part of the Bee V1.4.0 update, we looked at this issue on several levels:

1. Detection -- Install components that detect reachability and maintain the status of nodes (and their peers). This is done directly through our P2P abstraction which provides accessibility services.

2. Visibility -- Make the node's reachability status (showing its own reachability status and that of its neighboring peers) visible to users and node operators. This is done through topology endpoints in our Debug API.

3. Documentation -- Document how the problem was resolved (seeThe document).

As the node operator, it is your responsibility to verify that your nodes are configured correctly and that your nodes are accessible from the common CIDR. You must verify that the address of your node can be accessed over the network.

While we are actively looking for ways to include and allow access to those inaccessible nodes, it should be clear that we expect node operators to comply with connection requirements and make their nodes accessible from the common IP CIDR.