Skip to content

Clean up and modularize chain syncing logic #598

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

Merged
merged 9 commits into from
Jul 29, 2025

Conversation

tnull
Copy link
Collaborator

@tnull tnull commented Jul 24, 2025

We intended to modularize and clean up our chain sync since quite a while. Here, we finally do it by introducing a new ChainSourceKind type and moving the respective syncing logic to new EsploraChainSource, ElectrumChainSource, and BitcoindChainSource objects in the respective modules.

This is a rather large refactor, but 99% of the changes are code moves.

Additional cleanup steps / minor fixes will be coming up, but given the PR size I'll probably open a follow-up for them.

@tnull tnull requested a review from joostjager July 24, 2025 14:38
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jul 24, 2025

👋 Thanks for assigning @joostjager as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

src/chain/mod.rs Outdated
@@ -697,118 +650,8 @@ impl ChainSource {
// etc.)
pub(crate) async fn sync_onchain_wallet(&self) -> Result<(), Error> {
match &self.kind {
ChainSourceKind::Esplora {
Copy link
Contributor

Choose a reason for hiding this comment

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

I really don't know how to review a diff like this. But I think it is possible to improve by keeping the moved code close to where it was removed in a first commit, and then doing a clean move in a second.

image

I think it is too much to ask from a reviewer to see changes like this in the diff as it is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hmm, will play around with that a bit. Maybe it makes sense to first move everything into individual impl blocks beneath the original method before joining all in the new location.

Copy link
Collaborator Author

@tnull tnull Jul 29, 2025

Choose a reason for hiding this comment

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

I now went ahead and introduced intermittent impl blocks, and split the commits introducing the new chain source types and moving them to the dedicated modules. All of this should make for a considerable improvement, especially when reviewed via git diff --color-moved --ignore-all-space. I think there are some areas where git diff is still tripping, but I honestly don't know how to improve things further there.

Now pushed this new rewrite, which amounted to an net diff that is almost 0 (just moved a single helper method to a more reasonable location in the process).

@tnull tnull self-assigned this Jul 24, 2025
@tnull tnull moved this to Goal: Merge in Weekly Goals Jul 24, 2025
tnull added 2 commits July 29, 2025 09:12
We introduce a new `ChainSourceKind` that is held as a field by
`ChainSource`, which better encapsulates the chain syncing logic, and
in future commits allows us to move some common fields to `ChainSource`.
.. in the hopes of making the git diff more readable going forward, we
break up the `ChainSource` impl block.
@tnull tnull force-pushed the 2025-07-chainsource-refactor branch from e966cc9 to d39869a Compare July 29, 2025 07:16
tnull added 2 commits July 29, 2025 09:23
We refactor our `ChainSource` logic and move out the Esplora code into
a new object.
@tnull tnull force-pushed the 2025-07-chainsource-refactor branch from d39869a to c6a45c1 Compare July 29, 2025 07:26
tnull added 3 commits July 29, 2025 09:40
We refactor our `ChainSource` logic and move out the Electrum code into
a new object.
We refactor our `ChainSource` logic and move out the Bitcoind code into
a new object.
@tnull tnull force-pushed the 2025-07-chainsource-refactor branch from c6a45c1 to f82eec4 Compare July 29, 2025 08:08
@tnull tnull requested a review from joostjager July 29, 2025 08:12
Copy link
Contributor

@joostjager joostjager left a comment

Choose a reason for hiding this comment

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

This PR shows a really nice decomposition / clean up. I think it was worth it.

The only real comment/question that I have is whether ChainSource is still needed? It is now mainly a pass through and I was wondering if that could be replaced by a trait?

src/chain/mod.rs Outdated
logger,
"Successfully broadcast transaction {}",
txid
self.logger,
Copy link
Contributor

Choose a reason for hiding this comment

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

Glad you did this somewhat artificial commit struct. Very easy to ascertain that it's still the same.

@@ -42,7 +42,83 @@ const BDK_ELECTRUM_CLIENT_BATCH_SIZE: usize = 5;
const ELECTRUM_CLIENT_NUM_RETRIES: u8 = 3;
const ELECTRUM_CLIENT_TIMEOUT_SECS: u8 = 10;

pub(crate) struct ElectrumRuntimeClient {
pub(super) enum ElectrumRuntimeStatus {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe the diff would improve a bit if you left this at roughly the same location as where it was.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm not sure I moved this much, but rather moved other things around that have git conclude that this was moved. Not sure it's worth experimenting further, I already did a few iterations until I reached the current state^^

Copy link
Contributor

@joostjager joostjager Jul 29, 2025

Choose a reason for hiding this comment

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

Yes, fair. Current state is already 90% of the win, if not 100% given diff limits.

@tnull
Copy link
Collaborator Author

tnull commented Jul 29, 2025

The only real comment/question that I have is whether ChainSource is still needed? It is now mainly a pass through and I was wondering if that could be replaced by a trait?

Ah, I don't think we can due to how different the transaction vs. block-polling-based chain sources are. If we'd introduce two traits for them, we'd still need an adaptor that would forward to the right implementation.

tnull added 2 commits July 29, 2025 14:10
.. now that we don't need them anymore for review, we drop the extra
`impl` blocks again.
@tnull tnull force-pushed the 2025-07-chainsource-refactor branch from f82eec4 to 7cb1d34 Compare July 29, 2025 12:10
@tnull
Copy link
Collaborator Author

tnull commented Jul 29, 2025

I think I'm gonna land this, will see to get a PR with follow-ups up soon.

@tnull tnull merged commit 0935401 into lightningdevkit:main Jul 29, 2025
10 of 15 checks passed
@github-project-automation github-project-automation bot moved this from Goal: Merge to Done in Weekly Goals Jul 29, 2025
@joostjager
Copy link
Contributor

The only real comment/question that I have is whether ChainSource is still needed? It is now mainly a pass through and I was wondering if that could be replaced by a trait?

Ah, I don't think we can due to how different the transaction vs. block-polling-based chain sources are. If we'd introduce two traits for them, we'd still need an adaptor that would forward to the right implementation.

I would think that something like process_broadcast_queue could just as well be a method of a shared trait?

But the actual logic is now separated, so goal achieved.

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

Successfully merging this pull request may close these issues.

3 participants