Вопрос: Какие векторы атаки могут быть выявлены, если у вас есть партнеры и заказчики в одной организации, и она настроена неправильно? Кто будут актерами? Клиенты, администраторы, другие организации сети, полные аутсайдеры?
Для обычных потоков транзакций, по сути, есть три типа сторон, которые необходимо подписать, прежде чем транзакция может быть зафиксирована.
Во-первых, это отправитель или клиент, который запрашивает подтверждения, создает транзакции и отправляет их в заказ. В целом клиенты попадают в категорию Application Writers. Им разрешено вызывать одноранговые API и широковещательную рассылку заказов.
Во-вторых, одноранговые узлы, которые выполняют транзакцию и создают результат транзакции. Одноранговый узел знает мировое состояние на момент выполнения и бизнес-лог c, связанный с вызванным чейнкодом. Партнер подписывает результат выполнения, чтобы подтвердить, что бизнес-лог c был выполнен правильно. Одноранговые узлы обычно попадают в категорию приложений Reader, поскольку им необходимо видеть все транзакции, чтобы поддерживать свое мировое состояние в актуальном состоянии (чтобы они могли выполнять свои функции для создания новых транзакций).
Наконец, это заказчик (и), которые устанавливают sh общий заказ для транзакции, помещают его в блок, а затем подписывают, чтобы подтвердить, что консенсус был достигнут по заказу, и что партнеры могут считать заказ этой транзакции окончательным. Заказчики попадают в категорию Заказчиков Reader и Writer, поскольку они реплицируют существующие цепочки и присоединяются к ним.
Итак, на ваш вопрос, что может go ошибаться, если эти роли объединяются. Если идентичность составлена неверно или политики неправильно составлены так, что одна идентичность может удовлетворять всем этим ролям, тогда для этой личности становится возможным создать атаку с двойным расходом.
Сложно спроектировано, поскольку эта идентичность квалифицируется как клиент, он может создать две корректно выглядящие транзакции: одна отправляет 5 долларов Алисе, а другая отправляет те же 5 долларов Бобу. Обычно транзакции отправляются на заказ, получают общий заказ, и первая из них выигрывает. Однако, поскольку этот идентификатор может действовать как заказчик, он может создать два блока с одинаковым номером, каждый из которых содержит одну из транзакций. Теперь, без действующего сертификата сервера TLS, у клиента нет возможности внедрить блок в систему как заказчик, но, если удостоверение является одноранговым узлом, то теперь он может попытаться ввести блок в сеть через средства сплетен. . Если два разных одноранговых узла могут быть обмануты, заставив их принять два разных фальсифицированных блока, то у каждого из этих одноранговых узлов будет сложиться впечатление, что передаваемый ими tx действителен. И теперь вы произвели двойную трату. (Конечно, сеть в конечном итоге обнаружит сфабрикованный блок, и это можно объяснить, но ущерб был нанесен.) три роли проблематичны c. В Fabri c v1.0 единственными ролями были «Администратор» и «Участник». Таким образом, в это время было абсолютно важно, чтобы организация-заказчик и организация приложения не перекрывались. Затем была введена роль «Пэр», а затем и «Заказчик». Эти новые роли упрощают разработку политик для обеспечения безопасности вашей сети, но все же безопаснее разделить эти организации на уровне CA, чем на уровне ролей.
Дополнительный вопрос: какова предлагаемая альтернатива в данном сценарии? Следует ли каждую участвующую организацию разделить на отдельную партнерскую организацию и организацию-заказчик? Например, Company1PeerOrg, Company1OrdererOrg, Company2PeerOrg, ...?
Да, рекомендуется просто иметь логическую упорядочивающую организацию и организацию приложений для каждого члена.