Handle Gas-Limit-Attack

[Latrasis]

We need to look into if we can address a gas-limit-attack. https://github.com/zmitton/eth-heap

[JakeOShannessy]

From my understanding of that repo, the problem is that if your contract code exposes an API that allows a malicious actor to add data to a data structure in your system, and the use of that data structure requires some kind of iteration, then they can fill the data structure, making it unusable due to the block gas limit.

In the kernel we have 2 iterable data structures: the procedure list and the capability list, however, neither of them are ever iterated by the kernel, they are iterated by the user only as a query (in which case we can do it locally for free). Everything else in the kernel is either constant time, or only exponential on a user's transaction data. So it's not a problem within the kernel.

If we are talking about protecting user code against this, I'm not sure that we can do that using only the kernel. The only thing I could think of doing with the kernel would be to limit the amount of storage that could be used by a procedure, but that's covered by the Write capability in a least one way.

Is that an accurate assessment?

[Latrasis]

@JakeOShannessy: Yes, from the Kernel Side, based on the Draft Spec #113, as you mention most syscalls are covered against gas-limit attacks. The only syscalls not covered is proc_call and tx_send.

As a disambiguation, assuming all procedures are safe, if there is an attack of some sort it would either be:

1. A malicious external account making a call to the kernel to make illegal changes. (proc_call)
2. A malicious external account being called from the kernel to make illegal changes. (tx_send)
3. A malicious procedure being called from the kernel to make illegal changes. (proc_call)