This is a sketch of a solution for the issue:

https://github.com/logos-co/nomos/issues/1479

• In the chain online mode,
  • Send a new SdpLedger of the new LIB to the SDP service, whenever the LIB is updated.
    • This information goes through: SDP → Membership → DA
• In the chain bootstrapping mode (i.e. during IBD and ProlongedBootstrapPeriod)
  • Suppose it’s fine to always skip blob validation during bootstrapping,
    • Don’t send SdpLedgers to the SDP service, since LIB is never updated during bootstrapping.
    • Once it’s switched to the online mode, it sends the SdpLedger of the updated LIB.
  • But it’s not fine. We want to enable blob validation at some point during bootstrapping.
    • For now, I think it’s the moment when there are only 8640 blocks left to be downloaded, considering that the DA window is 8460 blocks (= 2 * DA session).
      • Expecting that blobs outside of this window will be pruned by DA nodes.
    • Then, the issue is that “which membership should the DA service use for blob validation/sampling?”
    • It should use the latest DA session information older than the current block to be validated.
    • Option 1:
      • When the chain service wants to request blob sampling/validation, it seeks the latest session beginning block from the chain, and provides its SdpLedger along with the block that it wants to validate right now. It can be calculated based on block numbers and the session length.
        • The current implementation of the historic sampling won’t work in this case, because the DA service hasn’t stored any historic membership to the DB yet. In other words, the chain service hasn’t provided any block to the services during bootstrapping. So, I think the chain service should provide a proper SdpLedger when requesting historic sampling.
    • Option 2 👍
      • From the beginning of bootstrapping, the chain service continuously provides (height, HeaderID)s with the SDP service, similar as the regular process (online mode).
      • These blocks are not finalized yet, but the Membership service can continuously subscribe them and form the latest membership information, which is necessary for the DA service in the end.
      • The downside of this option is that the chain may be reorganized later, since LIB is never updated during bootstrapping. Then, the SDP and Membership services must be notified about it and do proper cleanup operations, which may be complicated.
        • Chain → SDP → Membership
          • Hey! LIB changed. I’m streaming all the block you will need.
    • Thus, for now, I guess the option 1 is more reasonable, but I still need to give it more thought.