EOS Mainnet Update: Block.one EOSIO Releases, Block Producer Infrastructure Improvements and EOSIO 2.0 Upgrade Process

Today we take a behind the scenes look at the collaborative work that’s been happening in the last few weeks between Block.one and the key block producers of the EOS Mainnet.

Block.one

The folks at Block.one have been phenomenal to work with to address the microforks and missing blocks challenges currently facing the EOS Mainnet. They’ve been in regular communication with block producers and have quickly addressed the critical issues that were identified by those block producers. A few highlights from the recent 1.8.11 and 2.0.2 releases:

• The “drop-late-blocks” feature means that blocks arriving late from the ‘prior block producer’ to the ‘next block producer’ are dropped. This is different than previous behaviour where those blocks would interrupt production, apply the block, and then resume production. It’s the responsibility of the ‘prior block producer’ to send blocks sufficiently fast that they don’t get dropped. The main thing to consider is the network latency, especially in cases where the ‘prior block producer’ and ‘next block producer’ are located on different continents.
• The “cpu-effort-percent” feature allows block producers to more finely tune how much of the CPU on their signing node is used to create blocks. Smaller blocks can get to the next block producer faster.
• Allowing “read-only” connections to be bi-directional.  Block producers are using “read-only” mode to allow faster block-exchange amongst themselves. The feature was not designed for that purpose, but it is now supported.

For the technically curious, here are the release notes for 1.8.11 and 2.0.2:

• 1.8.11 release notes
• 2.0.2 release notes

Block Producer Infrastructure

On the infrastructure side, many node setups have seen drastic changes in the past two weeks. The improvements can be generally grouped in a few areas:

• Faster performance: Faster CPU or additional memory upgrades.
• Improved network topology: Node architectural improvements both in terms of internal block producer infrastructure setup as well as optimized external connections to other block producers.
• EOSIO software changes: (see above)
• Configuration tuning: Reviewing key configuration options in EOSIO and adjusting where needed.

Many of these changes are not actually apparent to end users as they are completed and the overall result cannot be seen until multiple related changes come together.

In fact, sometimes while these kinds of changes are in progress, the overall network performance can degrade for a short time.  For example, a block producer brings a new node online, which aims to speed up block propagation, but it has a new IP address, which might need to be reflected in other block producers’ EOSIO configuration and firewall rules. Unfortunately, it’s not always possible to keep the old configuration and new configuration running at the same time.

EOSIO 2.0 Upgrade

As for the upgrade process to EOSIO 2.0, many block producers are already running EOSIO version 2.0.2 (released on February 6, 2020) on their public API and P2P nodes. Additionally, as part of these infrastructure improvements, version 2.0.2 is being introduced in a thoughtful manner where it can help improve performance. Block producers will upgrade various parts of their infrastructure when the time is right for them.

In terms of block production, EOS Nation is the first block producer to run 2.0.x on the EOS Mainnet starting from 2.0.2 pre-release versions. Someone must be the first to test new versions in production on the EOS Mainnet and EOS Nation is happy to take that role. Other block producers will soon be following our lead.

Our Chief Infrastructure Officer, Matthew Darwin, is in regular communication with Block.one, and by submitting our logs to Block.one has been able to help in identifying numerous EOSIO issues. Matthew has also submitted many github requests and HakerOne security-related isues of which two were awarded bounties.

We expect that block producers will be looking at the 2.0.2 release to see when and where it makes sense for them to upgrade. We expect it to be rolled out soon across the P2P network that is used between block producers to exchange blocks and then other places following that. 

When block producers do these changes you won’t notice anything different. The much-anticipated performance boost from EOS-VM cannot be activated until everybody on the whole network is ready and the microforks and dropped blocks issues have been resolved. 

Conclusion

A lot of work has been done and there is lots more work ahead to improve network stability and execute the 2.0 upgrade. The top block producers are in regular communication with each other and with Block.one to provide the best possible blockchain experience in the world!