The recent Vaulta (formerly EOS) Node Operator Meeting brought together participants to discuss the latest developments in the Antelope software. The conversation covered an urgent patch release for version 1.2.2, the ongoing progress of the much-anticipated Spring 2.0, and some lively debate around how nodes find each other on the network. It was a busy session focused on making the system more stable and easier to manage.
Key Takeaways
-
An urgent patch for Antelope Spring 1.2.2 is recommended for node operators to fix a rare issue that could stop block production. This update also includes minor network improvements.
-
Development on Antelope Spring 2.0 is moving forward, with Developer Preview 2 expected soon, introducing a new feature called 'events'. A separate testnet is planned for this release.
-
Developer Preview 3 is on the way and will be the last chance to make significant changes to interfaces before the final release of Spring 2.0, focusing on stability.
-
There's an ongoing discussion about how nodes connect, as current methods aren't connecting many operators. Ideas like starting with a small group of reliable 'hub' nodes are being considered.
-
Node operators are asking for simpler ways to find other nodes, suggesting tools like fetching peer lists from a URL or using simple JSON files.
Antelope Spring 1.2.2 Patch Release Urged
The Antelope development team has put out a call for node operators to update their systems to the 1.2.2 patch release for the Spring version. This update is important because it addresses a rare issue that could stop block production. It also packs in some small improvements for how nodes talk to each other and fixes a few other bugs. It's really in the best interest of network stability for everyone to get this patch installed as soon as they can.
Antelope Spring 2.0 Development Progress
Development on Antelope Spring 2.0 is moving along, with the team working on several key features. Developer Preview 2 is slated for release soon, likely in late September or early October. This preview will introduce a new data class called "events," which is expected to change how certain information is handled within the network. To support this release, a separate, temporary testnet is being set up, distinct from the existing Jungle testnet. This will allow for focused testing of the new features before they are integrated more broadly. The team is also planning for Developer Preview 3, which will aim to refine the features introduced in Preview 2 and address any compromises made. This third preview is intended to be the final opportunity for making significant changes to interfaces, with a focus on making sync calls and the new event functionality more robust.
Developer Preview 3 on the Horizon
The team is gearing up for Developer Preview 3, which is set to be the final opportunity for significant changes to the interface before the full release of Antelope Spring 2.0. This upcoming preview aims to clean up issues and address compromises made during the development of Preview 2. A major focus will be on making the synchronization calls more robust and refining the event functionality that was introduced earlier.
Key areas of work for Developer Preview 3 include:
-
Improving the stability and reliability of the node synchronization process.
-
Further development and testing of the new 'events' data class.
-
Resolving any outstanding bugs or performance bottlenecks identified in previous previews.
-
Ensuring a smoother transition for node operators upgrading to the new version.
Debate on Gossip Peering and Network Discovery
The discussion around how nodes find each other on the Antelope network, often called peer discovery, has been a hot topic. Right now, it seems like not everyone is connecting with as many other nodes as they could be. This has led to a lot of talk about the current method, which relies on a system called "gossip peering." Essentially, nodes share information about other nodes they know. However, the effectiveness of this system seems to be a point of contention.
Several ideas were brought up to make things better. One suggestion was to start new nodes with a small, reliable group of "hub" nodes. This would give them a solid base to begin connecting from. Another angle discussed was the balance between manually setting up connections to specific peers versus letting the gossip system automatically find them. The core issue seems to be ensuring robust and widespread connectivity without making it overly complicated for node operators.
This naturally led to calls for simpler ways to find peers. Many operators expressed a desire for tools that could fetch peer lists from a URL or a file. The idea of publishing lists of initial connection points, perhaps in a JSON format, is gaining some support. There was also a mention of adding ways to check if these lists are legitimate, just for extra safety.
Calls for Simplified Peer Discovery Tools
Many node operators have voiced a desire for simpler ways to find and connect with other nodes on the network. The current methods can be a bit involved, and there's a push to make this process more straightforward. A common suggestion is to allow operators to specify a URL or a file path from which the node can fetch a list of peers to connect to. This would move away from needing to manually configure every peer. Another idea gaining support involves publishing lists of seed nodes in a JSON format. This structured approach could make it easier for nodes to bootstrap their connections. There's also talk about adding optional ways to check if these peer lists are trustworthy, adding a layer of security to the discovery process.
Long-Term Improvements Under Consideration
Beyond the immediate fixes and upcoming releases, the team is looking at ways to make the network more robust and easier to manage over time. One idea being kicked around involves creating lightweight relay nodes. These nodes, potentially built using something like Wharfkit, could help spread information more efficiently across the network.
There's also talk about making the gossip system smarter. This could mean expanding how nodes share information and finding ways to automatically manage connections so operators don't have to do as much manual setup.
Additionally, the group plans to go back and look at some features that were proposed before but never quite made it into the code. These older ideas might offer solutions to some of the current challenges with how nodes find each other.
Meeting Wrap-Up and Next Steps
The discussions concluded with a clear set of actions and areas for continued focus. Node operators are strongly encouraged to begin testing the upcoming Developer Preview 2 of Antelope Spring as soon as it becomes available. This hands-on experience is vital for gathering feedback, particularly concerning the implications of the new "events" data class. The team is looking for broad participation to help assess how these events will function in real-world scenarios.
Several key points emerged from the day's conversations:
-
The community's interest in simpler peer discovery methods, like "poor man's discovery" using seed lists, was reaffirmed. This approach, which involves fetching peer lists from a URL or file, was seen as a practical step forward.
-
Further investigation into lightweight relay nodes, potentially using tools like Wharfkit, was agreed upon as a way to improve network propagation and ease the connection process for operators.
-
The team will revisit previously proposed but unmerged features that aim to improve the overall network discovery mechanisms.
These next steps aim to address the immediate needs for stability and usability while also laying the groundwork for more robust long-term solutions in network management.
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.