RFC: Reducing the Roll Size

The number of bakers has dropped in recent months. It could be related to yields on decentralized finance applications being more attractive than baking, regulatory mumblings in different jurisdictions, the only GUI solution (Kiln) being problematic or increasing hardware requirements.

A smaller number of bakers impacts the decentralization of the network negatively. To counter this trend, a clear approach is lowering barriers to becoming a baker:

Another factor in the roll size might be the price of XTZ. At the end of the Athens upgrade, when the roll size was reduced from 10,000 XTZ to 8,000 XTZ, the price of XTZ was ~ US$0.50. It sits over $5.00 at the time of writing.

Of course, the size of the roll should be high enough for bakers to take the responsibility seriously.

Should the roll size be reduced? What are the tradeoffs? What is the right roll size?

1 Like

Roll size has been discussed on this forum ad nauseam; just do a search. The biggest downside is the increase in hardware requirements to handle the additional calculations complexity. At each cycle, the network must calculate rights for all bakers. Now, double the number of rolls (by reducing the requirement in half, for example). At the beginning of the cycle, now, bakers’ software struggles with the calculations. And OCAML isn’t the best language for this either with its severe lack of multi-threaded capabilities. Granada introduced a HUGE, HUGE performance penalty in tezos when looking up endorsing and baking rights. Changing the roll size will only make things worse.

So you could say “cut roll size in half” but the counter would be “minimum system requirements doubled”.

2 Likes

I don’t think anybody disagree that we shouldn’t reduce the roll size for improving decentralization especially if the price continues to increase, but we just have to be careful in doing so for the reasons krixt had mentioned.

BakerDAO’s fixes this, lots of small TEZ hodlers joining together in a decentralized & noncustodial way to form a baker, without having to modify the protocol to decrease the roll size. Let’s build stuff on top of tezos, so we don’t have to modify the protocol that will create other issues.

I feel like some practical data would really help with this, since most of us don’t have a clear idea of exactly what the impact of lowering the roll size would be. There would be some increase in storage and CPU requirements for node operators, but by how much? From what to what?

I’d love to see a study with some actual results like “On 1 September 2021, a fully synced mainnet node with the current roll system used X GB of storage. With a simulated roll size of 4,000 it used Y GB. With a simulated roll size of 1,000 it used Z GB.” No idea whether that’s possible. If it is, could somebody be persuaded to study it and produce a report? For example Nomadic Labs seems to have various academic partnerships and student interns. Could this be a suitable project for that kind of researcher?

If we could see the actual practical impact, it might be much clearer to Tezos community members whether decreasing the roll size is a good idea or not.

If you bake with only 8,000 XTZ your luck will be horrible waiting too long to win a block. You are better off delegating 8,000 XTZ than baking it yourself even if you had no overhead cost to bake.