-
Notifications
You must be signed in to change notification settings - Fork 367
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
feat(gnoland): Define and implement SponsorTransaction concept #2630
base: master
Are you sure you want to change the base?
Conversation
I created a demo using gnokey to show how this feature works, assuming that the user (who wants to perform an on-chain action without paying gas fees) and sponsor (who covers all the gas fees) are on the same machine and use the same keybase. The steps and outputs are described below : Case where the user account already exists on-chain
The result is that the user's balance remains unchanged, and all transaction fees are deducted from the sponsor's balance Case where the user account does not yet exist on-chainThe steps are similar to the previous case (the difference being that the query results show that the user account does not yet exist on-chain) The result is that the user account has been created on-chain with a balance of 0, and the public key is set to the public key that the user used to sign the initial transaction |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2630 +/- ##
==========================================
+ Coverage 60.87% 61.04% +0.17%
==========================================
Files 563 563
Lines 75193 75357 +164
==========================================
+ Hits 45770 45999 +229
+ Misses 26055 25988 -67
- Partials 3368 3370 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
6cb0211
to
e2c19fc
Compare
Besides diversifying the test cases (unit tests, integration tests & txtar), i'm still figuring out how to clearly demonstrate the use case of this feature |
…to define-sponsorTx
…to define-sponsorTx
@moul Do you still have any concerns about the changes to this feature? Examples of sponsoring for multiple messages are available at https://github.com/gnolang/gno/blob/24c486f133f5274d3c253c6fa2653a90c1ca3299/gno.land/pkg/gnoclient/integration_test.go However, gnokey does not support creating multi-message transactions to demonstrate similar functionality |
Blocked by #2209
This PR performs the following tasks:
gnoclient
directory : remove redundant code, and write reusable functionsanteHandler
to allow the creation of a non-existent on-chain account if it is processed in a valid sponsor transaction (I need to review this part)gnoclient
: it is a type of transaction signed twice, first by the person who wants to perform the transaction, and second by the person sponsoring the gas for this transaction. A transaction is considered a sponsor transaction when it contains avm.MsgNoop
as the first message in the list of messagesgnokey
(I am not sure if this is necessary)gnokey
will be uploaded in the comments section belowFrom Proposal #2152 :
Before integrating this pull request (PR) into the main codebase, thorough testing and evaluation are crucial. Once verified, we can explore its integration into an external decentralized application (
sponsor service
) to cover gas fees for user transactionsInstead of users directly interacting with the blockchain (like sending tokens or calling specific Realm functions), they will engage with a
sponsor service
. Users will sign and send requests to thesponsor service
, which will handle all necessary checks for their on-chain address. If everything checks out, thesponsor service
will countersign the transaction, and cover the gas feesUpdates to the vm handler module: A NoopMsg has been defined in this PR to skip gas consumption calculation for messages bearing the dApp's signature. These modules will only process messages (e.g., Run, Call, AddPkg, Send) with user-provided arguments, tagging the caller as their on-chain address
At the conclusion of the process, users can filter events to track the outcomes effectively
Now we are finalizing the
sponsor service
implementation for the full-flow design described belowRelated Pull Requests:
I greatly appreciate everyone's feedback to improve this feature.
Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description