Уменьшение задержки Bullshark на Aptos: Подробное объяснение框架 Shoal
Aptos labs решили две важные открытые проблемы в DAG BFT, значительно уменьшив задержку и впервые устранив необходимость в приостановке в детерминированном реальном протоколе. В целом, задержка Bullshark была улучшена на 40% при отсутствии сбоев и на 80% в случае сбоев.
Фреймворк Shoal усиливает консенсусный протокол, основанный на Narwhal, (, такими как DAG-Rider, Tusk, Bullshark ), с помощью механизма конвейера и репутации лидера. Конвейер вводит одну опорную точку в каждом раунде, чтобы уменьшить задержку сортировки DAG, а репутация лидера гарантирует, что опорная точка связана с самыми быстрыми узлами верификации, что дополнительно улучшает задержку. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях, обеспечивая тем самым свойства универсального отклика.
Технология Shoal очень проста, она последовательно запускает несколько экземпляров базового протокола. Когда она инстанцируется с Bullshark, это похоже на группу "акул", которые участвуют в эстафете.
При стремлении к высокой производительности блокчейн-сетей внимание всегда уделялось снижению сложности связи, но это не привело к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem алгоритм Hotstuff достигал всего 3500 TPS, что значительно ниже целевого уровня в 100k+ TPS.
Недавний прорыв произошел благодаря осознанию того, что распространение данных является основной проблемой, основанной на соглашениях лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, все валидаторы одновременно распространяют данные, а компонента консенсуса только сортирует небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности в 160 000 TPS.
Aptos ранее представил Quorum Store, реализованный с помощью Narwhal, который отделяет распространение данных от консенсуса и используется для расширения текущего протокола консенсуса Jolteon. Jolteon сочетает в себе линейный быстрый путь Tendermint и изменения вида в стиле PBFT, уменьшая задержку Hotstuff на 33%. Однако, основанный на лидере протокол консенсуса не может в полной мере использовать потенциал пропускной способности Narwhal.
Таким образом, Aptos решил развернуть Bullshark, протокол консенсуса с нулевыми затратами на связь, на основе Narwhal DAG. К сожалению, DAG-структура, поддерживающая высокую пропускную способность Bullshark, приводит к 50% задержке.
В этой статье описывается, как Shoal значительно уменьшает задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с раундом. На входе в r-й раунд валидатор должен получить n-f вершин из r-1 раунда. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут наблюдать разные локальные представления DAG.
Ключевое свойство DAG заключается в том, что оно неразмытое: если два узла проверки имеют одинаковую вершину v в локальном представлении DAG, то у них полностью совпадают причинно-следственные истории v.
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на коммуникацию. Валидация в DAG-Rider, Tusk и Bullshark интерпретирует структуру DAG как протокол консенсуса, где вершины представляют собой предложения, а ребра представляют собой голоса.
Хотя логика взаимопересечения групп в структуре DAG различна, все консенсусные протоколы, основанные на Narwhal, имеют следующую структуру:
Предварительная точка: каждые несколько раундов есть заранее определенный лидер, его вершина называется точкой привязки.
Упорядочение якорей: валидаторы независимо, но с определенностью решают, какие якоря упорядочивать, а какие пропускать.
Упорядоченная причинно-следственная история: валидаторы обрабатывают упорядоченный список анкорных точек по одному, сортируя ранее неупорядоченные вершины в причинно-следственной истории каждой анкорной точки.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что список упорядоченных контрольных точек, созданный всеми честными узлами проверки, имеет одинаковый префикс на шаге (2). В Shoal мы наблюдаем:
Все валидаторы согласны с первой упорядоченной опорной точкой.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Задержка некоторых версий синхронизации лучше, чем у асинхронных версий, но все еще не является оптимальной.
Вопрос 1: Среднее время задержки блока. В Bullshark в каждой четной итерации есть опорная точка, а вершины нечетной итерации интерпретируются как голоса. В обычных случаях требуется две итерации DAG для сортировки опорных точек, но вершины в причинно-следственной истории опорных точек требуют больше итераций для ожидания сортировки опорных точек. В обычных случаях вершины нечетной итерации требуют три итерации, а вершины четной итерации, не являющиеся опорными, требуют четыре итерации.
Вопрос 2: Задержка в случае сбоя. Если один из лидеров не успевает вовремя транслировать опорную точку, то невозможно ее упорядочить ( пропускается ), и все непорядочные вершины из предыдущих раундов должны ждать, пока следующая опорная точка не будет упорядочена. Это значительно снижает производительность географической сети репликации, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
Каркас Shoal
Shoal улучшает Bullshark( или любой BFT протокол на основе Narwhal) с помощью конвейера, позволяя в каждом раунде иметь одну опорную точку, что снижает задержку всех неосновных вершин в DAG до трех раундов. Shoal также вводит механизм репутации лидера с нулевыми затратами в DAG, предпочитая выбор быстрых лидеров.
вызов
В протоколе DAG, проблемы с конвейером и репутацией лидера считаются сложными, по следующим причинам:
Ранее попытки изменить основную логику Bullshark в конвейере, похоже, были невозможны.
Доверие лидеров вводится в DiemBFT и формализуется в Carousel, динамически выбирая будущих лидеров на основе прошлых показателей валидаторов ( якорь в Bullshark ). Хотя разногласия по поводу лидерства не нарушают безопасность этих протоколов, они могут привести к совершенно различным порядкам в Bullshark, что поднимает основной вопрос: динамический и детерминированный выбор вращающегося якоря необходим для достижения консенсуса, валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности задачи реализация Bullshark ( включает в себя текущую производственную среду, которая ) не поддерживает эти функции.
соглашение
Несмотря на вышеупомянутые проблемы, решение скрыто в простоте.
Shoal полагается на способность выполнять локальные вычисления на DAG, чтобы сохранить и переинтерпретировать информацию из предыдущих раундов. Основываясь на согласии всех валидаторов с первым упорядоченным якорем, Shoal последовательно комбинирует несколько экземпляров Bullshark для потоковой обработки, что делает ( первым упорядоченным якорем, а ) причинная история якоря используется для вычисления репутации лидера.
( Конвейер
V, которое отображает раунд на лидера. Shoal последовательно запускает экземпляры Bullshark, где якорь каждого экземпляра заранее определяется отображением F. Каждый экземпляр сортирует якорь, что вызывает переключение на следующий экземпляр.
Сначала Shoal запустил первый экземпляр Bullshark на первом раунде DAG, который работал до тех пор, пока не был установлен первый упорядоченный опорный пункт ), как в r-м раунде ###. Все валидаторы согласились с этой опорной точкой, поэтому можно с уверенностью согласовать переинтерпретацию DAG с r+1 раунда. Shoal запускает новый экземпляр Bullshark на r+1 раунде.
В идеальных условиях это позволяет Shoal сортировать одно якорное звено за раунд. Первую точку якоря сортирует первый экземпляр. Затем, на втором раунде, Shoal запускает новый экземпляр, у которого есть свой собственный якорь, и он сортируется этим экземпляром, затем еще один новый экземпляр сортирует якорь на третьем раунде, и так продолжается.
Когда сортировка Bullshark пропускает якорные точки, задержка увеличивается. В этом случае конвейер бесполезен, так как новая инстанция не может быть запущена до сортировки предыдущей инстанции по якорной точке. Shoal назначает баллы для каждого узла проверки через механизм репутации, что обеспечивает малую вероятность выбора соответствующего лидера для обработки пропущенных якорных точек в будущем на основе его недавней истории активности. Проверяющие, которые реагируют и участвуют в протоколе, получают высокие баллы, в противном случае назначаются низкие баллы ) могут упасть, замедлиться или совершить зло ###.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, с уклоном в сторону лидера с высоким счетом. Для того чтобы валидаторы пришли к соглашению по новому отображению, они должны прийти к соглашению по счету, тем самым согласовавшись по истории, используемой для производных счетов.
В Shoal последовательности и репутация лидеров естественно сочетаются, поскольку они используют одну и ту же основную технологию: переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
Единственное отличие заключается в том, что после сортировки якорей в r-м раунде валидаторы начинают вычислять новое отображение F' с учетом причинно-исторических данных упорядоченных якорей из r-го раунда. Затем узлы валидаторов начинают использовать обновленную функцию выбора якорей F' для выполнения новой инстанции Bullshark, начиная с r+1 раунда.
( Не требуется больше времени
Тайм-ауты имеют решающее значение для всех реализаций BFT с определением на основе лидеров. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-ауты также значительно увеличивают задержку, поскольку их правильная настройка очень важна и обычно требует динамической регулировки, сильно зависящей от окружения ) сети ###. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если они слишком короткие, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истекает до того, как будет обеспечен прогресс.
К сожалению, протоколы, основанные на лидерах (, такие как Hotstuff и Jolteon ), по своей сути требуют тайм-аутов, чтобы гарантировать, что протокол может продвигаться вперед каждый раз, когда лидер терпит неудачу. Без тайм-аутов даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронном режиме невозможно различить неработоспособных и медленных лидеров, тайм-ауты могут привести к тому, что узлы проверки будут видеть изменения всех лидеров без активного консенсуса.
В Bullshark тайм-аут используется для построения DAG, чтобы гарантировать, что честные лидеры добавляют якорные точки в DAG с достаточной скоростью во время синхронизации для их сортировки.
Мы наблюдаем, что конструкция DAG обеспечивает "часы" для оценки скорости сети. При отсутствии пауз, как только n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продолжаться. Хотя Bullshark может не сортировать ( по скорости сети из-за проблем с лидерами ), DAG все равно растет с сетевой скоростью, несмотря на проблемы с некоторыми лидерами или асинхронностью сети. В конечном итоге, когда безотказные лидеры достаточно быстро транслируют якорные точки, вся причинно-следственная история якорных точек будет отсортирована.
В процессе оценки мы сравнили Bullshark в следующих ситуациях на предмет тайм-аута:
Быстрые лидеры, по крайней мере, быстрее других валидаторов. В этом случае оба метода обеспечивают одинаковую задержку, так как якорь упорядочен и не использует тайм-аут.
Ошибочные лидеры, в этом случае Bullshark без паузы обеспечивает лучшее время задержки, поскольку узлы проверки сразу пропускают свою привязку, в то время как проверяющие с паузой будут ждать ее истечения, прежде чем продолжить.
Медленный лидер, это единственный случай, когда Bullshark имеет лучшую производительность при тайм-ауте. Потому что без паузы контрольная точка может быть пропущена, так как лидер не может достаточно быстро ее транслировать, а при наличии паузы валидатор будет ждать контрольной точки.
В Shoal избегайте тайм-аутов, которые тесно связаны с репутацией лидера. Повторное ожидание.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Aptos внедрил фреймворк Shoal, что значительно снизило задержку Bullshark и устранило потребность в тайм-ауте.
Уменьшение задержки Bullshark на Aptos: Подробное объяснение框架 Shoal
Aptos labs решили две важные открытые проблемы в DAG BFT, значительно уменьшив задержку и впервые устранив необходимость в приостановке в детерминированном реальном протоколе. В целом, задержка Bullshark была улучшена на 40% при отсутствии сбоев и на 80% в случае сбоев.
Фреймворк Shoal усиливает консенсусный протокол, основанный на Narwhal, (, такими как DAG-Rider, Tusk, Bullshark ), с помощью механизма конвейера и репутации лидера. Конвейер вводит одну опорную точку в каждом раунде, чтобы уменьшить задержку сортировки DAG, а репутация лидера гарантирует, что опорная точка связана с самыми быстрыми узлами верификации, что дополнительно улучшает задержку. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях, обеспечивая тем самым свойства универсального отклика.
Технология Shoal очень проста, она последовательно запускает несколько экземпляров базового протокола. Когда она инстанцируется с Bullshark, это похоже на группу "акул", которые участвуют в эстафете.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
Фон
При стремлении к высокой производительности блокчейн-сетей внимание всегда уделялось снижению сложности связи, но это не привело к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem алгоритм Hotstuff достигал всего 3500 TPS, что значительно ниже целевого уровня в 100k+ TPS.
Недавний прорыв произошел благодаря осознанию того, что распространение данных является основной проблемой, основанной на соглашениях лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, все валидаторы одновременно распространяют данные, а компонента консенсуса только сортирует небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности в 160 000 TPS.
Aptos ранее представил Quorum Store, реализованный с помощью Narwhal, который отделяет распространение данных от консенсуса и используется для расширения текущего протокола консенсуса Jolteon. Jolteon сочетает в себе линейный быстрый путь Tendermint и изменения вида в стиле PBFT, уменьшая задержку Hotstuff на 33%. Однако, основанный на лидере протокол консенсуса не может в полной мере использовать потенциал пропускной способности Narwhal.
Таким образом, Aptos решил развернуть Bullshark, протокол консенсуса с нулевыми затратами на связь, на основе Narwhal DAG. К сожалению, DAG-структура, поддерживающая высокую пропускную способность Bullshark, приводит к 50% задержке.
В этой статье описывается, как Shoal значительно уменьшает задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с раундом. На входе в r-й раунд валидатор должен получить n-f вершин из r-1 раунда. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут наблюдать разные локальные представления DAG.
Ключевое свойство DAG заключается в том, что оно неразмытое: если два узла проверки имеют одинаковую вершину v в локальном представлении DAG, то у них полностью совпадают причинно-следственные истории v.
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на коммуникацию. Валидация в DAG-Rider, Tusk и Bullshark интерпретирует структуру DAG как протокол консенсуса, где вершины представляют собой предложения, а ребра представляют собой голоса.
Хотя логика взаимопересечения групп в структуре DAG различна, все консенсусные протоколы, основанные на Narwhal, имеют следующую структуру:
Предварительная точка: каждые несколько раундов есть заранее определенный лидер, его вершина называется точкой привязки.
Упорядочение якорей: валидаторы независимо, но с определенностью решают, какие якоря упорядочивать, а какие пропускать.
Упорядоченная причинно-следственная история: валидаторы обрабатывают упорядоченный список анкорных точек по одному, сортируя ранее неупорядоченные вершины в причинно-следственной истории каждой анкорной точки.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что список упорядоченных контрольных точек, созданный всеми честными узлами проверки, имеет одинаковый префикс на шаге (2). В Shoal мы наблюдаем:
Все валидаторы согласны с первой упорядоченной опорной точкой.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Задержка некоторых версий синхронизации лучше, чем у асинхронных версий, но все еще не является оптимальной.
Вопрос 1: Среднее время задержки блока. В Bullshark в каждой четной итерации есть опорная точка, а вершины нечетной итерации интерпретируются как голоса. В обычных случаях требуется две итерации DAG для сортировки опорных точек, но вершины в причинно-следственной истории опорных точек требуют больше итераций для ожидания сортировки опорных точек. В обычных случаях вершины нечетной итерации требуют три итерации, а вершины четной итерации, не являющиеся опорными, требуют четыре итерации.
Вопрос 2: Задержка в случае сбоя. Если один из лидеров не успевает вовремя транслировать опорную точку, то невозможно ее упорядочить ( пропускается ), и все непорядочные вершины из предыдущих раундов должны ждать, пока следующая опорная точка не будет упорядочена. Это значительно снижает производительность географической сети репликации, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
Каркас Shoal
Shoal улучшает Bullshark( или любой BFT протокол на основе Narwhal) с помощью конвейера, позволяя в каждом раунде иметь одну опорную точку, что снижает задержку всех неосновных вершин в DAG до трех раундов. Shoal также вводит механизм репутации лидера с нулевыми затратами в DAG, предпочитая выбор быстрых лидеров.
вызов
В протоколе DAG, проблемы с конвейером и репутацией лидера считаются сложными, по следующим причинам:
Ранее попытки изменить основную логику Bullshark в конвейере, похоже, были невозможны.
Доверие лидеров вводится в DiemBFT и формализуется в Carousel, динамически выбирая будущих лидеров на основе прошлых показателей валидаторов ( якорь в Bullshark ). Хотя разногласия по поводу лидерства не нарушают безопасность этих протоколов, они могут привести к совершенно различным порядкам в Bullshark, что поднимает основной вопрос: динамический и детерминированный выбор вращающегося якоря необходим для достижения консенсуса, валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности задачи реализация Bullshark ( включает в себя текущую производственную среду, которая ) не поддерживает эти функции.
соглашение
Несмотря на вышеупомянутые проблемы, решение скрыто в простоте.
Shoal полагается на способность выполнять локальные вычисления на DAG, чтобы сохранить и переинтерпретировать информацию из предыдущих раундов. Основываясь на согласии всех валидаторов с первым упорядоченным якорем, Shoal последовательно комбинирует несколько экземпляров Bullshark для потоковой обработки, что делает ( первым упорядоченным якорем, а ) причинная история якоря используется для вычисления репутации лидера.
( Конвейер
V, которое отображает раунд на лидера. Shoal последовательно запускает экземпляры Bullshark, где якорь каждого экземпляра заранее определяется отображением F. Каждый экземпляр сортирует якорь, что вызывает переключение на следующий экземпляр.
Сначала Shoal запустил первый экземпляр Bullshark на первом раунде DAG, который работал до тех пор, пока не был установлен первый упорядоченный опорный пункт ), как в r-м раунде ###. Все валидаторы согласились с этой опорной точкой, поэтому можно с уверенностью согласовать переинтерпретацию DAG с r+1 раунда. Shoal запускает новый экземпляр Bullshark на r+1 раунде.
В идеальных условиях это позволяет Shoal сортировать одно якорное звено за раунд. Первую точку якоря сортирует первый экземпляр. Затем, на втором раунде, Shoal запускает новый экземпляр, у которого есть свой собственный якорь, и он сортируется этим экземпляром, затем еще один новый экземпляр сортирует якорь на третьем раунде, и так продолжается.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
( Репутация лидера
Когда сортировка Bullshark пропускает якорные точки, задержка увеличивается. В этом случае конвейер бесполезен, так как новая инстанция не может быть запущена до сортировки предыдущей инстанции по якорной точке. Shoal назначает баллы для каждого узла проверки через механизм репутации, что обеспечивает малую вероятность выбора соответствующего лидера для обработки пропущенных якорных точек в будущем на основе его недавней истории активности. Проверяющие, которые реагируют и участвуют в протоколе, получают высокие баллы, в противном случае назначаются низкие баллы ) могут упасть, замедлиться или совершить зло ###.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, с уклоном в сторону лидера с высоким счетом. Для того чтобы валидаторы пришли к соглашению по новому отображению, они должны прийти к соглашению по счету, тем самым согласовавшись по истории, используемой для производных счетов.
В Shoal последовательности и репутация лидеров естественно сочетаются, поскольку они используют одну и ту же основную технологию: переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
Единственное отличие заключается в том, что после сортировки якорей в r-м раунде валидаторы начинают вычислять новое отображение F' с учетом причинно-исторических данных упорядоченных якорей из r-го раунда. Затем узлы валидаторов начинают использовать обновленную функцию выбора якорей F' для выполнения новой инстанции Bullshark, начиная с r+1 раунда.
( Не требуется больше времени
Тайм-ауты имеют решающее значение для всех реализаций BFT с определением на основе лидеров. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-ауты также значительно увеличивают задержку, поскольку их правильная настройка очень важна и обычно требует динамической регулировки, сильно зависящей от окружения ) сети ###. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если они слишком короткие, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истекает до того, как будет обеспечен прогресс.
К сожалению, протоколы, основанные на лидерах (, такие как Hotstuff и Jolteon ), по своей сути требуют тайм-аутов, чтобы гарантировать, что протокол может продвигаться вперед каждый раз, когда лидер терпит неудачу. Без тайм-аутов даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронном режиме невозможно различить неработоспособных и медленных лидеров, тайм-ауты могут привести к тому, что узлы проверки будут видеть изменения всех лидеров без активного консенсуса.
В Bullshark тайм-аут используется для построения DAG, чтобы гарантировать, что честные лидеры добавляют якорные точки в DAG с достаточной скоростью во время синхронизации для их сортировки.
Мы наблюдаем, что конструкция DAG обеспечивает "часы" для оценки скорости сети. При отсутствии пауз, как только n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продолжаться. Хотя Bullshark может не сортировать ( по скорости сети из-за проблем с лидерами ), DAG все равно растет с сетевой скоростью, несмотря на проблемы с некоторыми лидерами или асинхронностью сети. В конечном итоге, когда безотказные лидеры достаточно быстро транслируют якорные точки, вся причинно-следственная история якорных точек будет отсортирована.
В процессе оценки мы сравнили Bullshark в следующих ситуациях на предмет тайм-аута:
Быстрые лидеры, по крайней мере, быстрее других валидаторов. В этом случае оба метода обеспечивают одинаковую задержку, так как якорь упорядочен и не использует тайм-аут.
Ошибочные лидеры, в этом случае Bullshark без паузы обеспечивает лучшее время задержки, поскольку узлы проверки сразу пропускают свою привязку, в то время как проверяющие с паузой будут ждать ее истечения, прежде чем продолжить.
Медленный лидер, это единственный случай, когда Bullshark имеет лучшую производительность при тайм-ауте. Потому что без паузы контрольная точка может быть пропущена, так как лидер не может достаточно быстро ее транслировать, а при наличии паузы валидатор будет ждать контрольной точки.
В Shoal избегайте тайм-аутов, которые тесно связаны с репутацией лидера. Повторное ожидание.