Shoal Framework: Как уменьшить задержку Bullshark на Aptos?
Недавно Aptos Labs решили две важные открытые проблемы в DAG BFT, значительно снизив задержку и впервые устранив потребность в таймаутах в детерминированных реальных протоколах. В целом, в условиях отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев - на 80%.
Shoal - это фреймворк, который усиливает основанный на Narwhal протокол консенсуса ( с помощью обработки в конвейере и механизма репутации лидеров, таких как DAG-Rider, Tusk, Bullshark ). Обработка в конвейере уменьшает задержка сортировки DAG, вводя опорную точку в каждом раунде, а механизм репутации лидеров дополнительно улучшает проблему задержки, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять универсальные характеристики отклика, включая обычно требуемые оптимистичные ответы.
Эта технология очень проста и включает в себя последовательный запуск нескольких экземпляров базового протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
Фон
В процессе стремления к высокой производительности блокчейн-сети внимание людей всегда сосредотачивалось на снижении сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, достиг лишь 3500 TPS, что значительно ниже целевых 100000+ TPS.
Недавний прорыв произошел благодаря осознанию того, что распространение данных является основным узким местом, основанным на протоколе лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, в то время как компонент консенсуса только сортирует небольшое количество метаданных. Доклад по Narwhal сообщает о пропускной способности в 160 000 TPS.
Aptos ранее представил Quorum Store, реализацию Narwhal, которая разделяет распространение данных и консенсус, а также то, как использовать это для масштабирования текущего протокола консенсуса Jolteon. Jolteon - это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и смену видов в стиле PBFT, позволяя снизить задержку Hotstuff на 33%. Тем не менее, протоколы консенсуса на основе лидера явно не могут полностью использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, по мере увеличения пропускной способности лидер Hotstuff/Jolteon по-прежнему остается ограниченным.
Поэтому Aptos решил развернуть Bullshark на Narwhal DAG, что является консенсусным протоколом с нулевыми затратами на коммуникацию. К сожалению, по сравнению с Jolteon, DAG-структура, поддерживающая высокую пропускную способность Bullshark, приводит к 50% задержке.
В статье описано, как Shoal значительно уменьшает задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определённым раундом. Чтобы войти в раунд r, валидатор должен сначала получить n-f вершин, принадлежащих раунду r-1. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент времени наблюдать разные локальные представления DAG.
Ключевым свойством DAG является отсутствие двусмысленности: если два узла проверки имеют в своем локальном представлении DAG одинаковую вершину v, то у них полностью совпадает причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий предисловие
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как консенсусный протокол, где вершины представляют предложения, а ребра представляют голоса.
Хотя логика группового пересечения в структуре DAG различна, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Забронированная опора: каждые несколько раундов (, например, в Bullshark каждые два раунда ) будет заранее определенный лидер, вершина которого называется опорой.
Точки сортировки: валидатор независимо, но детерминировано решает, какие точки сортировки учитывать, а какие пропускать.
Упорядочение причинно-следственной истории: валидаторы обрабатывают свои упорядоченные списки анкеров один за другим, и для каждого анкера они сортируют все предыдущие неупорядоченные вершины в своей причинно-следственной истории с помощью некоторых детерминированных правил.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (2) все честные узлы-валидаторы создают упорядоченный список контрольных точек, чтобы все списки делили один и тот же префикс. В Shoal сделаны следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первым упорядоченным якорем.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя более практичная часть синхронной версии Bullshark имеет лучшую задержку по сравнению с асинхронной версией, она далека от оптимальной.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голосование. В обычных случаях требуется две итерации DAG для сортировки опорных точек, однако вершины в причинно-следственной истории опорной точки требуют больше итераций, чтобы дождаться сортировки опорных точек. В обычных случаях вершины в нечетной итерации требуют три итерации, а не опорные вершины в четной итерации требуют четыре итерации.
Вопрос 2: Задержка случаев сбоя. Указанный анализ задержки применим в условиях без сбоев, с другой стороны, если лидер раунда не успевает достаточно быстро транслировать опорные точки, то невозможно отсортировать опорные точки (, и они пропускаются ), поэтому все несортированные вершины из предыдущих раундов должны ожидать, пока следующая опорная точка будет отсортирована. Это значительно снижает производительность географической сети репликации, особенно потому, что Bullshark использует таймаут для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Каркас Shoal
Shoal решает две проблемы задержки, он усиливает Bullshark( или любой другой протокол BFT на основе Narwhal) с помощью конвейерной обработки, позволяя в каждом раунде иметь одну опору и снижая задержку всех неопорных вершин в DAG до трех раундов. Shoal также вводит механизм репутации лидеров без затрат в DAG, что делает выбор более склонным к быстрым лидерам.
Вызов
В контексте протокола DAG, конвейерная обработка и репутация лидера считаются сложными проблемами по следующим причинам:
Ранее попытки изменения логики ядра Bullshark через конвейерную обработку, казалось, были невозможными по своей сути.
Репутация лидеров вводится в DiemBFT и официально формализована в Carousel, основываясь на динамическом выборе будущих лидеров на основе прошлых достижений валидаторов, идеи якоря в Bullshark (. Хотя разногласия в отношении лидерства не нарушают безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает суть проблемы: динамический и детерминированный выбор вращающегося якоря необходим для достижения консенсуса, и валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности задачи реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
Протокол
Несмотря на вышеуказанные вызовы, решение скрыто в простоте.
В Shoal мы полагаемся на способность выполнять локальные вычисления на DAG и реализуем возможность хранения и переосмысления информации из предыдущих раундов. Благодаря тому, что все валидаторы согласны с основным пониманием первого упорядоченного якоря, Shoal последовательно комбинирует несколько экземпляров Bullshark и обрабатывает их по конвейерному принципу, что делает ) первым упорядоченным якорем и ( причиной причинной истории якоря, используемой для вычисления репутации лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Обработка конвейера
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-0b0928cb6240e994c1514c75e080a4b2.webp(
Репутация лидеров
При пропуске анкерных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейерной обработки бесполезны, так как новый экземпляр не может быть запущен до сортировки анкерной точки предыдущего экземпляра. Shoal обеспечивает малую вероятность выбора соответствующего лидера для обработки потерянных анкерных точек в будущем, присваивая каждому узлу проверки балл на основе истории недавней активности каждого узла проверки с помощью механизма репутации. Проверяющие, которые отвечают и участвуют в протоколе, получат высокий балл, в противном случае узлы проверки будут получать низкий балл, так как они могут выходить из строя, работать медленно или злонамеренно.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, ориентируясь на лидера с более высоким счетом. Чтобы валидаторы пришли к согласию по новому отображению, они должны прийти к соглашению по счету, тем самым достигнув консенсуса по истории, используемой для вывода счета.
В Shoal обработка по конвейерному методу и репутация лидера могут естественно сочетаться, так как они оба используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения консенсуса по первому упорядоченному якорному пункту.
На самом деле, единственное отличие заключается в том, что после сортировки опорных точек на r-ом раунде, валидатору необходимо просто на основании причинно-исторических данных упорядоченных опорных точек в r-ом раунде вычислить новое отображение F' начиная с r+1 раунда. Затем, узлы-валидаторы начинают использовать обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Нет больше задержек
Таймаут играет жизненно важную роль во всех реализациях BFT с детерминированной частичной синхронизацией, основанных на лидерах. Однако они вводят сложность, увеличивая количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку очень важно правильно их настроить, и часто требуется динамическая коррекция, поскольку это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за тайм-аут для вышедшего из строя лидера. Таким образом, настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истекает до того, как они смогут продвинуться вперед.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
9 Лайков
Награда
9
5
Поделиться
комментарий
0/400
ChainSpy
· 9ч назад
Зеленый свет, APT на луну
Посмотреть ОригиналОтветить0
AirdropHunter007
· 20ч назад
задержка снизилась на 40%? Эта волна На луну!
Посмотреть ОригиналОтветить0
BTCBeliefStation
· 21ч назад
удивительный Эта оптимизация поразила меня
Посмотреть ОригиналОтветить0
CounterIndicator
· 21ч назад
Бык, задержка снизилась более чем вдвое.
Посмотреть ОригиналОтветить0
MoonRocketTeam
· 21ч назад
Ай-ай, задержка, падение на 50%. Это окно запуска скоро на луну.
Оптимизация фрейма Shoal для Соглашения Aptos, Падение задержки Bullshark значительно снизилось
Shoal Framework: Как уменьшить задержку Bullshark на Aptos?
Недавно Aptos Labs решили две важные открытые проблемы в DAG BFT, значительно снизив задержку и впервые устранив потребность в таймаутах в детерминированных реальных протоколах. В целом, в условиях отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев - на 80%.
Shoal - это фреймворк, который усиливает основанный на Narwhal протокол консенсуса ( с помощью обработки в конвейере и механизма репутации лидеров, таких как DAG-Rider, Tusk, Bullshark ). Обработка в конвейере уменьшает задержка сортировки DAG, вводя опорную точку в каждом раунде, а механизм репутации лидеров дополнительно улучшает проблему задержки, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять универсальные характеристики отклика, включая обычно требуемые оптимистичные ответы.
Эта технология очень проста и включает в себя последовательный запуск нескольких экземпляров базового протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
Фон
В процессе стремления к высокой производительности блокчейн-сети внимание людей всегда сосредотачивалось на снижении сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, достиг лишь 3500 TPS, что значительно ниже целевых 100000+ TPS.
Недавний прорыв произошел благодаря осознанию того, что распространение данных является основным узким местом, основанным на протоколе лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, в то время как компонент консенсуса только сортирует небольшое количество метаданных. Доклад по Narwhal сообщает о пропускной способности в 160 000 TPS.
Aptos ранее представил Quorum Store, реализацию Narwhal, которая разделяет распространение данных и консенсус, а также то, как использовать это для масштабирования текущего протокола консенсуса Jolteon. Jolteon - это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и смену видов в стиле PBFT, позволяя снизить задержку Hotstuff на 33%. Тем не менее, протоколы консенсуса на основе лидера явно не могут полностью использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, по мере увеличения пропускной способности лидер Hotstuff/Jolteon по-прежнему остается ограниченным.
Поэтому Aptos решил развернуть Bullshark на Narwhal DAG, что является консенсусным протоколом с нулевыми затратами на коммуникацию. К сожалению, по сравнению с Jolteon, DAG-структура, поддерживающая высокую пропускную способность Bullshark, приводит к 50% задержке.
В статье описано, как Shoal значительно уменьшает задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определённым раундом. Чтобы войти в раунд r, валидатор должен сначала получить n-f вершин, принадлежащих раунду r-1. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент времени наблюдать разные локальные представления DAG.
Ключевым свойством DAG является отсутствие двусмысленности: если два узла проверки имеют в своем локальном представлении DAG одинаковую вершину v, то у них полностью совпадает причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий предисловие
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как консенсусный протокол, где вершины представляют предложения, а ребра представляют голоса.
Хотя логика группового пересечения в структуре DAG различна, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Забронированная опора: каждые несколько раундов (, например, в Bullshark каждые два раунда ) будет заранее определенный лидер, вершина которого называется опорой.
Точки сортировки: валидатор независимо, но детерминировано решает, какие точки сортировки учитывать, а какие пропускать.
Упорядочение причинно-следственной истории: валидаторы обрабатывают свои упорядоченные списки анкеров один за другим, и для каждого анкера они сортируют все предыдущие неупорядоченные вершины в своей причинно-следственной истории с помощью некоторых детерминированных правил.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (2) все честные узлы-валидаторы создают упорядоченный список контрольных точек, чтобы все списки делили один и тот же префикс. В Shoal сделаны следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первым упорядоченным якорем.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя более практичная часть синхронной версии Bullshark имеет лучшую задержку по сравнению с асинхронной версией, она далека от оптимальной.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голосование. В обычных случаях требуется две итерации DAG для сортировки опорных точек, однако вершины в причинно-следственной истории опорной точки требуют больше итераций, чтобы дождаться сортировки опорных точек. В обычных случаях вершины в нечетной итерации требуют три итерации, а не опорные вершины в четной итерации требуют четыре итерации.
Вопрос 2: Задержка случаев сбоя. Указанный анализ задержки применим в условиях без сбоев, с другой стороны, если лидер раунда не успевает достаточно быстро транслировать опорные точки, то невозможно отсортировать опорные точки (, и они пропускаются ), поэтому все несортированные вершины из предыдущих раундов должны ожидать, пока следующая опорная точка будет отсортирована. Это значительно снижает производительность географической сети репликации, особенно потому, что Bullshark использует таймаут для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Каркас Shoal
Shoal решает две проблемы задержки, он усиливает Bullshark( или любой другой протокол BFT на основе Narwhal) с помощью конвейерной обработки, позволяя в каждом раунде иметь одну опору и снижая задержку всех неопорных вершин в DAG до трех раундов. Shoal также вводит механизм репутации лидеров без затрат в DAG, что делает выбор более склонным к быстрым лидерам.
Вызов
В контексте протокола DAG, конвейерная обработка и репутация лидера считаются сложными проблемами по следующим причинам:
Ранее попытки изменения логики ядра Bullshark через конвейерную обработку, казалось, были невозможными по своей сути.
Репутация лидеров вводится в DiemBFT и официально формализована в Carousel, основываясь на динамическом выборе будущих лидеров на основе прошлых достижений валидаторов, идеи якоря в Bullshark (. Хотя разногласия в отношении лидерства не нарушают безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает суть проблемы: динамический и детерминированный выбор вращающегося якоря необходим для достижения консенсуса, и валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности задачи реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
Протокол
Несмотря на вышеуказанные вызовы, решение скрыто в простоте.
В Shoal мы полагаемся на способность выполнять локальные вычисления на DAG и реализуем возможность хранения и переосмысления информации из предыдущих раундов. Благодаря тому, что все валидаторы согласны с основным пониманием первого упорядоченного якоря, Shoal последовательно комбинирует несколько экземпляров Bullshark и обрабатывает их по конвейерному принципу, что делает ) первым упорядоченным якорем и ( причиной причинной истории якоря, используемой для вычисления репутации лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Обработка конвейера
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-0b0928cb6240e994c1514c75e080a4b2.webp(
Репутация лидеров
При пропуске анкерных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейерной обработки бесполезны, так как новый экземпляр не может быть запущен до сортировки анкерной точки предыдущего экземпляра. Shoal обеспечивает малую вероятность выбора соответствующего лидера для обработки потерянных анкерных точек в будущем, присваивая каждому узлу проверки балл на основе истории недавней активности каждого узла проверки с помощью механизма репутации. Проверяющие, которые отвечают и участвуют в протоколе, получат высокий балл, в противном случае узлы проверки будут получать низкий балл, так как они могут выходить из строя, работать медленно или злонамеренно.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, ориентируясь на лидера с более высоким счетом. Чтобы валидаторы пришли к согласию по новому отображению, они должны прийти к соглашению по счету, тем самым достигнув консенсуса по истории, используемой для вывода счета.
В Shoal обработка по конвейерному методу и репутация лидера могут естественно сочетаться, так как они оба используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения консенсуса по первому упорядоченному якорному пункту.
На самом деле, единственное отличие заключается в том, что после сортировки опорных точек на r-ом раунде, валидатору необходимо просто на основании причинно-исторических данных упорядоченных опорных точек в r-ом раунде вычислить новое отображение F' начиная с r+1 раунда. Затем, узлы-валидаторы начинают использовать обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Нет больше задержек
Таймаут играет жизненно важную роль во всех реализациях BFT с детерминированной частичной синхронизацией, основанных на лидерах. Однако они вводят сложность, увеличивая количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку очень важно правильно их настроить, и часто требуется динамическая коррекция, поскольку это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за тайм-аут для вышедшего из строя лидера. Таким образом, настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истекает до того, как они смогут продвинуться вперед.
К сожалению, на основе протокола лидера ) как