NEP-366: Meta transactions

README.md

@@ -25,6 +25,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement
 |[0245](https://github.com/near/NEPs/blob/master/neps/nep-0245.md)   | Multi Token Standard | @zcstarr @riqi @jriemann @marcos.sun | Review |
 |[0297](https://github.com/near/NEPs/blob/master/neps/nep-0297.md)   | Events Standard | @telezhnaya | Final |
 |[0330](https://github.com/near/NEPs/blob/master/neps/nep-0330.md)   | Source Metadata | @BenKurrek | Review |
+|[0366](https://github.com/near/NEPs/blob/master/neps/nep-0000.md) | Meta Transactions | @ilblackdragon | Draft |
 
 
 

neps/nep-0366.md

@@ -0,0 +1,148 @@
+---
+NEP: 366
+Title: Meta Transactions
+Author: Illia Polosukhin <[email protected]>
+DiscussionsTo: https://github.com/nearprotocol/neps/pull/366
+Status: Draft
+Type: Protocol Track
+Category: Runtime
+Created: 21-Jun-2022
+---
+
+## Summary
+
+In-protocol meta transactions allowing for third-party account to initiate and pay transaction fees on behalf of the account.
+
+## Motivation
+
+NEAR has been designed with simplicity of onboarding in mind. One of the large hurdles right now is that after creating an implicit or even named account the user does not have NEAR to pay gas fees to interact with apps.
+
+For example, apps that pay user for doing work (like NEARCrowd or Sweatcoin) or free-to-play games.
+
+[Aurora Plus](https://aurora.plus) has shown viability of the relayers that can offer some number of free transactions and a subscription model. Shifting the complexity of dealing with fees to the infrastructure from the user space.
+
+## Rationale and alternatives
+
+Proposed here design provides the easiest for users and developers way to onboard and pay for user transactions.
+There is no requirement on the user account, including user account may not even exist on chain and implicit account can be used.
+
+An alternative is proxy contracts deployed on the user account.
+This design has severe limitations as it requires user to deploy such contract and additional costs for storage.
+
+## Specification
+
+The main flow of the meta transaction will be as follows:
+ - User will sign `DelegateActionMessage` specifying set of actions that they need to be executed. It also includes specific relayer to ensure secure execution.
+ - User sends signed `DelegateAction` data to the relayer
+ - Relayer forms a `Transaction` with `receiver_id` equal to the user's account and `actions: [DelegateAction { ... }]`, and signs it with it's key. Note, that such transaction can contain other actions toward user's account (for example calling a function).
+ - This transaction is processed normally, by creating a receipt with copy of the all the actions into the `Receipt`.
+ - When processing `DelegateAction` a number of checks are done (see below), mainly `signature` matching user account's key.
+ - When such `Receipt` with valid `DelegateAction` in actions arrives to the user's account it gets executed. The executed means creation of a new Receipt with `receiver_id: AccountId`, `actions: Action` matching `receiver_id` and `actions` inside `DelegateAction`. 
+ - The new `Receipt` looks like normal receipt that would have been originating from user's account, with `predeccessor_id` equal to user's account.
+
+### DelegateAction
+
+Delegate action allows for an account to initiate a batch of actions on behalf of the receiving account, allowing to proxy actions. This is used in implementation of meta transactions.
+
+```rust
+pub struct DelegateAction {
+    /// Receiver of the delegated actions.
+    receiver_id: AccountId,
+    /// List of actions to be executed.
+    actions: Vec<Action>,
+
+    /// Public key that is used to sign this delegated action.
+    signer_pk: PublicKey,
+    /// Nonce is used to determine that the same delegate action is not sent twice by relayers and should match for given account's `signer_pk`. 
+    /// After this action is processed it will increment.
+    nonce: Nonce,
+    /// Signature of the originating user signing `DelegateActionMessage` formed out of the data in the `DelegateAction`.
+    signature: Signature,
+}
+```
+
+ Supporting a batch of `actions` means `DelegateAction` can initiate a complex steps like creating a new account and transferring funds, deploying a contract and executing an initialization function.
+
+***Validation***:
+To ensure that `DelegateAction` is correct, on receival the verification of signature is done: `verify_signature(hash(message), signer_pk, signature)`.
+
+The `message` is formed in the next format and must be signed by the user:
+```rust
+struct DelegateActionMessage {
+    /// If not None, should match the `predecessor_id` that have created `DelegateAction`.
+    sender_id: Option<AccountId>,
+    /// Matching the given account_id.
+    signer_id: AccountId,
+    /// Matching the `signer_pk` from `DelegateAction`.
+    public_key: PublicKey,
+    /// Nonce for the given `public_key` from `DelegateAction`.
+    nonce: Nonce,
+    /// Matching the `receiver_id` from `DelegateAction`.
+    receiver_id: AccountId,
+    /// Block hash to ensure validity.
+    /// Actions matching `actions` from `DelegateAction`.
+    actions: Vec<Action>,
+}
+```
+
+The next set of security concerns are addressed by this format:
+ - If format matches `Transaction`, the relayer can just send it directly, not receiving payment.
+ - Because set of actions can include pay back to the relayer (for example by paying in FT), the `sender_id` is added directly into the message to ensure that nobody else can send this message.
+ - `nonce` is included to ensure that this message can't be replayed again.
+ - `public_key` and `signer_id` are needed to ensure the on the right account, work across rotating keys and fetch correct `nonce`.
+
+The permissions are verified based on kind `AccessKeyPermission` of `signer_pk`:
+ - `AccessKeyPermission::FullAccess`, all actions are allowed.
+ - `AccessKeyPermission::FunctionCall`, only a single `FunctionCall` action is allowed in `actions`. 
+    - `DelegateAction.receiver_id` must match to the `account[public_key].receiver_id`
+    - `DelegateAction.actions[0].method_name` must be in the `account[public_key].method_names`
+
+***Outcomes***:
+- If `signature` matches receiver's accounts `signer_pk`, new receipt is created from this account with set of `ActionReceipt { receiver_id, action }` for each item in `actions`. 
+
+#### Errors
+
+**Validation Error**
+- If `signer_pk` does not exist for the given account, the following error will be returned
+```rust
+/// Signer key for delegate action is missing from given account
+DelegateActionSignerDoesNotExist
+```
+
+- If `nonce` does not exist match `signer_pk` for  `receiver_id`, the following error will be returned
+```rust
+/// Nonce must be account[signer_pk].nonce + 1
+DelegateActionInvalidNonce
+```
+
+- If `signature` does not match to the data and `signer_pk` of the given key, the following error will be returned
+```rust
+/// Signature does not match the provided actions and given signer public key.
+DelegateActionInvalidSignature
+```
+
+
+See the [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for details.
+
+## Security Implications
+
+Delegate actions do not override `signer_pk`, leaving that to the original signer that initiated transaction (eg relayer in meta transaction case). Although it is possible to override `signer_pk` in the context with one from `DelegateAction`, there is no clear value to do that.
+
+See ***Validation*** section in [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for security considerations around what user signs and validation of actions with different permissions.
+
+## Drawbacks
+
+Increases complexity of the the NEAR's transactional model.
+
+Meta transactions take an extra block to execute, as they first need to be included by the originating account, then routed to the delegate account and only after that to the real destination.
+
+Delegate actions are not programmable as they require having signatures. Original proposal contained a new `AccessKey` kind that would support programmable delegated actions. On the other hand, that would be limiting without programmability of smart contracts, hence that idea evolved into [Account Extensions](https://github.com/nearprotocol/neps/pull/346).
+
+## Future possibilities
+
+Supporting ZK proofs instead of just signatures can allow for an anonymous transactions, which pay fees to relayers in anonymous way.
+
+## Copyright
+[copyright]: #copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

specs/RuntimeSpec/Receipts.md

@@ -1,6 +1,6 @@
 # Receipt
 
-All cross-contract (we assume that each account lives in it's own shard) communication in Near happens trough Receipts.
+All cross-contract (we assume that each account lives in it's own shard) communication in Near happens through Receipts.
 Receipts are stateful in a sense that they serve not only as messages between accounts but also can be stored in the account storage to await DataReceipts.
 
 Each receipt has a [`predecessor_id`](#predecessor_id) (who sent it) and [`receiver_id`](#receiver_id) the current account.