Document concepts of late-publishing & rollback about sidetree

[AlexITC]

Here is a simple implementation that detects what operations need to be applied in order to syncrhonize a block database with the one from the bitcoin node: LedgerSynchronizationStatusService#getSyncingStatus.

While the code is in Scala, the comments should give you the idea of how it works:

  /**
   * Lets define some values:
   * - The candidate is the block that needs to be stored.
   * - The latestLedgerBlock is the newer block that is stored.
   * - The LCA is the least common ancestor between both chains.
   *
   * There are some trivial cases to handle:
   * - There are no blocks stored, just sync everything.
   * - The candidate is already stored, just ignore it.
   *
   * So, let's assume that:
   * - The candidate is not stored.
   * - We have at least a block stored (latestLedgerBlock).
   * - The LCA is on the candidate's chain, and on our stored blocks.
   *
   * Then, we can apply the candidate by rolling back until the LCA, then, applying missing blocks until catching up
   * the candidate.
   *
   * @param candidate the block that we need to store
   * @return the state that needs to be applied in order to store the candidate block
   */

[thehenrytsai]

Resolution logic is independent of late-publishing of operations. And are tests written for roll-back detection and handling. Will rename this to be more of an documentation issue instead.

[OR13]

Non normative section with text.

[OR13]

What happens when I publish on ledger, but not on CAS... then later on CAS, and history changes... is it a feature, or is it a defect...

[OR13]

@csuwildcat need to add language about how to address this, and handle the new version history.

[csuwildcat]

Done