Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Align block_helper.toJSON with hashed values #92

Merged
merged 2 commits into from
Apr 12, 2018

Conversation

AusIV
Copy link
Contributor

@AusIV AusIV commented Mar 29, 2018

I have a project where we're trying to use Ganache to test our services that
are written in Go. The RPC client that ships with Geth ignores the
hash provided by RPC and recalculates it instead. Due to some discrepancies
between the value used to calculate the hash and the values served over
RPC, the Go client is unable to compute the same hash as Ganache.

Two of the issues I ran into are in Ganache core. One was that the RPC
value for mixHash did not match the value used to calculate the checksum.
For reasons that are not clear even after reviewing the commit history,
rather than including the mixHash used to calculate the hash, block_helper
was including a string of repeating "10"s. I have changed this to reflect
the mixHash stored in the block header.

The other issue I ran into was extraData. If block.header.extraData was
an empty buffer, it would get encoded as "0x00", which decodes to a buffer
containing a single null byte. When a client uses that value to compute
the hash, they obviously get different results. This modifies
to.rpcDataHexString to pass empty buffers through as "0x" instead of
padding it with an extra 0 byte.

My mission of being able to compute the same hash with Ganache and the Geth
RPC client has one more stop at ethereumjs-block, which defaults to having
an empty nonce instead of an appropriately sized buffer of null bytes.

At OpenRelay, we're trying to use Ganache to test our services that
are written in Go. The RPC client that ships with Geth ignores the
hash provided by RPC and recalculates it instead. Due to some discrepancies
between the value used to calculate the hash and the values served over
RPC, the Go client is unable to compute the same hash as Ganache.

Two of the issues I ran into are in Ganache core. One was that the RPC
value for mixHash did not match the value used to calculate the checksum.
For reasons that are not clear even after reviewing the commit history,
rather than including the mixHash used to calculate the hash, block_helper
was including a string of repeating "10"s. I have changed this to reflect
the mixHash stored in the block header.

The other issue I ran into was extraData. If block.header.extraData was
an empty buffer, it would get encoded as "0x00", which decodes to a buffer
containing a single null byte. When a client uses that value to compute
the hash, they obviously get different results. This modifies
to.rpcDataHexString to pass empty buffers through as "0x" instead of
padding it with an extra 0 byte.

My mission of being able to compute the same hash with Ganache and  the Geth
RPC client has one more stop at ethereumjs-block, which defaults to having
an empty nonce instead of an appropriately sized buffer of null bytes.
@AusIV
Copy link
Contributor Author

AusIV commented Mar 31, 2018

The failing checks don't relate to the changes in this PR. At the last commit to develop, web3-providers-ws was at version 1.0.0-beta.30. By 1.0.0-beta.33 web3-provider-ws they changed the invocation of the listener function from cb(err, response) to cb(response), which is causing these tests to fail.

Several items, difficulty, totalDifficulty, gasLimit, gasUsed, and timestamp
are quantities, which the JSON RPC Spec says should not have leading 0s.
to.rpcQuantityHexString() already accounts for this, but these values were
not translated with rpcQuantityHexString().
@AusIV AusIV force-pushed the standardize-block-rpc branch from 266b715 to d951cae Compare April 5, 2018 19:56
@benjamincburns
Copy link
Contributor

Thanks for this one, @AusIV! I think this fixes #387 and #51.

@benjamincburns
Copy link
Contributor

Also kudos for adding/updating the test suite - this was a very easy change to accept!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants