Часто задаваемые вопросы

Одобрение

Архитектура одобрения:

Вопрос:Какое количество одноранговых узлов в сети должно одобрить транзакцию?
Ответ:Количество одноранговых узлов, необходимое для одобрения транзакции, определяется политикой одобрения, указанной в определении соответствующего чейнкода.
Вопрос:Нужно ли клиентскому приложению соединяться со всеми одноранговыми узлами?
Ответ:Клиенты должны подключаться только к тому количеству одноранговых узлов, которое требуется политикой одобрения чейнкода

Безопасность и контроль доступа

Вопрос:

Как обеспечить конфиденциальность данных?

Ответ:

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

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

В третьих, в качестве альтернативы хешированию данных при использовании приватных данных в Fabric клиентское приложение может хешировать или шифровать данные перед вызовом чейнкода. Если вы хешируете данные, то вам нужно будет предоставить средства обмена исходными данными. Если вы шифруете данные, то вам нужно будет предоставить средства обмена ключами для их расшифровки.

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

В пятых, данные реестра могут быть могут быть зашифрованы путем шифрования файловой системы на одноранговом узле, а данные при передаче шифруются с помощью TLS.

Вопрос:

Видят ли узлы упорядочения данные транзакций?

Ответ:

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

Модель разработки приложений

Вопрос:

Как клиенты приложений узнают о результатах проведения транзакции?

Ответ:

Результаты симуляции транзакции возвращаются одобряющим узлом клиенту в ответе на предложение транзакции. Если одобряющих узлов несколько, клиент может проверить, что все их ответы одинаковы, и отправить эти ответы вместе с одобрениями узлов дальше для упорядочивания и подтверждения. Одноранговые узлы либо подтвердят либо отклонят транзакцию, и клиент узнает об этом через событие, которое приложение получит через SDK.

Вопрос:

Как запросить данные из реестра?

Ответ:

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

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

Вопрос:

Как запросить историю данных, чтобы понять их происхождение?

Ответ:

Функция API чейнкода GetHistoryForKey() возвращает историю значений для ключа.

Вопрос:

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

Ответ:

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

Чейнкод (умные контракты и цифровые активы)

Вопрос:

Поддерживает ли Hyperledger Fabric логику умных контрактов?

Ответ:

Да. Мы называем эту функцию Чейнкод. Это наша интерпретация метода/алгоритма умного контракта с дополнительными возможностями.

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

Вопрос:

Как создать бизнес-контракт?

Ответ:

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

Вопрос:

Как создавать активы?

Ответ:

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

Существует два популярных подхода к определению активов в большинстве блокчейн-решений: модель UTXO без состояния, в которой остатки на счетах кодируются в записях проведенных транзакций; и модель с использованием счета, баланс которого сохраняется пространстве хранения состояния в реестре.

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

Вопрос:

Какие языки программирования поддерживаются для написания чейнкодов?

Ответ:

Чейнкод может быть написан на любом языке программирования и запущен в контейнере. На данный момент поддерживаются языки Go, Node.js и Java.

Вопрос:

Есть ли в Hyperledger Fabric собственная валюта?

Answer:

Нет. Однако, если вам действительно нужна собственная валюта в вашей блокчейн-сети, вы можете ее разработать с помощью чейнкода. Общим атрибутом собственной валюты является то, что некоторая ее сумма будет переводиться (путем вызова обрабатывающего ее чейнкода) при проведении каждой транзакции.

Различия в последних выпусках

Вопрос:Где можно найти информацию о различиях между выпусками?
Ответ:Различия между последующими выпусками предоставляются вместе с информацией о самих выпусках (см. Выпуски).
Вопрос:Где получить помощь по техническим вопросам, на которые не ответов выше?
Ответ:Пожалуйста, используйте StackOverflow.

Упорядочивающий сервис

Вопрос:У меня есть служба упорядочивания и я хочу заменить алгоритм консенсуса. Как это сделать?
Ответ:Явно это не поддерживается.
Вопрос:Что такое системный канал службы упорядочивания?
Ответ:Системный канал службы упорядочивания - это канал, с которым изначально загружаются узлы службы упорядочивания. Он используется для управления созданием каналов. В системном канале определены консорциумы и начальная конфигурация новых каналов. Во время создания канала определение организации в консорциуме, параметры и политики группы /Channel, а также параметры и политики группы /Channel/Orderer, объединяются для формирования определения нового канала.
Вопрос:Нужно ли при обновлении канала приложений обновлять системный канала службы упорядочения?
Ответ:После создания канала он управляется независимо от других каналов (включая системный канал службы упорядочения). В зависимости от того, какие изменения делаются, они могут быть или не быть желательными для переноса в другие каналы. Так, изменения MSP должны быть синхронизированы между всеми каналами, а изменения политики, скорее всего, будут специфичны для конкретного канала.
Вопрос:Может ли одна и та же организация владеть упорядочивающими узлами и одноранговыми узлами?
Ответ:Хотя это и возможно, такая конфигурация крайне не рекомендуется. По умолчанию политика /Channel/Orderer/BlockValidation позволяет подписывать блоки любым действительным сертификатом упорядочивающих организаций. Если у организации есть одновременно и упорядочивающие узлы, и одноранговые узлы, эта политика должна быть обновлена, чтобы подписывать блоки можно было только сертификатами узлов службы упорядочения.
Вопрос:Я хочу написать реализацию консенсуса для Fabric. С чего начать?
Ответ:Плагин консенсуса должен реализовывать интерфейсы Consenter и Chain, определенные в пакете consensus. Вы можете изучить пакет raft, чтобы получить больше информации для своей собственной реализации. Код службы упорядочения можно найти в пакете orderer.
Вопрос:Я хочу изменить конфигурацию службы упорядочения, например, время формирования нового блока. Что мне делать после запуска сети?
Ответ:Это относится к изменению конфигурации сети. Пожалуйста, ознакомьтесь со статьей Команда configtxlator.

BFT

Вопрос:Когда будет доступна BFT-версия службы упорядочения?
Ответ:Дата не установлена. Мы работаем над тем, чтобы сделать соответствующий выпуск в цикле 2.x, т.е. эта функция будет включена в выпуск с небольшими обновлениями в Fabric.