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.
В предыдущей статье было представлено Quorum Store, а именно реализация Narwhal, которая отделяет распространение данных от консенсуса, а также то, как использовать его для масштабирования текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, сочетающий линейный быстрый путь Tendermint и изменения представления в стиле PBFT, который может снизить задержку Hotstuff на 33%. Однако протокол консенсуса на основе лидера не может в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на отделение распространения данных от консенсуса, с увеличением пропускной способности лидеры Hotstuff/Jolteon все еще остаются ограниченными.
Поэтому было решено развернуть Bullshark на Narwhal DAG, это протокол консенсуса с нулевыми затратами на связь. К сожалению, структура DAG, поддерживающая Bullshark с высокой пропускной способностью, приводит к падению на 50% по сравнению с Jolteon.
В этой статье описывается, как Shoal значительно сокращает задержку Bullshark.
Предыстория 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-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных коммуникационных затрат. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как согласованный протокол, где вершины представляют предложения, а ребра представляют голоса.
Хотя логика пересечения групп в структуре DAG различна, все существующие консенсусные протоколы на основе Narwhal имеют следующую структуру:
Запланированная опорная точка: каждые несколько раундов будет заранее определенный лидер, вершина лидера называется опорной точкой;
Точки сортировки: валидаторы независимо, но с определённостью решают, какие точки привязки заказывать, а какие пропускать;
Упорядочивание причинно-следственной истории: валидаторы обрабатывают свои упорядоченные списки анкорных точек по одному, и для каждой анкорной точки с помощью некоторых детерминированных правил упорядочивают все предыдущие неупорядоченные вершины в ее причинно-следственной истории.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (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( или любой другой основанный на Narwhal BFT протокол ) через конвейер, позволяя в каждой итерации иметь одну опору и снижая задержку всех не-якорных вершин в 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 раунда. Затем узлы валидации начинают выполнять новый экземпляр Bullshark с обновленной функцией выбора опорных точек F' с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Больше нет задержек
Тайм-аут играет решающую роль во всех основанных на лидере детерминированных частично синхронных BFT реализациях. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку очень важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за тайм-аут неисправному лидеру. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff были перегружены, и тайм-аут истек до того, как они смогли продвинуться.
К сожалению, протоколы, основанные на лидерах ), такие как Hotstuff и Jolteon(, по сути, требуют задержки, чтобы обеспечить каждого лидера.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Shoal框架大幅 Падение Aptos上Bullshark задержка提升40%-80%
Shoal框架:如何 Падение Aptos上Bullshark的 задержка
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.
В предыдущей статье было представлено Quorum Store, а именно реализация Narwhal, которая отделяет распространение данных от консенсуса, а также то, как использовать его для масштабирования текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, сочетающий линейный быстрый путь Tendermint и изменения представления в стиле PBFT, который может снизить задержку Hotstuff на 33%. Однако протокол консенсуса на основе лидера не может в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на отделение распространения данных от консенсуса, с увеличением пропускной способности лидеры Hotstuff/Jolteon все еще остаются ограниченными.
Поэтому было решено развернуть Bullshark на Narwhal DAG, это протокол консенсуса с нулевыми затратами на связь. К сожалению, структура DAG, поддерживающая Bullshark с высокой пропускной способностью, приводит к падению на 50% по сравнению с Jolteon.
В этой статье описывается, как Shoal значительно сокращает задержку Bullshark.
Предыстория 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-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных коммуникационных затрат. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как согласованный протокол, где вершины представляют предложения, а ребра представляют голоса.
Хотя логика пересечения групп в структуре DAG различна, все существующие консенсусные протоколы на основе Narwhal имеют следующую структуру:
Запланированная опорная точка: каждые несколько раундов будет заранее определенный лидер, вершина лидера называется опорной точкой;
Точки сортировки: валидаторы независимо, но с определённостью решают, какие точки привязки заказывать, а какие пропускать;
Упорядочивание причинно-следственной истории: валидаторы обрабатывают свои упорядоченные списки анкорных точек по одному, и для каждой анкорной точки с помощью некоторых детерминированных правил упорядочивают все предыдущие неупорядоченные вершины в ее причинно-следственной истории.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (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( или любой другой основанный на Narwhal BFT протокол ) через конвейер, позволяя в каждой итерации иметь одну опору и снижая задержку всех не-якорных вершин в 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 раунда. Затем узлы валидации начинают выполнять новый экземпляр Bullshark с обновленной функцией выбора опорных точек F' с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Больше нет задержек
Тайм-аут играет решающую роль во всех основанных на лидере детерминированных частично синхронных BFT реализациях. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку очень важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за тайм-аут неисправному лидеру. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff были перегружены, и тайм-аут истек до того, как они смогли продвинуться.
К сожалению, протоколы, основанные на лидерах ), такие как Hotstuff и Jolteon(, по сути, требуют задержки, чтобы обеспечить каждого лидера.