Based on metrics from the last bull run, and the possible scenario of another bull run in the next few years, Cardano needs to be ready. Maximum transaction volume was around October 2021. Currently the Cardano chain load touches 60% and periodically spikes to 94% as shown on pool.pm in the past few weeks. Brief periods of heavy user activity during new token drops contributes to load spikes. This topic needs a lot of further discussion to iron out which parameter increases are needed to be ready.

Refer to @Quantumplation PCP for max_tx_ex_mem on his PCP.

I suggest the following in preparation for more Cardano users:
Increase max_block_size from 90,112 to 96,000

Increase max_tx_ex_mem from 14,000,000 to some higher number based on inputs from dapp developers.

Increase max_tx_ex_steps from 10,000,000,000 to some higher number based on inputs from dapp developers.

Increase max_block_ex_mem from 62,000,000 to some higher number accordingly.

Increase max_block_ex_steps from 20,000,000,000 to some higher number accordingly.



The biggest thing I’d want to see in support of this is an analysis correlating block size with block propagation times.

We should have lots of good data from the 4 or 5 times this was increased to show how it impacted things. I don’t have that data on-hand, but perhaps @gufmar does.


Yes I agree. We don’t want to increase block size to the point where there is an increase in height battles and an increase in block size would actually slow the chain down.


Info from Smaug


Thanks @rickymac, I have also added my detailed charts here:


Here’s some sample data from Markus. Probably need more historical data to estimate demand


Arguably not very congested compared to the last bull market. Feels like the back pressure will encourage the move to plutus v2/3 and we should not rush to increase before major dApps have upgraded?

Here is another data point of the current network load and the affect an increased transaction load has on slot battles and propagation delay.

Sorry @rickymac, I hadn’t noticed this discussion thread before but I have commented on @Quantumplation’s thread.

Something I have been at pains to point out is that the effect of increased block propagation delays is not evenly felt across the network. Unfortunately increased delays causes the protocol to unfairly disadvantage the more physically remote pools. This effect arises from the fact that slots are only 1 second in duration and “fork battles” are settled using the block VRF.

I explained the cause and how it works against decentralisation in this comment to @Quantumplation’s thread.

In summary, any increase in the block size will exacerbate this protocol design unfairness which is already quite significant. See for example my analysis of a recent block with a breakdown of production, propagation and validation times for 3 machines with different computation speed.

A correct fix for this design problem might involve two changes combined:

  1. Modify how slot leadership is determined so that only every 3rd or 4th slot is valid
  2. Only settle “fork battles” using block VRF if slot is identical (otherwise prefer current chain)

If such changes were instituted first, then increasing the block size wouldn’t produce such an uneven and unfair effect, which works against decentralisation.

1 Like

You bring up a good point Terminada. Blocks will not reach maximum size, ostensibly maximum latency, unless the network is at maximum utilization. My main concern here is now that Cardano has more complex transactions, including larger txs with metadata in them, the effect on users trying to use the chain at above 100% during a bull run will be more detrimental for individual users than the effect of outlying nodes operating at higher than average latency, especially latency exceeding 1 second.

This is one of those tradeoffs we need too consider so good thing you brought it up.

1 Like

And the different participants will mitigate their losses, or frustration, by different means. The geographically decentralised pool operators will give up and move their stake pools to a data centre owned by Amazon and people will start criticising Cardano for being less decentralised.

The thing is that we don’t need to make this trade-off. We need to get the design architects recognising this problem because they will realise that their design has a fixable flaw. In particular a fundamental assumption of Ouroboros has not been implemented properly. This assumption is that each pool has the chance of it’s blocks being admitted to the chain directly proportional to the amount of stake it has. But this is not the case for geographically remote pools because with 1 second delays they suffer 3 times the number of “fork battles” and with 2 second delays they suffer 5 times the “fork battles”. Note that just 1 or 2 second delays is well under the networking safety design requirement of less than 5 seconds.

I think the design architects will want fix this design flaw because it isn’t just causing unfairness for stake pool operators in terms of earning rewards. It also, and maybe more importantly, compromises the security of the chain, because it means that a malicious group could control the chain with less than 50% of the stake. Or a malicious group could have more ability to do nasty things like MEV with less ability for the community to mitigate such attacks by shifting their stake to other geographically decentralised pools.

By having operators move their pools to Amazon data centres in an effort to suffer less “fork battles”, this hands power to Amazon giving them greater ability to differentially control propagation delays between groups of pools. The Ouroboros papers outline several attacks related to an actor having differential control over propagation delays.

Hi @Joaquin here is my PCP form.

1 Like

Terminada I was able to capture this data point yesterday to add to the conversation. This shows the impact of fuller blocks on the block propagation times. This is not perfectly precise data but does a good job of graphically depicting the technical limitations.

This graph is from pool tool a few hours after Epoch 466 started and there was heavy chain load for a new NFT feature that attracted a lot of user activity, with the 466 column only representing a few hours of data. 457-465 are showing 5 day averages.

1 Like

Thanks @rickymac

The propagation delays are magnified at the geographically decentralised parts of the network. Which, unfortunately creates a centralising pressure to move block producers to a data centre owned by BigTech in EU/USA.

I proposed a fix for the Ouroboros-network issue: “subpar handling of blocks from the future”:

If such changes were deemed appropriate by the design architects, then it would provide more leeway to increase the block size without imposing unfairness on the geographically remote participants.

This graph created by @Quantumplation w/ Markus Gufler and @Smaug data is a good idea to look at this distribution when considering a block size increase.

Here’s my artistic illustration of what may happen at some point if block size increased too much. The drastically increasing propagation time will get pushed to the right but at some point will hit a point of diminishing returns and slow down the chain. I don’t know at what block size this phenomena will occur.