Mega helpful post. Thank you.

I need time to digest/re-read some stuff, but this means most side-chain projects (HE and Honeycomb ie, which are 100% JSON-based) accounts will need to increase their RC vests substantially. On the other side, if one would centralize more diverse types of pool calls on the same account, that might become beneficial due to the "resource popularity share", am I understanding it right?

The new mechanism helps here. When history bytes become more popular, its pool popularity share increases, but it also means shares of other pools decrease. So comments can actually have their cost lowered during such time, because they also consume significant amount of state, which will drop in price as a result.

This recalls me of how Slurm "fair tree fairshare" works. Very interesting to see some of these problems being shared across completely different things that aim to somehow solve the same problem: Resource consumption "fair" schedule.

Super excited to finally understand more of this stuff =) Really overwhelming how much thought was put behind all this. Really amazes me 😎