Как я могу ограничить набор узлов от инициирования потока

Один из способов - иметь другой набор клиентов RPC для банка и страховой компании с соответствующими разрешениями. В разрешениях вы можете определить, какой пользователь может запускать какой поток. Разрешения можно установить в конфигурации вашего узла в файле build.gradle.

Есть несколько подходов, которые позволяют запретить узлам запускать определенные потоки:

• Вы можете установить CorDapp только для определения специфичных для страховщика потоков на узлах страховщика, но не на узлах банка.

  • Вы даже можете зайти так далеко, что предоставите доступ только к CorDapp JAR, содержащему потоки страховщика, к узлам страховщика.

• Как говорит Kid101, вы можете ограничить разрешения RPC узлов, чтобы разрешить только пользователям RPC узлов страховщика запускать рассматриваемый поток. Например:

  rpcUsers=[
      {
          username=exampleUser
          password=examplePass
          permissions=[
              "StartFlow.net.corda.flows.ExampleFlow1",
              "StartFlow.net.corda.flows.ExampleFlow2"
          ]
      }
      ...
  ]
  

Эти два подхода основаны на доверии между узлами. Нет ничего, что могло бы помешать одному из узлов банка получить CorDapp, содержащий потоки страховщика, и предоставить себе разрешения RPC для его запуска.

Если узлы не доверяют (что вы должны предположить, что они находятся в мире DLT), вам следует вместо этого воспользоваться одним из следующих подходов:

• Вы можете выполнить проверку в потоке респондента. Например, если у вас есть потоковая пара IssueInsurancePolicyFlow / IssueInsurancePolicyFlowResponder, вы можете добавить проверку в IssueInsurancePolicyFlowResponder, чтобы убедиться, что инициатором IssueInsurancePolicyFlow является узел страховщика.

  В псевдокоде:

  if (counterpartySession.counterparty !in insurerNodeList) {
      throw IllegalStateException("Flow must be run by an insurer node.")
  }
  

  Здесь вам решать, как получить список допустимых узлов страховщика. Например, его можно прочитать из базы данных отвечающего узла.

  Обратите внимание, что этот подход работает только в том случае, если есть необходимая подписывающая сторона, кроме инициатора (помимо нотариуса). В противном случае невозможно заставить недобросовестный банковский узел отправить сообщение честному контрагенту, чтобы вызвать поток ответчика (и, следовательно, включенную проверку).

  Также обратите внимание, что эта проверка должна быть помещена в поток ответчика, поскольку инициатор не может изменить код, выполняемый на стороне респондента. Если проверка помещена в поток инициатора, узел банка может создать свой собственный поток инициации и оставить эту проверку.

• Вы можете выполнить проверку в рамках самого контракта. Например:

  override fun verify(tx: LedgerTransaction) {
      ...
  
      val dealStateOutput = tx.outputsOfType<DealState>().single()
      if (dealStateOutput.insurer !in approvedInsurers)
          throw IllegalArgumentException("Unapproved insurer.")
  
      ...
  }  
  

  Сложность такого подхода заключается в том, чтобы в договор был включен список утвержденных страховщиков. Вы можете жестко запрограммировать его, но со временем он может измениться, что вынудит вас обновить контракт. Одним из альтернативных вариантов могло бы быть включение подписанной оракулом команды, указывающей, что данная страховая компания утверждена, и проверка того, что эта страховая компания соответствует страховщику по выходному состоянию.