Intro: This proposal suggests implementing transaction sponsorship on the Massa blockchain, allowing dApp developers or third parties to cover transaction fees for users. This reduces barriers for non-crypto users and encourages broader dApp adoption, similar to Ethereum’s sponsorship mechanism.
Proposal Details:
Sponsored Transactions:
Users sign transactions verifying their intent; sponsors (dApp backends or third parties) pay the transaction fees.
The sponsor submits the transaction to the Massa network, ensuring execution without the user needing Massa coins.
Workflow Example:
Users interact with the dApp, signing a transaction.
The backend wraps and submits the transaction, paying the fee.
Use Cases:
IoT dApps: Users interact with IoT devices seamlessly while backend sponsors fees.
Gaming/E-commerce: Users pay in fiat, and the dApp covers the blockchain interaction.
Benefits:
Simplifies User Experience: Reduces friction for new users, especially those unfamiliar with crypto.
Encourages Adoption: Users can engage with dApps without needing to manage wallets or tokens.
Flexibility for Developers: Allows developers to control the impact of transaction fees on user experience.
Challenges:
Abuse Prevention: Safeguards needed to avoid exploitation of the sponsorship mechanism.
Cost Management: Tools for sponsors to monitor and limit transaction fee expenditures.
What do you think of this ? Any comments on feasibility, costs, or how to do this?
Probably a standard could be made. I’ll maybe formalize something if my thoughts about this are all straight.
Edit: In other words, an equivalent of ERC-4337 in Massa. This would allow Massa apps to be used for non-massa native users.
The sponsor submits the transaction to the Massa network
This is already doable today on Massa in the following way:
the target smart contract has a execute_user_request(request, public_key, signature) that can be called by anyone and does the following;
verifies the signature of the request with respect to the public key. This prevents the sponsor from altering the user request before sending it. The user is authenticated by their public key
executes whatever request was demanded by that user as long as it is safe and supported by the smart contract
then, the user just sends their signed request to their sponsor, who sends a new transaction that calls the smart contract’s execute_user_request function with the user provided data
The drawback is that the user relies on the sponsor forwarding their transaction. If the sponsor is offline at the moment, or simply refuses to forward a certain transaction, that transaction won’t go through. This adds a central point of failure that might be acceptable in some cases, not others.
Note that ERC-4337 is way more comprehensive than this.
What would be more powerful is to allow smart contracts to accept to sponsor some categories of incoming transactions. This needs filtering to avoid flood. But to implement those filters we hit a problem: Massa is high throughput, low resources. This means that block producers don’t have the power to simulate the execution of transactions before they include them, but still need to be certain they will get the associated fee to avoid denial of service attacks. This makes account abstraction tricky but not impossible to implement on Massa.
That seems like a nice approach.
Indeed user will replie fully on the sponsor. I was imagining that the “user” in my case could be devices and the sponsor is the user. That way, one user can sponsor as much devices he likes to interact with the chain.
It won’t fit the typical blockchain user, but these ideas could help me maybe make a PoC. I’ll have to see how far I’ll go in my free time.