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

Handling of genesis block takes too much time #6573

Closed
ManuGowda opened this issue Jul 9, 2021 · 1 comment
Closed

Handling of genesis block takes too much time #6573

ManuGowda opened this issue Jul 9, 2021 · 1 comment
Assignees
Milestone

Comments

@ManuGowda
Copy link
Contributor

ManuGowda commented Jul 9, 2021

Expected behavior

Even with a large genesis block file, it should be able to sync the nodes properly.

Actual behavior

  • Procedure getHighestCommonBlock for given block ids returns the whole common block header, in case of testnet or mainnet genesis block header the size of genesis block header is too big (20-200MB).
  • When getting the block, it tries to decode the asset which takes long.
  • Genesis block are kept in memory

Steps to reproduce

  • Migrate 2.1.6 and generate genesis block (which is around 200MB)
  • Run lisk-core start -n mainnet with the new genesis block
  • Connect to running node as seed peer
  • Observer the syncing node fails to request block during synchronisation

Which version(s) does this affect? (Environment, OS, etc...)

5.1.1, 3.0.0

@ManuGowda ManuGowda added this to the Sprint 48 milestone Jul 9, 2021
@shuse2 shuse2 changed the title Update getHighestCommonBlock to return common block Id Handling of genesis block takes too much time Jul 12, 2021
@shuse2 shuse2 self-assigned this Jul 12, 2021
@shuse2
Copy link
Collaborator

shuse2 commented Jul 12, 2021

General direction of solving this issue will be

  • lisk-chain package will not decode the block header asset, and it will be encode/decode only when it's needed. (ie: for hooks etc)
  • Add genesis data to consensus state (init round and height) so that genesis header is not needed in the memory
  • Update getHighestCommonBlock to return only ID of the common block

shuse2 added a commit that referenced this issue Jul 13, 2021
shuse2 added a commit that referenced this issue Jul 13, 2021
Update p2p block response not to use the decoding data access -  Closes #6573
@shuse2 shuse2 closed this as completed Jul 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants