Uploaded image for project: 'Indy Node'
  1. Indy Node
  2. INDY-877

Backward compatibility for clients with state proof support

    XMLWordPrintable

Details

    • Task
    • Status: Complete
    • Medium
    • Resolution: Done
    • None
    • None
    • None

    Description

      We may have old client (python indy-clients) be not 100% backward compatible with pool having state proofs support.
      This is because old clients will check for f+1 equal replies from the nodes. Noes with state proof support will include proof into replies. As the proof's state root multi-sig may be different for the latest txn (this is because it becomes equal only with the next batch when Primary propagates )

      So, we have the following Options:

      Option1:

      • do nothing, and require update of the client (we will deprecate the python CLI in any case soon, so probably it isn't worth efforts here?)

      Option 2:

      • make sure that we always have equal replies.
      • It can be done by not calculating multi-sigs be individual nodes for the latest batch, and always use the multi-sig from the Primary only.
        We need to send multi-sig for timeout in this case
      • It will have a problem that we will not have a multi-sig for the ;ast batch immediately (only after some timeout)
      • Also we will still have a problem if some nodes in the pool have state proofs support (that is they return proofs in replies), but some nodes don't have it (that is they don't return it). It means that we may not have equal f+1 replies.

      Option3:

      • A new client must specify its version with each of the requests.
      • If there is no version, then we assume that the client doesn't support state proofs, and we don't return it with replies.
      • This is a long-term solution for other possible backward-compatibilities problems.

      I prefer either Option1 or Option3

      Attachments

        Activity

          People

            danielhardman Daniel Hardman
            ashcherbakov Alexander Shcherbakov
            Alexander Shcherbakov, Daniel Hardman, Olga Zheregelya
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: