Можно ли распространять консенсусную службу Hyperledger Fabric?

Я прочитал предложение ткани на архитектура консенсуса с интересом, и у меня есть вопрос о сервисе консенсуса. Мне кажется, что это фактически единый сервис, который гарантирует, что все одноранговые узлы получат блоки в порядке, который они решают. Таким образом, похоже, что он должен быть запущен одной идентифицированной и доверенной организацией в любой момент времени для данной цепочки. Не похоже, что услуга может быть распространена. Это правильно, или я неправильно понял?

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


hyperledger-fabric hyperledger consensus
person Rich N    schedule 12.12.2016    source источник

Ответы (1)


arrow_upward
8
arrow_downward

ОБНОВЛЕНИЕ. Kafka Orderer готов к работе:

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

Служба заказов на основе Kafka (производственная). Служба заказов на основе Kafka использует систему публикации / подсистемы Kafka для выполнения заказа, но включает ее в знакомое определение ab.proto, чтобы клиент однорангового заказчика код не должен быть написан специально для Kafka. Kafka в настоящее время является предпочтительным выбором для производственных развертываний, требующих высокой пропускной способности и доступности, но не требующих византийской отказоустойчивости.

Служба заказа PBFT (ожидается). Служба заказа PBFT будет использовать реализацию PBFT Hyperledger Fabric (в настоящее время находится в разработке) для упорядочивания сообщений византийским отказоустойчивым способом.

Консенсусная служба в Hyperledger Fabric - это подключаемый модуль. Есть информация о трех анонсированных реализациях:

Индивидуальный заказчик. Индивидуальный заказчик должен быть чрезвычайно простым в развертывании, непроизводственным заказчиком. Он состоит из единого процесса, который обслуживает всех клиентов, поэтому «консенсуса» не требуется, поскольку существует единый центральный орган. Соответственно, отсутствует высокая доступность или масштабируемость. Это делает соло идеальным вариантом для разработки и тестирования, но не для развертывания. Заказчик Solo зависит от резервной необработанной книги.

Заказчик Kafka (ожидает рассмотрения). Заказчик Kafka использует систему pubsub Kafka для выполнения заказа, но включает это в знакомое определение ab.proto, чтобы клиентский код однорангового заказчика не был написан специально для Кафка. В реальных развертываниях можно было бы ожидать, что прото-сервис Kafka будет локально привязан в процессе, поскольку у Kafka есть собственный надежный проводной протокол. Однако для тестирования или новых сценариев развертывания заказчик Kafka может быть развернут как сетевая служба. Ожидается, что Kafka станет предпочтительным выбором для производственных развертываний, которые требуют высокой пропускной способности и доступности, но не требуют византийской отказоустойчивости. Заказчик Kafka не использует вспомогательную необработанную книгу, потому что ею занимаются брокеры Kafka.

Заказчик PBFT (ожидается). Заказчик PBFT использует реализацию PBFT структуры гипертекстов для упорядочивания сообщений византийским отказоустойчивым способом. Поскольку реализация разрабатывается специально для структуры Hyperledger, ab.proto используется для проводной связи с заказчиком PBFT. Поэтому необычно привязывать заказчик PBFT к одноранговому процессу, хотя это может быть желательно для некоторых развертываний. Заказчик PBFT зависит от резервной необработанной книги.

  • Для Ордера Solo (доступного сейчас) утверждение «должно выполняться одной идентифицированной и доверенной организацией» верно.
  • Kafka Orderer (в разработке) - должна быть возможность распределенного развертывания.
  • PBFT Orderer - не нашел информации об этой реализации.
person Sergey Balashevich    schedule 19.12.2016