Блоки добываются в 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

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

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

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

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

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

Ответ 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 Доказательство Работы. Завершение работы (интенсивный процессорный алгоритм консенсуса в стиле Накамото). Обычно используется в неразрешенных блокчейнах