-
Notifications
You must be signed in to change notification settings - Fork 130
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
Comments
Hi, |
Snapshot can't work on a running node, for balance must be fixed in snapshot working process. |
Yes, if a snapshot node is added, the newly added node only needs to synchronize the latest snapshot and the data after the snapshot. |
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. |
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.
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
The text was updated successfully, but these errors were encountered: