NEP-417: Meta transactions #417
Conversation
Squashed commit of the following:
commit 06ea3bbcbf7387923d7ced70de55fadc2391be21
Author: Illia Polosukhin <ilblackdragon@gmail.com>
Date: Fri Jun 24 06:57:01 2022 -0400
More text fixes
commit 3901b139e1f97b94a3df95eba566476cc7a41491
Author: Illia Polosukhin <ilblackdragon@gmail.com>
Date: Fri Jun 24 06:51:51 2022 -0400
Move details of the DelegateAction from Actions.md to the proposal. Add the flow of data
commit cd576a5bd382957566fc2d9611a13cdcaa3c91e1
Author: Illia Polosukhin <ilblackdragon@gmail.com>
Date: Thu Jun 23 16:01:40 2022 -0400
Adding PR number
commit c9ee1e6f7d7ab96a12cad0a59a97855ae5c61d06
Author: Illia Polosukhin <ilblackdragon@gmail.com>
Date: Thu Jun 23 08:38:51 2022 -0400
Adding a lot more details for DelegateAction design
commit 9142bf9fb262927afd1ade75e5f9ffa91370b790
Author: Illia Polosukhin <ilblackdragon@gmail.com>
Date: Tue Jun 21 17:18:51 2022 -0400
Initial commit for meta tx standard
There was a problem hiding this comment.
Thanks @e-uleyskiy. This looks like a great start. My comments are generally minor. They should help someone less familiar with the proposal understand it better.
|
|
||
| The main flow of the meta transaction will be as follows: | ||
| - User requests the relayer for its access key (public key) which the relayer are going to use. The user specifies this key as `relayer_pub_key` in `DelegateAction`. | ||
| - User fetches the relayer's access key `nonce`, increments it and assigns the value to `relayer_nonce` in `DelegateAction`: `relayer_nonce = nonce + 1`. |
There was a problem hiding this comment.
Will the relayer have one nonce per user? If not, then a relayer can only work with one user at a time. This will have lower throughput and a potential attack vector where the user can request the nonce from the relayer and never send the subsequent transaction.
There was a problem hiding this comment.
Actually the implementation of the relayer node is up to developers, I think. But if you want me to describe it in this NEP, I will do. Bellow are my thoughts:
A relayer should have one nonce per access key. And one access key per user. A relayer can import a lot of access keys to its account and schedule them between users.
the user can request the nonce from the relayer and never send the subsequent transaction
The relayer can reserve an access key for some time. When this time ends, other users can use this key.
And one important thing, the user requests access key/public key, not nonce.
There was a problem hiding this comment.
I agree that the implementation of the relayer node will be up to the developers. And I suppose a NEP is not the right place to provide best practices for developers either. However, I felt that fellow developers who are interested in building a relayer would be curious about this point. For me personally, just this conversation should suffice and I don't think we need to add more text to the NEP.
| - User forms `SignedDelegateAction` with the `DelegateAction` and the `DelegateAction` signature. | ||
| - User forms `DelegateActionMessage` with the `SignedDelegateAction`. | ||
| - User sends `DelegateActionMessage` data to the relayer. | ||
| - Relayer verifies actions specified in `DelegateAction`: the total cost and whether the user included the reward for the relayer. |
There was a problem hiding this comment.
- Should we clarify how a user may include the reward given that the user may not have any NEAR tokens yet.
- Is there an attack vector where the relayer can keep the reward and not finish the transaction? Will the user have any recourse there or will users generally have to trust relayers.
| - Relayer forms a `Transaction` with `receiver_id` equals to `delegate_action.sender_id` and `actions: [SignedDelegateAction { ... }]`. Signs it with its key. Note that such transactions can contain other actions toward user's account (for example calling a function). | ||
| - This transaction is processed normally. A `Receipt` is created with a copy of the actions in the transaction. | ||
| - When processing a `SignedDelegateAction`, a number of checks are done (see below), mainly a check to ensure that the `signature` matches the user account's key. | ||
| - When a `Receipt` with a valid `SignedDelegateAction` in actions arrives at the user's account, it gets executed. Execution means creation of a new Receipt with `receiver_id: AccountId` and `actions: Action` matching `receiver_id` and `actions` in the `DelegateAction`. |
There was a problem hiding this comment.
Should we clarify what we mean by "user's account" here? If I understand things properly, users may not have accounts yet.
|
|
||
| ## Summary | ||
|
|
||
| In-protocol meta transactions allowing for third-party account to initiate and pay transaction fees on behalf of the account. |
There was a problem hiding this comment.
nit: I wonder if this feature should be called delegate transactions instead of meta transactions. I feel like that is a more precise name.
|
@e-uleyskiy Thanks for the NEP! The following parts should be added into the NEP:
|
|
Hey @e-uleyskiy, thank you for submitting this NEP. Since this is a continuation of #366, could you please submit a pull request to change 366 and close 417? This way we can keep the content and discussion centralized in one NEP. Thank you very much. |
|
@ori-near |
frol
added
A-NEP
|
Close this pull request. Need to discuss more about this approach. |
ori-near
added
S-rejected
|
Moved this to Rejected since this is a duplicate/continuation of #366. |
Summary
This is a fork of NEP-366. Main changes:
DelegateActionandDelegateActionMessageformats are changed.I will attach a diagram a little bit later.