[Review] New Transaction Type: Celo Dynamic Fee v2

[gastonponti]

Simple Summary

Create a new EIP-2718 Transaction Type that will act as eip1559 tx but including the feeCurrency field for paying in a different currency.

Abstract

This CIP proposes to create a new EIP-2718 Transaction Type 0x7b, which will have the same functionality as the CIP-42, but removing the gateway fields (already deprecated in the CIP-57).
With the format 0x7b || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, feeCurrency signature_y_parity, signature_r, signature_s])

Motivation

In the Espresso Hard Fork the EIP-2718 was introduced. We also added a new transaction type 0x7c, which is the CeloDynamicFee transaction from EIP-1559, with the ability to be paid in a different currency. This transaction type was added as part of the CIP-42.

In our pursuit to be closer to Ethereum and become an L2, we are deprecating the full node incentives (CIP-57), which will make the CIP-42 a transaction that will maintain two unused fields (the gatewayFee and gatewayFeeRecipient). This CIP aims to give a pruned alternative that eventually will allow us to deprecate CIP-42 transactions without loosing any functionality and allow a smoother transition to L2.

Specification

Definitions

• TransactionType 123 ⇒ 0x7b. See EIP-2718
• || is the byte/byte-array concatenation operator
• feeCurrency is the address of the whitelisted currency to be used to pay for gas

As of FORK_BLOCK_NUMBER, a new EIP-2718 transaction is introduced with TransactionType 123.

The EIP-2718 TransactionPayload for this transaction is 0x7b || rlp([chainId, nonce, maxPriorityFeePerGas, maxFeePerGas, gasLimit, to, value, data, accessList, feeCurrency, signatureYParity, signatureR, signatureS]).

The signatureYPparity, signatureR, signatureS elements of this transaction represent a secp256k1 signature over keccak256(0x7b || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, feeCurrency])).

The EIP-2718 ReceiptPayload for this transaction is rlp([status, cumulativeGasUsed, logsBloom, logs]).

Rationale

The creation of this new transaction type will maintain functionality that we already have and will also allow us to prune our codebase in the L2 migration. That future migration will require to reduce differences to Ethereum as much as we can to reduce the complexity added for proof creations in either scenario (optimistic and zk), for example the future removal of the transaction added in the CIP-42 plus reverting the celo legacy tx, to be exactly the same as the legacy in Ethereum. Also, it will give us the opportunity to prune our codebase and make it more maintainable.

Backwards Compatibility

As every new transaction type, this needs to be added as part of a fork, and as it is a new transaction type, it shouldn’t change any actual behaviour

Implementation

An implementation suggestion is available at celo-org/celo-blockchain#2170

Security Considerations

This contains the same considerations as the CIP-42.

License

This work is licensed under the Apache License, Version 2.0.