The gas-less feature

[jjyr]

Abstract

The gas fee is preventing new users step into the web3 world. Users must learn to get the native token(CKB or ETH) before playing a blockchain game or exchanging tokens with a DEX. The gasless feature can provide a way for developers to sponsor transaction fees for users to give them a smooth experience.

There are several solutions built on Ethereum:

GSN

1. not wildly accepted by the community
2. need wallet and explorer to adapt; otherwise, it can't display the tx history

ERC-4337

1. not wildly accepted by the community
2. designed for smart contracts, but unfortunately, most users still use key-based wallets.
3. It May have DOS and security exploit(https://blog.openzeppelin.com/eth-foundation-account-abstraction-audit/). It needs the confidence to use ERC-4337 in the production environment.

The ERC-4337 is bounded to account abstract, which means only smart wallets can adopt ERC-4337.

Smart wallets with account abstracts can bring a different experience to the blockchain, but most people still use the key-based wallet. We have a gap between smart wallets and today's users. We want to combine the existing design philosophy to provide a gas-less experience for today's users.

Our solution is based on ERC-4337, but we have a few key differences:

• ERC-4337 requires a smart wallet to verify the user's account. Our solution support key-based wallet such as Metamask.
• ERC-4337 defines an UserOperation structure. Users sign on this structure instead of a transaction. Our solution requires the user to sign the transaction, just like sending a typical transaction.
• Do not use bundlers/relayers, bundlers respond to collect transactions and send them to miners, but since in the current stage, layer-2 rollup only has one block producer, the block producer can do the bundler/relayer's work.

Although the design aims to offer a gas-less feature for today's "non-smart" wallet, the gas-less feature only needs changes in the application layer of the Godwoken node; The feature doesn't conflict with ERC-4337, GSN, or any other alternative solutions. The developers can deploy ERC-4337 or other implementations to Godwoken.

Gas-less

The basic approach to implementing the gas-less feature

• An entrypoint contract to hold pre-paid tokens from developers. All gasless transactions must send to the contract so that we can implement the pre-paid logic in the smart contract.
• Developers need to deploy a paymaster contract to determine whether they will pay the tx fee for user operations.
• All gas-less transactions must satisfy the requirements:
  • tx.data must be the call data of calling Entrypoint's handleOp(UserOperation calldata op) function, which contains the target contract and the paymaster address.
  • Must set tx.gasPrice to 0
  • The tx.to must be set to the Entrypoint contract.

EntryPoint

struct UserOperation {
    address callContract;           # address of the target contract
    bytes callData;                 # call data
    uint256 callGasLimit;           # gas used to execute the call
    uint256 verificationGasLimit;   # gas used to verification
    uint256 maxFeePerGas;           # gas price
    uint256 maxPriorityFeePerGas;   # must equals to maxFeePerGas, reserved for EIP-1559
    bytes paymasterAndData;         # pay master address and extra data
}

API

TODO

Block producer changes

The block producer should be able to recognize gas-less transactions, then sort them in the mem-pool by its sponsored gasPrice instead of the tx.gasPrice, which is 0.

Godwoken node assumes a tx is a gas-less tx if it is satisfied:

1. tx.gasPrice is 0.
2. tx.data is a valid UserOperation.
3. tx.gas is equals to UserOperation.callGasLimit + UserOperation.verificationGasLimit * 3.
4. tx.to is equal to EntryPoint's address
5. UserOperation.paymasterAndData contains a paymaster address.

For gas-less txs, the node pushes it into mem-pool and sorts it with sponsored gasPrice instead of the tx.gas.

Conclusion

Account abstraction has high uncertainty. We skip the account abstraction and focus on bringing gasless features to today's developers and users - borrowing the design philosophy from current proposals. We offer a solution that developers can integrate their contract without changes, and users can sign gasless tx with the wallet they already use.

[wenyuanhust]

• An entrypoint contract to hold pre-paid tokens from developers. All gasless transactions must send to the contract so that we can implement the pre-paid logic in the smart contract.
• Developers need to deploy a paymaster contract to determine whether they will pay the tx fee for user operations.

Could you please decribe entrypoint & paymaster contract in detail? Thank you very much.

[RetricSu]

The detail of Entrypoint & Paymaster contracts can be found at code repo, which is a fork based on impl by eth-infinitism

Main API

Entrypoint:

     /**
     * Execute a UserOperation.
     * @param op the operations to execute
     */
    function handleOp(UserOperation calldata op) external;

    /**
    * Simulate a call to paymaster.validatePaymasterUserOp.
    * Validation succeeds if the call doesn't revert.
    * @dev The node must also verify it doesn't use banned opcodes, and that it doesn't reference storage outside the wallet's data.
     *      In order to split the running opcodes of the wallet (validateUserOp) from the paymaster's validatePaymasterUserOp,
     *      it should look for the NUMBER opcode at depth=1 (which itself is a banned opcode)
     * @param userOp the user operation to validate.
     * @return preOpGas total gas used by validation (aka. gasUsedBeforeOperation)
     * @return prefund the amount the paymaster had to prefund
     * @return deadline until what time this userOp is valid (paymaster's deadline)
     */
    function simulateValidation(UserOperation calldata userOp)
    external returns (uint256 preOpGas, uint256 prefund, uint256 deadline);

Full interface for Entrypoint, please check here

Paymaster:

     /**
     * payment validation: check if paymaster agree to pay.
     * Must verify sender is the entryPoint.
     * Revert to reject this request.
     * Note that bundlers will reject this method if it changes the state, unless the paymaster is trusted (whitelisted)
     * The paymaster pre-pays using its deposit, and receive back a refund after the postOp method returns.
     * @param userOp the user operation
     * @return context value to send to a postOp
     *  zero length to signify postOp is not required.
     * @return deadline the last block timestamp this operation is valid, or zero if it is valid indefinitely.
     *      Note that the validation code cannot use block.timestamp (or block.number) directly.
     */
    function validatePaymasterUserOp(UserOperation calldata userOp)
    external returns (bytes memory context, uint256 deadline);

     /**
     * post-operation handler.
     * Must verify sender is the entryPoint
     * @param mode enum with the following options:
     *      opSucceeded - user operation succeeded.
     *      opReverted  - user op reverted. still has to pay for gas.
     *      postOpReverted - user op succeeded, but caused postOp (in mode=opSucceeded) to revert.
     *                       Now this is the 2nd call, after user's op was deliberately reverted.
     * @param context - the context value returned by validatePaymasterUserOp
     * @param actualGasCost - actual gas used so far (without this postOp call).
     */
    function postOp(PostOpMode mode, bytes calldata context, uint256 actualGasCost) external;

     /**
     * add a deposit for this paymaster, used for paying for transaction fees
     */
    function deposit() public payable;

     /**
     * withdraw value from the deposit
     * @param withdrawAddress target to send to
     * @param amount to withdraw
     */
    function withdrawTo(address payable withdrawAddress, uint256 amount) public onlyOwner;

    /**
     * add stake for this paymaster.
     * This method can also carry eth value to add to the current stake.
     * @param extraUnstakeDelaySec - set the stake to the entrypoint's default unstakeDelay plus this value.
     */
    function addStake(uint32 extraUnstakeDelaySec) external payable onlyOwner;

Full interface for Paymaster, please check here and here

Contract Workflow

The user signed a transaction to call entrypoint with func handleOp, and entrypoint will then call paymaster with func validatePaymasterUserOp to verify if they are willing to pay gas fee for the user to execute this transaction.

Dapp Example: How to leverage gasless transaction

Let's say we have the entrypoint contract at 0x9a11f47c0729fc56d9c44c059987d40703249569（this is a fake one please do not use it directly） and as a game developer, we want to pay the gas fee for some whitelist users, so we wrote a paymaster contract just like this one and deployed it at 0x6b019795aa36dd19eb4a4d76f3b9a40239b7c19f(this is a fake one please do not use it directly).

dapp frontend using ethers.js

      // define UserOp
      const userOp: UserOperationStruct = {
          callContract: realGameContract.address,
          callData: realGameContractCallData,
          callGasLimit: gasToExecuteRealGameContractCallData,
          verificationGasLimit: gasToVerifyPaymaster,
          maxFeePerGas: gasPrice,
          maxPriorityFeePerGas: gasPrice,
          paymasterAndData: "0x6b019795aa36dd19eb4a4d76f3b9a40239b7c19f" 
      }
      
      // 1. construct and send gasless transaction
      const abiCoder = new ethers.utils.AbiCoder();
      const userOp = abiCoder.encode(["tuple(address callContract, bytes callData, uint256 callGasLimit, uint256 verificationGasLimit, uint256 maxFeePerGas, uint256 maxPriorityFeePerGas, bytes paymasterAndData) UserOperation"], [userOp]);
      // first 4 bytes of keccak hash of handleOp((address,bytes,uint256,uint256,uint256,uint256,bytes))
      const fnSelector = "fb4350d8";
      // gasless payload = ENTRYPOINT_HANDLE_OP_SELECTOR + abiEncode(UserOperation)
      const payload = "0x" + fnSelector + userOp.slice(2);
      const gaslessTx = {
        from: whitelistUser.address,
        to: '0x9a11f47c0729fc56d9c44c059987d40703249569',
        data: payload,
        gasPrice: 0,
        gasLimit: 1000000,
        value: 0,
      }
      const signer = new ethers.Wallet("private key");
      const tx = await signer.sendTransaction(gaslessTx);
      await tx.wait();
      // 2. or just use ethers contract factory
      {
        // Send tx with a valid user.
        const EntryPoint = await ethers.getContractFactory("EntryPoint");
        const entrypoint = await EntryPoint.attach('0x9a11f47c0729fc56d9c44c059987d40703249569');
        const tx = await entryPoint.connect(whitelistUser).handleOp(userOp, {gasLimit: 100000, gasPrice: 0});
        await tx.wait();
      }

[RetricSu]

Support Gasless Transaction on Blockchain Explorer

In order to display the actual gas price and gas cost for such gasless transactions, the blockchain explorer must parse it when collecting gasless transactions.

here is how the explorer parses gasless transactions:

1. collect gasless transactions:

• tx.to == entrypoint address (eg, on v1 testnet, the entrypoint address is 0x791ec459f57362256f313f5512bdb9f6d7cae308 which can be found via JSON RPC poly_version)
• tx.gasPrice == 0

when a transaction meets those two requirements, it should be considered to be a gasless transaction.

2. parse the gasless transaction

tx.dataof gasless transactions contain the call data of calling the entrypoint contract's method handleOp(UserOperation calldata userOperation). the actual gas price and other details are encoded in the UserOperation data structure. In the following example, we use js library tool ether.js to decode such info:

      // first 4 bytes of keccak hash of handleOp((address,bytes,uint256,uint256,uint256,uint256,bytes))
      const fnSelector = "fb4350d8";
      
      // gasless payload = fnSelector + abiEncode(UserOperation)
      const payload = tx.data;
      if(payload.slice(2,10) !== fnSelector){
          throw new Error("invalid fn selector!")
      }

     const userOpData = "0x" + payload.slice(10);
      
      // parse the UserOperation data
      const abiCoder = new ethers.utils.AbiCoder();
      const userOp = abiCoder.decode(["tuple(address callContract, bytes callData, uint256 callGasLimit, uint256 verificationGasLimit, uint256 maxFeePerGas, uint256 maxPriorityFeePerGas, bytes paymasterAndData) UserOperation"], userOpData);
      
      const {
          callContract,
          callData,
          callGasLimit,
          verificationGasLimit,
          maxFeePerGas,
          maxPriorityFeePerGas,
          paymasterAndData 
      } = userOp[0];      

3. display

• the actual GasPrice is maxFeePerGas, which also equals maxPriorityFeePerGas
• the actual GasUsed is the transaction gas used, same as the normal transaction

For better UX, we strongly recommend the explorer display the detailed UserOperation info for gasless transactions so that users can find out what the target contract is, which paymaster contract pays the fee for this transaction, etc.

V1 Testnet Example

example gasless transaction:

• https://v1.testnet.gwscan.com/tx/0xe83e9ae5d3194fa27a5485f3cf5e0abddd264dc6a04a43d7bfffd45e157db207?search=0xe83e9ae5d3194fa27a5485f3cf5e0abddd264dc6a04a43d7bfffd45e157db207

tx.data:

0xfb4350d800000000000000000000000000000000000000000000000000000000000000200000000000000000000000001005c8b8ee7a873576f5a6a9862c0c14909e01c100000000000000000000000000000000000000000000000000000000000000e000000000000000000000000000000000000000000000000000000000000186a000000000000000000000000000000000000000000000000000000000000186a000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000016000000000000000000000000000000000000000000000000000000000000000444dd3b30b000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000168d8f646cfffa073c207eb8f83d62cb3d842ade4e123400000000000000000000

parse result:

{
          callContract: "0x1005C8b8ee7A873576F5A6A9862C0c14909e01c1",
          callData: "0x4dd3b30b00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001",
          callGasLimit: "100000",
          verificationGasLimit: "100000",
          maxFeePerGas: "1",
          maxPriorityFeePerGas: "1",
          paymasterAndData: "0x8d8f646cfffa073c207eb8f83d62cb3d842ade4e1234", 
 } 

[Keith-CY]

What would the callContract and callData be if it's a transfer of native token without calling a contract

[RetricSu]

right now we didn't impl such feature, will consider it in the production design.

[RetricSu]

we are migrating the contract repo to https://github.com/godwokenrises/evm-contract for a more clear structure. please take review the new repo.

[Flouse]

Related docs

• https://docs.godwoken.io/gasless-feature
  This feature offers our users a unique experience of using blockchain technology without any associated costs.

[Flouse]

We have a new article.
https://docs.godwoken.io/gasless-with-ERC4337

This post is supposed to introduce our recent works about bringing a gasless-transaction feature on Godwoken.
It covers the basic principle and details about how the gasless feature works based on simplified ERC-4337 specs. We would also love to treat it as an opportunity to discuss the pros and cons of such a model with the most intelligent readers in crypto.