Mechanism to ensure sufficient resources

[Stebalien]

Background

Currently, there's no way for some actor A to call some other actor B while ensuring that B has some minimum required resources (memory and stack depth).

For example, given actors A, B, and C:

1. A calls B.
2. B calls C.
3. C fails, claiming it ran out of stack.

At the moment, there's no (efficient) way for B to know if C is lying, or if A called B with very little call stack space remaining.

This becomes important when B needs to know if it should:

1. Ignore the failed call to C (e.g., because it believes C has a bug, etc.).
2. Fail because it wasn't called (by A) with enough resources to complete the operation.

At the moment, a "safe" contract needs to assume (2).

Proposal

Add a flag to the "send" syscall to assert that there must be room for at least N (256?) recursive calls and at least M (256 or 512?) MiB of memory left.

Given our scenario above, this would allow B to call C while ensuring that it's giving C the minimum required resources

Alternatives

Send Flags versus Resource Usage Getters

An alternative to send flags is to provide some way to ask the system for the current memory used and/or current stack depth.

I'm proposing a flag because:

1. It saves us at least one syscall. The stack depth could be exposed in the invocation context, but the user would have to ask the system for the current memory remaining every time.
2. It's more accurate, at least when checking available memory. There's no way to accidentally allocate between checking the available memory and calling the target actor.
3. It's more convenient.

However, there are good reasons to just expose an available_memory syscall:

1. Some algorithms may want to make gas/memory trade-offs. However, memory allocation failures are technically recoverable in WASM so an available_memory syscall isn't strictly-speaking necessary here.
2. It's more flexible.

Really, I could be convinced either way.

[Kubuxu]

What is the threat model we are assuming here? Because if the C contract can be malicious, then C can just maliciously run out of memory or call stack.

[Stebalien]

Because if the C contract can be malicious, then C can just maliciously run out of memory or call stack.

That's fine. The problem is that either A or C can be malicious (or just buggy), and we need to know whom to blame. I.e.:

1. With this mechanism, B can just ignore the failure from C and say "well, I tried".
2. Without this mechanism, B can't just ignore the failure because the failure may not have been C's fault. Instead, A could have forced the failure.

[anorth]

Thanks for writing this up. Right now I'm not convinced either that we need it, or which way is better. I understand some of the hypothetical situations that give rise to this thinking, but none are concrete enough for me just yet. This could change if we realise that something like this is necessary to implement any version of, say, user-programmable markets, but I currently don't expect this to be the case.

This is a great discussion to start, but to devote more energy I think we need more concrete use cases needing it, and an exploration how other smart contract environments have solved or avoided the stated problem.

[Stebalien]

This is one step towards implementing programmable markets where the the storage provider doesn't need to trust the client. However, it's not sufficient. That would require a pure version of authenticate-message.

[arajasek]

I'm inclined to agree with @anorth here until a clear motivation is provided. Right now this just strikes me as something "neat" to be able to do, but I'm not jumping to make it happen. I could very well believe that we will eventually be required to do this, but I'm happy for us to wait until then.

Of the two presented options, I have a strong-ish preference for making this a flag on the Send syscall, and not just exposing the information. It's cleaner, and much less open-ended, which I think is a good thing (I'm not convinced the "flexibility" of Option 2 is much of an advantage).