Shoal-рамка: Инновационное решение для Падения задержки Bullshark на Aptos
Aptos Labs недавно решила две важные открытые проблемы в DAG BFT, значительно уменьшив задержку и впервые устранив необходимость в тайм-ауте в детерминированном реальном протоколе. В общем, в случае отсутствия сбоев задержка 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)
Фон и мотивация
В процессе стремления к высокой производительности блокчейн-сетей люди всегда обращали внимание на Падение сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff достиг всего 3500 TPS, что значительно ниже нашей цели в 100000+ TPS.
Недавний прорыв связан с осознанием того, что распространение данных является основным узким местом, основанным на протоколах лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, при которой все валидаторы одновременно распространяют данные, а компонент консенсуса сортирует лишь небольшое количество метаданных. В статье о Narwhal сообщается о пропускной способности в 160000 TPS.
В предыдущих статьях мы представили Quorum Store - наше решение Narwhal, которое отделяет распространение данных от консенсуса, и то, как мы используем его для расширения текущего протокола консенсуса Jolteon. Jolteon - это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и смену видов в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Однако очевидно, что протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на отделение распространения данных от консенсуса, по мере увеличения пропускной способности лидер Hotstuff/Jolteon по-прежнему ограничен.
Поэтому мы решили развернуть Bullshark на Narwhal DAG - это протокол консенсуса с нулевыми коммуникационными затратами. К сожалению, по сравнению с Jolteon, структура DAG, поддерживающая высокую пропускную способность Bullshark, приводит к падению производительности на 50%.
В этой статье будет рассмотрено, как Shoal значительно снижает задержку Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория 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-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя синхронная версия Bullshark более практична и имеет лучшую задержку по сравнению с асинхронной версией, она все же далеко не оптимальна.
Вопрос 1: Средняя задержка блока. В Bullshark в каждой четной итерации есть опорная точка, а вершины каждой нечетной итерации интерпретируются как голоса. В обычных случаях требуется две итерации DAG, чтобы отсортировать опорные точки, однако вершины в причинно-следственной истории опорной точки требуют больше итераций, чтобы дождаться сортировки опорной точки. В обычных случаях вершины в нечетной итерации требуют три итерации, тогда как не опорные вершины в четной итерации требуют четыре итерации.
Вопрос 2: Ситуация с неисправностями задерживается. Вышеупомянутое задержка анализа применимо к безотказной ситуации, с другой стороны, если лидер очередного раунда не сможет достаточно быстро транслировать якорные точки, то якорные точки не могут быть отсортированы (, поэтому они будут пропущены ), что приведет к тому, что все несортированные вершины из предыдущих раундов должны будут ждать, пока следующая якорная точка будет отсортирована. Это будет значительно Падение производительности географической репликационной сети, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Рамка Shoal
Shoal решило эти две проблемы задержки, оно усилило Bullshark( или любой другой основанный на Narwhal BFT протокол ) через обработку в конвейере, позволяя иметь одну опорную точку в каждом раунде и снижая задержку всех не опорных вершин в DAG до трех раундов. Shoal также ввело в DAG механизм репутации лидера с нулевыми затратами, что делает выбор склонным к быстрым лидерам.
Вызов
В контексте протокола DAG, конвейерная обработка и репутация лидера считаются сложными проблемами по следующим причинам:
Предыдущие попытки обработки по конвейерной технологии пытались изменить основную логику Bullshark, но это, по сути, кажется невозможным.
Репутация лидера вводится в DiemBFT и официально закрепляется в Carousel, что основано на динамическом выборе будущих лидеров в зависимости от прошлых показателей валидаторов, идея заключается в использовании анкеров в Bullshark (. Хотя наличие разногласий относительно идентичности лидера не нарушает безопасность этих протоколов, в Bullshark это может привести к совершенно другим порядкам, что поднимает суть вопроса: динамический и детерминированный выбор анков является необходимым для решения консенсуса, и валидаторы должны достичь согласия по упорядоченной истории для выбора будущих анков.
В качестве доказательства сложности проблемы мы отмечаем, что реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.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-9f789cb669f6fcc244ea7ff7648e48b4.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-1baf540693f376d93cb18ef3193593cc.webp)
Устранить задержку
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированным частичным синхронизированным лидерством. Однако, введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
4
Поделиться
комментарий
0/400
ZKProofEnthusiast
· 17ч назад
Эм-хм, все, что связано с soal, растет довольно странно.
Посмотреть ОригиналОтветить0
SchrodingerWallet
· 17ч назад
Эта волна 3 будет На луну?
Посмотреть ОригиналОтветить0
SmartContractPlumber
· 17ч назад
Соглашение слой улучшений является наиболее легким для возникновения цепных рисков. Давайте поговорим, когда появятся новые уязвимости.
Посмотреть ОригиналОтветить0
DecentralizedElder
· 17ч назад
Это круто! Эта задержка действительно может достигать 10%?
Shoal: Новый фреймворк Aptos значительно Падение задержка Bullshark, устраняет требования к тайм-ауту
Shoal-рамка: Инновационное решение для Падения задержки Bullshark на Aptos
Aptos Labs недавно решила две важные открытые проблемы в DAG BFT, значительно уменьшив задержку и впервые устранив необходимость в тайм-ауте в детерминированном реальном протоколе. В общем, в случае отсутствия сбоев задержка 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)
Фон и мотивация
В процессе стремления к высокой производительности блокчейн-сетей люди всегда обращали внимание на Падение сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff достиг всего 3500 TPS, что значительно ниже нашей цели в 100000+ TPS.
Недавний прорыв связан с осознанием того, что распространение данных является основным узким местом, основанным на протоколах лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, при которой все валидаторы одновременно распространяют данные, а компонент консенсуса сортирует лишь небольшое количество метаданных. В статье о Narwhal сообщается о пропускной способности в 160000 TPS.
В предыдущих статьях мы представили Quorum Store - наше решение Narwhal, которое отделяет распространение данных от консенсуса, и то, как мы используем его для расширения текущего протокола консенсуса Jolteon. Jolteon - это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и смену видов в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Однако очевидно, что протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на отделение распространения данных от консенсуса, по мере увеличения пропускной способности лидер Hotstuff/Jolteon по-прежнему ограничен.
Поэтому мы решили развернуть Bullshark на Narwhal DAG - это протокол консенсуса с нулевыми коммуникационными затратами. К сожалению, по сравнению с Jolteon, структура DAG, поддерживающая высокую пропускную способность Bullshark, приводит к падению производительности на 50%.
В этой статье будет рассмотрено, как Shoal значительно снижает задержку Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория 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-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя синхронная версия Bullshark более практична и имеет лучшую задержку по сравнению с асинхронной версией, она все же далеко не оптимальна.
Вопрос 1: Средняя задержка блока. В Bullshark в каждой четной итерации есть опорная точка, а вершины каждой нечетной итерации интерпретируются как голоса. В обычных случаях требуется две итерации DAG, чтобы отсортировать опорные точки, однако вершины в причинно-следственной истории опорной точки требуют больше итераций, чтобы дождаться сортировки опорной точки. В обычных случаях вершины в нечетной итерации требуют три итерации, тогда как не опорные вершины в четной итерации требуют четыре итерации.
Вопрос 2: Ситуация с неисправностями задерживается. Вышеупомянутое задержка анализа применимо к безотказной ситуации, с другой стороны, если лидер очередного раунда не сможет достаточно быстро транслировать якорные точки, то якорные точки не могут быть отсортированы (, поэтому они будут пропущены ), что приведет к тому, что все несортированные вершины из предыдущих раундов должны будут ждать, пока следующая якорная точка будет отсортирована. Это будет значительно Падение производительности географической репликационной сети, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Рамка Shoal
Shoal решило эти две проблемы задержки, оно усилило Bullshark( или любой другой основанный на Narwhal BFT протокол ) через обработку в конвейере, позволяя иметь одну опорную точку в каждом раунде и снижая задержку всех не опорных вершин в DAG до трех раундов. Shoal также ввело в DAG механизм репутации лидера с нулевыми затратами, что делает выбор склонным к быстрым лидерам.
Вызов
В контексте протокола DAG, конвейерная обработка и репутация лидера считаются сложными проблемами по следующим причинам:
Предыдущие попытки обработки по конвейерной технологии пытались изменить основную логику Bullshark, но это, по сути, кажется невозможным.
Репутация лидера вводится в DiemBFT и официально закрепляется в Carousel, что основано на динамическом выборе будущих лидеров в зависимости от прошлых показателей валидаторов, идея заключается в использовании анкеров в Bullshark (. Хотя наличие разногласий относительно идентичности лидера не нарушает безопасность этих протоколов, в Bullshark это может привести к совершенно другим порядкам, что поднимает суть вопроса: динамический и детерминированный выбор анков является необходимым для решения консенсуса, и валидаторы должны достичь согласия по упорядоченной истории для выбора будущих анков.
В качестве доказательства сложности проблемы мы отмечаем, что реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.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-9f789cb669f6fcc244ea7ff7648e48b4.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-1baf540693f376d93cb18ef3193593cc.webp)
Устранить задержку
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированным частичным синхронизированным лидерством. Однако, введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
超时也会显著 увеличить задержку