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

Dynamic validation may behave differently depending on unrelated aspects



    • Type: Bug
    • Status: Complete
    • Priority: Medium
    • Resolution: Invalid
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Environment:


    • Epic Link:
    • Sprint:
      Sprint 18.03 Stability, DKMS


      It has been found that the dynamic validation may behave differently depending on unrelated aspects such as whether the request is duplicate of another one previously committed into the ledger or not.

      Below there is a fragment of ev1.log.2018-01-24 from INDY-1103:

      2018-01-24 13:21:06,174 | DEBUG | replica.py ( 882) | processPrePrepare | ev1:0 received PRE-PREPARE(6, 2) from BIGAWSUSEAST1-001:0

      2018-01-24 13:21:06,174 | DEBUG | replica.py (1147) | _apply_pre_prepare | ev1:0 state root before processing PREPREPARE{'ppSeqNo': 2, 'discarded': 5, 'stateRootHash': 'GGtQgZh5r9oydsoavWnvMjL8YNo7Z32Q2xGsWpbvbJC', 'ppTime': 1516800066, 'instId': 0, 'ledgerId': 1, 'txnRootHash': '9RierSCibg6PkQNgHcTiJm9V1xGGaVvur2hAg3utLnXr', 'reqIdr': [('J4N1K1SEB8uY2muwmecY5q', 1515790849028036), ('J4N1K1SEB8uY2muwmecY5q', 1515166029574854), ('J4N1K1SEB8uY2muwmecY5q', 1515715477356351), ('J4N1K1SEB8uY2muwmecY5q', 1515167900196091), ('J4N1K1SEB8uY2muwmecY5q', 1515169081791625), ('J4N1K1SEB8uY2muwmecY5q', 1515169124908830)], 'digest': '4657fe4649366a3e6d9dc0a7773e20e375b2334936a16772fb5875e32f2cded6', 'viewNo': 6} is b'9gQ\xe9\xf5\t\xc5\x17\x0e\xfb\xf6\x93*\xd4$W\x11pp\xeaK\x98\x89\xc7\xd7\n\x17\xc8\xf3\xdc\xcc\xa8', D896UvYCu32N19Xj2ZPVNCQsQgDm4duHDhoQQQM99ozL

      2018-01-24 13:21:06,181 | WARNING | replica.py ( 682) | processReqDuringBatch | ev1:0 encountered exception UnauthorizedClientRequest('STEWARD cannot update verkey',) while processing Request: {'identifier': 'J4N1K1SEB8uY2muwmecY5q', 'reqId': 1515169124908830, 'operation': {'dest': '7SeddhvXz8NXMuQ3Y2Wda3', 'type': '1', 'verkey': '~PMiFnDt9fmNnSYzeEBY7ZQ'}, 'signature': '5XZeadMpaYjXuaiMJnoH2et6LTp8m37x7s9tTBmRdcaysc27jCLS9AUUUgsbjkTP4jdxXMp7p3aAJxZ6LLm5PJKf'}, will reject

      Here we see that the dynamic validation behaved differently for requests-duplicates and regular requests. The requests ('J4N1K1SEB8uY2muwmecY5q', 1515166029574854), ('J4N1K1SEB8uY2muwmecY5q', 1515167900196091), ('J4N1K1SEB8uY2muwmecY5q', 1515169081791625), ('J4N1K1SEB8uY2muwmecY5q', 1515169124908830) were NYM requests for the same existing nym. All these requests have the same values of the domain fields and the same sender. The values of the domain fields of these requests were the same as the values of these fields of this nym in the domain state at that moment. The difference is that the requests ('J4N1K1SEB8uY2muwmecY5q', 1515166029574854), ('J4N1K1SEB8uY2muwmecY5q', 1515167900196091), ('J4N1K1SEB8uY2muwmecY5q', 1515169081791625) are duplicates of the requests which had already been committed into the ledger (see the domain ledger of the node ev1 in the attachments to INDY-1103) while the request ('J4N1K1SEB8uY2muwmecY5q', 1515169124908830) had not been committed into the ledger yet. We can see that Replica.processReqDuringBatch called from Replica._apply_pre_prepare multiple times (one time for each request from the PREPREPARE message) invalidated only the request ('J4N1K1SEB8uY2muwmecY5q', 1515169124908830) but treated all the other requests in the PREPREPARE message as valid. (There are no warnings from Replica.processReqDuringBatch }} called from this very invocation of {{Replica._apply_pre_prepare below this fragment.) Also we can see that the primary which sent this PREPREPARE message also invalidated only the request ('J4N1K1SEB8uY2muwmecY5q', 1515169124908830) - discarded field value of PREPREPARE contains the index starting from which invalid requests are located.

      In scope of this ticket it must be determined which behavior of the dynamic validation is correct and then the correct behavior must be ensured for all the cases.

      NOTE: As to processing of requests-duplicates, we made a fix preventing processing of a PROPAGATE message with a request-duplicate. The version 1.2.50-stable of indy-node does not contain this fix, so we could observe the case with processing of requests-duplicates described above. However, the described case revealed non-uniform behavior of the dynamic validation that we should investigate.


          Issue Links



              anikitinDSR Andrew Nikitin
              spivachuk Nikita Spivachuk
              Alexander Shcherbakov, Andrew Nikitin, Nikita Spivachuk, Sean Bohan
              0 Vote for this issue
              4 Start watching this issue