Рамка Shoal: как уменьшить задержку Bullshark на Aptos
Обзор
Aptos Labs решило две важные открытые проблемы в DAG BFT, значительно сократив задержку и впервые устранив необходимость в тайм-ауте в детерминированных реальных протоколах. В общем, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев — на 80%.
Shoal является фреймворком, который улучшает основанный на Narwhal консенсусный протокол (, такой как DAG-Rider, Tusk, Bullshark ), через конвейер и репутацию лидера. Конвейер уменьшает задержка сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидера дополнительно улучшает задержку, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять то, что мы называем свойством универсального отклика, которое включает в себя обычно необходимый оптимистичный отклик.
Эта технология очень проста и включает в себя последовательное выполнение нескольких экземпляров основного протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Мотивация
При стремлении к высокой производительности блокчейн-сетей внимание всегда уделялось снижению сложности коммуникации. Однако этот подход не дал значительного увеличения пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, достиг всего 3500 TPS, что намного ниже целевого значения в 100k+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является главным узким местом, основанным на соглашении лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от логики основного согласия, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, в то время как компоненты согласия просто упорядочивают ограниченное количество метаданных. В статье Narwhal сообщается о пропускной способности 160 000 TPS.
Ранее был представлен Quorum Store, а именно реализация Narwhal, которая отделяет распространение данных от консенсуса, а также то, как его можно использовать для расширения текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, который объединяет линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, очевидно, что протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на отделение распространения данных от консенсуса, с увеличением пропускной способности лидеры Hotstuff/Jolteon по-прежнему остаются ограниченными.
Таким образом, было решено развернуть Bullshark, протокол консенсуса с нулевыми затратами на коммуникацию, на Narwhal DAG. К сожалению, структура DAG, поддерживающая высокий уровень пропускной способности Bullshark, приводит к 50% задержке по сравнению с Jolteon.
В данной статье рассматривается, как Shoal значительно сокращает задержку Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы войти в r-ый раунд, валидатор должен сначала получить n-f вершин, принадлежащих к (r-1)-му раунду. Каждый валидатор может транслировать одну вершину за раунд, каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут наблюдать разные локальные представления DAG в любой момент времени.
Ключевое свойство DAG не является двусмысленным: если два узла-валидатора имеют одну и ту же вершину v в своих локальных представлениях DAG, то у них есть абсолютно одинаковая причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Общий порядок
Можно добиться согласия по общему порядку всех вершин в DAG без дополнительных коммуникационных затрат. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как консенсусный протокол, где вершины представляют собой предложения, а ребра - голоса.
Хотя логика пересечения групп в структуре DAG различна, все существующие протоколы консенсуса, основанные на Narwhal, имеют следующую структуру:
Предварительная опора: через несколько раундов будет заранее определённый лидер, вершина которого называется опорой;
Порядок якорей: валидаторы независимо, но с определенностью решают, какие якоря заказывать, а какие пропускать;
Упорядочение причинной истории: валидаторы по одному обрабатывают свои упорядоченные списки якорей и сортируют все предыдущие неупорядоченные вершины в причинной истории каждого якоря.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (2) все честные узлы верификации создают упорядоченный список якорных точек, чтобы все списки имели одинаковый префикс. В Shoal сделаны следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первой упорядоченной точкой привязки.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя синхронная версия Bullshark более практична и имеет лучшую задержку по сравнению с асинхронной версией, она все еще далеко не оптимальна.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голосование. В обычных случаях требуется две итерации DAG для упорядочивания опорных точек, однако вершины в причинно-историческом контексте опорной точки требуют больше итераций для ожидания сортировки опорной точки. В обычных случаях вершины в нечетных итерациях требуют три итерации, тогда как вершины не опорных точек в четных итерациях требуют четыре итерации.
Вопрос 2: задержка случаев сбоя, приведенный выше анализ задержки применим к безотказным условиям. С другой стороны, если лидер раунда не успевает достаточно быстро распространить контрольные точки, то контрольные точки не могут быть отсортированы ( и поэтому пропускаются ). Таким образом, все несортированные вершины в предыдущих раундах должны ждать, пока следующая контрольная точка не будет отсортирована. Это значительно снизит производительность географически распределенной сети, особенно учитывая, что таймаут Bullshark используется для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Shoal фрейм
Shoal улучшил Bullshark( или любой другой протокол BFT на основе Narwhal) с помощью конвейера, позволяя иметь одну опорную точку в каждом раунде и сокращая задержку всех не опорных вершин в DAG до трех раундов. Shoal также ввел в DAG механизм репутации лидера без затрат, что делает выбор более предвзятым в пользу быстрого лидера.
Вызов
В контексте протокола DAG вопросы конвейерной обработки и репутации лидеров считаются сложными по следующим причинам:
Ранее конвейер пытался изменить основную логику Bullshark, но это, по сути, кажется невозможным.
Репутация лидера вводится в DiemBFT и формализуется в Carousel, динамически выбирая будущих лидеров на основе прошлых результатов валидаторов в идее якоря в (Bullshark. Хотя разногласия по поводу лидерства не нарушают безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает суть проблемы: динамический и детерминированный выбор колесного якоря является необходимым для достижения консенсуса, и валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности задачи реализация Bullshark ) не поддерживает эти функции, включая текущие реализации в производственной среде (.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Протокол
В Shoal мы полагаемся на возможность выполнения локальных вычислений на DAG и реализуем возможность сохранения и переосмысления информации из предыдущих раундов. Благодаря основному пониманию, что все валидаторы согласны с первой упорядоченной привязкой, Shoal последовательно комбинирует несколько экземпляров Bullshark для их конвейерной обработки, так что ) первая упорядоченная привязка является точкой переключения экземпляров, а ( причинно-следственная история привязок используется для вычисления репутации лидера.
Конвейер
V, которое сопоставляет раунды с лидерами. Shoal последовательно запускает экземпляры Bullshark, так что для каждого экземпляра анкор заранее определен с помощью отображения F. Каждый экземпляр заказывает анкор, что вызывает переключение на следующий экземпляр.
Изначально Shoal запустил первый экземпляр Bullshark в первом раунде DAG и работал с ним до тех пор, пока не был определен первый упорядоченный якорь, например, в раунде r. Все валидаторы согласились с этим якорем. Таким образом, все валидаторы могут уверенно согласовать повторную интерпретацию DAG, начиная с раунда r+1. Shoal просто запустил новый экземпляр Bullshark в раунде r+1.
В лучшем случае это позволяет Shoal заказывать якорь в каждом раунде. Якорь первого раунда сортируется по первому экземпляру. Затем Shoal начинает новый экземпляр во втором раунде, у которого сам по себе есть якорь, сортируемый по этому экземпляру, затем другой новый экземпляр заказывает якорь в третьем раунде, и этот процесс продолжается.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Репутация лидера
При пропуске якорных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, поскольку новый экземпляр не может быть запущен до тех пор, пока не будет заказана предыдущая якорная точка. Shoal обеспечивает, чтобы соответствующий лидер для обработки потерянных якорных точек в будущем был маловероятен, присваивая каждому узлу проверки балл на основе истории недавней активности каждого узла проверки с использованием механизма репутации. Проверяющие, которые реагируют и участвуют в протоколе, получают высокий балл, в противном случае узлы проверки получают низкий балл, поскольку они могут выйти из строя, быть медленными или злоумышленниками.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное соответствие F от раунда к лидеру, отталкиваясь от лидеров с более высокими очками. Чтобы валидаторы могли достичь согласия по новым соответствиям, они должны достичь согласия по очкам, тем самым достигая согласия по истории, используемой для вывода очков.
В Shoal конвейеры и репутация лидеров могут естественно сочетаться, поскольку они оба используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле, единственное различие заключается в том, что после сортировки опорной точки в r-м раунде валидатору необходимо просто вычислить новое отображение F' начиная с r+1 раунда, основываясь на причинно-следственной истории упорядоченных опорных точек в r-м раунде. Затем узлы-валидаторы начиная с r+1 раунда используют обновленную функцию выбора опорной точки F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
Нет больше задержка
Тайм-аут играет ключевую роль во всех реализациях BFT с частичной синхронизацией, основанных на лидере. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Таймаут также значительно увеличивает задержку, поскольку крайне важно их правильно настроить, и их обычно необходимо динамически регулировать, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку таймаута для вышедшего из строя лидера. Поэтому настройки таймаута не могут быть слишком консервативными, но если время таймаута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдаем
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Shoal框架大幅 Падение Aptos上Bullshark Соглашение задержка 提升40%-80%
Рамка Shoal: как уменьшить задержку Bullshark на Aptos
Обзор
Aptos Labs решило две важные открытые проблемы в DAG BFT, значительно сократив задержку и впервые устранив необходимость в тайм-ауте в детерминированных реальных протоколах. В общем, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев — на 80%.
Shoal является фреймворком, который улучшает основанный на Narwhal консенсусный протокол (, такой как DAG-Rider, Tusk, Bullshark ), через конвейер и репутацию лидера. Конвейер уменьшает задержка сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидера дополнительно улучшает задержку, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять то, что мы называем свойством универсального отклика, которое включает в себя обычно необходимый оптимистичный отклик.
Эта технология очень проста и включает в себя последовательное выполнение нескольких экземпляров основного протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Мотивация
При стремлении к высокой производительности блокчейн-сетей внимание всегда уделялось снижению сложности коммуникации. Однако этот подход не дал значительного увеличения пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, достиг всего 3500 TPS, что намного ниже целевого значения в 100k+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является главным узким местом, основанным на соглашении лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от логики основного согласия, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, в то время как компоненты согласия просто упорядочивают ограниченное количество метаданных. В статье Narwhal сообщается о пропускной способности 160 000 TPS.
Ранее был представлен Quorum Store, а именно реализация Narwhal, которая отделяет распространение данных от консенсуса, а также то, как его можно использовать для расширения текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, который объединяет линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, очевидно, что протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на отделение распространения данных от консенсуса, с увеличением пропускной способности лидеры Hotstuff/Jolteon по-прежнему остаются ограниченными.
Таким образом, было решено развернуть Bullshark, протокол консенсуса с нулевыми затратами на коммуникацию, на Narwhal DAG. К сожалению, структура DAG, поддерживающая высокий уровень пропускной способности Bullshark, приводит к 50% задержке по сравнению с Jolteon.
В данной статье рассматривается, как Shoal значительно сокращает задержку Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы войти в r-ый раунд, валидатор должен сначала получить n-f вершин, принадлежащих к (r-1)-му раунду. Каждый валидатор может транслировать одну вершину за раунд, каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут наблюдать разные локальные представления DAG в любой момент времени.
Ключевое свойство DAG не является двусмысленным: если два узла-валидатора имеют одну и ту же вершину v в своих локальных представлениях DAG, то у них есть абсолютно одинаковая причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Общий порядок
Можно добиться согласия по общему порядку всех вершин в DAG без дополнительных коммуникационных затрат. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как консенсусный протокол, где вершины представляют собой предложения, а ребра - голоса.
Хотя логика пересечения групп в структуре DAG различна, все существующие протоколы консенсуса, основанные на Narwhal, имеют следующую структуру:
Предварительная опора: через несколько раундов будет заранее определённый лидер, вершина которого называется опорой;
Порядок якорей: валидаторы независимо, но с определенностью решают, какие якоря заказывать, а какие пропускать;
Упорядочение причинной истории: валидаторы по одному обрабатывают свои упорядоченные списки якорей и сортируют все предыдущие неупорядоченные вершины в причинной истории каждого якоря.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (2) все честные узлы верификации создают упорядоченный список якорных точек, чтобы все списки имели одинаковый префикс. В Shoal сделаны следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первой упорядоченной точкой привязки.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя синхронная версия Bullshark более практична и имеет лучшую задержку по сравнению с асинхронной версией, она все еще далеко не оптимальна.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голосование. В обычных случаях требуется две итерации DAG для упорядочивания опорных точек, однако вершины в причинно-историческом контексте опорной точки требуют больше итераций для ожидания сортировки опорной точки. В обычных случаях вершины в нечетных итерациях требуют три итерации, тогда как вершины не опорных точек в четных итерациях требуют четыре итерации.
Вопрос 2: задержка случаев сбоя, приведенный выше анализ задержки применим к безотказным условиям. С другой стороны, если лидер раунда не успевает достаточно быстро распространить контрольные точки, то контрольные точки не могут быть отсортированы ( и поэтому пропускаются ). Таким образом, все несортированные вершины в предыдущих раундах должны ждать, пока следующая контрольная точка не будет отсортирована. Это значительно снизит производительность географически распределенной сети, особенно учитывая, что таймаут Bullshark используется для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Shoal фрейм
Shoal улучшил Bullshark( или любой другой протокол BFT на основе Narwhal) с помощью конвейера, позволяя иметь одну опорную точку в каждом раунде и сокращая задержку всех не опорных вершин в DAG до трех раундов. Shoal также ввел в DAG механизм репутации лидера без затрат, что делает выбор более предвзятым в пользу быстрого лидера.
Вызов
В контексте протокола DAG вопросы конвейерной обработки и репутации лидеров считаются сложными по следующим причинам:
Ранее конвейер пытался изменить основную логику Bullshark, но это, по сути, кажется невозможным.
Репутация лидера вводится в DiemBFT и формализуется в Carousel, динамически выбирая будущих лидеров на основе прошлых результатов валидаторов в идее якоря в (Bullshark. Хотя разногласия по поводу лидерства не нарушают безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает суть проблемы: динамический и детерминированный выбор колесного якоря является необходимым для достижения консенсуса, и валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности задачи реализация Bullshark ) не поддерживает эти функции, включая текущие реализации в производственной среде (.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Протокол
В Shoal мы полагаемся на возможность выполнения локальных вычислений на DAG и реализуем возможность сохранения и переосмысления информации из предыдущих раундов. Благодаря основному пониманию, что все валидаторы согласны с первой упорядоченной привязкой, Shoal последовательно комбинирует несколько экземпляров Bullshark для их конвейерной обработки, так что ) первая упорядоченная привязка является точкой переключения экземпляров, а ( причинно-следственная история привязок используется для вычисления репутации лидера.
Конвейер
V, которое сопоставляет раунды с лидерами. Shoal последовательно запускает экземпляры Bullshark, так что для каждого экземпляра анкор заранее определен с помощью отображения F. Каждый экземпляр заказывает анкор, что вызывает переключение на следующий экземпляр.
Изначально Shoal запустил первый экземпляр Bullshark в первом раунде DAG и работал с ним до тех пор, пока не был определен первый упорядоченный якорь, например, в раунде r. Все валидаторы согласились с этим якорем. Таким образом, все валидаторы могут уверенно согласовать повторную интерпретацию DAG, начиная с раунда r+1. Shoal просто запустил новый экземпляр Bullshark в раунде r+1.
В лучшем случае это позволяет Shoal заказывать якорь в каждом раунде. Якорь первого раунда сортируется по первому экземпляру. Затем Shoal начинает новый экземпляр во втором раунде, у которого сам по себе есть якорь, сортируемый по этому экземпляру, затем другой новый экземпляр заказывает якорь в третьем раунде, и этот процесс продолжается.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Репутация лидера
При пропуске якорных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, поскольку новый экземпляр не может быть запущен до тех пор, пока не будет заказана предыдущая якорная точка. Shoal обеспечивает, чтобы соответствующий лидер для обработки потерянных якорных точек в будущем был маловероятен, присваивая каждому узлу проверки балл на основе истории недавней активности каждого узла проверки с использованием механизма репутации. Проверяющие, которые реагируют и участвуют в протоколе, получают высокий балл, в противном случае узлы проверки получают низкий балл, поскольку они могут выйти из строя, быть медленными или злоумышленниками.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное соответствие F от раунда к лидеру, отталкиваясь от лидеров с более высокими очками. Чтобы валидаторы могли достичь согласия по новым соответствиям, они должны достичь согласия по очкам, тем самым достигая согласия по истории, используемой для вывода очков.
В Shoal конвейеры и репутация лидеров могут естественно сочетаться, поскольку они оба используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле, единственное различие заключается в том, что после сортировки опорной точки в r-м раунде валидатору необходимо просто вычислить новое отображение F' начиная с r+1 раунда, основываясь на причинно-следственной истории упорядоченных опорных точек в r-м раунде. Затем узлы-валидаторы начиная с r+1 раунда используют обновленную функцию выбора опорной точки F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
Нет больше задержка
Тайм-аут играет ключевую роль во всех реализациях BFT с частичной синхронизацией, основанных на лидере. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Таймаут также значительно увеличивает задержку, поскольку крайне важно их правильно настроить, и их обычно необходимо динамически регулировать, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку таймаута для вышедшего из строя лидера. Поэтому настройки таймаута не могут быть слишком консервативными, но если время таймаута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдаем