Aptos labs решило две важные открытые проблемы в DAG BFT, значительно снизив задержку и впервые устранив необходимость в тайм-ауте в детерминированных реальных протоколах. В целом, структура Shoal улучшила задержку Bullshark на 40% в безотказном режиме и на 80% в случае сбоев.
Shoal — это система, которая улучшает основанный на Narwhal консенсусный протокол ( с помощью конвейера и репутации лидера, такие как DAG-Rider, Tusk, Bullshark ). Конвейер уменьшает задержку сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидера дополнительно улучшает проблему задержки, гарантируя, что опорные точки связаны с самыми быстрыми узлами верификации. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG, чтобы устранить тайм-ауты во всех сценариях. Это позволяет Shoal предоставлять свойства, которые мы называем универсальным откликом, которое включает в себя обычно необходимые оптимистичные ответы.
Технология 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.
Aptos ранее представил Quorum Store, это их реализация Narwhal, которая разделяет распространение данных и консенсус и используется для масштабирования текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и изменения вида в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, по мере увеличения пропускной способности лидеры Hotstuff/Jolteon все равно остаются ограниченными.
Таким образом, Aptos решил развернуть Bullshark, консенсусный протокол с нулевыми затратами на связь, поверх Narwhal DAG. К сожалению, по сравнению с Jolteon, структура DAG, поддерживающая высокую пропускную способность Bullshark, имеет 50% Падение.
В этой статье рассказывается о том, как Shoal значительно уменьшает задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы войти в раунд r, валидатор сначала должен получить n-f вершин, принадлежащих раунду r-1. Каждый валидатор может транслировать одну вершину за раунд, при этом каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент времени наблюдать различные локальные представления DAG.
Ключевое свойство DAG не является неопределенным: если два узла проверки имеют одинаковую вершину v в своем локальном представлении DAG, то у них есть совершенно одинаковая причинно-следственная история v.
Общий порядок сортировки
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как согласованный протокол, где вершины представляют собой предложения, а ребра - голоса.
Хотя логика пересечения групп в структуре DAG различна, все существующие основанные на Narwhal протоколы согласия имеют следующую структуру:
Запланированная опорная точка: каждые несколько раундов (, как в Bullshark, через каждые два раунда ) будет заранее определенный лидер, вершина лидера называется опорной точкой.
Точки привязки сортировки: валидаторы независимо, но с определенной уверенностью решают, какие точки привязки сортировать, а какие пропустить.
Порядок причинно-следственной истории: валидаторы обрабатывают свои упорядоченные списки якорных точек один за другим, и для каждой якорной точки с помощью некоторых детерминированных правил сортируют все предыдущие неупорядоченные вершины в их причинно-следственной истории.
Ключом к безопасности является обеспечение того, чтобы на этапе (2) все честные узлы проверки создавали упорядоченный список анкорных точек, чтобы все списки имели одинаковый префикс. В Shoal сделаны следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первым упорядоченным якорем.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя наиболее практичная часть Bullshark в синхронной версии имеет лучшую задержку по сравнению с асинхронной версией, она далеко не является оптимальной.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голосование. В обычных случаях для сортировки опорных точек требуется две итерации DAG, однако вершины в причинно-историческом контексте опорной точки требуют большего количества итераций, чтобы дождаться сортировки опорной точки. В обычных случаях вершины в нечетной итерации требуют три итерации, а вершины, не являющиеся опорными, в четной итерации требуют четыре итерации.
Вопрос 2: Примеры сбоев задержка, приведенный выше анализ задержки применим к безсбойной ситуации, с другой стороны, если лидер раунда недостаточно быстро транслирует опорную точку, опорную точку невозможно отсортировать (, поэтому она пропускается ), таким образом, все несортированные вершины из предыдущих раундов должны ждать, пока следующая опорная точка будет отсортирована. Это значительно снижает производительность географической репликации сети, особенно потому что Bullshark таймаут используется для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Фреймворк Shoal
Shoal решает эти две проблемы задержки, усиливая Bullshark ( или любой другой протокол BFT на основе Narwhal ) через конвейер, позволяя иметь анкер в каждом раунде и сокращая задержку всех неанкерных вершин в DAG до трех раундов. Shoal также вводит в DAG механизм репутации лидеров с нулевыми затратами, что делает выбор более склонным к быстрым лидерам.
Вызов
В контексте протокола DAG, проблемы конвейера и репутации лидера считаются сложными по следующим причинам:
Ранее конвейер пытался изменить основную логику Bullshark, но это, по сути, кажется невозможным.
Репутация лидера вводится в DiemBFT и формализуется в Carousel, что основано на динамическом выборе будущих лидеров на основе прошлой производительности валидаторов, идея якоря в Bullshark (. Несмотря на то, что разногласия по поводу статуса лидера не нарушают безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает основной вопрос: динамический и детерминированный выбор вращающегося якоря необходим для решения консенсуса, и валидаторы должны достичь согласия по упорядоченной истории для выбора будущего якоря.
В качестве доказательства сложности проблемы реализация Bullshark, включая текущую реализацию в рабочей среде, не поддерживает эти функции.
! [10 000 слов, объясняющих структуру 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 начинает новый экземпляр во втором раунде, который сам имеет анкер, а этот анкер сортируется по этому экземпляру, затем другой новый экземпляр сортирует анкер в третьем раунде, и этот процесс продолжается.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Репутация лидера
Во время пропуска опорной точки в сортировке Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, поскольку новый экземпляр не может быть запущен до сортировки опорной точки предыдущего экземпляра. Shoal гарантирует, что в будущем маловероятно выбрать соответствующего лидера для обработки потерянных опорных точек, присваивая каждому валидатору балл на основе истории недавней активности каждого узла проверки с использованием механизма репутации. Валидаторы, которые отвечают и участвуют в протоколе, получат высокие баллы, в противном случае узлы проверки будут получать низкие баллы, так как они могут быть сбойными, медленными или злонамеренными.
Их концепция заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, склоняясь к лидеру с более высоким счетом. Чтобы валидаторы могли прийти к согласию по новому отображению, им следует достичь согласия по счету, тем самым согласовавшись на историю, используемую для вывода счета.
В Shoal потоки и репутация лидеров могут естественно сочетаться, так как они оба используют одну и ту же основную технологию, а именно перепроверку DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле единственное отличие заключается в том, что после сортировки якорных точек на r-м раунде валидатору нужно лишь на основе причинной истории упорядоченных якорных точек в r-м раунде вычислить новое отображение F' начиная с r+1 раунда. Затем узлы валидаторов с r+1 раунда начинают использовать обновленную функцию выбора якорных точек F', чтобы выполнить новый экземпляр Bullshark.
Нет больше задержек
Тайм-аут играет жизненно важную роль во всех реализациях BFT с определением на основе лидера. Однако внедрение этой сложности увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Таймаут также значительно увеличивает задержку, потому что очень важно правильно их настраивать, и их обычно необходимо динамически корректировать, так как они сильно зависят от среды ( сеть ). Перед переходом к следующему лидеру протокол выплачивает полное наказание за задержку таймаута для вышедшего из строя лидера. Таким образом, настройки таймаута не могут быть слишком консервативными, но если время таймаута слишком короткое, протокол может
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
8
Поделиться
комментарий
0/400
CryptoGoldmine
· 07-29 08:33
80% оптимизация задержки Технически близка к идеальному соотношению затрат и收益.
Посмотреть ОригиналОтветить0
just_here_for_vibes
· 07-27 18:20
Так много улучшений в производительности? Давай попробуем!
Посмотреть ОригиналОтветить0
BridgeNomad
· 07-26 20:35
хм... улучшенная задержка выглядит хорошо, но все еще нужно проверить эти векторы доверия, честно говоря
Посмотреть ОригиналОтветить0
BearMarketHustler
· 07-26 20:30
Офигеть, Aptos действительно неплохо справляется!
Посмотреть ОригиналОтветить0
Whale_Whisperer
· 07-26 20:28
Это улучшение просто великолепно. Сначала накоплю немного apt.
Посмотреть ОригиналОтветить0
CryptoMotivator
· 07-26 20:17
Aptos gogo～задержка 80% действительно мощно
Посмотреть ОригиналОтветить0
StakeHouseDirector
· 07-26 20:17
про啊 Эта оптимизация производительности действительно впечатляет
Посмотреть ОригиналОтветить0
Layer2Observer
· 07-26 20:08
задержка повысилась на 80%, это немного хардкорно, жду тестовые данные
Shoal框架大幅 Падение Aptos в блокчейне Bullshark задержка
Shoal框架:如何 Падение Aptos上Bullshark的 задержка
Aptos labs решило две важные открытые проблемы в DAG BFT, значительно снизив задержку и впервые устранив необходимость в тайм-ауте в детерминированных реальных протоколах. В целом, структура Shoal улучшила задержку Bullshark на 40% в безотказном режиме и на 80% в случае сбоев.
Shoal — это система, которая улучшает основанный на Narwhal консенсусный протокол ( с помощью конвейера и репутации лидера, такие как DAG-Rider, Tusk, Bullshark ). Конвейер уменьшает задержку сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидера дополнительно улучшает проблему задержки, гарантируя, что опорные точки связаны с самыми быстрыми узлами верификации. Кроме того, репутация лидера позволяет Shoal использовать асинхронную конструкцию DAG, чтобы устранить тайм-ауты во всех сценариях. Это позволяет Shoal предоставлять свойства, которые мы называем универсальным откликом, которое включает в себя обычно необходимые оптимистичные ответы.
Технология 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.
Aptos ранее представил Quorum Store, это их реализация Narwhal, которая разделяет распространение данных и консенсус и используется для масштабирования текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и изменения вида в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, по мере увеличения пропускной способности лидеры Hotstuff/Jolteon все равно остаются ограниченными.
Таким образом, Aptos решил развернуть Bullshark, консенсусный протокол с нулевыми затратами на связь, поверх Narwhal DAG. К сожалению, по сравнению с Jolteon, структура DAG, поддерживающая высокую пропускную способность Bullshark, имеет 50% Падение.
В этой статье рассказывается о том, как Shoal значительно уменьшает задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы войти в раунд r, валидатор сначала должен получить n-f вершин, принадлежащих раунду r-1. Каждый валидатор может транслировать одну вершину за раунд, при этом каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент времени наблюдать различные локальные представления DAG.
Ключевое свойство DAG не является неопределенным: если два узла проверки имеют одинаковую вершину v в своем локальном представлении DAG, то у них есть совершенно одинаковая причинно-следственная история v.
Общий порядок сортировки
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как согласованный протокол, где вершины представляют собой предложения, а ребра - голоса.
Хотя логика пересечения групп в структуре DAG различна, все существующие основанные на Narwhal протоколы согласия имеют следующую структуру:
Запланированная опорная точка: каждые несколько раундов (, как в Bullshark, через каждые два раунда ) будет заранее определенный лидер, вершина лидера называется опорной точкой.
Точки привязки сортировки: валидаторы независимо, но с определенной уверенностью решают, какие точки привязки сортировать, а какие пропустить.
Порядок причинно-следственной истории: валидаторы обрабатывают свои упорядоченные списки якорных точек один за другим, и для каждой якорной точки с помощью некоторых детерминированных правил сортируют все предыдущие неупорядоченные вершины в их причинно-следственной истории.
Ключом к безопасности является обеспечение того, чтобы на этапе (2) все честные узлы проверки создавали упорядоченный список анкорных точек, чтобы все списки имели одинаковый префикс. В Shoal сделаны следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первым упорядоченным якорем.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя наиболее практичная часть Bullshark в синхронной версии имеет лучшую задержку по сравнению с асинхронной версией, она далеко не является оптимальной.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голосование. В обычных случаях для сортировки опорных точек требуется две итерации DAG, однако вершины в причинно-историческом контексте опорной точки требуют большего количества итераций, чтобы дождаться сортировки опорной точки. В обычных случаях вершины в нечетной итерации требуют три итерации, а вершины, не являющиеся опорными, в четной итерации требуют четыре итерации.
Вопрос 2: Примеры сбоев задержка, приведенный выше анализ задержки применим к безсбойной ситуации, с другой стороны, если лидер раунда недостаточно быстро транслирует опорную точку, опорную точку невозможно отсортировать (, поэтому она пропускается ), таким образом, все несортированные вершины из предыдущих раундов должны ждать, пока следующая опорная точка будет отсортирована. Это значительно снижает производительность географической репликации сети, особенно потому что Bullshark таймаут используется для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Фреймворк Shoal
Shoal решает эти две проблемы задержки, усиливая Bullshark ( или любой другой протокол BFT на основе Narwhal ) через конвейер, позволяя иметь анкер в каждом раунде и сокращая задержку всех неанкерных вершин в DAG до трех раундов. Shoal также вводит в DAG механизм репутации лидеров с нулевыми затратами, что делает выбор более склонным к быстрым лидерам.
Вызов
В контексте протокола DAG, проблемы конвейера и репутации лидера считаются сложными по следующим причинам:
Ранее конвейер пытался изменить основную логику Bullshark, но это, по сути, кажется невозможным.
Репутация лидера вводится в DiemBFT и формализуется в Carousel, что основано на динамическом выборе будущих лидеров на основе прошлой производительности валидаторов, идея якоря в Bullshark (. Несмотря на то, что разногласия по поводу статуса лидера не нарушают безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает основной вопрос: динамический и детерминированный выбор вращающегося якоря необходим для решения консенсуса, и валидаторы должны достичь согласия по упорядоченной истории для выбора будущего якоря.
В качестве доказательства сложности проблемы реализация Bullshark, включая текущую реализацию в рабочей среде, не поддерживает эти функции.
! [10 000 слов, объясняющих структуру 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 начинает новый экземпляр во втором раунде, который сам имеет анкер, а этот анкер сортируется по этому экземпляру, затем другой новый экземпляр сортирует анкер в третьем раунде, и этот процесс продолжается.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Репутация лидера
Во время пропуска опорной точки в сортировке Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, поскольку новый экземпляр не может быть запущен до сортировки опорной точки предыдущего экземпляра. Shoal гарантирует, что в будущем маловероятно выбрать соответствующего лидера для обработки потерянных опорных точек, присваивая каждому валидатору балл на основе истории недавней активности каждого узла проверки с использованием механизма репутации. Валидаторы, которые отвечают и участвуют в протоколе, получат высокие баллы, в противном случае узлы проверки будут получать низкие баллы, так как они могут быть сбойными, медленными или злонамеренными.
Их концепция заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, склоняясь к лидеру с более высоким счетом. Чтобы валидаторы могли прийти к согласию по новому отображению, им следует достичь согласия по счету, тем самым согласовавшись на историю, используемую для вывода счета.
В Shoal потоки и репутация лидеров могут естественно сочетаться, так как они оба используют одну и ту же основную технологию, а именно перепроверку DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле единственное отличие заключается в том, что после сортировки якорных точек на r-м раунде валидатору нужно лишь на основе причинной истории упорядоченных якорных точек в r-м раунде вычислить новое отображение F' начиная с r+1 раунда. Затем узлы валидаторов с r+1 раунда начинают использовать обновленную функцию выбора якорных точек F', чтобы выполнить новый экземпляр Bullshark.
Нет больше задержек
Тайм-аут играет жизненно важную роль во всех реализациях BFT с определением на основе лидера. Однако внедрение этой сложности увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Таймаут также значительно увеличивает задержку, потому что очень важно правильно их настраивать, и их обычно необходимо динамически корректировать, так как они сильно зависят от среды ( сеть ). Перед переходом к следующему лидеру протокол выплачивает полное наказание за задержку таймаута для вышедшего из строя лидера. Таким образом, настройки таймаута не могут быть слишком консервативными, но если время таймаута слишком короткое, протокол может