Customizable block sync service

[liuchengxu]

In subspace, we have a special kind of node called domain which is an execution chain and doesn't have its consensus, all the domain blocks are derived from the consensus chain blocks, so an execution chain can be built by syncing the consensus chain and processing the consensus blocks accordingly (let's call this naive sync), this syncing approach will be used when no peers of execution chain (basically when the execution chain is initially launched), once there are more peers on the network and the node is connected to someone, we plan to support fast sync by doing a state sync so that new nodes can sync from others pretty quickly. So basically, our first requirement is to disable the built-in block sync for the execution chain in Substrate when doing the naive consensus chain sync as it's needless, and we have already seen some issues on our side when these two syncings are enabled at the same time, which could be on our side or something in Substrate but they can just be avoided if the built-in block sync can be toggled off.

[altonen]

I don't see why this isn't at least theoretically possible right now. We've refactored syncing out of sc-network and right now it lives insc-network-sync which means it should be possible to replace to the syncing implementation using your own custom implementation by "just" replacing everything in sc-network-sync.

If you need to modify how syncing works without completely rewriting the current implementation, you can implement a modified SyncingService which is returned from the SyncingEngine here. The functionality you'd like to replace (such as NetworkBlock) can be done by modifying the implementation of SyncingService which right now just delegates to SyncingEngine. So in essence, when something in Substrate calls SyncingService::announce_block(), you can execute whatever code you've specified, it's just a matter of catching the announce_block() signal in SyncingService and calling your custom code.

Is there a reason why this model doesn't work for you?

[liuchengxu]

Yeah, we aim to replace only the NetworkBlock component while retaining the rest of the structure. To implement a custom SyncingService, we essentially need to create a SyncingService wrapper and modify the NetworkBlock trait implementation. (This does not work well as SyncingService is not generic) However, this would necessitate duplicating the entire build_network() function to incorporate our custom SyncingService.

Given that build_network() encompasses a significant amount of networking logic, spanning over 250 lines of code, and considering our custom version closely mirrors the original, it would simplify maintenance if we could avoid replicating the entire build_network(). I understand your perspective, and we can proceed in this manner if no superior alternatives are suggested.

UPD: I could misunderstand your point. How do you override a specific trait implementation of SyncingService? It's not allowed in Rust if I understand correctly. BTW, I have replicated build_network() with a few necessary pieces exposed and then modified the inner build_network_future() to meet our requirement.

[altonen]

You need to modify this code to provide a custom NetworkBlock implementation for your node. How you decide to go about it is up to you. Right now this code sends NewBestBlockImported and AnnounceBlock to SyncingEngine so you probably want to send those events to some other listener.

[liuchengxu]

If I'm not mistaken, that modification would necessitate forking Substrate and using the forked version moving forward, which is not an ideal solution. I'm exploring alternatives that would allow us to achieve our goal without resorting to forking Substrate. Anyway, I can update #14238 to expose a few necessary structures for replicating the build_network() function on our side.