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

[#9927] Fast blocks sync after being offline #9942

Merged
merged 1 commit into from
Jan 30, 2020

Commits on Jan 30, 2020

  1. [#9927] Fast blocks sync after being offline

    Front end changes:
     As there is no guarantee that `newblock` event will be dispatched
    consequently (e.g. if there was a delay after block#1 the next event
    might be dispatched for a block#2000, no guarantee that block#2 will be
    the next one), `newTransactions` field was added with a map of accounts
    to the number of new transactions received to this block. In result if
    there are new transactions we request them all of db instead of fetching
    them on for the block specified in `newblock` event, as it was done
    previously.
    
    Back end changes:
    - In order to avoid handling of the reorganized blocks we use an offset
    from the latest known block when start listening to new blocks. Before
    this commit the offset was 15 blocks for all networks. This offset is
    too big for mainnet and causes noticeable delay of marking a transfer as
    confirmed in Status (comparing to etherscan). So it was changed to be 5
    blocks on mainnet and is still 15 blocks on other networks.
    - Also before this commit all new blocks were handled one by one with
    network specific interval (10s for mainnet), which means that in case of
    lost internet connection or application suspension (happens on iOS)
    receiving of new blocks would be paused and then resumed with the same
    "speed" - 1 blocks per 10s. In case if that pause is big enough the
    application would never catch up with the latest block in the network,
    and this also causes the state of transfers to be delayed in the
    application. In this commit in case if there was more than 40s delay
    after receiving of the previous block the whole history in range between
    the previous received block and ("latest"-reorgeSafetyDepth) block is
    checked at once and app catches up with a recent state of the chain.
    rasom committed Jan 30, 2020
    Configuration menu
    Copy the full SHA
    b41df2f View commit details
    Browse the repository at this point in the history