Алгоритм PBFT в гиперледнике

Может ли кто-нибудь объяснить алгоритм PBFT подробно, не предоставив ссылки на то же самое? И как это работает в Hyperledger. Итак, после отправки транзакции на blockchain:

  1. Кто проверяет транзакцию?

  2. Как достигается консенсус по сделке?

  3. Как транзакция фиксируется в блокчейне?

ОТВЕТЫ

Ответ 1

"Hyperledger" - это блок-консорциум под Linux Foundation. В настоящее время в Hyperledger существует по меньшей мере 4 различных реализации блок-схем:

  • Ткань (IBM)
  • Corda (R3)
  • Iroha
  • Sawtooth Lake (Intel)

В Fabric v0.6:

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

  1. Руководитель заказывает кандидаты на транзакции, которые должны быть включены в блок, и передает этот список упорядоченных транзакций всем другим партнерам по проверке в сети.
  2. Когда каждый из валидаторов проверки получает упорядоченный список транзакций, каждый сверятель проверки выполняет следующие действия:
    1. Он начинает выполнять упорядоченные транзакции один за другим.
    2. Как только все транзакции будут выполнены, он будет вычислять хэш-код для вновь созданного блока (хэш-код включает хеши для выполненных транзакций и конечного состояния мира).
    3. Затем он передает свой ответ (полученный хэш-код) другим одноранговым узлам в сети и начинает подсчитывать ответы от них.
    4. Если он видит, что у 2/3 всех одноранговых узлов проверки есть один и тот же хэш-код, он переносит новый блок на свою локальную копию книги.

В Fabric v1.0:

Эта версия все еще находится в разработке. В v1 нет "лидера", отдельный заказ " Заказчик " отвечает за порядок транзакций в блоке. Эта услуга подключается и объявляется, что будет 3 различных варианта:

  1. Solo - единый процесс отвечает за заказ
  2. Заказчик Kafka - использует систему pubsub Kafka для выполнения заказа
  3. PBFT - пока не реализован.

В Корде:

PBFT не используется. Эта реализация использует другой подход к архитектуре.

Ответ 2

В Корде консенсус предоставляется нотариусами. Именно для нотариального оператора используется консенсусный алгоритм. BFT - один из вариантов. Здесь вы можете увидеть образец нотариуса Corda BFT: https://github.com/corda/corda/tree/master/samples/notary-demo.

Чтобы ответить на ваши вопросы:

(1). Кто проверяет транзакцию?

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

(2). Как достигается консенсус по сделке?

Использование стандартного алгоритма BFT. Каждый узел в нотариальном кластере голосует за то, считают ли они транзакцию двойной тратой. Окончательное решение основано на правиле большинства и может допускать до 1/3 узлов в кластере, являющихся вредоносными.

(3). Как транзакция передается блочной цепочке?

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

Ответ 3

Выше не хватает алгоритмов консенсуса от 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). Также Плот не раскладывается. Hyperledger Sawtooth имеет преимущество, заключающееся в том, что у него непростительный консенсус. Алгоритм может быть изменен без повторной инициализации блокчейна или даже перезапуска программного обеспечения.

Вот некоторые другие согласованные алгоритмы:

  • PoW Доказательство работы. Завершение работы (интенсивный процессорный алгоритм консенсуса в стиле Накамото). Обычно используется в неразрешенных блокчейнах
  • PoS Доказательство кола. Алгоритм консенсуса в стиле Накамото, основанный на наибольшем богатстве или возрасте (кол)
  • PBFT Практическая византийская терпимость к ошибкам. "Классический" алгоритм консенсуса, который использует конечный автомат. Использует лидера и блокирует выборы. PBFT - это трехфазный, интенсивный по сети алгоритм (n ^ 2 сообщений), поэтому он не масштабируется для больших сетей