EIP1035: Transaction execution batching and delegation

Question

EIP1035: Transaction execution batching and delegation

k06a opened this issue 6 years ago · comments

eip: EIP1035
title: Transaction execution batching and delegation
author: Anton Bukov (@k06a) k06aaa@gmail.com
discussions-to: k06aaa@gmail.com
status: Draft
type: Core
category: Core
created: 2018-04-25
updated: 2018-04-26
relates: #901

Simple Summary

It will be great to allow trustless delegated execution of the transactions inside EVM. I mean some account can sign target, call data, account nonce, network chain_id and pass them to any other, who will be able to perform this call and pay Ethereum fees like this:

target.authorizedcall(data, account , nonce, chain_id, signature)

This also will allow batching/chaining account transactions and many other features. One more use case: sender of any ERC20 tokens can signed necessary call and pass it to receiver, and receiver (exchange?) will be able to pay fees for this transaction.

Abstract

Abstract implementation of target.authorizedcall(data, account, nonce, chain_id, signature) method should perform:

Check nonce of the account to be valid
Check chain_id to be valid for this network
Check signature of target|data|nonce|chain_id and extract signer
Check signer is the same as account
Perform data call on target with msg.sender == account
Increment account nonce

Motivation

Ethereum fees is a real problem for some new users, who had some (bounty?) tokens and can't even spend this tokens without buying some ether.
Look at #827, #1003 – these protocols are trying to solve the problem of batching/chaining user transactions.

Specification

From solidity side this should looks like function on every smart contract:

function authorizedcall(bytes data, address account, uint256 nonce, uint256 chain_id, bytes signature);

Test Cases

Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.

Implementation

This is working example: https://github.com/bitclave/Feeless

Complete code:

import { ECRecovery } from "zeppelin-solidity/contracts/ECRecovery.sol";


contract Feeless {
    
    address internal msgSender;
    mapping(address => uint256) public nonces;
    
    modifier feeless {
        if (msgSender == address(0)) {
            msgSender = msg.sender;
            _;
            msgSender = address(0);
        } else {
            _;
        }
    }

    function performFeelessTransaction(address sender, bytes data, uint256 nonce, bytes sig) public payable {
        bytes memory prefix = "\x19Ethereum Signed Message:\n32";
        bytes32 hash = keccak256(prefix, keccak256(data, nonce));
        msgSender = ECRecovery.recover(hash, sig);
        require(msgSender == sender);

        require(nonces[msgSender]++ == nonce);
        require(address(this).call.value(msg.value)(data));
        msgSender = address(0);
    }
    
}

Usage:

contract MyToken is StandardToken, Feeless {

    string public constant symbol = "XXX";
    string public constant name = "MyToken";
    uint8 public constant decimals = 18;
    string public constant version = "1.0";

    function transfer(address _to, uint256 _value) public feeless returns (bool) {
        balances[msgSender] = balances[msgSender].sub(_value);
        balances[_to] = balances[_to].add(_value);
        Transfer(msgSender, _to, _value);
        return true;
    }

}

Signing call data:

const target = myToken.options.address;
const nonce = await myToken.methods.nonces(wallet1).call();
const data = await myToken.methods.transfer(wallet2, 5 * 10**18).encodeABI();
const hash = web3.utils.sha3(target + data.substr(2) + web3.utils.toBN(nonce).toString(16,64));
const sig = await web3.eth.accounts.sign(hash, wallet1PrivateKey);

Delegated execution by any other account:

await myToken.performFeelessTransaction(wallet1, target, data, nonce, sig).send({ from: wallet2 });

Micah Zoltu · Answer 1 · Wed Apr 25 2018 17:46:28 GMT+0800 (China Standard Time)

I would personally prefer this to be an EVM layer change, rather than contract layer. It feels silly that the person authorizing the transaction has to be the same person paying fees for the transaction. Miners care whether they get fees, they don't care about who they get fees from. Users care about other people not being able to use/spend assets under the control of their private keys, they don't care about how the transaction ends up in a block.

I would like to see transactions be two layers, the outer layer is signed by the fee payer and contains feePayerNonce, gasPrice, gasLimit, feePayerSignature, transactorNonce, to, value, data, transactorSignature. It would be even cooler if transactorNonce, to, value, data, transactorSignature was actually an array, for batching.

The above scheme would allow users to pay for "transaction submission services" off-chain via other mechanisms (e.g., monthly subscription, pre-paid, paid with fiat, add-on benefit to other services, etc.). It would also indirectly enable gas payments in non-eth if batching was supported, as the transactor executing the transaction could provide two signed transactions to the feePayer, one that transfers them some tokens and another that does the thing desired, with the nonce of the token transfer being one more than the nonce of the desired action. The feePayer can batch these two transactions together to effectively be paid in tokens, while miners are still paid in ETH. Alternatively, if the transactor is willing to enter into a trusted relationship with the feePayer then they could pre-pay for submissions via something like DAI.

Anton Bukov · Answer 2 · Thu Apr 26 2018 19:58:55 GMT+0800 (China Standard Time)

@MicahZoltu the more I think about this proposal the more I see this is the solution for tx batching to replace ERC827 (and ERC1003). Ethereum also can provide default smart contract (0x05?) for batching transactions with the methods like this:

function batchWithRequire(
    address account,
    address[] targets,
    bytes[] datas,
    uint256 firstNonce,
    uint256 chain_id,
    bytes[] sigs) public
{
    for (uint i = 0; i < targets.length; i++) {
        require(targets[i].authorizedcall(datas[i], account, firstNonce + i, chain_id, sigs[i]));
    }
}

Anton Bukov · Answer 3 · Mon Jun 25 2018 03:48:38 GMT+0800 (China Standard Time)

This EIP will help a lot in inter-chain development.

Sergey Ukustov · Answer 4 · Tue Jun 26 2018 01:17:34 GMT+0800 (China Standard Time)

Yay! That would greatly help with off-chain scaling schemes like state channels.

Philippe Castonguay · Answer 5 · Mon Jul 02 2018 22:30:05 GMT+0800 (China Standard Time)

Strongly related to #1077 by @alexvandesande. Have you considered collaborating on this one @k06a?

Anton Bukov · Answer 6 · Tue Jul 03 2018 02:41:05 GMT+0800 (China Standard Time)

@PhABC thanks, I'll dig into it!

Mohamed Amine LEGHERABA · Answer 7 · Sat Sep 01 2018 20:37:38 GMT+0800 (China Standard Time)

I agree with @MicahZoltu , I think we should allow any Ethereum transaction to have gas payment delegated, with no need of in contract function. I think this proposal is related to #1228 and #865 .

Roman Storm · Answer 8 · Sun Sep 02 2018 07:17:30 GMT+0800 (China Standard Time)

If someone is looking for ETH, ERC20 batch sender - feel free to use:
https://multisender.app

Cameron Sajedi · Answer 9 · Tue Jun 11 2019 22:41:09 GMT+0800 (China Standard Time)

I would personally prefer this to be an EVM layer change, rather than contract layer. It feels silly that the person authorizing the transaction has to be the same person paying fees for the transaction. Miners care whether they get fees, they don't care about who they get fees from. Users care about other people not being able to use/spend assets under the control of their private keys, they don't care about how the transaction ends up in a block.

I would like to see transactions be two layers, the outer layer is signed by the fee payer and contains feePayerNonce, gasPrice, gasLimit, feePayerSignature, transactorNonce, to, value, data, transactorSignature. It would be even cooler if transactorNonce, to, value, data, transactorSignature was actually an array, for batching.

The above scheme would allow users to pay for "transaction submission services" off-chain via other mechanisms (e.g., monthly subscription, pre-paid, paid with fiat, add-on benefit to other services, etc.). It would also indirectly enable gas payments in non-eth if batching was supported, as the transactor executing the transaction could provide two signed transactions to the feePayer, one that transfers them some tokens and another that does the thing desired, with the nonce of the token transfer being one more than the nonce of the desired action. The feePayer can batch these two transactions together to effectively be paid in tokens, while miners are still paid in ETH. Alternatively, if the transactor is willing to enter into a trusted relationship with the feePayer then they could pre-pay for submissions via something like DAI.

Is this EIP continuing? I am especially interested in details pertaining to the EVM change described above. It would simplify the creation of a retroactive metatransactions upgrade to all existing tokens and contracts. relevant to EIPs: 1776, 965, 985.

Micah Zoltu · Answer 10 · Wed Jun 12 2019 20:08:08 GMT+0800 (China Standard Time)

@AlexeyAkhunov has been pushing recently for changing the transaction protocol so it can evolve over time. It may be worth considering #1035 (comment) in that design.

Cameron Sajedi · Answer 11 · Mon Jun 17 2019 00:17:04 GMT+0800 (China Standard Time)

@MicahZoltu I stumbled upon this EIP while having similar discussions regarding enabling meta transactions on the Zilliqa blockchain. My overall goal is driving towards subscription-based recurring payments that would drastically benefit from transaction batching. I've linked your comment to justify work breaking out the messaging standard like so. In that regard, I'd like to stay in the loop and contribute as I can to the Ethereum effort. Kudos to you ETH guys for discussing and innovating in the open... Zilliqa really needs an EIP repository.

longduer · Answer 12 · Thu Aug 01 2019 15:53:18 GMT+0800 (China Standard Time)

what if the ERC20 token already existed,Could implement the feeless contract? if can ,how

Arjun Sasikumar · Answer 13 · Sat May 16 2020 07:20:20 GMT+0800 (China Standard Time)

import { ECRecovery } from "zeppelin-solidity/contracts/ECRecovery.sol";

contract Feeless {
address internal msgSender;
mapping(address => uint256) public nonces;

modifier feeless {
    if (msgSender == address(0)) {
        msgSender = msg.sender;
        _;
        msgSender = address(0);
    } else {
        _;
    }
}

function performFeelessTransaction(address sender, bytes data, uint256 nonce, bytes sig) public payable {
    bytes memory prefix = "\x19Ethereum Signed Message:\n32";
    bytes32 hash = keccak256(prefix, keccak256(data, nonce));
    msgSender = ECRecovery.recover(hash, sig);
    require(msgSender == sender);

    require(nonces[msgSender]++ == nonce);
    require(address(this).call.value(msg.value)(data));
    msgSender = address(0);
}
}
Usage:
contract MyToken is StandardToken, Feeless {
string public constant symbol = "XXX";
string public constant name = "MyToken";
uint8 public constant decimals = 18;
string public constant version = "1.0";

function transfer(address _to, uint256 _value) public feeless returns (bool) {
    balances[msgSender] = balances[msgSender].sub(_value);
    balances[_to] = balances[_to].add(_value);
    Transfer(msgSender, _to, _value);
    return true;
}
}
Signing call data:
const target = myToken.options.address;
const nonce = await myToken.methods.nonces(wallet1).call();
const data = await myToken.methods.transfer(wallet2, 5 * 10**18).encodeABI();
const hash = web3.utils.sha3(target + data.substr(2) + web3.utils.toBN(nonce).toString(16,64));
const sig = await web3.eth.accounts.sign(hash, wallet1PrivateKey);
Delegated execution by any other account:
await myToken.performFeelessTransaction(wallet1, target, data, nonce, sig).send({ from: wallet2 });

If all it takes is just one public address to delegate the transaction, how is the security maintained ?
What is stopping someone from delegating the transaction to random accounts ?

github-actions · Answer 14 · Wed Dec 08 2021 04:12:44 GMT+0800 (China Standard Time)

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

github-actions · Answer 15 · Wed Dec 22 2021 05:09:51 GMT+0800 (China Standard Time)

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

ogpadmin · Answer 16 · Thu Jul 18 2024 12:28:58 GMT+0800 (China Standard Time)

If anyone is looking to send ETH, tokens, and NFTs in batches, a good option is OGP Bulk Sender

EIP1035: Transaction execution batching and delegation

eip: EIP1035 title: Transaction execution batching and delegation author: Anton Bukov (@k06a) k06aaa@gmail.com discussions-to: k06aaa@gmail.com status: Draft type: Core category: Core created: 2018-04-25 updated: 2018-04-26 relates: #901

Simple Summary

Abstract

Motivation

Specification

Test Cases

Implementation

eip: EIP1035
title: Transaction execution batching and delegation
author: Anton Bukov (@k06a) k06aaa@gmail.com
discussions-to: k06aaa@gmail.com
status: Draft
type: Core
category: Core
created: 2018-04-25
updated: 2018-04-26
relates: #901