Possible resource exhausition attack for account storage with reasonable funds

[ryoqun]

Problem

Currently, the cluster doesn't further collect rents for the duration of current epoch if previous rent has been already collected for the epoch.
A determined attacker can exploit this behavior of rather lenient rent check and can mount a temporal resource exhaustion attack within an epoch with reasonable fund like this:

1. Create MAX_PERMITTED_DATA_LENGTH-sized account with the balance of rent_exempt_for(MAX_PERMITTED_DATA_LENGTH) with 5,000 transaction fee.
2. Transfer all of the balance out of the newly-created account but 1 lamports (which leaves a huge account rent-exempt for the epoch) with 5,000 transaction fee.
3. Repeat the above

Each iteration effectively costs 10001 lamports and only takes minimum of 2 slots while that would forces the cluster to hold 10M bytes for duration of an epoch.
Also, this can easily parallelized.

So, attacker can consume 500TB with 500 concurrent processing with about 550 sols and ~24 hours, causing the trouble for the remainder of the epoch (~1 day):

[11] pry(main)> ((500 * 1024 * 1024 * 1024 * 1024) / (10 * 1024 * 1024)) * 10001
=> 524340428800
[14] pry(main)> (((500 * 1024 * 1024 * 1024 * 1024) / (10 * 1024 * 1024)) / 500) * 2 / 2.5 / 3600
=> 23.301555555555556

Worse yet, if this attack is done persistently, the resource exhaustion attack can continue until the attack ends + 1 epoch. Upper bound to 1PB resource exhaustion with 1100 sols per epoch for sustained cost with the proceeding assumption.

Alternatively, this could be bound to the IO bandwidth to the mmap()-ed account storage...

Anyway, this is well above the worst-case resource assumption across our current validators.

Proposed Solution

Adjust to increase rent check timing?

Context

Found via thinking for the fix of #10468

[ryoqun]

Hmm, I tested quickly tested this locally. It seems that we can't just do only this system-owned accounts.

But this still doable. So, we must do this with custom-deployed simple program with the crafted large accounts owned by the program.