This past week, node operators for Vaulta, previously known as EOS, gathered to discuss important updates. The meeting covered progress on the Antelope Spring 2.0 software, how the new gossip system for connecting block producers is working out, and ideas for making network connections safer. Node operators shared their experiences with technical problems and how their networks are set up, all while keeping the Vaulta blockchain running smoothly.
Key Takeaways
-
Antelope Spring 2.0's Developer Preview 1 is out, focusing on sync calls, with more significant changes expected in Preview 2 around September.
-
The new event system will require node operators to set storage limits, with more details coming as development continues.
-
Adoption of the gossip peering system is happening, but not all major block producers are connected yet, meaning the network isn't fully meshed.
-
Setting up the gossip network has been tough, with issues in finding peers and suggestions made to use hosted lists to help new nodes connect.
-
A new idea is to allow node operators to create lists of allowed or blocked peers for the gossip system to help manage connections and security.
Antelope Spring 2.0 Development Progress
The development of Antelope Spring 2.0 is moving along, with the first Developer Preview (DP1) now out. This initial release brings support for sync calls and gives access to a testnet environment. Developers are being asked to rebuild their contracts using CDT 5.0 dev 1.1. Right now, DP1 doesn't change much for node operators, as the bigger impacts are expected with DP2. That next preview, DP2, is planned for early September and will include the new event system along with improvements to how fast things run.
Event System Preview and Implications
The upcoming Developer Preview 2 (DP2) for Antelope Spring 2.0 is set to introduce a new event system. This system will allow for the broadcasting of ephemeral events that are cryptographically committed within the consensus data. For node operators, this means a new configuration parameter will be introduced, requiring them to set minimum storage settings for these events. The exact details and best practices for managing these events are still being worked out as development progresses, but DP2 will provide the initial node-relevant features and configurations needed to handle them. The implications for node operators are significant, as they will need to adapt their configurations to accommodate this new data stream.
Event System Functionality
-
Events are temporary messages.
-
They are secured through cryptographic commitments in consensus.
-
Node operators must define storage limits.
Configuration Requirements for Node Operators
-
Set minimum storage for ephemeral events.
-
Monitor event data flow.
-
Adapt to new configuration parameters in DP2.
Anticipated Impact of Event System
-
New data types to manage.
-
Potential for enhanced network monitoring.
-
Need for updated operational procedures.
Gossip BP Peering Adoption Status
Several top Block Producers (BPs) have taken steps to register their peer keys, which is a good start. We're seeing some partial peering connections happening, like between Genereos and Eosphere, showing that the basic connectivity is functional for some. However, this isn't happening across the entire network yet. Adoption is still a work in progress, and more coordination and clear confirmations from BPs would really help speed things up. We haven't reached a critical mass of adoption, which might be why the gossip network isn't fully meshed as expected.
Technical Challenges in Gossip Network Formation
Setting up a stable gossip network for Block Producers (BPs) isn't as straightforward as it might seem. There are a few hurdles we're running into. For starters, finding other peers can be hit or miss. This is often because some BPs might not have their configurations fully sorted out, or maybe firewalls are getting in the way, blocking those connections. It means that sometimes, nodes just can't see each other when they should be able to.
Right now, to get things going, people are suggesting we manually add peers to bootstrap the connections. This works, but it's not ideal for a decentralized system that's supposed to find its own way. We're missing a way for nodes to automatically discover each other, like a "seed peer" system that helps new nodes find existing ones. Some ideas floating around include using hosted JSON lists of peers to help with this initial setup.
Proposed Whitelist/Blacklist Feature for Gossip Connections
To help manage connections within the gossip network, a feature allowing for whitelists and blacklists of peers is being considered. This would give node operators more control over which other nodes they connect to. The idea is to let operators specify particular Block Producer (BP) accounts that are either allowed or disallowed from connecting.
This proposed system would work alongside existing manual peer configurations. Any peers you manually add to your node's configuration would still be prioritized. However, for peers discovered through the gossip protocol, the whitelist and blacklist rules would then apply.
The primary goal behind this feature is to provide a way to prevent connections with nodes that might be malfunctioning or are under some form of attack. It's seen as a way to reduce the need for operators to manage complex external firewall rules just to filter incoming gossip traffic.
Here's a breakdown of how it might function:
-
Whitelist: A list of specific BP accounts that are explicitly permitted to connect to your node via gossip.
-
Blacklist: A list of specific BP accounts that are explicitly forbidden from connecting to your node via gossip.
-
Default Behavior: If neither a whitelist nor a blacklist is configured, or if a peer is not on either list, the node would likely follow its default connection behavior, potentially allowing the connection.
Concerns Over Peer Identification and Abuse Mitigation
Peer Identification Challenges
One of the main worries with the gossip system is figuring out who is actually sending what. Because messages can get passed around by different nodes, it's tough to track down where bad traffic really started. This makes it hard to stop problems at the source. If you block one node that's causing trouble, it might just keep spreading through other nodes you haven't identified yet. It feels a bit like playing whack-a-mole, and there's no easy way to know for sure who the original sender was.
Abuse Mitigation Strategies
To deal with this, people are asking for better ways to control who can connect and what kind of traffic is allowed. This means having more than just simple blocking. We need systems that can look at the identity of the peers and enforce rules more carefully. The current setup doesn't really give us that kind of detailed control, which is a big hurdle for keeping the network clean and safe. It's clear that just blocking individual nodes isn't enough when the network is designed to relay information so freely.
Networking Constraints Affecting Feature Viability
When we look at making new features work, especially things like the proposed whitelist and blacklist for gossip connections, we run into some real-world networking issues. It's not always as simple as just flipping a switch. For instance, a lot of nodes use proxy servers to connect. This is pretty common, but it means the original IP address of a connection gets hidden. That makes it tough to know exactly where traffic is coming from, which is a big problem if you're trying to control who can connect.
Then there's the underlying technology itself. The TCP protocol, which is what gossip uses, doesn't offer the same kind of fine-grained control over who connects as something like HTTP might. This means we can't easily set up rules to allow or block specific connections based on detailed information. Plus, with dynamic IP addresses and all these different proxy setups, trying to enforce a strict whitelist or blacklist becomes a real headache. It feels like we're constantly playing catch-up.
Because of these challenges, many node operators are finding that traditional firewall-level controls are still the most practical and effective way to manage their network traffic. They're used to it, and it works reliably, even if it's not as integrated as a gossip-specific feature might be. We need to consider if the proposed features can really overcome these existing networking realities or if they'll just add more complexity without solving the core problems.
Conclusion and Next Steps
The development of Antelope Spring 2.0, particularly the upcoming Developer Preview 2 (DP2) and its integrated event system, represents a significant area for upcoming node operator testing and feedback. Continued efforts to encourage and monitor the adoption of the Gossip protocol for Block Producer (BP) peering are also important. The proposed whitelist and blacklist feature for managing gossip connections has been acknowledged as a potentially useful tool, though its current limitations mean it is not a complete solution for network security. Further research and community input will be gathered to assess the practical viability and effectiveness of implementing such features.
Key Focus Areas for Operators
-
DP2 and the Event System: Node operators should prepare for testing these components as they become available.
-
Gossip Peering Adoption: Continued participation and confirmation of successful peering are encouraged to build a more robust gossip network.
-
Security Feature Feedback: Providing input on the proposed whitelist/blacklist mechanism and other security concerns will help shape future developments.
Future Considerations
-
Gossip Network Robustness: Addressing challenges in peer discovery and connection stability remains a priority.
-
Identity and Abuse: Developing more effective methods for identifying and mitigating abuse within the gossip network requires further investigation.
-
Networking Realities: Practical constraints related to IP masking and existing network infrastructure need to be carefully considered when designing new features.
This article was created with support from AI-driven technology, drawing on multiple reputable sources. The final content has been thoroughly reviewed and edited by BlockzHub's editorial team to ensure accuracy, clarity, and coherence. Original reporting sources are credited whenever appropriate and as required. The opinions expressed in this article do not necessarily represent the official views or positions of BlockzHub. This article is intended for informational purposes only and should not be considered financial or professional advice. Investing involves risk, and you should consult a qualified financial advisor before making any investment decisions.