August 16: IF Leap Integration Status, Deferred Transactions Phase-out & More

August 23: Strategize Upcoming Upgrade and Information Dissemination

August 31: Disabling Deferred TX on Testnet, Software Status Update, NodeOS Config Matrix

Instant Finality target date: September 29th

Exploration to expedite the date.

Deferred transactions are to be disabled in the 5.0 upgrade.

Seeking input on coordinating this change among node operators.

Considerations for disabling deferred transactions.

All active Block Producers (BPs) must disable DTs for accurate testing.

Enforcement via EOS node code removal in 5.0.

Option to require user configuration for deferred transactions.

Options for software rollout discussed.

Minor version vs. coordinated configuration update.

Consideration of full 4.1 release before 5.0.

Emphasis on coordinating updates across significant chains.

Acknowledgement of potential challenges with deferred transaction removal.

Need to assess deferred transactions' impact on dApps.

Proposal to use reporting to track deferred transactions.

Communication plan for dApp developers about phase-out involving EOS Support

Emphasis on prompt action and adaptation.

Disabling Deferred Transactions Plan: A plan was formulated to disable deferred transactions. This plan prioritizes transparency, clear communication, and a structured timeline. It also allows room for feedback, ensuring that the community is actively engaged in the process.

Improving Documentation: A concerted effort is underway to elevate documentation quality. This includes enhancing user guides, exploring the creation of a configuration guide for user convenience, and even considering the involvement of guest speakers to provide valuable insights and make the documentation more user-friendly.

Enhanced Resources: Recognizing the importance of supporting node operators, there's a focus on providing detailed explanations. This also involves documenting changes and offering supplementary resources to ensure node operators have the necessary tools and information.

Operator Manual: To facilitate collaboration between node operators and dApps, plans are in motion to create a concise operator manual. This manual will be a valuable resource for users, promoting better understanding and efficient operation.

Raising Awareness: Efforts are being directed towards simplifying complex concepts and raising awareness. This encompasses creating educational resources, developing EOS help sections for users, forming working groups to facilitate discussion and progress, and a coordinated communication strategy to inform users about the depreciation of deferred transactions.

Schedule and Development Progress: The participants examined the current status of the schedule, emphasizing the draft announcement concerning the depreciation of deferred transactions, and discussed the importance of community engagement in the implementation process.

Distribution Plan: A comprehensive distribution strategy encompassed blog posts, public channels like Twitter, direct outreach to notable apps, mailing lists, newsletters, and coordination with exchanges and top block producers.

Task and Milestone Tracking: The need for a centralized task and milestone tracking system was highlighted. Participants explored the utilization of GitHub for this purpose.

Finalizer Keys: A significant portion of the discussion focused on the importance of finalizer keys in the new consensus algorithm, emphasizing the need for meticulous management to ensure smooth operation.

Block Production Keys: The Node Operators considered the need for a more robust system operating at a transaction level and explored supporting a stack of keys with automatic rotation or regeneration.

Monitoring and Reacting to Node Status: The challenges associated with monitoring node synchronization and the importance of quicker response times were discussed, along with potential solutions.

Multiple Signing Keys: The possibility of incorporating multiple signing keys for a producer was explored, although complications prevented immediate implementation.

Configuration and Implementation: Ongoing work and discussions revolved around configuring and implementing new features, underscoring the importance of understanding when and why specific settings should be enabled.

Separation of Roles: Separating the leader role and introducing multiple backup block producers after the 5.0 update was considered, emphasizing effective communication among the top 21 block producers.

Documentation and Knowledge Gaps: Concerns about potential disruptions and knowledge gaps in the new architecture were raised. The Node Operators emphasized the need for comprehensive documentation and an understanding of the implications before making changes.

Feedback and Communication: The importance of gathering feedback and clarifying the reported metrics was discussed, along with plans to disable deferred transactions and adjust schedules accordingly.

Spreading Information: The roundtable concluded with participants expressing their readiness to disseminate information within their respective communities, fostering collaboration and ensuring a smooth transition.

Task Focus: Discussions touched on the removal of specific software development tasks related to deferred transactions due to constraints in time and resources. Instead, low-fidelity methods, such as block explorers, were considered to gather information. The participants acknowledged the absence of an estimated delivery date for disabling deferred transactions in code but expressed confidence in achieving it before the release candidate.

Mainnet Release and Testing: Planning for the EOS mainnet release and the progress of the Leap 5.0 software were discussed. Timelines for the BP upgrade and removing dependencies were established to ensure a smooth transition.

A tag for existing mainnet features was introduced to enhance testing and bolster confidence in preparation for the release.

Enhancements and Documentation: Participants shared excitement about trying out new features while emphasizing the importance of documentation, testing, and benchmarking. They invited user feedback and suggestions and sought assistance from other API node operators to understand configurations better and provide recommendations.

Resource Monitor Override: The concept of creating a resource monitor override for different settings related to API usage was explored. The goal is to create a comprehensive guide for running an API, clarifying settings, and offering recommended values. The participants expressed support for this initiative and offered to contribute comments and suggestions.

Configuration Matrix Clarity: The importance of reviewing and commenting on configuration files was underscored, especially with the impending release of version 5.0. The participants discussed the need for a better understanding of configurations and proposed creating a centralized document or website with parsed information and links to official documentation.
​

EOS Support Learning Center