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.
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.
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?
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:
Modify how slot leadership is determined so that only every 3rd or 4th slot is valid
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.
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.
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.
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.
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.
Well, it probably won’t go like that. Instead, gradually the more remote stake pools will migrate their block producers to Amazon data centres. It will be like some reverse black hole where the most peripheral pools move to the centre in order to remain competitive by not losing too many blocks to “fork battles”. This inwards sucking will make the network propagation quicker and mitigate the increase in block size.
I am writing to you on behalf of the Parameters Committee to inform you about the status of your recent Parameter Change Proposal (PCP).
As you can read in the last update from the committee, the upcoming PCP-003 has been selected and so other extant PCP applications will be deferred as per the PCP process. This decision does not reflect a lack of merit in your proposal, but is rather the result of current prioritization and our limited capacity to process all the proposals.
The deferral of extant PCPs after a given triage and selection period provides a period for the authors to continue to refine their message, to accentuate the importance of the PCP for the next period, and to assess its ongoing relevance given developments (including the results of active PCPs) in the interim. When the Committee opens the next submission period, you can notify us that you wish to renew the PCP.
We encourage you, if you wish, to use this time to revisit and strengthen your proposal, incorporate any feedback you have received, and account for any relevant developments in the ecosystem. The Parameters Committee values your contribution to the Cardano community.
Should you have any questions or require further clarification, please do not hesitate to reach out to us.
Thank you for your understanding and for your dedication to improving the Cardano ecosystem.
