Simulating Monero’s Dynamic Blocks

I have seen a lot of recent discussion regarding transaction volume increases, and Monero's dynamic block size/fee algorithm. This post is intended to illustrate the mechanics of Monero's scaling. Quick note that I am a Monero hobbyist and no one has checked my work, so take this post with a grain of salt.

A couple of major points:

  1. Dynamic blocks does NOT mean perfectly elastic blocks. Monero does not just slam the entire mempool into the next block. Fees have to be paid to exceed certain limits, and there are limits that cannot be exceeded no matter how much is paid. These limits adjust in response to recent blocks, hence 'dynamic.'

  2. Monero is very adaptive if we assume higher fees are paid. It is possible to increase the block size to ~30MB in the course of 12 hours in an extremely high fee environment. This would be expensive, but it is possible.

  3. Flooding the chain with minimum fee transactions does very little to expand the block size. My understanding is that there is a small grace window for a transaction which partially crosses the penalty median, but the ultimate effect of this is very limited in comparison to using higher fee transactions.

I have written a Dynamic block size simulation in Python, and used it to illustrate an example. The simulation is imperfect, but generally accurate as I understand the algorithm. The simulation assumes:

  1. A 10x transaction volume increase in a 2 day time frame, starting with 100kB blocks.

  2. Users respond to congestion by broadcasting medium fee transactions (~16x the low fee).

Here is an animated plot showing the result:

The bottom line is that Monero easily adjusts to the increased transaction volume over the course of the ramp when medium fees are paid. After the block expansion is finished, users can return to broadcasting low fee transactions to maintain the new block size of 1MB.

Looking at the plots, you can see the short term limit being continuously hit from blocks 400-950. Around block 950 the short term median limit exceeds the ramping volume, clears the mempool, and allows a window of low fees from block 1000-1150. As the ramp continues the short term median adjusts down from the earlier peak, and the transaction ramp finishes with a steady increase in block size driven by medium fees. The ramp finishes at block 1540, the mempool is cleared, and the network continues with 1MB blocks and low fees from users.

To make the simulation more realistic, I ran it a second time adding significant noise to the transactions being broadcast. An animated plot showing that result is here:

The bottom line remains the same: Pay medium fees during a rapid expansion, and Monero will fully adapt to a 10x increase in 2 days. Monero can adapt much faster (or slower) than that depending on conditions, but for practical purposes this should address people's questions about a large transaction volume increase happening in Monero.

The full simulation code is here:

I want to encourage everyone to consider creating graphics to explain the inner workings of Monero. I would happily assist anyone if they are interested in improving this simulation. My hope is to eventually have an interactive demo, similar to

Animations, interactive demonstrations, and other visualizations would greatly help the general public understand how Monero works. There are many opportunities to contribute something fun that educates people.

submitted by /u/spackleXMR
[link] [comments]

Leave a Reply

Your email address will not be published. Required fields are marked *