Meta-Transactions support

[anthony-near]

CLI support for meta transactions as specified in NEP-366

Specific implementation TBD.

[frol]

@anthony-near I am happy to discuss how exactly we will integrate it into CLI. There are definitely a ton of opportunities here!

[anthony-near]

Based on the discussion with @frol there are 2 potential ways to implement this solution:

1. change config.toml to add a relayer RPC config where the RPC endpoint is changed to that of the relayer.
2. hit the normal RPC endpoint but using a relay_tx RPC method instead of tx_broadcast method

As far as the CLI flow is concerned, after the details of the tx are filled at the last step there will be an option that allows the user to choose whether to sign the tx or to send it to a relayer.

Personally do not have a preference whether we go with 1 or 2, but would like to get input from others. We could implement both eventually as well, but will start with choosing one of them.

[frol]

Just to give some context about both options:

The first option (1):

I expect the relayer to mimic the NEAR JSON RPC interface and just intercept broadcast_tx* functions while routing all the other RPC calls as-is. This way it is completely transparent to the CLI users and the gas fees are paid by the relayer. I think it could be a viable solution for "Pagoda+" if one would exist like Aurora+.

The second option (2):

Instead of requiring relayer node to be a transparent proxy we can define a completely independent API with just a couple of methods (blocking and non-blocking calls just like broadcast_tx* has) to relay a transaction, and then from CLI point of view, at the last step where we currently ask user for confirmation to send a transaction we can extend it with an option to send via relayer. Here is the current flow:

So in addition to send and print we can have send-via-relay (I believe we should consider how to frame it properly, as the current naming proposal is implementation-driven)

The second option is more explicit and I would probably go this route.

[firatNEAR]

I also think that the second option would be a better option for now. User could be explicit about sending the transaction via the relayer.

[frol]

@anthony-near @firatNEAR Meta-transaction support is implemented in #189! After some brainstorming with @FroVolod we decided to go with a fully-transparent mode, so users won't be bothered to make a choice whether to send it on their own or through a delegation relay. Given that near-cli-rs has support for several network-connection configs, "free transactions"-providers can offer users to set up a new connection like this:

near config \
    add-connection \
        --network-name testnet \
        --connection-name pagoda-testnet \
        --rpc-url https://near-testnet.api.pagoda.co/rpc/v1/ \
        --wallet-url https://wallet.testnet.near.org/ \
        --explorer-transaction-url https://explorer.testnet.near.org/transactions/ \
        --rpc-api-key 'c0a25b3c-39c2-4f62-a621-50e208b88e64' \
        --linkdrop-account-id testnet \
        --faucet-url https://helper.nearprotocol.com/account \
        --meta-transaction-relayer-url https://near-testnet.api.pagoda.co/relay

(Note that --meta-transaction-relayer-url is not a real service, I made this URL up for the demo purposes)

When the network-connection is configured and has meta-transaction-relayer-url, all the transactions submitted through this network-connection will be submitted through the relayer:

Notice that once "meta-testnet" was selected, the hint messages were turned to refer to signing and sending "delegate action" instead of a "transaction".

There are no relayer services I am aware of that support this relayer protocol ({"signed_delegate_action": "base64-encoded-string-of-borsh-serialized-signed-delegate-action"}, so it is not a surprise that it failed with "Request failed with status code: 422 Unprocessable Entity". Here is how you can, however manually relay the delegated action with near-cli-rs:

1. Prepare the delegate action from frol14.testnet to frol13.testnet:

2. Relay the signed delegate action (base64-encoded borsh-serialized delegate action) by qq.frol10.testnet: