# Beacon State Management in Prysm With the state in mainnet growing bigger every day with the seemingly endless amount of new users and staking pools depositing, I decided to look at ways we can improve or make it better. Given that in a few weeks we will most likely end up on pyrmont sized states, it was important to see how to improve it further. After thinking through it 2 potential solutions came to mind. ### Revamp the whole state This was discussed with raul previously but we didnt go through it because it was too risky before launch. Right now it was worth it to go through again and look at its feasibility. Instead of having the state as a protobuf object , we have it as a custom state type with custom ssz marshalling, etc. *Pros* - More efficient representation of the state( representing arrays as fixed length vs variable length currently). We can experiment with a lot of different things including creative data structures for certain large fields in the state. - Not tied to limitations of protobufs *Cons* - A very big change that will touch the whole repo. A change like this has the potential to introduce many issues and potentially even consensus issues, data corruption, etc. - Will take a while to implement and do properly. Given that we are in mainnet now with real money running with prysm we cant really push something like this compared to a year back. ### Make Individual validators in the state immutable Only track the references in the registry and just share that across states. Any modification to a validator requires a new copy of the validator be created first. Pros - Relatively small change, is easier to inspect and validate. - Offers a quicker way to solve memory issues Cons - Might be potentially just be kicking the can down the road, as we still might have memory issues with even larger states(500k validator set) - Modify core consensus code, so will need to be closely examined. ### Current Resolution For now I have proceeded with the 2nd option https://github.com/prysmaticlabs/prysm/pull/8397 In initial testruns, numbers are pretty great. Its a 50 -60% reduction in memory across the board. Also potentially rapid spikes in memory have stopped so far. Its staying at 1 - 1.6 gb , with the current mainnet state.