Проверка потоков в Корде

Question

Как нотариус / узел проверяет, что указанный поток c был вызван при получении транзакции?

Означает ли это, что Corda может гарантировать, что поток не был изменен по сравнению с тем, что было указано в соответствующем Cordapp?

Answer 1

Подробно:

1. Это DLT (технология распределенной книги); в некотором смысле, вы не можете никому доверять.
2. Нотариус не получает потоки, он принимает транзакции и следит за тем, чтобы не было двойных расходов (т. Е. Использованные ресурсы больше не потребляются).
3. Даже если вы дали узлу свой CorDapp, он может переопределить поток респондента. Смотрите ссылки ниже.
4. Неправильные предположения о потоках респондента: https://www.corda.net/blog/corda-flow-responder-wrong-assumptions/
5. Настройка потоков респондента: https://docs.corda.net/flow-overriding.html
6. Переопределение потоков из внешних CorDapps: https://dzone.com/articles/extending-and-overriding-flows-from-external-corda
7. Когда вы отправляете и получаете данные между инициатором и его ответчиками; полученные данные (на обоих концах) считаются ненадежными; Вы должны развернуть и проверить его: https://docs.corda.net/api-flows.html#receive

Короче говоря:

1. Ваш инициатор должен проверить все полученные данные от ответчика ( с).
2. Ваш респондент должен проверить все полученные данные от инициатора; плюс, если вы ожидаете, что инициатором является определенная сущность, вы должны проверить, что контрагент (который отправил вам сеанс потока) - это тот, кем вы ожидаете (например, flowSession.counterParty == "O = Good Org, L = Лондон, C = UK ").

Answer 2

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

Сетевые параметры определяют, какие банки smartapp для контрактов приемлемы для проверки. Наиболее распространенной формой ограничений контракта являются ограничения подписи, что означает, что может быть принят любой jar контракта, подписанный тем же ключом разработчика. Это препятствует тому, чтобы злонамеренный контрагент заставил вас выполнить слабую проверку: https://docs.corda.net/api-contract-constraints.html#signature -ограничений

Начиная с Corda 4, любой нераспознанный jar cordapp контракта не будет доверенным, если оператор узла явно не сообщит Corda доверять банке. https://docs.corda.net/cordapp-build-systems.html#cordapp -contract-attachments Как только подпись является доверенной, любые будущие баночки, подписанные этой подписью, будут неявно доверенными.