Кажется, там много вопросов.Позвольте мне объяснить это шаг за шагом.Пожалуйста, оставляйте свои комментарии, если что-то не так или неясно.
Fabric спроектирован как Consortium Blockchain System и широко используется в бизнес-сценариях предприятия.В бизнес-сети Fabric каждая организация обычно содержит, по крайней мере, одного партнера и, необязательно, примерно один.
Представьте себе такой бизнес-сценарий.Несколько компаний хотят вести бизнес вместе.Однако они недостаточно доверяют друг другу.Поэтому они решили использовать ткань, чтобы решить свою болевую точку.Предположим, что эта сеть содержит 3 компании (организации), и каждая компания (организация) имеет одного партнера и одну компанию.
Теперь бизнес-сеть уже настроена.
Во-первых, позвольте мне объяснить концепциюзарегистрируйтесь.
- У каждой организации есть пользователь начальной загрузки, это происходит по имени пользователя и паролю, обычно в примерах используется admin / adminpw.Во время установки сервера ca этот пользователь начальной загрузки записывал в базу данных CA.После установки пользователь начальной загрузки регистрируется.но не зачислен.
- Следующая вещь -
enroll the bootstrap user.На этом шаге fabric-sdk (позже я буду использовать sdk) сначала сгенерирует пары закрытых / открытых ключей, затем сгенерирует csr ( запрос на подпись сертификата ), наконец, использует закрытый ключ для подписиcsr и отправьте подписанный csr на сервер Fabric-CA. - Когда сервер Fabric-CA получил подписанный CSR.Он генерирует сертификат для этого пользователя.Сертификат содержит открытый ключ пользователя.Fabric-ca будет использовать свой закрытый ключ для подписания этого запроса и добавления своей подписи к сертификату.
- Ответ sdk get (сертификат от 3) с сервера Fabric-CA.Fabric-SDK соединяет сертификат и закрытый ключ пользователя (мы называем это регистрацией) как ответ метода
enroll(). - Теперь пользователь начальной загрузки имеет свою регистрацию и может посещать сеть Fabric с помощью этой регистрации.
Мы можем использовать пользователя начальной загрузки для регистрации и регистрации новых пользователей в этой организации.Вот почему мы называем консорциумную систему блокчейнов как разрешенную систему блокчейнов.
Во-вторых, позвольте мне объяснить концепции sdk KVS (key-value-store).
Мы уже получили privateKey пользователяи справка из вышеперечисленных шагов.Так как же нам сохранить эти данные?Есть несколько вариантов: сохранить его в базе данных прикладного уровня, аппаратном зашифрованном кошельке, облачном HSM и т. Д.
Fabric-sdk предоставляет KVS для этого.Это необязательный выбор, вы можете использовать его или нет.Честно говоря, я не рекомендую использовать это в производственной системе.Если вы просто хотите что-то попробовать или протестировать, это хорошо, потому что это довольно просто.
По умолчанию fabirc-sdk-node будет использовать файловую систему KVS.Он хранит учетные данные на диске, это то, что вы упомянули в папке hfc-key-store.
Так что же произойдет, если KVS был украден?
Все записи украдены.Все сертификаты и частные ключи украдены.Злоумышленник может использовать эти сертификаты и privateKeys для посещения системы блокчейнов с идентификатором в этих сертификатах.Это катастрофа.
Для чего используется createUser ()?
Вместо сохранения этих регистраций в файловой системе.Лучший выбор для хранения в базе данных уровня приложений.Каждый раз, когда мы хотим посетить систему блокчейнов, мы можем сначала выполнить запрос из базы данных и получить сертификат и privateKey.Затем используйте интерфейс createUser() для создания нового пользовательского экземпляра.Этот экземпляр пользователя используется в качестве удостоверения для посещения системы блокчейна.
Наконец, позвольте мне объяснить поток транзакций в фабрике
У нас нет действительного сертификата пользователя и privateKey.Как отправить транзакцию в сеть Fabric?Как фабричный узел проверяет транзакцию и узнает, кто я?
- Каждая транзакция содержит личность пользователя.Если вы хотите отправить транзакцию по номеру
userA, вам следует позвонить по номеру setUserContext(userA) перед дальнейшим подтверждением вызова. - Предложение по транзакции содержит сертификат пользователя в заголовке сообщения.И до того, как транзакция будет отправлена на устройство-узел, sdk будет использовать закрытый ключ текущего пользователя для подписания этого предложения по транзакции.
- На стороне партнера.когда одноранговый узел получает запрос об одобрении, одноранговый узел будет использовать корневой сертификат Fabric-CA для проверки сертификата в этом запросе, так что одноранговый узел будет знать, что этот запрос исходит от удостоверения, выданного известным центром сертификации, теперь сертификат заслуживает доверия.Затем узел проанализирует сертификат и получит открытый ключ удостоверения, а затем использует этот открытый ключ для проверки подписи транзакции (я описал выше, что tx был подписан закрытым ключом, а теперь он проверен открытым ключом),теперь транзакция является надежной.
Из потока транзакций мы узнали, что транзакция должна быть отправлена с сертификатом пользователя и подписана его закрытым ключом.Вот почему мы разработали интерфейс setUserContext() в fabirc-sdk.
инструмент шифрования
Этот инструмент используется для генерации пар секретного / открытого ключа и соответствующих сертификатов при настройке системы.После этого нам нужен механизм динамического добавления / удаления идентификаторов.И решение может быть Fabric-CA.
Обратите внимание, Fabric-CA не является обязательным, вы можете использовать любой другой CA.