# A validation on VOPS(Valid-Only Partial Statelessness)
## The premises
The premise that VOPS is based on is the following:
> State growth is marked by 3 factors:
> - Number of storage slots written at some point with value != 0.
> - Number of unique accounts with > 0 wei.
>
> State growth has a much more steep curve of growth when related to storage slots rather than when compared to unique activated accounts.
**Why is this important?**:
Well, imagine in VOPS we require an initial investment to nodes for hardware capable of executing 100M gas blocks.
That would mean, storing at least:
$$
298\,\text{million} \times (20\text{ bytes}_{\text{address}} + 8\text{ bytes}_{\text{nonce}} + 11\text{ bytes}_{\text{balance}}) \approx 11\ \text{GiB}
$$
### Effects of EIP-7702
After [EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md), notice that this number will change.
This happens because now accounts will actually store code. And therefore this code will need to be stored to if we want VOPS clients to be able to prune their mempools correctly.
:::warning
Get more input here from Matt and try to get numbers from common 7702 delegation contracts like {%preview https://github.com/ithacaxyz/exp-0001/blob/main/contracts/src/ExperimentDelegation.sol %}
Also, figure out if we can just hold a hashmap or similar for the hashes of the contract in case their bytecode needs to be stored. There will be a lot of repetition so maybe it's feasible to handle).
:::
## The implications
Consider the scenario where:
>Throughput is unlocked, state starts to grow quickly. And the unique number of accounts is the driving factor for ethereum's state growth (lots of unique new addresses get activated every day and the number grows exponentially).
>
>That would mean, that this `triplets` also grow exponentially in size.
Luckily, we have backup data that helps us to understand state growth implied by unique ethereum accounts.
### Ethereum state growth implied by unique account increase
Based on the analysis of [Etherscan's Ethereum Unique Addresses Chart](https://etherscan.io/chart/address), here’s some data to understand **why VOPS can be a good solution for the short-medium term for statelessness in ethereum**:
#### Growth Summary

The table above shows:
- Average Daily New Addresses: **~100K per day -> 6MiB**.
- Average Monthly Growth: **~3M addresses per month -> 180MiB**.
- Average Yearly Growth: **~40M addresses per year -> 2.4GiB**.
These averages smooth over extreme spikes, giving a baseline for state-growth over time and what we can expect the growth to be if we consider "hype-years" to be the norm for the future.
---
#### 30‑Day Rolling Average of Daily Onboarding
The final plot smooths daily noise to reveal multi‑week trends.
Based on that, we get the following data:

As we can see. Spikes can happen from time to time. Originated ocasionally by ICOs, marketing or simply Fork updates.
Nevertheless, here's some data on the major deviations from the average:
|Date | 30d MA (MB/day) | Deviation (MB) | Type|
|-|-|-|-|
|2025-03-05 | 12.94 | +6.67 | Peak|
|2018-01-15 | 13.67 | +7.40 | Peak|
|2018-03-15 | 2.92 | −3.35 | Trough|
|2019-01-20 | 3.00 | −3.27 | Trough|
This can allow us to compute worst cases for `triplets` size increase.
### Storage requirements for VOPS clients for future years

The chart above projects the next 10 years of on‑chain storage for account triplets, starting from today’s ~ 19 GiB baseline (313.5 M accounts at 60 bytes each), under three linear growth scenarios obtained from the data above:
- **Average trend (6.27 MB/day)** — blue solid
- **2018‑peak rate (13.67 MB/day)** — orange dashed
- **2025‑peak rate (12.94 MB/day)** — red dotted
**Main takeaways:**
- At the **average** rate, ∼0.183 GiB/month (6.27 MB/day × 30 / 1024) would be added, reaching **~41 GiB by 2035.**
- Under **2018‑peak** onboarding, ∼0.40 GiB/month would be added, climbing to **~68 GiB in a decade.**
- At the slightly lower **2025‑peak** rate, we'd hit **~65 GiB by 2035.**
This illustrates how temporary surges in user onboarding can dramatically accelerate long‑term state growth, and how this solution is well-suited to support such growth for at least a decade while a better long term solution is worked out.
### Block re-execution hardware requirements for VOPS clients
:::warning
Pending from: https://discord.com/channels/595666850260713488/688075293562503241/1362347896896487474
> @kamil_chodola , @Ben {chmark} Adams or someone from Nethermind, RE: https://x.com/ChodoKamil/status/1912584118686318681
>
>Do you have any sort of data collection of all these benchmarks? Would be useful for statelessness.
>
>I'm specially interested in minimal hardware requirements to perform block execution with blocks of these sizes.
>
>Is there any way to get access to the code or tool you are using to gather the data if you haven't actually stored it?
:::
## Conclusions
VOPS has the potential to be a good medium-term solution for statelessness which allows to departamentize roles for validators in ethereum and enable different feasible requirements for different roles within CR.
Here, we show how the `triplets storage` assumption would influence VOPS nodes overtime.
:::warning
Pending to get block re-execution cost data to conclude something.
:::