Since the mainnet launch back in June, organized mass Block Producer calls have become more sparse. Lately, EOS Canada has taken part in many discussions surrounding the recent greylisting of accounts, and regarding the memory leak issues that have been noted by Block Producers across the ecosystem.
We’re Working to Bring the Community Together
EOS Canada wanted to organize a call to “rally the troops” and have a face-to-face conversation in hopes of getting more ideas discussed and evaluated than we were accomplishing through Telegram. Bart and Matt, two team members from Block.one, also joined the call to offer some guidance, ask some questions of us, and work towards improvements together.
Greylisting
A large part of the discussion on the call focused on greylisting.For those unaware, greylisting is a subjective measure that Block Producers can take to reduce the throughput of certain accounts proportionally to their staked EOS. It disables the account's burst capacity without affecting everyone else's, as a means to tame obvious abuse, while staying within the boundaries of the EOS.IO promise.
The algorithm that controls this mechanism is part of consensus and hardforking changes will be required in order to tweak its parameters. This debate was sparked by the extreme usage of the network by an account called `blocktwitter` that is sending out thousands of transactions at a time only holding the message “WE LOVE BM”. Some dApps were complaining that their customers were unable to utilize their contracts when `blocktwitter` was actively sending out their praise of Dan Larimer.
For a more indepth look at greylisting, we recommend reading this analysis penned by the team at Greymass.
Memory Leak
The discussion then focussed on a memory leak that is currently being observed by Block Producers. It is unconfirmed whether it is related to some recent software releases, the greylisting of some accounts, or network topology issues. A large number of transactions are being sent to the network, but are not necessarily being put into a block (due to collective rate limiting of the sending account).
Schedule Optimization
Schedule optimization was also discussed. As it currently stands, the list of the Top 21 Block Producers is sorted alphabetically, and that is what determines the ordering of production. Since geographic location is not being taken into account, nor is latency between nodes, a Block Producer might be handing off production of the next round of blocks to someone on the other side of the planet. This is part of the issue of why there will sometimes be “missed” blocks during a producer’s schedule.
A few methods for optimizing the production schedule are being discussed and worked on by multiple teams. Some changes to the system contract could effectively sort the proposed schedule differently, for example, based on the `location` put forth by the Block Producers when they call `regproducer` (which was its original raison-d’être). Study of the best world-wide route had already been started by Eric from EOS Sw/eden and Igor from EOS Rio and friends.
Nodeos Software Upgrades
Another point that was raised was that currently most Block Signing nodes are running v1.1.6, while Block.one has pushed many versions since then (the latest version to date being v1.2.5). After this call, we hope to see more thorough feedback as to why upgrades have not been done fully on the network, and what tests remain to be completed before Producers would feel comfortable with the latest upgrades.
Acknowledgements
A special thank you to EOS Detroit for livestreaming the call to make sure that a record existed that any EOS community member could go back and refer to, and potentially be able to offer up their own insights and solutions.
Further, thank you to all the Block Producers who took the time to join this call. We are lucky to have so many dedicated and brilliant minds working on EOS together.