Consensus upgrade to modify the restrictions on RAM billing

[arhag]

Background

In the v1.2.3 release of EOSIO, an optional subjective mitigation was introduced (#5451) which if enabled would (during block production only) completely disallow any operation in an action executing under a notify context (i.e. when receiver != code) which would cause the RAM usage of any account other than receiver to increase. An exception is made to this restriction if the receiver is privileged.

The "feature" of allowing an action executing under a notify context to bill RAM to authorizers of the original action turned out to be undesirable in practice since it led to malicious contracts abusing the feature to charge RAM to users in ways they did not intend. While there are legitimate uses for the feature that some contracts have utilized, it appears to be for the better to disable this "feature" especially considering that there are better alternative patterns to do the things most contracts were using this feature to do (accepting token deposits). For EOSIO blockchains where all the active block producers have enabled the subjective mitigation, the "feature" is already effectively disabled. However, it is still desirable to make the change objective with a consensus upgrade.

Additionally, contract developers may have come across a limitation of the existing protocol rules in which they are unable to migrate rows of an existing table to a new table while preserving the existing RAM payers of the row, even though the total RAM usage to each of the payers does not increase. This is because any database operation that causes an increase in RAM usage for an account requires that the account authorize the action in which that operation occurred, even if the remainder of database operations in that action would result in a net decrease in RAM usage of the account.

Consensus protocol upgrade feature

The goal of this consensus protocol upgrade feature (codename: RAM_RESTRICTIONS) is to change the restrictions regarding when authorizations from accounts are required on an action which modifies the database entires for which those accounts are paying the RAM to achieve two objectives:

1. disallow an unprivileged contract that is executing an action under a notify context from increasing the RAM usage of accounts other than itself (thus making the subjective restriction of Subjectively fail transaction if contract bills RAM to another account within a notification handler #5451 obsolete);
2. making the RAM billing rules more flexible to enable contracts to do things like migrating table rows paid by other accounts while still protecting the RAM payers from being charged additional RAM without their authorization.

Rather than simply making the subjective checks of #5451 objective, this proposal aims for a more flexible restriction that achieves the same goals of #5451. So, when RAM_RESTRICTIONS is activated, the subjective mitigation of #5451 will be disabled since it will no longer be necessary and would in fact interfere with the safe flexibility introduced with the RAM_RESTRICTIONS protocol feature.

After RAM_RESTRICTIONS activation, an unprivileged contract executing an action would now be free to do operations that increase the RAM usage of any account as long as the following restrictions are satisfied:

• At the end of the action, any contract other than the receiver that has a net RAM usage increase must have authorized the action (no accounts are considered to authorize an action in a notify context).
• Scheduling a deferred transaction with a payer other than receiver is only allowed within an action that has been authorized by the payer and is not in a notify context.

The second limitation is in place to avoid changing the expectations for when RAM will be returned to a user that authorized an action which schedules a deferred transaction. A user that audits a smart contract could determine that an action would schedule a deferred transaction to execute at the earliest at a certain time, expire ten minutes after that earliest time, and charge them a certain number of bytes of RAM that would be returned when the deferred transaction retires (perhaps by expiration). But if a contract could replace that transaction without the authorization of the user and continue billing them the same amount, then reserved RAM could be held indefinitely. Even if the contract did not do that initially, it could be replaced later (but before the earliest execution time for the deferred transaction) to do it. So the safest thing to do is to require the authorization of any payer of a scheduled deferred transaction.

The above scenario does not really apply in the case of regular RAM billing for table rows because the expectation of the user in that case is that the RAM consumed will be reserved until the smart contract (which could potentially be changed) chooses to release it. So an action without the authorization of a particular RAM payer should still be allowed to change the data structures that are billed to that RAM payer as long as the total RAM usage of that payer does not increase.

[arhag]

This issue depends on #6429. It will also be setup by default to be a protocol feature requiring pre-activation, thus it also depends on #6431.

[arhag]

Resolved by #7131.