Switch to unbounded queue

[dknopik]

I realised that a last minute change in #212 is actually broken - the bounded queue's blocking_send can only be used outside of the tokio runtime. While the calling function is not async, we are still in the runtime - causing the call to panic.

We could use try_send instead, but I feel like it is preferable to use an unbounded queue instead.

We are sending PublicKeyBytes, which has a size of 48 bytes. Mainnet has ~100000 validators hosted by SSV, so the worst-case is approximately 4.8 MB, which is very tolerable. The real world case will be far smaller, as the queue is handled rather quickly.

[diegomrsantos]

I think it might be risky. For example, could it be exploited to make the node's memory grow unbounded?

[dknopik]

@diegomrsantos

During live operation, this is not possible - blocks occur every 12 seconds, and can only contain a certain amount validator registrations (which can be calculated with the max block size), results in a slower rate than the queue is processed by orders of magnitude.

Of course, for historic sync, we fill the queue far quicker. But as I noted above, 100000 validator keys result in approx 4.8 MB of data - which is really not that much. If an attacker wants to increase this by densely registering fake validators, he has to

• pay for the transaction on-chain
• deposit SSV token

For the sake of the argument, let us at least quickly calculate the cost of the former. Registering 50 validators in bulk costs ~3M gas: https://holesky.etherscan.io/tx/0x16e754c3fcc6b428ea1df8943fd01e381e4f78c1761ea2bac98afd73868bf0d2

Filling up a block up to the gas target with gas target 18M therefore allows us to register 300 validators - assuming there are no other transactions. With a gas cost of 1gwei, we pay 0.018 ETH for that, resulting in a cost of 0.00006 per validator. So registering 100000 validators costs us 6 ETH (~ 8819.48 USD), and then we also have to consider the SSV token cost.

This attack results in a memory increase of 4.8 MB during initial sync (worst case - we are also processing the queue while adding to it). To get to problematic numbers, we have to ramp up the attack, making it more expensive.

So no - I do not think this is risky.