Добавление организации в образец сети HLF - но с настройками? - PullRequest
0 голосов
/ 27 июня 2019

Мы осуществляем переход от HL Composer к собственному Fabric и пытаемся приспособить рабочую демонстрационную модель, которую мы разрабатываем, к вашей демонстрационной сети здесь: https://hyperledger -fabric.readthedocs.io / о / релиз-1.4 / Сеть / network.html

Наши сетевые правила отличаются незначительно но может кто-нибудь подтвердить или исправить наш подход? Отличия отмечены ниже:

Пять организаций, R1, R2, R3, R4 и R5, совместно решили и записали в соглашение, что они будут создавать и использовать сеть HL Fabric, нашу демонстрационную сеть N.

Разница - R4 является корпоративным родителем R1 и осуществляет надзор за бизнесом за всем, что делает R1, но не участвует в повседневных операциях. Это важно, поскольку он хочет просматривать / просматривать все, но не предпринимает никаких действий.

Справочная информация - R1 кредиты, за отдельную плату, определенные активы для R2 и R3. Он может заимствовать один и тот же актив обоим, но условия кредитной сделки являются частными между R1 / R2 и R1 / R3. Поскольку R2 и R3 являются благотворительными, когда происходят определенные события, R2 и R3 также платят R5. R5 не проводит никаких других транзакций в сети, кроме как для получения и подтверждения получения этой благотворительной помощи.

Изменить для ясности: в отличие от примера сети HLF, наша демонстрационная сеть имеет R1 и R3 на C2, а не R2 и R3.

R4 был назначен инициатором сети (admin) - ему была предоставлена ​​возможность настроить первоначальную версию сети. R4 не собирается выполнять бизнес-транзакции в сети.

Разница - однако мы хотим, чтобы R4 имел полную прозрачность для всех транзакций, передачи активов и т. Д. Итак, мы хотим, чтобы R4 представлял собой «взгляд бога» демо-сети N. Все, включая деятельность канала.

Возможно ли это?

R1 и R2 нуждаются в частной связи внутри всей сети. R1 и R3 имеют одинаковую потребность.

Разница - R5 будет иметь право просматривать определенные транзакции по каждому из C1 и C2 - чтобы подтвердить, что с R2 и R3 осуществляются правильные платежи, и принять эти платежи. R5 может также представить отчет о транзакциях обратно в R1 и R4.

Возможно ли это? Как мы можем присоединиться к R5 к C1 и к C2 с определенными правами? C1 предоставит R5 права на рассмотрение предложений по оплате, принятие их и представление отчетов по ним. С2 сделал бы то же самое. Конфиденциальность будет сохраняться в пределах C1, то же самое для C2. IOW R2 и R3 не будут видеть друг друга.

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

В дополнение к вашим другим данным, у каждой из пяти организаций есть привилегированный центр сертификации, поэтому мы будем добавлять CA для R5.

Мы не считаем, что R5 понадобится отдельный партнер или служба заказа, но это может быть неправильно - может кто-то подтвердить или исправить?

Заранее спасибо за любые рекомендации.

Ответы [ 2 ]

1 голос
/ 28 июня 2019

Вы задали много вопросов, я постараюсь ответить на столько, сколько смогу, без особого порядка. Я думаю, что некоторая путаница возникает из-за того, что в этой системе нет эквивалента permissions.acl.

Разница - R4 является корпоративным родителем R1 и осуществляет надзор за бизнесом за всем, что делает R1, но не участвует в повседневных операциях. Это важно, поскольку он хочет просматривать / просматривать все, но не предпринимает никаких действий.

Если вы хотите, чтобы у каждой организации был свой ЦС, этот пункт не имеет значения. R4 будет иметь свои собственные равноправные узлы и CA. Если вы готовы рассматривать R4 и R1 как единое целое, вы можете сократить свою систему до 4 организаций.

R4 был назначен инициатором сети (admin) - ему была предоставлена ​​возможность настроить начальную версию сети.

Афайк нет такого понятия, как инициатор сети. В Hyperledger Composer то, что мы называли PeerAdmin, было администратором для одной организации. Для настройки сети каждая организация имеет своего администратора, который подключит одноранговые узлы к каналам и установит необходимый цепной код. Это должны быть совместные усилия.

R4 не собирается выполнять бизнес-транзакции в сети.

Отлично, тогда R4 не нужно делать никаких вызовов API. Здесь особо нечего делать.

Мы хотим дать R4 «взгляд бога» демо-сети

Возможно только в том случае, если равноправные узлы под R4 соединили все каналы. Они автоматически получают доступ для чтения и могут выполнять расширенные запросы.

R5 будет иметь право просматривать определенные транзакции на каждом из C1 и C2

Похоже, что R5 - это своего рода регулятор / надзиратель. Чтобы это работало, им нужно присоединиться к обоим каналам, которые вы выяснили, что означает, что либо парни из R5 получают доступ к узлам, которые настроил R4, либо имеют собственный узел. В сценарии IRL наблюдатель должен иметь для себя независимый одноранговый узел.

1 голос
/ 27 июня 2019

Что ж, пока все хорошо, но по мере того, как число организаций будет расти, поддержание отдельных каналов между наборами будет большим кошмаром, и это также повлияет на производительность.

Почему бы не попробовать использовать сбор личных данных вместо добавления новых каналов каждый раз, когда вам нужна конфиденциальность между двумя сторонами. Таким образом, только заинтересованные стороны в сети смогут просматривать данные транзакции.

R5 потребуется одноранговый узел.

...