Блоки добываются в HyperLedger Fabric?

Я читал документацию о том, как проект HyperLedger Fabric реализует решение BlockChain с открытым исходным кодом: https://github.com/hyperledger/fabric/blob/master/docs/protocol-spec.md

Я видел, что используется алгоритм согласования PBFT, но я не понимаю, как блоки добываются и распределяются между всеми проверяющими узлами в сети BlockChain.

Ответы

Ответ 1

Hyperledger Validating Peers (VPs) не блокируют блоки и не разделяют блоки между ними. Вот как это работает:

  • Транзакция отправляется одному доверенному VP.
  • VP передает транзакцию всем другим VP.
  • Все VP достигают консенсуса (с использованием алгоритма PBFT) в следующем порядке для выполнения транзакций.
  • Все VP-серверы выполняют транзакции "самостоятельно" после общего порядка и строят блок (вычисляя хэши в основном) с выполненными транзакциями.

Все блоки будут одинаковыми, потому что: выполнение транзакции является детерминированным (должно быть) и фиксировано число tx в блоке.

Ответ 2

По данным Hyperledger Fabric 1.X

  1. Пользователь через Client SDK отправляет предложение о транзакции в адрес одобряющих партнеров.
  2. Одобряющий одноранговый узел проверяет транзакцию и вносит предложение об одобрении транзакции (с установленным значением "чтение/запись" (предыдущее значение/измененное значение)) и снова отправляет клиентский SDK.
  3. Клиентский SDK ожидает все одобрения, как только он получает все предложения одобрения, он делает один запрос вызова и отправляет заказчику.
  4. Заказчик проверяет аренду запроса вызова с помощью клиентского SDK, проверяя определенные Политики (Консенсус), проверяет транзакцию и добавляет в блок.
  5. В соответствии с конфигурацией, определенной для блока, после указанного времени или номера транзакции он формирует хэш блока с использованием хеша транзакции, метаданных и хеша предыдущего блока.
  6. Блоки транзакций "доставляются" Заказчику всем партнерам на канале.
  7. Все принимающие одноранговые узлы проверяют подтверждающую политику и гарантируют, что не было никаких изменений в состоянии регистра для переменных набора чтения, так как набор чтения был сгенерирован выполнением транзакции. После этого выполняются все транзакции в блоке и обновляется бухгалтерская книга с новым блоком и текущим состоянием актива.

Главная книга содержит

  • 1) База данных текущего состояния (уровень BD или Couch DB)
  • 2) Блокчейн (Файлы) (Связанные блоки)

Прочитать поток транзакций Hyperledger Fabric

Проверьте изображение для справки Hyperledger Fabric Transaction Flow

Ответ 3

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

  • PoET Доказательство прошедшего времени (необязательный алгоритм консенсуса в стиле Накамото, используемый для Sawtooth). У PoET с SGX есть BFT. У PoET Simulator есть ЦФТ. Не потребляет много ресурсов процессора, как в алгоритмах в стиле PoW, хотя все еще может работать с устаревшими блоками. См. Спецификацию PoET по адресу https://sawtooth.hyperledger.org/docs/core/release s/latest/Architecture/Стихи .html.
  • RAFT Консенсусный алгоритм, который выбирает лидера на срок произвольного времени. Лидер заменен, если это тайм-аут. Плот быстрее, чем PoET, но не BFT (Raft - CFT). Также Плот не раскладывается.
  • При отключенном консенсусе другой алгоритм консенсуса может быть изменен без повторной инициализации блокчейна или даже перезапуска программного обеспечения.

Для полноты, оригинальный алгоритм консенсуса с биткойнами (и использует майнинг):

  • PoW Доказательство Работы. Завершение работы (интенсивный процессорный алгоритм консенсуса в стиле Накамото). Обычно используется в неразрешенных блокчейнах