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

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

• Ткань (ИБМ)
• Корда (R3)
• Ироха
• Озеро Пилообразное (Intel)

В Fabric v0.6:

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

1. Лидер упорядочивает транзакции-кандидаты, которые должны быть включены в блок, и рассылает этот список упорядоченных транзакций всем другим одноранговым узлам проверки в сети.
2. When each of the Validation Peers receives the ordered list of transactions, each validation peer does the following:
   1. It starts executing the ordered transactions one by one.
   2. Как только все транзакции будут выполнены, он рассчитает хеш-код для вновь созданного блока (хеш-код включает в себя хэши для выполненных транзакций и конечное состояние мира).
   3. Затем он транслирует свой ответ (результирующий хэш-код) другим узлам в сети и начинает подсчитывать ответы от них.
   4. Если он увидит, что 2/3 всех одноранговых узлов имеют одинаковый хэш-код, он зафиксирует новый блок в своей локальной копии леджера.

В Fabric v1.0:

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

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

В Корде:

ПБТ не используется. В этой реализации используется другой подход к архитектуре.

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

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

<сильный>(1). Кто проверяет транзакцию?

Сделка проверяется группой из одного или нескольких нотариусов. Нотариусы — это узлы, единственной целью которых является устранение конфликтов при попытках двойного расходования средств.

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

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

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

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

pbft — это алгоритм консенсуса, предложенный Барбарой Лисков и Мигелем Кастро в 1999 году для предотвращения злонамеренных атак, поскольку злонамеренные атаки и программные ошибки могут привести к тому, что неисправные узлы будут демонстрировать византийское (то есть произвольное) поведение. pBFT был разработан для эффективной работы в асинхронных системах по сравнению с предыдущими алгоритмами bft, которые работали только в синхронных системах.

вот исследовательская работа, в которой говорится, что

Практический алгоритм репликации конечного автомата, допускающий византийские ошибки. Алгоритм обеспечивает как живучесть, так и безопасность при условии, что не более ⌊n-1 / 3⌋ из общего количества реплик одновременно неисправны. Это означает, что клиенты в конечном итоге получают ответы на свои запросы, и эти ответы являются правильными в соответствии с линеаризуемостью. Алгоритм работает в асинхронных системах, таких как Интернет, и включает в себя важные оптимизации, которые позволяют ему работать эффективно.

Алгоритм работы примерно такой:

1. Клиент отправляет запрос на вызов операции службы основному серверу.
2. Первичный многоадресный запрос к резервным копиям
3. Реплики выполняют запрос и отправляют ответ клиенту
4. Клиент ждет 1 ответа от разных реплик с одинаковым результатом; это результат операции.

Как и для всех методов репликации конечного автомата, к репликам предъявляются два требования:

• Они должны быть детерминированными
• Они должны начинаться в одном и том же состоянии.

Учитывая эти два требования, алгоритм обеспечивает свойство безопасности, гарантируя, что все исправные реплики согласуются с общим порядком выполнения запросов, несмотря на сбои.

Ограничения пбфт:

Алгоритм консенсуса pbft работает эффективно только тогда, когда количество узлов в распределенной сети меньше.

Ткань гиперледжера:

Согласно Hyperledger Fabric v1.4, используемые в настоящее время механизмы консенсуса включают SOLO, Kafka и Raft.

Гиперледжер Пилообразный:

Согласно Hyperledger Sawtooth, как используется pbft, хорошо объясняется здесь

В приведенном выше примере отсутствуют алгоритмы консенсуса от Hyperledger Sawtooth, так что вот они:

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