Может ли каждый участник Corda DLT иметь собственный CorDapp для управления общими состояниями?

Question

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

Например, в случае ethereum мы знал, что код смарт-контракта является идентичной копией на каждом узле. Это верно и для Корды? Если это не так, то какие части CorDapp (потоки, состояния, контракты и т. Д. c) должны быть одинаковыми для всех участников, а какие могут быть настроены или разработаны каждым участником?

Answer 1

• Обычно CorDapp разбивается на 2 модуля:

  1. Контракты CorDapp, который имеет состояние и свой контракт
  2. Рабочие процессы CorDapp, в котором есть потоки
• На всех узлах, работающих с определенным состоянием, должен быть установлен контракт CorDapp.
• Контракты CorDapp обычно разрабатываются одной организацией, которая подписывает CorDapp и распространяет его среди других узлов (см. здесь , почему вам необходимо подписать свое CorDapp).
• Таким образом, контракты CorDapp идентичны для всех узлов, и это гарантирует, что все они будут выполнять один и тот же контракт, когда они разрешат или завершат транзакцию, которая имеет это состояние.
• Контракты должны быть детерминированными c, означая, что для одной и той же транзакции они должны всегда возвращать один и тот же результат (т.е. транзакция прошла проверку или нет) независимо от того, на каком узле выполняется этот контракт; вот почему вы не можете получить доступ к внешним ресурсам (например, к базе данных узла), использовать даты или генераторы случайных чисел в своем контракте, потому что это приведет к разным результатам на разных узлах.
• Corda 4.4 теперь имеет определенное значение c JVM, которая защищает вас от ошибки при использовании недетерминированного кода c в вашем контракте. См. здесь .
• Подводя итог вышесказанному, контракты CorDapp должны быть одинаковыми для всех узлов, которые используют определенное состояние.
• Что касается рабочих процессов CorDapp, каждый узел может иметь свой собственный; особенно относительно потока ответчика; Ответственность за реализацию потока ответчика, как правило, лежит на отвечающем узле.
• Например, давайте возьмем IOU CorDapp; вы увидите, что для выдачи IOU существует инициатор .
• Инициатор проверит транзакцию (т.е. запустит контракт) перед подписанием и отправкой другим стороны.
• Даже если инициатор пропустил проверку транзакции, когда ответчик получает транзакцию, чтобы подписать или завершить ее; это неявно проверяется, поэтому респондент не будет подписывать или завершать транзакцию, которая не соответствует критериям, которые были согласованы всеми узлами (то есть контракт).
• Вы заметите, что в примере IOU инициатор отправляет транзакцию одной стороне, которая внутри потока ответчика проверяет эту транзакцию перед ее подписанием (см. здесь ). Так что, если инициатор отправлял транзакцию нескольким сторонам; каждая сторона может реализовать свой собственный респондент (так что одна сторона может принимать только IOU, которые меньше 100, другая будет принимать IOU, которые меньше, чем 500, и т. д.)
• Итак, для подведения итогов, узлы могут реализовать свои собственные рабочие процессы CorDapps, чтобы они могли иметь свои собственные правила проверки; но независимо от рабочих процессов CorDapps, все узлы должны иметь одно и то же Contracts CorDapp.