Shoal Framework: Значительно сократите задержку Bullshark на Aptos
Aptos Labs недавно решила две важные открытые проблемы в DAG BFT, значительно Падение задержки и впервые устранила необходимость в тайм-ауте в детерминированном фактическом протоколе. В целом, в случае отсутствия сбоев задержка Bullshark улучшилась на 40%, а в случае сбоев - на 80%.
Shoal является фреймворком, который улучшает любой протокол согласия на основе Narwhal (, такой как DAG-Rider, Tusk, Bullshark ), с помощью конвейера и репутации лидера. Конвейер снижает задержку сортировки DAG, вводя опорную точку на каждом раунде, а репутация лидера дополнительно улучшает задержку, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения таймаутов во всех сценариях. Это позволяет Shoal предоставлять свойство, которое мы называем универсальным откликом, которое включает в себя обычно требуемый оптимистичный ответ.
Наша технология очень проста, она включает в себя последовательный запуск нескольких экземпляров базового протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Мотивация
При стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на Падение сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, обеспечивал всего 3500 TPS, что значительно ниже нашей цели в 100k+ TPS.
Однако недавний прорыв произошел благодаря осознанию того, что распространение данных является основным узким местом, основанным на протоколе лидеров, и может извлечь выгоду из параллелизации. Система Narwhal разделяет распространение данных и основную логику консенсуса и предлагает архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты консенсуса лишь упорядочивают небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности в 160 000 TPS.
В предыдущей статье мы представили Quorum Store. Наша реализация Narwhal отделяет распространение данных от консенсуса и то, как мы используем это для расширения текущего протокола консенсуса Jolteon. Jolteon - это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, очевидно, что консенсусный протокол на основе лидера не может в полной мере использовать потенциал пропускной способности Narwhal. Хотя распространение данных отделено от консенсуса, с увеличением пропускной способности лидер Hotstuff/Jolteon все еще ограничен.
Таким образом, мы решили развернуть Bullshark на Narwhal DAG, протоколе консенсуса с нулевыми затратами на связь. К сожалению, по сравнению с Jolteon, структура 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 консенсусные протоколы имеют следующую структуру:
Предварительная точка: каждые несколько раундов (, например, в двух раундах 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 и обрабатывает их по конвейерному принципу, что делает ( первым упорядоченным якорем и ) причинной историей якоря, используемой для вычисления репутации лидера.
Конвейер
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 с определённостью, основанных на лидере. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку их правильная настройка очень важна и обычно требует динамической корректировки, так как это сильно зависит от окружения ( сети ). Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдаем
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
6
Поделиться
комментарий
0/400
FortuneTeller42
· 19ч назад
Это слишком круто, увеличение на 80%
Посмотреть ОригиналОтветить0
StableGeniusDegen
· 07-27 13:52
Хардкорные технологи! Рост цен не за горами
Посмотреть ОригиналОтветить0
EthSandwichHero
· 07-26 07:15
задержка Падение? бык啊 бык啊, вот так На луну
Посмотреть ОригиналОтветить0
GasOptimizer
· 07-26 07:14
80% задержка оптимизация лучше, чем любые Газ расходы.
Шаблон Shoal значительно улучшил производительность сети Aptos, задержка Bullshark снизилась на 80%
Shoal Framework: Значительно сократите задержку Bullshark на Aptos
Aptos Labs недавно решила две важные открытые проблемы в DAG BFT, значительно Падение задержки и впервые устранила необходимость в тайм-ауте в детерминированном фактическом протоколе. В целом, в случае отсутствия сбоев задержка Bullshark улучшилась на 40%, а в случае сбоев - на 80%.
Shoal является фреймворком, который улучшает любой протокол согласия на основе Narwhal (, такой как DAG-Rider, Tusk, Bullshark ), с помощью конвейера и репутации лидера. Конвейер снижает задержку сортировки DAG, вводя опорную точку на каждом раунде, а репутация лидера дополнительно улучшает задержку, обеспечивая связь опорной точки с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG для устранения таймаутов во всех сценариях. Это позволяет Shoal предоставлять свойство, которое мы называем универсальным откликом, которое включает в себя обычно требуемый оптимистичный ответ.
Наша технология очень проста, она включает в себя последовательный запуск нескольких экземпляров базового протокола. Таким образом, когда мы инстанцируем Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Мотивация
При стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на Падение сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, обеспечивал всего 3500 TPS, что значительно ниже нашей цели в 100k+ TPS.
Однако недавний прорыв произошел благодаря осознанию того, что распространение данных является основным узким местом, основанным на протоколе лидеров, и может извлечь выгоду из параллелизации. Система Narwhal разделяет распространение данных и основную логику консенсуса и предлагает архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты консенсуса лишь упорядочивают небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности в 160 000 TPS.
В предыдущей статье мы представили Quorum Store. Наша реализация Narwhal отделяет распространение данных от консенсуса и то, как мы используем это для расширения текущего протокола консенсуса Jolteon. Jolteon - это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, очевидно, что консенсусный протокол на основе лидера не может в полной мере использовать потенциал пропускной способности Narwhal. Хотя распространение данных отделено от консенсуса, с увеличением пропускной способности лидер Hotstuff/Jolteon все еще ограничен.
Таким образом, мы решили развернуть Bullshark на Narwhal DAG, протоколе консенсуса с нулевыми затратами на связь. К сожалению, по сравнению с Jolteon, структура 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 консенсусные протоколы имеют следующую структуру:
Предварительная точка: каждые несколько раундов (, например, в двух раундах 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 и обрабатывает их по конвейерному принципу, что делает ( первым упорядоченным якорем и ) причинной историей якоря, используемой для вычисления репутации лидера.
Конвейер
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 с определённостью, основанных на лидере. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку их правильная настройка очень важна и обычно требует динамической корректировки, так как это сильно зависит от окружения ( сети ). Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдаем