Comments (2)
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.
from lips.
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.
from lips.
Related Issues (20)
- [UP Extension] Add Compatibility for multiple Web3-Extensions HOT 4
- [LSP6] Add EIP-1271 verification mechanism for relay calls
- Add gas limit to calls of a controller with only SUPER_TRANSFERVALUE permission HOT 1
- Differentiating between a Deleted Data Key and an Unset Data Key HOT 1
- [LSP2] CompactBytesArray - complete technical overview with examples HOT 6
- [LSP2] Tuple encoding HOT 1
- [LSP0] Improve LSP0 Anti-Phishing by Adding Transfer Delay HOT 3
- [LSP24] Multichain Address Resolution HOT 5
- [LSP11] SocialRecovery Improvement HOT 8
- [LSP25] Execute Relay Call as its own standard (extracted from LSP6)
- [LSP4] Add Background image field to LSP4 JSON Metadata HOT 4
- [LSP7,LSP8] Non-transferable flag HOT 1
- Remove `JSONURL` and only use `AssetURL`?
- Add Currency Symbol (Ŀ) For Lukso
- [LSP2] Add `contract` / `Contract` as a valid valueType + valueContent
- [LSP8] Discussion - truncation of `bytes32` tokenId for keyTypes Mapping
- ..
- [LSP8] Define if `0x` prefix should be added to `LSP8MetadataBaseURI` HOT 1
- Icon Request: icon-lyx HOT 18
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lips.