Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consensus upgrade to modify the restrictions on RAM billing #6105

Closed
arhag opened this issue Oct 23, 2018 · 2 comments

Comments

Projects
None yet
1 participant
@arhag
Copy link
Contributor

commented Oct 23, 2018

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 #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 arhag added the HARDFORK label Oct 23, 2018

@arhag

This comment has been minimized.

Copy link
Contributor Author

commented Dec 7, 2018

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 arhag added CONSENSUS and removed HARDFORK labels Mar 22, 2019

@arhag arhag changed the title Consensus upgrade to objectively restrict RAM billing within a notify context Consensus upgrade to modify the restrictions on RAM billing Apr 15, 2019

arhag added a commit that referenced this issue Apr 15, 2019

fix api_tests/ram_billing_in_notify_tests to not activate RAM_RESTRIC…
…TIONS; fix api_tests/deferred_transaction_tests to catch the right exception given RAM_RESTRICTIONS activation #6105

arhag added a commit that referenced this issue Apr 15, 2019

disable_all_subjective_mitigations now disables the subjective mitiga…
…tion preventing RAM billing in notification contexts #6105

@arhag arhag referenced this issue Apr 16, 2019

Merged

Implement RAM_RESTRICTIONS protocol feature #7131

1 of 3 tasks complete
@arhag

This comment has been minimized.

Copy link
Contributor Author

commented Apr 18, 2019

Resolved by #7131.

@arhag arhag closed this Apr 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.