Консенсус

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

Все сети Iroha 3 используют доступность данных и надежные маршруты вещания. Это требования консенсуса, а не дополнительные возможности развертывания.

Sumeragi

Sumeragi является консенсусным двигателем Iroha, который воспринимает транзакции из очереди, заставляет коллег-варидаторов согласовывать один и тот же упорядоченный блок и завершает этот блок только после того, как достаточное количество валидаторов воспроизведет тот же результат и подпишет сертификат обязательства.

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

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

Тот же Sumeragi трубопровод используется как в разрешенных, так и в назначенных установках доказательства участия (NPoS):

1. Валидатор предлагает блокировать транзакции в очереди.
2. Валидаторы подтверждают предложение, осуществляя сделки против одного и того же мирового государства.
3. Валидаторы обмениваются голосами и кворумными удостоверениями на текущую высоту и вид.
4. После достижения кворума, коллеги блокируют и обновляют свое мировое состояние.

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

Голоса - это небольшие подписанные консенсусные сообщения. Они относятся к предлагаемому блоку, высоте, просмотру и идентификации validator. Сертификат является прочным доказательством того, что достаточное количество validators наблюдали тот же результат для одного и того же блока.

Кворум, собиратели и наблюдатели

Количество валидаторов голосования n определяет бюджет византийской ошибки. Для сетей с не менее чем четырьмя валидаторами бюджет составляет f = floor((n - 1) / 3), а кворум обязательства - 2f + 1. Для одного-трех валидаторов требуются все валидаторы для обязательства, что полезно для разработки, но не имеет практического отставания в оффлайн режиме.

Коллекторы - это просто оптимизация. Вместо того, чтобы каждый проверяющий отправлял каждое голосование каждому другим проверяющему, Sumeragi может выбрать один или более коллекторов для высоты. Сборщики собирают голоса, публикуют прогресс кворума и сокращают количество дублированного избирательного трафика. Эффективные настройки коллектора выявлены через GET /v1/sumeragi/collectors; Сборник CLI Это ... ops sumeragi telemetry мгновенный снимок сообщает текущий сборщиков.

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

Просмотр изменений и восстановление

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

Восстановление полезной нагрузки отдельно от решения о окончательности. Пир может получить кворум или сертификат обязательства до того, как он получит полную полезную нагрузку блока. В этом случае пир использует надежную трансляцию (RBC) или синхронизацию блоков для восстановления полезной загрузки, проверяет ее по сравнению с объявленными хэшами и только после этого применяется блок к мировому государству и Kura.

Режим консенсуса

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

Режим .	Лучше всего подходит .	Установка валидатора	Операционный фокус
Разрешено .	Частные сети, консорциумные и управляемые операторами	Валидаторы исходят из надежной топологии , согласованной с развертыванием	Сохраняйте все валидаторы на одном и том же подписанном генезисе, доверенных сверстников, ключей сверстника и параметрах Sumeragi
НПОС	Общественные или ориентированные на Nexus сети , в которых проверка следует за политикой номинации и участия	Валидаторы выбираются по профилю NPoS, обычно на протяжении многих эпох, и требуют ключей BLS плюс доказательства владения	Сохраняйте сжатые снимки ставок, параметры эпохи, валидатор PoPs, и NPoS фазы времени выхода совпадают по всей сети

Разрешенный режим

Используйте режим с разрешением, когда список валидаторов является явным операционным выбором. Это обычная отправная точка для самостоятельного хостинга Iroha сети, потому что изменения в членстве являются преднамеренными действиями администратора или управления. Важным операционным правилом является то, что каждый validator должен работать с одинаковым взглядом на генезис, доверенные коллеги, BLS Доказательства владения; и Sumeragi Одно однородное с другой топологией или подписанным генезисом может предотвратить совершение сети.

Режим NPOS

Используйте режим NPoS, когда в профиле развертывания ожидается, что участие validator будет обусловлено номинацией и состоянием ставки. SORA Nexus Развертывания используют NPoS, и их генерируемые профили включают в себя BLS идентификации валидаторов, свидетельства о владении, установки эпохи и Sumeragi Параметры NPoS, необходимые при запуске. Изменения эпохи могут заменить активный валидатор, установленный на определенных высотах, Таким образом, операторы должны следить как за состоянием консенсуса, так и за состоянием ставки или номинации, которые обеспечивают следующий список.

Многосторонний консенсус

Путь консенсуса Iroha по многолинейным линиям реализуется через конфигурацию полосы и пространства данных Nexus. Sumeragi все еще завершает один заказанный блок-поток; полосы описывают, как транзакции маршрутизируются, планируются, учтены и хранятся внутри этого потока.

Конфигурация запуска создает три части состояния полосы:

• lane_catalog: конфигурированные полосы, каждая из которых содержит цифру LaneId, псевдонимы, пространство данных, видимость, профиль хранения, схему проверки и метаданные.
• dataspace_catalog: конфигурированные пространства данных, каждая из которых содержит цифру DataSpaceId и значение допустимости ошибок, используемое для измерения размера реле-комиссии.
• routing_policy: пара по умолчанию полосы/пространства данных и порядковые правила маршрутизации, которые могут совпадать с учетными записями или путями инструкций.

Когда транзакция входит в очередь, маршрутизатор полосы решает ее на RoutingDecision { lane_id, dataspace_id }. В режиме одного полоса это всегда полоса 0 и универсальное пространство данных. В режиме Nexus конфигурированный маршрутизатор применяет правила масштабирования пространства данных, маршрутизацию расчетов, правила учетной записи, явные правила маршрутизации и, наконец, стандартный маршрут. Решенная полоса и пространство данных должны присутствовать в их каталогах, а полоса должна быть связана с разрешенной полосой данных; в противном случае транзакция отклоняется до того, как она будет выставлена в очередь.

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

• Он пересекает транзакции по полосам, так что одна полоса не доминирует в блоке только потому, что его транзакции были выставлены в очереди первыми.
• Он применяется к единицам исполнения транзакций на полосу (TEU) пределы. Транзакции, которые превышают конфигурированную емкость полосы, откладываются и задерживаются, за исключением того, что первая операция с избыточным весом для полосы может быть допущена, чтобы избежать оживления.

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

Надежная трансляция (RBC)

Надежная трансляция (RBC) - это путь распространения и восстановления полезной нагрузки Sumeragi. Она помогает валидаторам и наблюдателям получить корпус блока, который принадлежит к предложению или сертификат обязательства, особенно когда сообщение BlockCreated, обновление синхронизации блоков или прямая передача полезной загрузки задерживаются или теряются.

RBC работает на уровне полезной загрузки. Предлагатель объявляет сессию RBC для высоты блока, просмотра и хэширования полезной нагрузки, а затем отправляет куски полезной погрузки через топологию commit. Peers отслеживают получение частей, проверяют восстановленную полезную нагрузку по сравнению с объявленным хэшем и обмениваются сигналами READY и DELIVER после того, как достаточное количество подтверждающих наблюдает ту же полезную загрузку. Сеансы ограничены TTL, фрагментом, фанутом, лимитами ожидаемого хранилища и постоянными магазинами, поэтому трафик восстановления не может расти безгранично.

RBC не является отдельным консенсусным решением, и он не заменяет сертификат обязательства. RBC вносит обязательные доказательства наличия и восстановления полезной нагрузки, в то время как прогресс commit обусловлен сертификатами commit плюс местная payload. Если сертификат прибывает до payload, peer может восстановить payload через RBC или блок-синхронизацию и затем commit.

В оперативном отношении RBC полезен для диагностики недостатков полезной нагрузки и наличия данных:

• iroha --output-format text ops sumeragi telemetry показывает совокупные голоса по доступности, текущее количество коллекционеров и ожидающие сессии RBC.
• GET /v1/sumeragi/rbc и GET /v1/sumeragi/rbc/sessions раскрыть подробные совокупные и активные данные сеанса по Torii, включая частичный прогресс, готовность, состояние доставки и задержку полосы или пространства данных; см. Torii конечные точки.
• Сигналы Prometheus, такие как sumeragi_rbc_store_pressure, sumeragi_rbc_backpressure_deferrals_total, а также показатели загрузки на полосу или пространство данных RBC помогают отделить потерю сети, восстановление частей и давление хранения; см. Выполнение и метрика.

Kura использует выведенную конфигурацию полосы для планирования хранения. Каждая полоса получает определённые названия хранения, такие как blocks/lane_000_core и merge_ledger/lane_000_core_merge.log; изменение жизненного цикла полосы может предусматривать, отменять или перемещать эти сегменты без изменения глобального порядка блоков.