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

Amendment for Subcoin milestone3 #2376

Merged
merged 1 commit into from
Aug 23, 2024
Merged

Conversation

liuchengxu
Copy link
Contributor

In light of recent developments, it has become evident that fully syncing to the tip of the Bitcoin network and enabling new nodes to perform fast sync to the latest Bitcoin state is more challenging than initially anticipated, caused by the huge state of UTXO set (over 12GiB, much larger than any existing Substrate chains to my knowledge). We'll also discuss the fast sync challenge in the article delivery at this milestone. As a result, I would like to propose adjusting the delivery goal for this milestone.

The most significant known blocker is paritytech/polkadot-sdk#4. Other underlying issues may also contribute to the difficulty. Recent experiments have shown that fast sync from around block height 580,000 is currently infeasible, succeeding only on machines with 128GiB of memory (paritytech/polkadot-sdk#5053 (comment)), which is impractical for most users. Nevertheless, we have successfully demonstrated that decentralized fast sync is possible within a prototype implementation.

While syncing to the Bitcoin network's tip remains a future target, addressing the existing technical challenges will require substantial R&D efforts. We remain committed to exploring potential solutions, including architectural changes and contributing to resolving issue paritytech/polkadot-sdk#4,

In light of recent developments, it has become evident that fully syncing
to the tip of the Bitcoin network and enabling new nodes to perform fast
sync to the latest Bitcoin state is more challenging than initially anticipated,
caused by the huge state of UTXO set (over 12GiB). As a result, I propose
adjusting the delivery goal for this milestone.

The most significant known blocker is paritytech/polkadot-sdk#4.
Other underlying issues may also contribute to the difficulty. Recent experiments
have shown that fast sync from around block height 580,000 is currently infeasible,
succeeding only on machines with 128GiB of memory (paritytech/polkadot-sdk#5053 (comment)),
which is impractical for most users. Nevertheless, we have successfully demonstrated that
decentralized fast sync is possible within a prototype implementation.

While syncing to the Bitcoin network's tip remains a future target, addressing
the existing technical challenges will require substantial R&D efforts.
We remain committed to exploring potential solutions, including architectural
changes and contributing to resolving issue paritytech/polkadot-sdk#4,
@github-actions github-actions bot added the admin-review This application requires a review from an admin. label Aug 22, 2024
@PieWol
Copy link
Member

PieWol commented Aug 22, 2024

Hey @liuchengxu ,
thanks for reaching out about this issue. Simply out of interest, have you tried to allow for a huge swap file so that this might be successful even on machines without 128gb of RAM?

@PieWol PieWol self-assigned this Aug 22, 2024
@liuchengxu
Copy link
Contributor Author

liuchengxu commented Aug 22, 2024

have you tried to allow for a huge swap file so that this might be successful even on machines without 128gb of RAM?

This is interesting. After increasing the swap to 128GiB locally, I successfully completed a fast sync from a node at height 612,272. The peak memory usage was around 128GiB of RAM plus 50GiB of swap, importing the state took about 50 minutes on my machine. However, after importing the synced state, the node took an unreasonably long time to restart. It appears that Substrate encounters significant challenges when handling state at this scale.

To conclude, a fast sync from height ~580,000 might be still possible with 128GiB of RAM and just 2GiB of swap. But when syncing from height 612,272, the memory consumption rose to 128GiB of RAM plus 50GiB of swap, which is unsustainable considering there are still over 240,000 blocks left to sync. Extrapolating from these numbers, syncing the latest Bitcoin state might require 128GiB RAM plus swap ~400GiB, which is simply unmanageable.

Copy link
Collaborator

@Noc2 Noc2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to go ahead with this.

@Noc2 Noc2 added the ready for review The project is ready to be reviewed by the committee members. label Aug 23, 2024
Copy link
Member

@PieWol PieWol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for swiftly conducting the experiment and laying out the results. The change to the grant agreement sounds very reasonable to me.

@keeganquigley keeganquigley added amendment This PR proposes changes to an existing application. and removed admin-review This application requires a review from an admin. labels Aug 23, 2024
@Noc2 Noc2 merged commit e5d2ad5 into w3f:master Aug 23, 2024
15 of 16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
amendment This PR proposes changes to an existing application. ready for review The project is ready to be reviewed by the committee members.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants