Проблемы с развертыванием сети блокчейн Hyperledger Fabri c - PullRequest
1 голос
/ 18 марта 2020

Я готовлю сценарий развертывания для некоторого программного решения на основе блокчейна Hyperledger Fabri c ver. 2,0. Я рассмотрел официальные документы и примеры, но некоторые моменты, касающиеся развертывания / поддержки в реальной производственной среде, все еще неясны для меня.

Предположим, что в проектируемой сети блокчейнов участвуют следующие участники:

  • организация поставщика программного обеспечения, которая подготавливает и поддерживает базовую инфраструктуру блокчейна c;
  • консорциум из N организаций (Org1, Org2, ..., OrgN), участвующих в бизнес-операциях через сеть блокчейнов
  • в каждой организации в консорциуме есть системный администратор, который более или менее знаком с технологией блокчейна и Hyperledger Fabri c

Примерный сценарий развертывания, который я ожидал is:

  1. Все участники (поставщик программного обеспечения, Org1, Org2, ... OrgN) подготавливают необходимые удостоверения: выбирают их центры сертификации (CA), получают сертификаты X.509, генерируют личные и общедоступные c ключи для защищенного соединения et c.
  2. Поставщик программного обеспечения развертывает узел заказа, создает канал системы и определяет консорциум из N организаций. Поэтому Поставщик программного обеспечения должен получить опубликованные c удостоверения (MSP) ВСЕХ участвующих организаций.
  3. Все организации в консорциуме (Org1, Org2, ... OrgN) открывают хотя бы одного партнера в своей локальной среде.
  4. Консорциум согласовывает бизнес-правила, которые будут использоваться на производстве. Исходя из этого, некоторые организации (например, Org1) должны создать бизнес-канал с установленным соответствующим цепным кодом. Для этого в Org1 должны быть MSP ВСЕХ организаций, чтобы настроить бизнес-канал для всего консорциума.
  5. Все организации присоединяются к этому бизнес-каналу и используют только свои собственные MSP (с личными данными) для идентификации в сети. .
  6. После этого Org1 устанавливает согласованный код цепи в бизнес-канале. Требуемое количество других организаций утверждает этот код цепи.
  7. Когда утверждение завершено, Org1 фиксирует определение кода цепочки.
  8. Теперь все организации могут использовать свои собственные MSP для взаимодействия с подтвержденным кодом сети (запросить данные регистра и вызвать интеллектуальные контракты).

В соответствии с этим сценарием я считал, что только 2 организации (поставщик программного обеспечения и Org1) должны каким-то образом получить публичные c идентификаторы (MSP) ВСЕХ других членов консорциума, А для других организаций достаточно использовать их собственных частных MSP для надлежащей авторизации в сети.

Но на самом деле, по крайней мере, на шаге № 5 каждая организация технически должны явно работать с MSP всех членов консорциума. Вот команда, которая должна быть выполнена на шаге 5 каждой организацией для регистрации однорангового узла:

configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./output/channel-artifacts/organchors.tx -channelID mychannel -asOrg OrgX

Вышеупомянутый профиль TwoOrgsChannel определен в конфигурации канала (configtx.yaml ), который, в свою очередь, содержит ссылки на ССП всех организаций. Это означает, что при присоединении к каналу каждая организация должна использовать локальную копию конфигурации канала (configtx.yaml) и каким-то образом получать локальные копии всех MSP в консорциуме. Возникает сразу несколько вопросов:

a) Для производственного сценария действительно ли необходимо, чтобы каждая участвующая организация имела ССП всех других членов консорциума? Похоже, что администратору организации очень неудобно управлять этой сложной конфигурацией вручную ...

b) Почему требуется инициировать обновление узлов привязки явно каждой организацией, хотя информация о для всех узлов привязки уже указано в начальной конфигурации канала (configtx.yaml), используемой для подготовки блока генезиса для канала (по Org1)?

c) Что произойдет, если I пропустить обновление однорангового узла step?

d) И, кроме того, есть ли какой-нибудь способ в Hyperledger Fabri c добавить какую-либо организацию (или даже неавторизованных участников) с разрешением только для чтения для доступа к регистру в каком-либо канале? Например, что нам делать, если клиенты когда-нибудь попросят нас (как поставщика программного обеспечения) предоставить доступ к бухгалтерской книге аудиторским компаниям?

Не могли бы вы уточнить эти моменты?

Спасибо и С уважением

Игорь Егоров

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...