Этап проверки потока транзакций в сети Hyperledger Fabric (по предполагаемому сценарию)

Question

Наша команда является новичком в Hyperledger Fabric и проходит официальную документацию .Мы застряли в чем-то, где мы действительно ценим всю помощьДалее следует наше понимание (относящееся к вопросу), за которым следует фактический вопрос.

---

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

2. Далее, каждый узел в канале, которому был распределен этот блок, обрабатывает его независимо, хотя и вточно так же, как и все другие одноранговые узлы на этом канале (чтобы регистр можно было поддерживать согласованным)

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

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

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

---

Нашевопросы:

1. Что происходит сейчас, если эти коммитирующие одноранговые узлы во время валидации получат разные результаты (например, у каждого свой конечный результат) для блока, все в одно и то же время,Как будет обновляться регистр / состояние мира?Существует ли какой-либо набор одноранговых узлов, которые будут обрабатываться с более высоким приоритетом, чем остальные, или система может пойти на решение, основанное на консенсусе?Как будет разрешен такой конфликт?

2. Является ли это действительной возможностью (при таком событии - узлы однорангового узла становятся неконтролируемыми во время фазы проверки) при любых обстоятельствах?Или в сети уже есть проверки для предотвращения этого?

3. Какие могут быть возможные причины, которые могут привести к такой ситуации, если это произойдет?Возможная ошибка сети, приводящая к тому, что Заказчик отправляет несколько разных копий одного и того же блока разным партнерам?Или преднамеренное / злонамеренное изменение кода проверки, которым обладает каждый равноправный узел, который он затем будет выполнять при каждой транзакции внутри этого блока?Или, может быть, что-то еще?

   ---

Большое вам спасибо за терпение, которое вы прочитали.Мы ценим всю помощь, которую вы можете оказать в этом отношении.

Answer 1

Во-первых, я хотел бы исправить первую точку вашего понимания:

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

Матрица Hyperledger работает на архитектуре execute-order-validate .Транзакции из клиентских приложений сначала передаются на подтверждающие узлы.Подтверждающий узел выполняет предложенные транзакции, захватывает наборы для чтения и записи и отправляет их обратно в приложение в качестве ответов после подписания . Затем приложение отправляет ответы в виде транзакций в службу заказа.

Ответы на ваши вопросы:

1. Что происходит сейчас, если пэры каким-то образом это делаютне прийти к аналогичному результату (где разные коллеги предлагают свой конечный результат для блока)?Существует ли какой-либо набор одноранговых узлов, чей результат будет рассматриваться с более высоким приоритетом, чем у остальных, или система может пойти на решение, основанное на консенсусе?Как будет разрешен такой конфликт?

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

2. Является ли это допустимой (при возникновении такого события) при любых обстоятельствах?Или в сети уже есть проверки, чтобы этого не происходило?

Ответ.Это возможно в случае злонамеренных узлов, сбоя в работе узла, разбиения сети и т.

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

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