Служба восстановления

Услуги по ремонту

RepairService отвечает за извлечение недостающих фрагментов, которые не удалось доставить с помощью основных протоколов связи, таких как Turbine. Он отвечает за управление протоколами, описанными ниже в разделе «Протоколы восстановления».

Проблемы:

1) Валидаторы могут не получить определенные фрагменты из-за сетевых сбоев.

2) Рассмотрим сценарий, в котором блочный магазин содержит набор слотов {1, 3, 5}. Затем Blockstore получает фрагменты для некоторого слота 7, где для каждого из фрагментов b, b.parent == 6, поэтому отношение родитель-потомок 6 -> gt; 7 хранится в блочном хранилище. Однако нет возможности привязать эти слоты к какому-либо из существующих банков в Blockstore, и поэтому протокол «Shred Repair» не будет восстанавливать эти слоты. Если эти слоты окажутся частью основной цепочки, это остановит процесс воспроизведения на этом узле.

Примитивы, связанные с ремонтом

Слоты эпохи: Каждый валидатор отдельно рекламирует в сплетнях различные части «слотов эпохи»:

• Тайник: сжатый набор всех завершенных слотов длиной в эпоху.
• Кэш: кодирование длин серий (RLE) последних N завершенных слотов, начиная с какого-то слота M, где N – это количество слотов, которые помещаются в пакет размера MTU.

«Слоты эпохи» в сплетнях обновляются каждый раз, когда валидатор получает полный слот в течение эпохи. Завершенные слоты обнаруживаются блочным магазином и отправляются по каналу в RepairService. Важно отметить, что мы знаем, что к моменту завершения слота «X» расписание эпох должно существовать для эпохи, содержащей слот «X», потому что WindowService отклонит фрагменты для неподтвержденных эпох.

Каждые N/2 заполненных слотов, самые старые N/2 слотов перемещаются из кеша в тайник. Базовое значение M для RLE также должно быть обновлено.

Протоколы запросов на восстановление

Протокол восстановления делает все возможное для развития структуры разветвления Blockstore.

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

1. Shred Repair (Addresss Challenge #1): Это самый простой протокол восстановления, предназначенный для обнаружения и заполнения «дыр» в бухгалтерской книге. Blockstore отслеживает последний корневой слот. Затем RepairService будет периодически повторять каждую вилку в блочном хранилище, начиная с корневого слота, отправляя запросы на восстановление валидаторам для любых недостающих фрагментов. Он будет отправлять не более N запросов на ремонт за итерацию. При ремонте клоков приоритет должен отдаваться ремонту вилок в зависимости от веса вилки лидера. Валидаторы должны отправлять запросы на исправление только тем валидаторам, которые отметили этот слот как завершенный в своих EpochSlots. Валидаторы должны отдавать приоритет восстановлению фрагментов в каждом слоте, за ретрансляцию которого они отвечают через турбину. Валидаторы могут вычислить, какие фрагменты они несут ответственность за повторную передачу, поскольку начальное значение для турбины основано на идентификаторе лидера, слоте и индексе фрагмента.

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

2. Упреждающее восстановление слотов (Решение задачи #2): Цель этого протокола состоит в том, чтобы обнаружить отношение цепочки «сиротских» слотов, которые в настоящее время не связаны ни с одним известным ответвлением. Ремонт клока должен отдавать приоритет ремонту потерянных слотов в зависимости от веса вилки лидера.

   • Blockstore будет отслеживать набор «сиротских» слотов в отдельном семействе столбцов.

   • RepairService будет периодически делать запросы «сироты» для каждого из сирот в блочном магазине.

     Запрос «сирота (сирота)» — «сирота» — это слот-сирота, который запрашивающая сторона хочет узнать.

     При получении ответов p, где p — это какой-то фрагмент в родительском слоте, валидаторы будут:

     • Вставьте пустой SlotMeta в хранилище блоков для p.slot, если он еще не существует.
     • Если p.slot существует, обновите родителя p на основе parents

     Примечание: как только эти пустые слоты будут добавлены в хранилище, протокол «Shred Repair» должен попытаться заполнить эти слоты.

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

Валидаторам следует попытаться отправить потерянные запросы тем валидаторам, которые пометили этот потерянный запрос как выполненный в своих EpochSlots. Если таких валидаторов не существует, выберите валидатора случайным образом с учетом ставок.

Восстановить протокол ответа

Когда валидатор получает запрос на клочок «S», он отвечает клоком, если он у них есть.

Когда валидатор получает фрагмент в ответ на восстановление, он проверяет EpochSlots, чтобы убедиться, что <= 1/3 сети пометила этот слот как завершенный. Если это так, они повторно отправляют этот фрагмент через связанный с ним путь турбины, но только в том случае, если этот валидатор ранее не передал этот фрагмент повторно.