Rucknium

joined 2 years ago
1
submitted 10 months ago* (last edited 10 months ago) by [email protected] to c/[email protected]
 

(Thanks to spackle for this writeup!)

The first week has been a wild ride, and there is a lot to share. Presented roughly by order of importance:

PR Improving Node Startup

Restarting a node while there is a large mempool can take over an hour in extreme conditions, since the node must process all the mempool transactions before resuming regular operation. 0xFFFC has addressed this with a massive speed up in PR 9376. These changes are now in use on the stressnet, to great effect.

Block Sync Size

Block propagation and network synchronization suffer at larger block sizes, which encourages the creation of alternative chains. Setting '--block-sync-size 1' allows nodes to handle larger blocks more easily, and this is now standard practice on the stressnet. Further updates are expected on this soon.

Ongoing Investigations

  • Block sync size
  • Wallet-to-daemon connectivity and performance enhancements
  • Tx pool management (including flush_txpool processing time)

General Announcements

  • Go to monitor.stressnet.net to see network stats
  • explorer.stressnet.net is offline for now
  • Node operators should upgrade to latest release for a smooth(er) stressnet experience. Older releases struggle with larger blocks, and ban too many nodes.
  • Congratulations to strawberry, winner of the wallet draining competition
  • Ongoing discussion is being held on Matrix at #monero-stressnet:monero.social and Libera Chat IRC on ##monero-stressnet.

Stressnet Stats

  • This plot shows the block sizes on stressnet over the past week
  • Largest Block: 2.49 MB at height 2521514
  • Most transactions processed in an hour: 33074 (equivalent of 794000 tx per day)
 

Why

Currently, Monero only has one node written in C/C++, many would see this as an issue. Having only one implementation makes us more vulnerable to implementation bugs, having another node will help us to spot and fix these issues.

monerod's code is also a bit of a mess, as many devs who have worked on it would agree. Cuprate is a fresh start and is built with modularity in mind which will lead to a cleaner and easier to understand codebase.

Having a consensus rules document will make it easier for developers to build software to interact with Monero. It will also make it easier to spot potential issues with consensus rules.