Author: Marco González
Editor: Randall Roland
Node operators, Antelope core developers, and community members get together each week to discuss the captivating questions of the day. The primary objective of each Node Operator Roundtable is:
“…to improve the Antelope protocol (specifically) for node operators”.
Meetings occur every Wednesday from 14 UTC to 15 UTC (13 UTC to 14 UTC during daylight savings). The EOS Network Foundation provides tutorials and documentation for those wishing to learn the basics of operating an EOS node (and more).
Below is a list of the roundtables contained within this bi-monthly summary:
July 19: ENF Recommended Configuration Changes for Version 5.0
July 26: Canceled
July 19: ENF Recommended Configuration Changes for Version 5.0
The July 19 roundtable may prove to be the point where the node operator community shifts its focus from Antelope v4.0 to v5.0. Action taken to prepare the 5.0 rollout likely begins with the ENF’s configuration changes discussed in today’s meeting.
OVERVIEW
Eric Passmore posted notes on Telegram that outline the ENF’s recommendations for nodeos configuration changes. The main points from the notes are listed in the following section.
Eric began by bringing attention to how much has changed since B1 released version 2.0. Changing configuration makes sense on so many levels. Still, the ENF bases its recommendations on both performance testing and empirical data.
TOPIC: Posted Recommendations from July 18 Node Operators Telegram Channel
The first item identified are transactions within the production environment that exceed 30ms. It’s here that the read_only transaction update added in Leap 4.0 stands out. Increasing limits immediately benefits both read_only and general production environment transactions.
The ENF’s July 2023 suggested configuration changes (as posted by Eric Passmore) are as follows.
1. For read-only configuration changes, only Leap versions 4.0 and later are affected:
“(165ms) read-only-read-window-time-us to 165,000”
“(151ms) max-transaction-time to 151”
2. For multisig changes, only the Jungle testnet is affected (at the moment). No changes are yet required for the mainnet:
“(150ms) max_transaction_cpu_usage to 150,000”
“(200ms) max_block_cpu_usage to 200,000”
Expect the suggested changes to remain focused on the Jungle TestNet until a rollout plan is coordinated with the weekly Node Operators meeting.
Suggested changes precede the default configuration that plans to accompany the release of version 5.0. Eric’s post concludes with the notification that the configuration settings will be among the items tracked to ensure that both producers and chains have the same settings to ensure a coordinated rollout of version 5.0.
Meeting Discussion
Eric joined the roundtable meeting to discuss the recommended changes. The community didn’t need to engage in much discussion to grasp the ENF’s intent. Nor were there any objections.
Topics briefly discussed include:
time clarifications
increasing from 30 to 151 milliseconds provide ample breathing room
expect a couple of weeks of testing on Jungle for new changes
emphasis on smooth coordination begins with configuration changes
sufficiency of subjective billing for transaction failures
Subjective billing helps deter failed transactions based on the cost of CPU and configuration changes.
Note that it’s impossible to perfectly simulate activity on the EOS Network. Planned changes may need to be altered. Further consideration should be given to what might go wrong (especially about block producers).
It’s at this point that a new blog post was suggested. Node operators are mentioned several times throughout the May 24 blog post, An Introduction to Subjective Billing and Lost Transactions.
Other notable mentions relating to configuration changes include performance/benchmark testing. There’s confidence that configurations will hold up.
Version 5.0, Subjective Billing, and Pushing Out Blocks Faster
How will Antelope Leap version 5.0 get blocks out faster? The May 24 post (mentioned above) introduces subjective billing updates:
“New features in Mandel 3.1 will allow node operators to set their node’s subjective billing decay time parameter upon initialization. This option will adjust the time it takes to zero out an account’s subjective bill.”
The August 8 announcement, Leap v3.1 Release Features & Additional Tools, outlines new transaction lifecycle tools:
“Previous articles explored how the subjective billing system can cause lost transactions and outlined existing fixes for common transaction lifecycle issues like lost transactions. The Leap v3.1 release introduces new tools to address these issues and other user experience hurdles.”
Profound improvements are on the horizon as the subjective billing system matures with v5.0. Instead of unapplied, queued transactions, the next block can begin immediately. It’s even been suggested that 12 blocks can be completed in a single round. Caution was given for control consideration of the last block.
The meeting ended early as the community looks forward to coordinating for version 5.0.
Sources & References