getTransaction() error

[emmtte]

Ethers Version

v6 latest

Search Terms

No response

Describe the Problem

v5 working fine v6 error
ethers.getTransaction() return error: TypeError: yParity mismatch

Code Snippet

v5
provider = new providers.WebSocketProvider( 'wss://rpc.gnosischain.com/wss' )
let transaction = await provider.getTransaction(transactionHash).catch( e => { log( {level: 'fatal', message: 'getTransaction', transactionHash, error: e.data } ) } )

v6
provider = new ethers.WebSocketProvider( 'wss://rpc.gnosischain.com/wss' )
let transaction = await provider.getTransaction(transactionHash).catch( e => { log( {level: 'fatal', message: 'getTransaction', transactionHash, error: e } ) } )

Contract ABI

na

Errors

error: TypeError: yParity mismatch

Environment

node.js (older than v12)

Environment (Other)

No response

[ricmoo]

Can you include the transaction hash?

[emmtte]

This is for every transaction hash
See code below

event.on('websocket', async () => {
provider = new ethers.WebSocketProvider( 'wss://rpc.gnosischain.com/wss' )
provider.on('pending', async (transactionHash) => { event.emit('transaction',transactionHash) })
})

event.on('transaction', async (transactionHash, data) => {
let transaction = await provider.getTransaction(transactionHash).catch( e => { log( {level: 'fatal', message: 'getTransaction', transactionHash, error: e } ) } )
 })

work for v5, but not for v6

[or2008]

any updates in this?

[zemse]

Quick reproduction script

const provider = new ethers.JsonRpcProvider("https://rpc.gnosis.gateway.fm");
const tx = await provider.getTransaction(
  "0x52ed38daf0ec619c92aaf8a12965b9a948b8a7520f80328e614beb822826caae"
);
console.log(tx);

[ssa3512]

This appears specifically to be an issue when running against a Nethermind based node. I am seeing this same running against my home node (ETH mainnet) as well, but have no issues when using Alchemy.

[MicahZoltu]

The bug here is that ethers is not decoding the yParity value (which is hex encoded) prior to trying to process it.

ethers.js/src.ts/crypto/signature.ts

Lines 342 to 348 in 1dd5427

	if (yParity != null) {
	switch (yParity) {
	case 0: return { v: 27 };
	case 1: return { v: 28 };
	}
	assertError(false, "invalid yParity");
	}

yParity here is going to be '0x0' or '0x1', which will result in hitting the default (missing) case and falling through to the assert.

[MicahZoltu]

Note: Nethermind returns both v and yParity, both hex encoded, for all transaction types (I believe they are just trying to be super defensive). I think it is important to note that a v of 0x0 or 0x1 is not a valid v! Nethermind gets this wrong, but it is inaccurate to compare v against yParity. They are not the same thing and should not match. I didn't spend enough time on this to figure out why ethers is looking for a v in a type 1 or type 2 transaction, any v value included in those should be ignored as any other excess property is ignored. Only yParity is valid for those transaction types.

[rubo]

I think it is important to note that a v of 0x0 or 0x1 is not a valid v! Nethermind gets this wrong

@MicahZoltu Do you mean the v (if included) must be y-parity + CHAIN_ID * 2 + 35 as EIP-155 defines?

[MicahZoltu]

@rubo Type 1 and type 2 transactions do not have a v value. they only have a yParity value. Including a v is incorrect behavior for anyone providing a signature for a type 1 or type 2 transaction.

If you are going to provide a v (against spec), then it should either be 27, 28, or yParity + CHAIN_ID * 2 + 35. 0 and 1 are never valid values of v for any transaction.

[rubo]

We fixed the Nethermind's part of this issue, so the v is no longer returned for the non-legacy transactions. Looking forward to the yParity handling fix in ethers.

Thanks, @MicahZoltu for pointing this out.

[ricmoo]

Is the only change necessary to allow hex values? Or does the Formatter also have to detect both a yParity and v and drop the v if yParity is present?

[KillariDev]

The only necessary thing is to allow hex values for yParity. Unless you want to support older Nethermind versions, then you also need to drop the v if yParity is there I think

[MicahZoltu]

There are two bugs currently.

1. yParity should be encoded as a hex string, not a number, in the JSON-RPC response. Some clients may encode it as a number (despite this being wrong) so it seems reasonable to accept either number or 0x${string} in ethers.

2. If a transaction is type 1 or 2, it should only have a yParity. If it has both a v and a yParity, the v should be ignored like any other extraneous unsupported parameter. If it has only a v and no yParity I would consider this an error, but if some existing clients do this you could try to interpret the v somehow. It strikes me as incorrect to simply call it yParity (expecting a value of 0 or 1), but such a client is already incorrect so it wouldn't surprise me if it was doubly incorrect. I think if you wanted to be as absolutely defensive as possible you would convert 0 or 1 directly to yParity, and you would treat any other values as a legacy/155 transaction v and figure out what the y parity bit is and derive yParity from that.

If there are no clients that fail to include yParity in type 1/2 TransactionResponses then my recommendation is to not write and maintain all of the code to convert v to yParity as it would just be code that isn't actually used and encourages future clients to misbehave.

[ricmoo]

This should be fixed in v6.6.4.

Can you try it out and confirm?

Thanks! :)

[rubo]

Can you try it out and confirm?

Works for me as expected with and without v. Thank you!

[ricmoo]

Awesome! I’ll close this then.

Thanks! :)