Closed elenadimitrova closed 6 years ago
@elenadimitrova per the JSON RPC wiki, the logsBloom
field is meant to be defined on the eth_getBlock*
responses, but not on eth_getTransactionReceipt
.
That said, I'm still uncertain as to how much we should treat that wiki page as a spec. Further, I need to balance the goal of adhering to the spec (weakly-defined as it is) so that people write dapps which are portable across ethereum clients, against supplying people what they need in order to test their Dapps adequately for their environments.
As a rule, we usually do our best to follow the RPC wiki page unless there's disagreement amongst major client implementations. In that case, we tend to take the intersection of functionality between Parity and geth rather than the union.
To help me make the decision:
eth_getTransactionReceipt
?It is breaking for ethers
which expects this in the transaction receipt
https://github.com/ethers-io/ethers.js/blob/511fff1390ba56ba56237053fd00ae0ec87b1e7b/providers/provider.js#L296
As for geth
this also returns logsBloom in the transaction receipt:
truffle(development)> web3.eth.getTransactionReceipt('0x485bacde24723e24c6eb278000c08cb95094f0c69e205aa39cfa9353f97db869')
{ blockHash: '0x2d43d6141761537eef97e00eb4f919cd8da4d27fa580cbc6f02981d77756a468',
blockNumber: 5317,
contractAddress: '0xab56c45847c68007cffe7d80cabdb24043d1b08f',
cumulativeGasUsed: 630488,
from: '0xc46fbd443feca41354c6ebfd36cea7d89c555bea',
gasUsed: 630488,
logs:
[ { address: '0xab56c45847c68007cffe7d80cabdb24043d1b08f',
topics: [Array],
data: '0x',
blockNumber: 5317,
transactionHash: '0x485bacde24723e24c6eb278000c08cb95094f0c69e205aa39cfa9353f97db869',
transactionIndex: 0,
blockHash: '0x2d43d6141761537eef97e00eb4f919cd8da4d27fa580cbc6f02981d77756a468',
logIndex: 0,
removed: false } ],
logsBloom: '0x00000002000000000010000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000080000000000000000000004000000000000000000000000000000000000000000002000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
root: '0x8c78a5f75f32094b64befcd08b1890c05c6d6f64a33557289ebd3548bb1b7fe3',
to: null,
transactionHash: '0x485bacde24723e24c6eb278000c08cb95094f0c69e205aa39cfa9353f97db869',
transactionIndex: 0 }
This points to omission in the JSON RPC wiki but the yellow paper clearly defines it.
That's good enough for me, then - we'll go ahead and add it.
From comparison of both objects you submitted, it seems we also don't respond with the root
field.
As per the JSON RPC this is actually correct as it states the transaction receipt returns either the root
(pre Byzantium) or the status
. The latter is returned in testrpc
.
To enable that in parity
we had to switch to 1.8.3-beta
and turn the "eip658Transition": 0
parameter in config. We haven't tried in geth
yet.
@elenadimitrova what version of geth was that output from above? It seems strange that it also has the root
field but is missing the status
field. Looks like I need to fire up a light client for myself...
I'm on geth
Version: 1.7.3-stable
Fixed in develop
branch now. Will go out with latest release. Thanks for reporting this, @elenadimitrova!
@elenadimitrova I've actually just pushed out a beta release of ganache-core
3.0.0 and ganache-cli
7.0.0. This change will be in there amongst other major things like websockets support, fixing #417, and fixes for other various race condition and stability bugs, including the pesky "key not found" db error. I hope that you'll find it to be a much better experience.
I've installed Ganache v1.2.0-beta.0 and I am still getting this problem when using Ethers.js Should this fix be included in the v1.20 release? Thanks
I caught up with @naddison36 offline, but for those reading along, this is in the v1.1.0-beta.1
release which is up now.
Thanks, @benjamincburns. I can confirm that the new version fixed this problem
The transaction receipts are missing the
logsBloom
property. Below are outputs from a non-specific transaction usingtestrpc
andparity
where the property is available.Test with
testrpc
Test against Parity:
The property is otherwise available on the
block
usingtestrpc
.According to the yellow paper, both the
block
and thetransaction
receipt definelogsBloom
in their properties.