[LSP1] Gas Limit for Universal Receivers

[YamenMerhi]

Gas Limit for Universal Receivers

Problem

A primary concern for individuals interacting with contracts utilizing the LSP1 universalReceiver(..) function is the potential for significant gas consumption on the contract being notified. In such scenarios, the transaction initiator (referenced by tx.origin) bears the high gas fees due to the logic executed in the notified contract.

Example

To illustrate, consider a scenario where a user transfers a token. The token contract, in turn, notifies the recipient via the universalReceiver(..) function. If this function contains complex logic, it could result in substantial gas consumption, forcing the sender to pay very high transaction fees.

How this problem is supposed to be solved ?

[YamenMerhi]

Solution

A viable solution to the high gas consumption challenge posed by the universalReceiver(..) function lies in social consensus.

Example

Consider a scenario: User A wishes to transfer a token to User B. If User A's off-chain client (e.g., a browser extension or mobile app) detects that User B's universalReceiver function consumes an exorbitant amount of gas, User A can be prompted with a warning. This warning would inform User A of the high gas costs associated with the transaction and seek confirmation on whether they wish to proceed.

In this setup, User B stands at a disadvantage if their universalReceiver function is gas-intensive, as they are the primary beneficiary of the token transfer. If User A decides against the transfer due to high gas costs, User B misses out.

It's essential to recognize that some solutions, like hardcoding a gas limit for the universalReceiver function, may not be feasible. Such restrictions could stifle potential use cases that require higher gas amounts. Moreover, with the evolving landscape of blockchain scalability, it's uncertain what future functionalities the universalReceiver might encompass. Imposing restrictive measures could inadvertently limit its potential.

Several alternative solutions exist:

Gas Reimbursement: The recipient's universalReceiver function could be designed to reimburse the gas costs. If it doesn't, the sender might opt not to proceed with the transaction.

Delegated Execution: The sender could sign a message, allowing the intended recipient to execute the action. This way, the recipient bears the gas costs and any additional load their universalReceiver function might introduce.

In essence, leveraging off-chain clients to provide users with real-time feedback on potential gas costs, combined with the power of social consensus, can offer a practical solution to this challenge.

Note: There are scenarios where enforcing a changeable gas limit becomes crucial. Some protocols or token contracts might implement this. For instance, in protocols where the token burn isn't controlled by the token owner but by the protocol owner (e.g., a rented NFT), it's vital for the protocol owner to notify the token owner of an impending burn. Yet, it's equally important not to provide unlimited gas for this notification. If given unchecked gas limits, a malicious token owner could intentionally block the execution by consuming all the gas, hindering the protocol's operations.

[CJ42]

A bit of background on the issue as well for history.

The initially thoughts before coming to these conclusions were to think of making the call to the LSP1 Delegate contract capped, while not reverting the whole transaction if the cap is reached.

There was also the need to assess what would be the behaviour in an implementation code if a fixed amount of gas is forwarded, but the LSP1 Delegate on the sender + receiver end reverts.