Консенсус Hyperledger Fabric - PullRequest
       17

Консенсус Hyperledger Fabric

0 голосов
/ 27 апреля 2018

Я новичок в Hyperledger Fabric. Я читаю с документом Fabric последней версии, но мне не ясно с консенсусом Fabric. Какой консенсус используется в Fabric? И как это работает? Пожалуйста, объясните.

1 Ответ

0 голосов
/ 28 апреля 2018

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

В Fabric, когда вы выполняете транзакцию, если не по ошибке, вы хотели бы, чтобы эта транзакция фиксировалась в регистре, то есть записывала транзакцию в блок в регистре в правильном порядке. И затем то же самое для последовательной синхронизации всех участников сети посредством совместного процесса. Так что этот процесс, который обеспечивает правильность порядка и синхронизации данных - называется консенсусом

HLF Стандартное определение:

Процесс синхронизации транзакций бухгалтерской книги по сети - чтобы гарантировать, что бухгалтерские книги обновляются только тогда, когда транзакции одобрены соответствующими участниками, и что, когда бухгалтерские книги действительно обновляются, они обновляются с теми же транзакциями в том же порядке - вызывается консенсус

Это делается в течение всего цикла транзакции следующими способами

  1. Когда вы отправляете транзакции, т.е. когда вы вызываете функцию в смарт-контракте, клиентский SDK, который вы используете, должен отправить это предложение по транзакции индоссантам (специфичным для этого смарт-контракта в конкретном канале). предложение транзакции использует криптографические учетные данные пользователя для создания уникальной подписи
  2. Подтверждающие одноранговые узлы выполняют свою долю проверок, как предложение действительно, пользователь, который попытался совершить транзакцию, имеет право на то же в этом канале и т. Д. . И тогда они имитируют транзакцию - и создают ответ и набор R / W. Он отправляется как ответ на предложение, возвращаемое в SDK.
  3. SDK накапливает их и проверяет, а затем отправляет их заказчику. Заказчик упорядочит транзакцию по времени, создаст блок и отправит этот блок всем партнерам в соответствующем канале
  4. Пиры, которые получают блок, начинают проверку каждой транзакции в блоке (используя цепной код системы проверки), чтобы убедиться в том, что для всех них выполнено одобрение, и правильный / правильный набор (проверка MVCC) . В зависимости от проверок транзакции могут быть помечены как действительные или недействительные

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

...