Гиперледжер Ткань дизайн - PullRequest
0 голосов
/ 07 декабря 2018

Я новичок в области DLT или "блокчейна" и пытаюсь создать приложение поверх Hyperledger Fabric .Прежде чем описать свой вариант использования, я должен упомянуть, что в силу характера моего варианта использования мне нужен закрытый и разрешенный «блокчейн», который оправдывает выбор Fabric (мне известны другие платформы, например Corda, частный Ethereum, но Fabric, похоже,лучше соответствовать моему варианту использования).

Вариант использования

Мой вариант использования состоит из двух разных типов участников.Ряд организаций (которые загружают и обмениваются информацией о лицах в распределенной книге) и клиент, который может запрашивать информацию о человеке.Клиент не должен видеть транзакции, загруженные организациями, и не будет иметь права на запись в DL.У него есть права только для чтения.Более того, организации доверяют друг другу, и между ними и клиентом также существует уровень доверия.

Проектные мысли

Основываясь на том, что я прочитал, ядумал о создании сети DL, которая включает в себя все эти стороны и использует каналы , которые, на основе документации , могут быть использованы для создания группировки среди ряда участников (организацийв моем случае) таким образом «скрывая» транзакции от сторон, не входящих в эту группу (клиент в моем случае).

Однако позже я прочитал о chaincode (он же умные контракты), который:

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

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

Я направляюсь в неправильном направлении (по дизайну)?

1 Ответ

0 голосов
/ 10 декабря 2018

Исходя из вашего описания, каналы Hyperledger Fabric звучат как хорошее решение.Вам также следует ознакомиться с частными коллекциями данных , так как это еще один способ скрыть некоторые данные от некоторых коллег.Какой вариант лучше всего подходит для вашего сценария, зависит от того, как структурированы ваши наборы данных, и от того, нужно ли вам также сохранять конфиденциальность данных у заказчика.

Клиенты не являются частью сети.Они запрашивают блокчейн, подключаясь к узлу, а затем запрашивая данные у этого узла.Затем они могут получить доступ только к данным, видимым для этого узла (которые хранятся локально этим узлом).Таким образом, клиент не может получить доступ к большему количеству данных, чем доступно одноранговому узлу, к которому он подключен.

В вашем примере у вас будет «клиентская» организация, имеющая хотя бы одного партнера.Этот одноранговый узел будет частью сети, и ваше клиентское приложение будет затем подключаться к нему для доступа к данным в регистре (обычно используя Hyperledger Fabric Node SDK ).

Существует дватипы цепного кода в Hyperledger Fabric.

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