Large event payloads unsafe?

Question

Premise

1. Substrate will, by default, store every event in a block in a storage value Event of type Vec<EventRecord> in the system module, which involves reading & writing this full vector each time, as explained here https://stackoverflow.com/questions/57219830/what-is-the-cost-of-event-storage-in-substrate.
2. The time it takes to read/write to the database increases with the size of the object being read, at least eventually in expectation.

Problem

If an extrinsic emits an event with has some payload with some size, say like a user provided Vec<u8>, then an attacker can submit a series of such extrinsics, radically increasing the size of this vector, and as a result making the real computational weight of all subsequent extrinsics in that same block much greater than what is reported by their weight functions, and also no fee is paid for this computation. In essence all weight functions for those extrinsics are wrong now. This problem increases in severity independently with block weight/length limits, and the size of individual events, because both independently can be used to bloat the size of Events.

Unfortunately, it's also in practice not feasible to opt out of the default behavior in the System module, as there is no storage of logs or events in Substrate that can be exposed to the myriad of tools that need to inspect this, they all rely on storage state snapshots in archival nodes.

Questions

1. Is this an accurate summary?
2. How was it determined that this is already not a problem in Polkadot or Kusama?

Answer 1

Substrate will, by default, store every event in a block in a storage value Event of type Vec in the system module, which involves reading & writing this full vector each time, as explained here https://stackoverflow.com/questions/57219830/what-is-the-cost-of-event-storage-in-substrate.

You don't read the entire vector every time in the runtime. Instead we have this specialized append function. This takes the value on the host side, appends your new data and puts back the value.

With the old state trie implementation it could lead to problems for Parachains, because in the next block when we delete the events they could may end up in the storage proof. However, with the new state trie implementation state_version = 1 this isn't a problem any more.

The time it takes to read/write to the database increases with the size of the object being read, at least eventually in expectation.

These read/writes are also not done in the database. No write while executing a block in Substrate is ever going directly to the database. Writes are always being stored in the Overlay. Any further read of a value that was written will also be answered by the Overlay. As this Overlay is in memory the access to it is "free" when seen from the benchmarking perspective.

If an extrinsic emits an event with has some payload with some size, say like a user provided Vec, then an attacker can submit a series of such extrinsics, radically increasing the size of this vector, and as a result making the real computational weight of all subsequent extrinsics in that same block much greater than what is reported by their weight functions, and also no fee is paid for this computation. In essence all weight functions for those extrinsics are wrong now. This problem increases in severity independently with block weight/length limits, and the size of individual events, because both independently can be used to bloat the size of Events.

Given my statements above, the problem statement is not really true. However, you could start by only storing the hash of some data in the event. Why store the full data? The full data can be restored from the state if needed. Then appending an event should always be constant time. This mainly depends on the system allocator on how fast it can allocate memory and if allocating memory will take more time with more memory.

Answer 2

If an extrinsic emits an event with has some payload with some size, say like a user provided Vec<u8>, then an attacker can submit a series of such extrinsics, radically increasing the size of this vector
...
How was it determined that this is already not a problem in Polkadot or Kusama?

Developers pay attention to never put user-provided unbound data directly into events.

It is smarter, as noted above, to only use hashes. This holds generally for all on-chain data; don't use the data itself but rather hashes wherever possible.
This keeps on-chain data small and cheap to scale.
If you still need to store blobs of data, you can use the preimage pallet.