Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: v and yParity aren't matching #7135

Closed
y0sher opened this issue May 23, 2024 · 0 comments · Fixed by #7139
Closed

Bug: v and yParity aren't matching #7135

y0sher opened this issue May 23, 2024 · 0 comments · Fixed by #7139

Comments

@y0sher
Copy link

y0sher commented May 23, 2024

Description

As an consumer of diversity of ethereum execution clients, I'm using ethclient as way to have consistent API to all these clients.

Apparently the ethclient does some checks when de-serializing the block received from the EL between those checks are -

  1. Either v or yParity fields exist in tx
  2. if both exist they MUST have the same value
    Ref

Steps to Reproduce (Bug)

  1. use ethclient to getBlockByNumber with recent blocks (ex: 1596869 on holesky)

code example:

ctx, cancel := context.Background()
client, err = ethclient.DialContext(ctx, "ws://your_WS_Besu_node_addr"/)
	if err != nil {
		return err
	}
b, err := client.BlockByNumber(ctx, big.NewInt(1596869))
if err != nil {
   // will error : 'v' and 'yParity' fields do not match
}

I got the same block manually through raw WS JSON-RPC and the values are indeed not matching, for example one TX from that block:

    {
      accessList: [],
      blockHash: '0xd4cff61214d981b4ae81c539f7bb0403685d46484966940006b7828958683d73',
      blockNumber: '0x185dc5',
      chainId: '0x4268',
      from: '0x217391cd635f089bc8ab5e2647ff0bf6dcfcda60',
      gas: '0xf4240',
      gasPrice: '0x7e7c6ca0',
      maxPriorityFeePerGas: '0x989680',
      maxFeePerGas: '0x174876e800',
      hash: '0x795cd0f767c5b5aed5fb44bcabd10b453ad07fec87f69af0ad14f54dd9dee0d8',
      input: '0x1a1016280000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000061465800000000000000000000000000000000000000000000000000000000000000021028cd6fce0c017e7fd3dd77e05b21dd34c2c9b9799549b8b0e93dcb2f7095945bc00000000000000000000000000000000000000000000000000000000000000',
      nonce: '0xea2a',
      to: '0xeb08c00f8a12e34951561da98f771248a6c2842e',
      transactionIndex: '0x62',
      type: '0x2',
      value: '0x0',
      yParity: '0x1',
      v: '0x84f4',
      r: '0x4b37a54bbac2df984f1c31a949b4ab2136df4c727b9f7249d2073a44c4029173',
      s: '0x18b9850eb99080eeb0286bfcede0b289872695c83821f43282b501c4f6c80457'
    }

The same block and tx got from Geth:

    {
      blockHash: '0xd4cff61214d981b4ae81c539f7bb0403685d46484966940006b7828958683d73',
      blockNumber: '0x185dc5',
      from: '0x217391cd635f089bc8ab5e2647ff0bf6dcfcda60',
      gas: '0xf4240',
      gasPrice: '0x7e7c6ca0',
      maxFeePerGas: '0x174876e800',
      maxPriorityFeePerGas: '0x989680',
      hash: '0x795cd0f767c5b5aed5fb44bcabd10b453ad07fec87f69af0ad14f54dd9dee0d8',
      input: '0x1a1016280000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000061465800000000000000000000000000000000000000000000000000000000000000021028cd6fce0c017e7fd3dd77e05b21dd34c2c9b9799549b8b0e93dcb2f7095945bc00000000000000000000000000000000000000000000000000000000000000',
      nonce: '0xea2a',
      to: '0xeb08c00f8a12e34951561da98f771248a6c2842e',
      transactionIndex: '0x62',
      value: '0x0',
      type: '0x2',
      accessList: [],
      chainId: '0x4268',
      v: '0x1',
      r: '0x4b37a54bbac2df984f1c31a949b4ab2136df4c727b9f7249d2073a44c4029173',
      s: '0x18b9850eb99080eeb0286bfcede0b289872695c83821f43282b501c4f6c80457',
      yParity: '0x1'
    },

Notice the yParity and v

Expected behavior: Adherence to the checks done by ethclient, matching v and yParity values

Actual behavior: : not matching values

Frequency: most recent blocks.

Logs (if a bug)

'v' and 'yParity' fields do not match
couldn't find any logs in Besu itself

Versions (Add all that apply)

  • Software version: 24.5.1
  • Java version: [java -version]
  • OS Name & Version: [cat /etc/*release]
  • Kernel Version: [uname -a]
  • Virtual Machine software & version: [vmware -v]
  • Docker Version: [docker version]
  • Cloud VM, type, size: [Amazon Web Services I3-large]
  • Consensus Client & Version if using Proof of Stake: [e.g. Teku, Lighthouse, Prysm, Nimbus, Lodestar]

Smart contract information (If you're reporting an issue arising from deploying or calling a smart contract, please supply related information)

  • Solidity version [solc --version]
  • Repo with minimal set of deployable/reproducible contract code - please provide a link
  • Please include specifics on how you are deploying/calling the contract
  • Have you reproduced the issue on other eth clients

Additional Information (Add any of the following or anything else that may be relevant)

  • Besu setup info - genesis file, config options ( holesky, but saw the same in mainnet)
  • System info - memory, CPU
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant