Shoal框架: Как уменьшить задержку Bullshark на Aptos?
Обзор
Aptos labs решило две важные открытые проблемы в DAG BFT, значительно сократив задержку и впервые устранив необходимость в паузах в детерминированных реальных протоколах. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев - на 80%.
Shoal является фреймворком, который улучшает любой протокол согласия на основе Narwhal (, такой как DAG-Rider, Tusk, Bullshark ), с помощью конвейерной обработки и механизма репутации лидеров. Конвейер снижает задержку сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидеров дополнительно улучшает проблему задержки, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидеров позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять свойства, которые мы называем универсальным ответом, содержащим обычно требуемый оптимистичный ответ.
Эта технология очень проста, она включает в себя последовательное выполнение нескольких экземпляров базового протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
Мотивация
При стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, 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, который является протоколом консенсуса с нулевыми затратами на связь. К сожалению, по сравнению с Jolteon, DAG-структура, поддерживающая высокую пропускную способность Bullshark, приводит к 50%-ному увеличению задержки.
В этой статье рассказывается о том, как Shoal значительно уменьшил задержку Bullshark.
Каждая вершина в 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. Хотя наиболее практичная часть Bullshark синхронной версии имеет лучшую задержку по сравнению с асинхронной версией, она все еще далека от оптимальной.
Вопрос 1: Среднее время задержки блока. В Bullshark каждая четная эпоха имеет якорную точку, а вершины каждой нечетной эпохи интерпретируются как голосование. В обычных случаях требуется две эпохи DAG для упорядочивания якорной точки, однако вершины в каузальной истории якорной точки требуют больше эпох для ожидания упорядочивания якорной точки. В обычных случаях вершины в нечетной эпохе требуют три эпохи, а ненакоренные вершины в четной эпохе требуют четыре эпохи.
Вопрос 2: Задержка в случае сбоя. Вышеупомянутое анализ задержек применимо к безаварийной ситуации, с другой стороны, если лидер раунда не успевает достаточно быстро распространить контрольную точку, то контрольная точка не может быть отсортирована ( и, следовательно, пропускается ), поэтому все несортированные вершины из предыдущих раундов должны ждать, пока следующая контрольная точка не будет отсортирована. Это значительно снижает производительность географической репликации сети, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
Shoal улучшил обработку Bullshark( или любого другого BFT-протокола на основе Narwhal) с помощью конвейера, позволяя иметь опорную точку в каждом раунде и уменьшая задержку всех не опорных вершин в DAG до трех раундов. Shoal также внедрил механизм репутации лидеров с нулевыми издержками в DAG, что делает выбор предпочтительным для быстрых лидеров.
Вызов
В контексте протокола DAG, конвейерная обработка и репутация лидеров считаются сложными вопросами по следующим причинам:
Ранее попытки изменить основную логику Bullshark в рамках конвейера обработки, но, по сути, это кажется невозможным.
Репутация лидеров вводится в DiemBFT и формализуется в Carousel, основываясь на динамическом выборе будущих лидеров на основе предыдущих результатов валидаторов, идея о якорях в Bullshark (. Хотя наличие разногласий в статусе лидера не нарушает безопасность этих соглашений, в Bullshark это может привести к совершенно различным порядкам, что поднимает основную проблему: динамический и детерминированный выбор якорей в цикле необходим для достижения консенсуса, и валидаторы должны достичь согласия по упорядоченной истории для выбора будущих якорей.
В качестве доказательства сложности проблемы мы отмечаем, что реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
![Подробное объяснение框架 Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Соглашение
Несмотря на указанные выше проблемы, решение скрыто в простоте.
В Shoal мы полагаемся на способность выполнять локальные вычисления на DAG и реализуем возможность сохранения и повторной интерпретации информации предыдущих раундов. Благодаря тому, что все валидаторы согласны с первым упорядоченным якорным пунктом, Shoal последовательно комбинирует несколько экземпляров Bullshark для их обработки в конвейерном режиме, что делает ) первым упорядоченным якорным пунктом, а ( причинной историей якорных пунктов для вычисления репутации лидеров.
Обработка по конвейеру
V, которое сопоставляет раунды с лидерами. Shoal последовательно запускает экземпляры Bullshark, так что для каждого экземпляра якорь заранее определяется с помощью отображения F. Каждый экземпляр заказывает якорь, что запускает переход к следующему экземпляру.
Изначально Shoal запустил первый экземпляр Bullshark в первом раунде DAG и продолжал его работу до определения первой упорядоченной опоры, например, в r-м раунде. Все валидаторы согласны с этой опорой. Таким образом, все валидаторы могут с уверенностью согласиться на переинтерпретацию DAG, начиная с раунда r+1. Shoal просто запустил новый экземпляр Bullshark в раунде r+1.
В лучшем случае это позволяет Shoal заказывать якорь в каждом раунде. Якорная точка первого раунда сортируется по первому экземпляру. Затем Shoal начинает новый экземпляр во втором раунде, который сам имеет якорную точку, сортируемую по этому экземпляру, затем другой новый экземпляр заказывает якорные точки в третьем раунде, и процесс продолжается.
![Подробное объяснение фрейма Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
Во время пропуска якорных точек в период сортировки Bullshark задержка увеличивается. В этом случае технология конвейерной обработки бессильна, поскольку новый экземпляр не может быть запущен до заказа якорной точки предыдущего экземпляра. Shoal обеспечивает малую вероятность выбора соответствующего лидера для обработки потерянных якорных точек в будущем, присваивая каждой проверочной ноде балл на основе истории недавней активности каждого узла проверки с помощью механизма репутации. Верификаторы, которые реагируют и участвуют в протоколе, получат высокие баллы, в противном случае ноды проверки будут получать низкие баллы, поскольку они могут быть сбоями, медленными или злонамеренными.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, отводя предпочтение лидерам с более высоким счетом. Чтобы валидаторы смогли согласовать новое отображение, они должны прийти к соглашению по счетам, достигнув согласия по истории, используемой для производных счетов.
В Shoal обработка в конвейерном режиме и репутация лидера могут естественно сочетаться, поскольку они используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения согласия по первому упорядоченному якорю.
На самом деле, единственное отличие заключается в том, что после сортировки анкерных точек на r-м раунде, валидатору нужно просто начать вычисление новой функции отображения F' с r+1-го раунда, основываясь на причинно-следственной истории упорядоченных анкерных точек в r-м раунде. Затем узлы-валидаторы начинают выполнять новый экземпляр Bullshark, используя обновленную функцию выбора анкерных точек F' с r+1-го раунда.
![Подробное объяснение схемы Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Больше нет таймаутов
Тайм-ауты играют решающую роль во всех реализациях BFT с определением на основе лидеров. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-ауты также значительно увеличивают задержку, поскольку важно правильно их настраивать, и обычно требуется динамическая настройка, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол накладывает полный штраф за задержку тайм-аута на вышедшего из строя лидера. Таким образом, настройки тайм-аута не должны быть слишком консервативными, но если тайм-аут слишком короткий, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff перегружены, и они терпят тайм-аут, прежде чем смогут продвинуться.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
21 Лайков
Награда
21
9
Поделиться
комментарий
0/400
RektCoaster
· 08-03 07:00
задержка снизилась так сильно? бык啊
Посмотреть ОригиналОтветить0
Degen4Breakfast
· 08-02 20:25
Ну и ладно, зачем так усложнять, если можно просто быть якорем?
Посмотреть ОригиналОтветить0
SatoshiLegend
· 08-02 17:14
Оптимизация DAG хороша, но не изменяя своих изначальных целей, можно достичь успеха. Под исходным кодом нет секретов.
Посмотреть ОригиналОтветить0
NonFungibleDegen
· 08-01 16:37
бычий af на aptos rn... 80% быстрее? вероятно, ничего сер
Посмотреть ОригиналОтветить0
Ser_This_Is_A_Casino
· 07-31 12:48
Уменьшение задержки может привести к таким последствиям.
Рамка Shoal значительно улучшает производительность Bullshark на цепочке Aptos, максимальная задержка сокращена на 80%.
Shoal框架: Как уменьшить задержку Bullshark на Aptos?
Обзор
Aptos labs решило две важные открытые проблемы в DAG BFT, значительно сократив задержку и впервые устранив необходимость в паузах в детерминированных реальных протоколах. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев - на 80%.
Shoal является фреймворком, который улучшает любой протокол согласия на основе Narwhal (, такой как DAG-Rider, Tusk, Bullshark ), с помощью конвейерной обработки и механизма репутации лидеров. Конвейер снижает задержку сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидеров дополнительно улучшает проблему задержки, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидеров позволяет Shoal использовать асинхронную конструкцию DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять свойства, которые мы называем универсальным ответом, содержащим обычно требуемый оптимистичный ответ.
Эта технология очень проста, она включает в себя последовательное выполнение нескольких экземпляров базового протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
Мотивация
При стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, 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, который является протоколом консенсуса с нулевыми затратами на связь. К сожалению, по сравнению с Jolteon, DAG-структура, поддерживающая высокую пропускную способность Bullshark, приводит к 50%-ному увеличению задержки.
В этой статье рассказывается о том, как Shoal значительно уменьшил задержку Bullshark.
! 万字详解Shoal框架:如何减少Aptos上的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. Хотя наиболее практичная часть Bullshark синхронной версии имеет лучшую задержку по сравнению с асинхронной версией, она все еще далека от оптимальной.
Вопрос 1: Среднее время задержки блока. В Bullshark каждая четная эпоха имеет якорную точку, а вершины каждой нечетной эпохи интерпретируются как голосование. В обычных случаях требуется две эпохи DAG для упорядочивания якорной точки, однако вершины в каузальной истории якорной точки требуют больше эпох для ожидания упорядочивания якорной точки. В обычных случаях вершины в нечетной эпохе требуют три эпохи, а ненакоренные вершины в четной эпохе требуют четыре эпохи.
Вопрос 2: Задержка в случае сбоя. Вышеупомянутое анализ задержек применимо к безаварийной ситуации, с другой стороны, если лидер раунда не успевает достаточно быстро распространить контрольную точку, то контрольная точка не может быть отсортирована ( и, следовательно, пропускается ), поэтому все несортированные вершины из предыдущих раундов должны ждать, пока следующая контрольная точка не будет отсортирована. Это значительно снижает производительность географической репликации сети, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
! 万字详解Shoal框架:如何减少Aptos上的Bullshark延迟?
Рамка Shoal
Shoal улучшил обработку Bullshark( или любого другого BFT-протокола на основе Narwhal) с помощью конвейера, позволяя иметь опорную точку в каждом раунде и уменьшая задержку всех не опорных вершин в DAG до трех раундов. Shoal также внедрил механизм репутации лидеров с нулевыми издержками в DAG, что делает выбор предпочтительным для быстрых лидеров.
Вызов
В контексте протокола DAG, конвейерная обработка и репутация лидеров считаются сложными вопросами по следующим причинам:
Ранее попытки изменить основную логику Bullshark в рамках конвейера обработки, но, по сути, это кажется невозможным.
Репутация лидеров вводится в DiemBFT и формализуется в Carousel, основываясь на динамическом выборе будущих лидеров на основе предыдущих результатов валидаторов, идея о якорях в Bullshark (. Хотя наличие разногласий в статусе лидера не нарушает безопасность этих соглашений, в Bullshark это может привести к совершенно различным порядкам, что поднимает основную проблему: динамический и детерминированный выбор якорей в цикле необходим для достижения консенсуса, и валидаторы должны достичь согласия по упорядоченной истории для выбора будущих якорей.
В качестве доказательства сложности проблемы мы отмечаем, что реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
![Подробное объяснение框架 Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Соглашение
Несмотря на указанные выше проблемы, решение скрыто в простоте.
В Shoal мы полагаемся на способность выполнять локальные вычисления на DAG и реализуем возможность сохранения и повторной интерпретации информации предыдущих раундов. Благодаря тому, что все валидаторы согласны с первым упорядоченным якорным пунктом, Shoal последовательно комбинирует несколько экземпляров Bullshark для их обработки в конвейерном режиме, что делает ) первым упорядоченным якорным пунктом, а ( причинной историей якорных пунктов для вычисления репутации лидеров.
Обработка по конвейеру
V, которое сопоставляет раунды с лидерами. Shoal последовательно запускает экземпляры Bullshark, так что для каждого экземпляра якорь заранее определяется с помощью отображения F. Каждый экземпляр заказывает якорь, что запускает переход к следующему экземпляру.
Изначально Shoal запустил первый экземпляр Bullshark в первом раунде DAG и продолжал его работу до определения первой упорядоченной опоры, например, в r-м раунде. Все валидаторы согласны с этой опорой. Таким образом, все валидаторы могут с уверенностью согласиться на переинтерпретацию DAG, начиная с раунда r+1. Shoal просто запустил новый экземпляр Bullshark в раунде r+1.
В лучшем случае это позволяет Shoal заказывать якорь в каждом раунде. Якорная точка первого раунда сортируется по первому экземпляру. Затем Shoal начинает новый экземпляр во втором раунде, который сам имеет якорную точку, сортируемую по этому экземпляру, затем другой новый экземпляр заказывает якорные точки в третьем раунде, и процесс продолжается.
![Подробное объяснение фрейма Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
Во время пропуска якорных точек в период сортировки Bullshark задержка увеличивается. В этом случае технология конвейерной обработки бессильна, поскольку новый экземпляр не может быть запущен до заказа якорной точки предыдущего экземпляра. Shoal обеспечивает малую вероятность выбора соответствующего лидера для обработки потерянных якорных точек в будущем, присваивая каждой проверочной ноде балл на основе истории недавней активности каждого узла проверки с помощью механизма репутации. Верификаторы, которые реагируют и участвуют в протоколе, получат высокие баллы, в противном случае ноды проверки будут получать низкие баллы, поскольку они могут быть сбоями, медленными или злонамеренными.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, отводя предпочтение лидерам с более высоким счетом. Чтобы валидаторы смогли согласовать новое отображение, они должны прийти к соглашению по счетам, достигнув согласия по истории, используемой для производных счетов.
В Shoal обработка в конвейерном режиме и репутация лидера могут естественно сочетаться, поскольку они используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения согласия по первому упорядоченному якорю.
На самом деле, единственное отличие заключается в том, что после сортировки анкерных точек на r-м раунде, валидатору нужно просто начать вычисление новой функции отображения F' с r+1-го раунда, основываясь на причинно-следственной истории упорядоченных анкерных точек в r-м раунде. Затем узлы-валидаторы начинают выполнять новый экземпляр Bullshark, используя обновленную функцию выбора анкерных точек F' с r+1-го раунда.
![Подробное объяснение схемы Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Больше нет таймаутов
Тайм-ауты играют решающую роль во всех реализациях BFT с определением на основе лидеров. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-ауты также значительно увеличивают задержку, поскольку важно правильно их настраивать, и обычно требуется динамическая настройка, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол накладывает полный штраф за задержку тайм-аута на вышедшего из строя лидера. Таким образом, настройки тайм-аута не должны быть слишком консервативными, но если тайм-аут слишком короткий, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff перегружены, и они терпят тайм-аут, прежде чем смогут продвинуться.