Hyperledger Composer - участники и коллеги - PullRequest
0 голосов
/ 17 декабря 2018

Я недавно начал пытаться понять концепции Hyperledger Composer.

Исходя из того, что я понимаю, Hyperledger Composer - это просто слой поверх Hyperledger Fabric с целью упрощения процесса работы.Путаница возникла, когда я попытался понять разницу между участниками (термин композитора) и пэрами (термин ткани).Исходя из определения первого, я понимаю, что участники - это своего рода клиенты сети блокчейнов (например, производитель автомобилей, покупатель автомобилей), которые имеют пользовательский интерфейс и взаимодействуют с блокчейном через API REST.С другой стороны, одноранговые узлы являются фактическими узлами в сети.Интуитивно понятно, что эти понятия кажутся связанными друг с другом в том смысле, что организации (участнику) необходимо связаться с каждым собственным узлом (одноранговым узлом) в сети, где этот одноранговый узел имеет определенные права на чтение / запись в сети.

В своих примерных сетях они используют сетевую конфигурацию по умолчанию (crypto-config.yaml), в которой, среди прочего, они определяют один узел.Тем не менее, мне разрешено создавать разные типы участников с одним пэром в сети.Более того, один REST API генерируется для всей сети.

Для сети из двух сторон (например, производитель автомобилей и парень по обеспечению качества автомобилей) для меня было бы целесообразно иметь 2 участников (клиенты с пользовательским интерфейсом), 2 одноранговых узла (один с правами чтения / записи и один с правами только на чтение) и 2 REST API (один для производителя автомобилей и один для car-qa-guy).Тем не менее, похоже, что Composer работает не так.

1) Мое понимание того, что различным типам участников нужно иметь своего партнера в сети неправильно?

2) Почемуони генерируют один REST API, включая методы для каждого участника в сети, а не несколько, чтобы их могли использовать разные клиенты с разными правами?

1 Ответ

0 голосов
/ 08 апреля 2019

Чтобы ответить на ваши вопросы в первую очередь:

1) Ваше описание, что

Я понимаю, что участники являются своего рода клиентами сети блокчейнов (например, производитель автомобилей, покупатель автомобилей), которые имеют пользовательский интерфейс и взаимодействуют с блокчейном через API REST.С другой стороны, одноранговые узлы - это действительные узлы в сети.

действительно правильно, и я так понимаю после того, как Composer более полугода работал в нескольких проектах.Однако утверждение о том, что

различным типам участников должны иметь своих партнеров в сети

, не совсем верно.Как вы правильно сказали, Composer - это абстракция Fabric, цель которой - значительно упростить разработку прототипа на Fabric .В результате некоторые нюансы в Fabric утеряны.Например, это невероятно сложно, если вы хотите запустить Composer с поддержкой нескольких каналов (в смысле Fabric).

В случае участников против пиров они совершенно разные и почти или почти не имеют отношения друг к другу. одноранговые узлы принадлежат миру Fabric и отвечают за работу инфраструктуры блокчейна Fabric.В базовом руководстве (для Fabric, который также используется в Composer) у вас есть только один пир во всей сети Fabric .После запуска Fabric Network вы можете использовать Composer для моделирования и развертывания бизнес-сетей по своему усмотрению.Обратите внимание на различие между Fabric Network и Business Network . Сеть Fabric относится к базовой инфраструктуре цепочки блоков, построенной с использованием Fabric, тогда как бизнес-сеть представляет собой модель, созданную с помощью Composer. Участники живут в бизнес-сети , смоделированной и развернутой с помощью Composer, в то время как peers являются магистралью, управляющей инфраструктурой цепочки блоков.Следовательно, эти два слабо связаны в том, что без пиров вы просто не можете иметь никакой бизнес-сети вообще.Однако после запуска сети участники почти полностью независимы от одноранговых узлов .

2) Скорее всего, вы сгенерировали один REST API, потому что учебное пособие сформулировано как таковое.Если вы все еще помните, когда вы вызывали REST API, вам нужно было указать сетевую карту для бизнеса.Следовательно, каждый владелец бизнес-сетевой карты может очень хорошо запустить собственный REST API.На практике вы должны выдать удостоверение личности и визитную карточку для каждого участника в деловой сети.Каждый участник будет иметь различные разрешения, предоставляемые элементами управления доступом, которые вы создали при моделировании бизнес-сети (напомним, что эти элементы управления доступом записаны в ACL ).Следовательно, хотя каждый участник и каждый REST API могут видеть все доступные методы, они не могут вызывать те, которые они не должны вызывать.Конечно, вы должны правильно смоделировать политики контроля доступа в ACL.


Вот некоторые из моих мыслей о Composer.

Hyperledger Composer - это просто слой поверх Hyperledger Fabric с целью упрощения работы.

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

...