Meta transaction pallet

[shunsukew]

Substrate can have meta-transaction pallet so users can execute calls without paying extrinsic fees.

What is meta transaction
Meta transactions are a way of processing transactions on blockchains without requiring the user to pay gas fees. Instead, a third party, such as a relayer, pays the gas fees on behalf of users. In other words, separating transaction signer and payer(sender) of the actual cost needed for processing transactions. This can be useful in scenarios where users may not have enough tokens to cover the cost of gas fees or where gas prices are high. This also can improve UX for new users with no funds to use Dapps on blockchains since it can omit processes for them to purchase or get tokens in some ways and brings easy onboarding.

Terminologies definition in this discussion thread

• Signer: Signer of the signature who wants to execute RuntimeCall without paying extrinsic fee.
• Sender: Actual users' accounts who receive signed data and signature from signer, and execute the call (cover extrinsic fee).

Design
This is just an idea for initiating discussion.

pub fn meta_call(
    origin: OriginFor<T>,
    signer: T::AccountId,
    signature: Vec<u8>,
    #[pallet::compact] nonce: T::Index,
    call: Box<<T as Config>::RuntimeCall>,
) -> DispatchResultWithPostInfo

(and also chain_id?)

1. Signer signs to Call and nonce tuple (nonce, RuntimeCall)
2. Signer sends request data (nonce, RuntimeCall) together with signature he/she gets at the step 1 to Sender (Relayer service).
3. Sender executes meta_call Extrinsic.
4. Validate signature and nonce on the pallet.
5. Dispatch Call with Origin::Signed(signer) (not sender) after validation.

In generic smart contract blockchains, this can be done by using contracts.
But using a pallet has advantages

• All substrate based blockchains (without frontier/evm pallets or pallet-contracts) can use it.
• Multiple signature schemes are available (ecdsa, sr25519, ed25519) while contracts are not.
• In smart contract context, Caller AccountId of the objective contract signers wants to call is always signers' AccountId. In the contracts approach, because we need Forwarder contract in-between, caller AccountId of that is Forwarder contract AccountId. This requires workarounds/adjustments for contracts developers, in Ethereum case, such as ERC20-permit, ERC721-permit, EIP 2771

But still, to be used widely, we need relayer service which receives requests from signers and send extrinsics on behalf of them outside of Substrate nodes.

[bkchr]

Duplicate of: https://github.com/paritytech/substrate/issues/11988

[shunsukew]

I see, thank you so much for pointing me to the issue.