Unsigned ethers v6 type 2 transaction

[mrosendin]

Suggestion

I cannot find an example anywhere for the use case where a client creates an unsigned type 2 (e.g., EIP-1559 / Dynamic Fee) transaction object. A typical use case might be to send the unsigned tx via API to a digital asset custodian for signing.

I have been testing with op-geth and get typed transaction too short or other similar errors. It would be beneficial to document the use case of deploying a contract.

const myContractFactory = new ethers.ContractFactory(
    MyContract.abi,
    MyContract.bytecode,
    provider // instantiation omitted
)

// Prepare the deployment data
const deployTransaction = await myContractFactory.getDeployTransaction(
  deployParam1, // omitted
  deployParam2 // omitted
)

const WALLET_ADDRESS = "..." // omitted

// Get the gas price and nonce
const feeData = await provider.getFeeData()
const gasPrice = feeData.gasPrice || ethers.parseUnits('20', 'gwei') // Set a default gas price if null

// Prepare the transaction parameters
const nonce = await provider.getTransactionCount(WALLET_ADDRESS)
const gasLimit = 3000000
const chainId = 84532

const txRequest = {
    nonce: nonce,
    to: ethers.ZeroAddress,
    maxFeePerGas: feeData.maxFeePerGas,
    maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
    gasLimit: gasLimit,
    data: deployTransaction.data,
    chainId: chainId,
    value: 0,
    type: 2, // EIP-1559 tx envelope, see https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2718.md
    accessList: [],
}

When op-geth tries to RLP decode, I get this error:

{
  error: 'BAD_GATEWAY',
  status: 502,
  description: 'decompiler failed to decompile transaction: rpc error: code = Unknown desc = typed transaction too short\n' +
    'error rlp decoding dynamic transaction\n' +
    'failed to decompile transaction'
}

Furthermore, if I instead try to manually RLP-encode the transaction, I get back a different error (maybe due to the ordering of the fields?)

const rlpFields = [
  ethers.toBeHex(chainId),
  ethers.toBeHex(Number(nonce)).replace(/^0x0+/, "0x"), // Remove leading 0 padding
  ethers.toBeHex(Number(feeData.maxPriorityFeePerGas)),
  ethers.toBeHex(Number(feeData.maxFeePerGas)),
  ethers.toBeHex(gasLimit).replace(/^0x0+/, "0x"), // Remove leading 0 padding
  tx.to,
  ethers.toBeHex(value),
  tx.data,
  [], // accessList
];
  
//  Data below submitted without the leading `0x` or you get error "encoding/hex: invalid byte: U+0078 'x'"
ethers.encodeRlp(rlpFields).slice(2)

[mrosendin]

Here is a proper encoded transaction acceptable by geth:

Tx:  {
  nonce: 0,
  value: 100,
  gasLimit: 21000,
  maxFeePerGas: 1000000,
  maxPriorityFeePerGas: 1000000,
  type: 2,
  to: '0xf1C5FE2cFFaaFDf3300F4E5e94E31B519A0781e4',
  data: null,
  chainId: 84532,
  v: '0x',
  r: '0x',
  s: '0x'
}
Encoded Tx: 
ad02eb83014a3402830f4240830f424082520894f1c5fe2cffaafdf3300f4e5e94e31b519a0781e46480c0808080

Here is what ethers yielded:

const serializedTx = ethers.Transaction.from(tx).unsignedSerialized;
Encoded Tx: 
0x02e883014a3480830f4240830f424082520894f1c5fe2cffaafdf3300f4e5e94e31b519a0781e46480c0

The main differences:

• 0x prefix is included, this can easily be sliced off
• ad prefix is not included. From my understanding, this hex value is a length prefix for the list. E.g., 45 bytes
• 808080 is missing, which are the null values for v, r, and s.

A bit more about the list length prefix (ad in the example) from the ethereum.org RLP docs:

Otherwise, if a string is 0-55 bytes long, the RLP encoding consists of a single byte with value 0x80 (dec. 128) plus the length of the string followed by the string. The range of the first byte is thus [0x80, 0xb7] (dec. [128, 183]).

The hex value ad is decimal value 173, and when we subtract 173-128 we get 45, the byte length of the list.

How the bytes array, RLP encoding, and object key/value pairs relate

Encoded Tx: ad02eb83014a3402830f4240830f424082520894f1c5fe2cffaafdf3300f4e5e94e31b519a0781e46480c0808080
Byte Array: [173, 2, 235, 131, 1, 74, 52, 128, 131, 15, 66, 64, 131, 15, 66, 64, 130, 82, 8, 148, 241, 197, 254, 44, 255, 170, 253, 243, 48, 15, 78, 94, 148, 227, 27, 81, 154, 7, 129, 228, 100, 128, 192, 128, 128, 128]

- 0xad: Length prefix for the list
- 0x02: Transaction type (EIP-1559)
- 0xeb: Chain ID (encoded)
- 0x83: Length prefix for a 3-byte item (Chain ID)
- 0x01, 0x4a, 0x34: Actual Chain ID
- 0x80: Empty string (nonce)
- 0x83: Length prefix for a 3-byte item (MaxPriorityFeePerGas)
- 0x0f, 0x42, 0x40: Actual MaxPriorityFeePerGas
- 0x83: Length prefix for a 3-byte item (MaxFeePerGas)
- 0x0f, 0x42, 0x40: Actual MaxFeePerGas
- 0x82: Length prefix for a 2-byte item (GasLimit)
- 0x52, 0x08: Actual GasLimit
- 0x94: Length prefix for a 20-byte address (To Address)
- 0xf1, 0xc5, 0xfe, 0x2c, 0xff, 0xaa, 0xfd, 0xf3, 0x30, 0x0f, 0x4e, 0x5e, 0x94, 0xe3, 0x1b, 0x51, 0x9a, 0x07, 0x81, 0xe4: Actual To Address
- 0x64: Value (encoded)
- 0x80: Empty string (Data field)
- 0xc0: Empty list (Access List, for EIP-2930 and EIP-1559 transactions)
- 0x80: Empty string (v)
- 0x80: Empty string (r)
- 0x80: Empty string (s)

[ricmoo]

For signing though (see EIP-1559) (which is why unsignedSerialized returns):

The signature_y_parity, signature_r, signature_s elements of this transaction represent a secp256k1 signature over keccak256(0x02 || rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list])).

I wonder why Geth requires those fields; my guess is that it decodes the serialized format and then re-seriailzes it sans the signature? Are you passing the unsigned tx directly to a Geth API?

[mrosendin]

my guess is that it decodes the serialized format and then re-seriailzes it sans the signature

I agree with that take.

Are you passing the unsigned tx directly to a Geth API?

Yep, the unsigned tx is sent to the Geth API for signing. There is a middleware API layer used by the custodian, but I'm 95% sure there is no preprocessing; they are passing the serialized tx directly to geth.

[ricmoo]

Do you have a link to the project repo? Should be easy to modify it to accept either a standard unsigned tx or the non-standard serialized form they use now; then it’s just more flexible.

If it is a common format too, I can add support for ethers to accept the non-standard form too, but I don’t know if I would create a way to generate the non-standard… But if popular I could. :)

[kevink1103]

A simple trick here is to include a zero-byte signature into the tx and use .serialized instead of .unsignedSerialized.

const txRequest = {
    nonce: nonce,
    to: ethers.ZeroAddress,
    maxFeePerGas: feeData.maxFeePerGas,
    maxPriorityFeePerGas: feeData.maxPriorityFeePerGas,
    gasLimit: gasLimit,
    data: deployTransaction.data,
    chainId: chainId,
    value: 0,
    type: 2, // EIP-1559 tx envelope, see https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2718.md
    accessList: [],
    signature: { r: '0x0000000000000000000000000000000000000000000000000000000000000000', s: '0x0000000000000000000000000000000000000000000000000000000000000000', v: 27 }
}

txRequest.serialized // use the returned value from this!

It seems odd that geth mandatorily requires signature field even for the unsigned RLP encoded tx :(