Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Consensus upgrade to modify the restrictions on RAM billing #6105
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
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:
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
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.