The February 26, 2025, EOS Node Operator Meeting brought together key players to discuss the latest updates and challenges facing the network. Topics ranged from software upgrades and governance proposals to node configurations and security measures. The meeting highlighted the importance of collaboration and timely action to maintain and improve the EOS ecosystem.
Key Takeaways
-
The Spring 1.1.1 patch is live, focusing on smoother block propagation and faster transactions.
-
Block producers are encouraged to upgrade to Spring 1.1.1 for better network performance.
-
System Contracts 3.7 introduces the Gift RAM feature to prevent misuse of allocated resources.
-
The Gift RAM feature ensures users can't exploit or resell gifted RAM.
-
System Contracts 3.8 will include Restricted Strings to reduce scam accounts.
-
Restricted Strings will block account names containing flagged substrings.
-
Best practices for block producers and finalizer nodes were discussed, focusing on setup and disaster recovery.
-
Community feedback is encouraged on governance issues like Restricted Strings and MSIG approvals.
Upgrade to Spring 1.1 Series
Release of Patch 1.1.1
The release of the Spring 1.1.1 patch marks an important step in improving network performance and stability. This update addresses several bugs that were identified in the initial 1.1 release, making it a recommended upgrade for all node operators. Operators who have not yet upgraded are encouraged to move directly to version 1.1.1 to benefit from the latest fixes and optimizations.
Key Enhancements in 1.1.1
The 1.1.1 patch introduces several key improvements aimed at optimizing node operations:
-
Optimized Block Propagation: Reduces delays caused by large, transaction-heavy blocks, ensuring smoother network communication.
-
Transactions-Only Mode: Public relays can now process transactions without being burdened by unnecessary block data.
-
Enhanced Network Health: The more nodes that adopt this update, the more efficiently transactions and blocks will propagate across the network.
These enhancements are especially beneficial for block producers (BPs) running separate finalizer nodes, as they improve synchronization and overall processing efficiency.
Adoption and Testing Update
The 1.1.1 patch has been deployed on two testnets and is undergoing additional monitoring to ensure stability before full deployment on the mainnet. Node operators are being urged to adopt the update quickly to address lingering issues, such as finality drift, that have been observed in certain scenarios. Large public endpoints that configure their nodes correctly following the upgrade are expected to have a particularly positive impact on overall network performance.
Multi-Signature (MSIG) Proposal for System Contracts 3.7
What’s Included in 3.7?
System Contracts 3.7 introduces several updates aimed at improving functionality and governance. The most notable addition is the Gift RAM feature, which allows accounts to allocate RAM to other accounts with specific restrictions. This ensures that gifted RAM cannot be sold or transferred to third parties. Instead, it can only be used by the recipient or returned to the sender. This proposal also includes fixes from the previously canceled 3.6.1 update, ensuring a more stable and secure implementation.
Why Gift RAM Matters
The Gift RAM feature is designed to address issues of resource misuse in the ecosystem. In the past, some users exploited free account creation programs by selling or misusing the RAM they received. With the new restrictions, account creation services can ensure that resources are used as intended. This not only prevents abuse but also promotes fair resource allocation. For example:
-
RAM gifted to new users can only support their account’s operations, preventing resale.
-
Service providers can reclaim unused RAM, ensuring efficient use of resources.
-
The ecosystem benefits from reduced exploitation, fostering trust among users.
Upcoming System Contracts 3.8 Release
Development and Release Timeline
System Contracts 3.8 is nearing completion, with the final stages of development and internal testing underway. The deployment to the Jungle Testnet is scheduled for next week, where it will undergo rigorous testing. If all goes as planned, the team aims to propose a multi-signature (MSIG) approval for mainnet deployment by March 11, 2025. This timeline reflects the community's commitment to ensuring the release is both stable and secure.
New Feature: Restricted Strings for Account Creation
A significant addition in this release is the introduction of restricted strings for account creation. This new feature enables the EOSIO privileged account to block the creation of accounts containing specific substrings. The goal is to reduce scams and impersonation attempts by preventing the misuse of official or misleading names.
Here’s how it works:
-
A privileged account pre-reserves hashed versions of restricted substrings to maintain confidentiality.
-
Once finalized, the restricted substrings are publicly disclosed, and enforcement begins immediately.
-
This two-step process eliminates any time gaps that malicious actors could exploit.
The list of restricted strings will be small and carefully curated, targeting only high-risk cases. Block Producers (BPs) will have the authority to approve or reject these restrictions, ensuring a decentralized and transparent governance process.
Governance and Security Considerations
While the restricted strings feature enhances security, it also introduces governance challenges. One key question is how to implement these restrictions without allowing bad actors to pre-register similar names before enforcement. The two-step process mentioned earlier addresses this issue effectively.
Additional considerations include:
-
Ensuring that the process remains transparent to the community.
-
Balancing security measures with the need for decentralized oversight.
-
Maintaining a minimal and focused list of restricted substrings to avoid overreach.
Block Producers play a critical role in this governance model. Their ability to approve or deny proposed restrictions ensures that no single entity has unchecked power over the system.
Block Producer (BP) and Finalizer Node Setup
Best Practices for BP & Finalizer Nodes
Setting up Block Producer (BP) nodes and their corresponding finalizer nodes is a critical part of maintaining a robust and reliable network. While there is no official recommendation on whether these nodes should operate on the same machine or separately, the decision often hinges on the operator's disaster recovery strategy. Each setup option comes with its own set of trade-offs.
Here are some key considerations:
-
Separate Nodes: Running BP and finalizer nodes on different machines can improve fault tolerance. However, this requires careful configuration to ensure seamless communication between the nodes, which can be technically demanding.
-
Shared Machine: Hosting both nodes on the same machine simplifies configuration but may create a single point of failure. This option is often chosen for smaller operations with limited resources.
-
Monitoring and Logs: Regardless of the setup, operators must closely monitor system logs to detect any irregularities or potential issues before they escalate.
Impact of Finalizer Delays
Finalizer nodes play a crucial role in the block production process. If a BP fails to receive votes from its associated finalizer, block production halts temporarily. The system is designed to allow a short delay—ranging from a few seconds to a few minutes—before stopping block production entirely. This buffer gives operators time to address minor issues without causing significant downtime.
To mitigate the impact of delays:
-
Regularly check the health and connectivity of finalizer nodes.
-
Implement automated alerts to flag potential synchronization problems.
-
Test disaster recovery procedures to ensure quick resolution of unexpected failures.
By adopting these practices, node operators can maintain high availability and contribute to the network's overall stability.
Open Discussion & Next Steps
System Contracts 3.7 – MSIG Approval Needed
Block Producers (BPs) are strongly encouraged to review and approve the Multi-Signature (MSIG) proposal for System Contracts 3.7. This update introduces the Gift RAM feature, which ensures that allocated RAM is used responsibly and cannot be exploited for profit. Timely approval is critical to maintaining the momentum of system upgrades and avoiding delays in deployment.
System Contracts 3.8 – Issue #186 Discussion
The community has been actively discussing the Restricted Strings feature, a key element of the upcoming System Contracts 3.8 release. This feature aims to block the creation of accounts with certain restricted substrings to reduce scams and impersonation attempts. Developers have requested feedback on two main points:
-
How to balance governance transparency with effective enforcement of name restrictions.
-
Potential risks and unintended consequences of implementing these restrictions.
Outreach to DaoBox Block Producer
DaoBox, a Block Producer that recently re-entered the top 21 rankings, has drawn attention from the ENF team. Efforts are underway to engage with DaoBox representatives to ensure they are aligned with the latest updates and system changes. Open communication with all top-ranking BPs is seen as essential to the network's success moving forward.
Conclusion
The recent discussions among EOS node operators highlight the network's ongoing commitment to improving performance, security, and governance. With updates like the Spring 1.1.1 patch and the upcoming System Contracts 3.7 and 3.8, the focus remains on optimizing operations and addressing challenges such as resource abuse and scam prevention. These advancements, coupled with the active involvement of block producers and the broader community, underscore the importance of collaboration in shaping the network's future. As these upgrades roll out, stakeholders are encouraged to stay informed, provide feedback, and ensure their systems are prepared for the changes ahead.
This article was written with the assistance of AI to gather information from multiple reputable sources. The content has been reviewed and edited by our editorial team to ensure accuracy and coherence. The views expressed are those of the author and do not necessarily reflect the views of BlockzHub. Original reporting sources are credited whenever appropriate and as required. This article is for informational purposes only and does not constitute financial advice. Investing involves risk, and you should consult a qualified financial advisor before making any investment decisions.