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

Historical data snapshot Feature #585

Open
LucasMLK opened this issue Apr 10, 2021 · 4 comments
Open

Historical data snapshot Feature #585

LucasMLK opened this issue Apr 10, 2021 · 4 comments

Comments

@LucasMLK
Copy link
Contributor

LucasMLK commented Apr 10, 2021

xdag currently stores nearly 340 million blocks. According to the design of loading all of them into memory, it will seriously increase the operating cost of the mining pool. This will cause xdag to become more and more centralized. We need to design a snapshot method to reduce the operating cost of full nodes.

requirements:

1. Export balance data specification

  • At present, there is a -l parameter in the c code.

  • The out_balances() function can be called to output the block address and balance.

Current format:

address amount
++/H4OicSdhuO0Sebhcd4t03DQdFy4+Y 1024.000000000

Snapshot export format:

address publickey amount
++/H4OicSdhuO0Sebhcd4t03DQdFy4+Y 036d27f617ce7b0cbdce0abebd1c7aafc147bd406276e6a08d64d7a7ed0ca68f0e 1024.000000000

Publickkey export will prepare for the future deletion of address block, It is recommended that the public key be in a compressed format

2. Full nodes export a snapshot of all address balances at the specified height

The balance changes in real time, you need to stop at the specified height before exporting the balance

3. Full nodes can import balance snapshots and continue to run

Imported according to the balance snapshot, does not rely on the original 340 million block storage, and does not affect the original user balance

@Sofarlemineur
Copy link
Contributor

Hi,
Very interesting.
Do you think that this kind of node could be run as node on a simple PC or does it need also the actual hardware specification?
Thanks for your work

@swordlet
Copy link

Snapshot can't work on a running node, for balance must be fixed in snapshot working process.
So a snapshot node would be developed. And it is a off-line node.
How to using blocks height to cut the storage into two parts: before snapshot part and after snapshot part?
New mining pool will load snapshot and after snapshot part of storage.

@LucasMLK
Copy link
Contributor Author

Snapshot can't work on a running node, for balance must be fixed in snapshot working process.
So a snapshot node would be developed. And it is a off-line node.
How to using blocks height to cut the storage into two parts: before snapshot part and after snapshot part?
New mining pool will load snapshot and after snapshot part of storage.

Yes, if a snapshot node is added, the newly added node only needs to synchronize the latest snapshot and the data after the snapshot.

@LucasMLK
Copy link
Contributor Author

Hi,
Very interesting.
Do you think that this kind of node could be run as node on a simple PC or does it need also the actual hardware specification?
Thanks for your work

It depends on the size of the snapshot and the index space required for data query. I think this means that an simple PC becomes a necessary job for a full node.

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

No branches or pull requests

3 participants