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

Filters: eth_newBlockFilter does not return canonical blocks #9858

Closed
ankitchiplunkar opened this issue Nov 2, 2018 · 1 comment

Comments

@ankitchiplunkar
Copy link

commented Nov 2, 2018

Before filing a new issue, please provide the following information.

  • Parity Ethereum version: v2.0.8-stable
  • Operating system: Ubuntu 18.04
  • Installation: one-line installer
  • Fully synchronized: yes
  • Network: ethereum
  • Restarted: no

Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue.

Expected behaviour

The eth_newBlockFilter when queried for using eth_getFilterChanges should return the forked blocks and also subsequently the canonical blocks.

Actual behaviour

The eth_newBlockFilter when queried for using eth_getFilterChanges does not return the canonical blocks (for almost every ~70 blocks)

Steps to reproduce the behaviour

I have a local parity node, am using web3.py for getting newblockfilters

from web3.auto import w3
from web3.utils.encoding import (to_hex)
import time

def log_loop(filter, poll_interval):
    while True:
        events = w3.eth.getFilterChanges(filter.filter_id)
        print(events)
        for event in events:
                blockData = w3.eth.getBlock(event) 
                print(("{}, {}, {} \n".format(to_hex(blockData['hash']), blockData['number'], to_hex(blockData['parentHash']))))
        time.sleep(poll_interval)

block_filter = w3.eth.filter('latest')
log_loop(block_filter, 1)

From time to time, I get a forked block from the filter but not the canonical block.

0x316c065382afdaa0a5946c168d151d5178690e94bf523571da323f5330c40363, 6630926, 0x26c2df9cf5a53e0643ea72653e9864de2c99643d26a896dbcf51bf0bd55fd186
0x82d8e543820d6a0c996a6b5eab816cae7e520ccdeec4e5478ebfb0ddbf999c9b, 6630927, 0x54d2120357ed9f9af4974b355e9d868e7aca96cb937c997f5ad870c2fe8a09e6

As we an see the hash of block 6630926 does not match the parent hash of 6630927, also the block 0x316c065382afdaa0a5946c168d151d5178690e94bf523571da323f5330c40363 does not exist in the canonical blockchain.

Is it possible to get canonical blocks from filterchanges method without relying on using the method eth_getBlockByNumber?

@joshua-mir joshua-mir added this to the 2.3 milestone Nov 2, 2018

@joshua-mir joshua-mir added this to Needs Assignment in Core via automation Nov 2, 2018

@jpzk

This comment has been minimized.

Copy link

commented Nov 5, 2018

This is an important issue, I believe many companies rely on this. It's also a major differentiator if it works in Parity, also Geth is unreliable.

@mattrutherford mattrutherford self-assigned this Nov 15, 2018

Core automation moved this from Needs Assignment to Done Nov 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.