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, который отделяет распространение данных от согласия, а также то, как его использовать для расширения текущего протокола согласия 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-b7ed8888da112bae8d34c0fdb338b138.webp)
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в 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-46d37add0d9e81b2f295edf8eddd907f.webp)
Shoal фрейм
Shoal решает эти две проблемы задержки, он усиливает Bullshark( или любой другой BFT-протокол на основе Narwhal) через конвейер, позволяя в каждой итерации иметь опорную точку и уменьшая задержку всех не-опорных вершин в 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-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
При пропуске опорной точки в процессе сортировки Bullshark задержка увеличивается. В этом случае технология конвейера бесполезна, так как новый экземпляр не может быть запущен до тех пор, пока не будет заказана предыдущая опорная точка. Shoal обеспечивает меньшее вероятность выбора соответствующего лидера для обработки потерянных опорных точек в будущем, присваивая баллы каждому узлу проверки на основе недавней истории активности каждого узла проверки с помощью механизма репутации. Проверяющие, которые реагируют и участвуют в протоколе, получат высокие баллы, в противном случае узлы проверки получат низкие баллы, так как они могут выйти из строя, работать медленно или совершать злонамеренные действия.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, отзываясь на более высокие баллы лидера. Чтобы валидаторы пришли к согласию по новому отображению, они должны достичь согласия по счету, тем самым достигнув согласия по истории, используемой для вывода счета.
В Shoal, конвейер и репутация лидеров могут естественно сочетаться, поскольку они используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле, единственное различие заключается в том, что после сортировки опорных точек в r-м раунде валидатору нужно просто на основе причинной истории упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с r+1 раунда. Затем валидатор узла начинает с r+1 раунда выполнять новый экземпляр Bullshark с обновленной функцией выбора опорных точек F'.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше тайм-аутов
Тайм-аут играет решающую роль во всех реализациях BFT с определённостью, основанных на лидере. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что их правильная настройка очень важна и часто требует динамической корректировки, так как она сильно зависит от окружения ) сети (. Перед переходом к следующему лидеру протокол оплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff были перегружены, и тайм-аут истек до того, как они смогли продвинуться.
К сожалению, протоколы, основанные на лидерах, такие как Hotstuff и Jolteon), по своей сути требуют задержки, чтобы обеспечить прогресс протокола каждый раз, когда лидер выходит из строя. Без задержки даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронный период невозможно различить, есть ли сбой.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
23 Лайков
Награда
23
6
Поделиться
комментарий
0/400
VirtualRichDream
· 07-25 11:15
задержка降这么多 aptos要На луну了
Посмотреть ОригиналОтветить0
CoffeeNFTs
· 07-22 19:02
Эта задержка Падение немного привлекательна.
Посмотреть ОригиналОтветить0
RugDocDetective
· 07-22 19:01
Так бык! Ждал так долго, наконец, вышло решение Aptos!
Посмотреть ОригиналОтветить0
RuntimeError
· 07-22 19:00
что на самом деле может этот новый трюк aptos
Посмотреть ОригиналОтветить0
UnluckyValidator
· 07-22 18:58
задержка высокая наконец закончилась, мучился полгода
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, мы получаем группу "акул", которые участвуют в эстафете.
! [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, который отделяет распространение данных от согласия, а также то, как его использовать для расширения текущего протокола согласия 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-b7ed8888da112bae8d34c0fdb338b138.webp)
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в 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-46d37add0d9e81b2f295edf8eddd907f.webp)
Shoal фрейм
Shoal решает эти две проблемы задержки, он усиливает Bullshark( или любой другой BFT-протокол на основе Narwhal) через конвейер, позволяя в каждой итерации иметь опорную точку и уменьшая задержку всех не-опорных вершин в 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-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
При пропуске опорной точки в процессе сортировки Bullshark задержка увеличивается. В этом случае технология конвейера бесполезна, так как новый экземпляр не может быть запущен до тех пор, пока не будет заказана предыдущая опорная точка. Shoal обеспечивает меньшее вероятность выбора соответствующего лидера для обработки потерянных опорных точек в будущем, присваивая баллы каждому узлу проверки на основе недавней истории активности каждого узла проверки с помощью механизма репутации. Проверяющие, которые реагируют и участвуют в протоколе, получат высокие баллы, в противном случае узлы проверки получат низкие баллы, так как они могут выйти из строя, работать медленно или совершать злонамеренные действия.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, отзываясь на более высокие баллы лидера. Чтобы валидаторы пришли к согласию по новому отображению, они должны достичь согласия по счету, тем самым достигнув согласия по истории, используемой для вывода счета.
В Shoal, конвейер и репутация лидеров могут естественно сочетаться, поскольку они используют одну и ту же основную технологию, а именно переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле, единственное различие заключается в том, что после сортировки опорных точек в r-м раунде валидатору нужно просто на основе причинной истории упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с r+1 раунда. Затем валидатор узла начинает с r+1 раунда выполнять новый экземпляр Bullshark с обновленной функцией выбора опорных точек F'.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше тайм-аутов
Тайм-аут играет решающую роль во всех реализациях BFT с определённостью, основанных на лидере. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что их правильная настройка очень важна и часто требует динамической корректировки, так как она сильно зависит от окружения ) сети (. Перед переходом к следующему лидеру протокол оплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff были перегружены, и тайм-аут истек до того, как они смогли продвинуться.
К сожалению, протоколы, основанные на лидерах, такие как Hotstuff и Jolteon), по своей сути требуют задержки, чтобы обеспечить прогресс протокола каждый раз, когда лидер выходит из строя. Без задержки даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронный период невозможно различить, есть ли сбой.