Unsigned ethers v6 type 2 transaction about ethers.js HOT 5 OPEN

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)

from ethers.js.

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?

from ethers.js.

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.

from ethers.js.

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. :)

from ethers.js.