Каркас 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)
Фон и мотивация
В процессе стремления к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, достиг всего 3500 TPS, что значительно ниже целевого показателя в 100k+ 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.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы войти в r-й раунд, валидатор должен сначала получить n-f вершин, принадлежащих (r-1)-му раунду. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети различные валидаторы могут в любой момент времени наблюдать разные локальные представления DAG.
Ключевым свойством DAG является его однозначность: если два узла проверки имеют в своих локальных представлениях DAG одинаковую вершину v, то у них есть полностью одинаковая причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий порядок сортировки
Можно согласовать общий порядок всех вершин в DAG без дополнительных накладных расходов на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как соглашение, где вершины представляют собой предложения, а ребра — голоса.
Хотя логика группового пересечения в структуре DAG отличается, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Запланированная опора: каждые несколько раундов будет заранее определенный лидер, вершина которого называется опорой.
Упорядочение опорных точек: валидаторы независимо, но с определенностью решают, какие опорные точки упорядочить, а какие пропустить.
Причинно-следственный порядок истории: валидаторы обрабатывают упорядоченный список якорей по одному, сортируя все ранее неупорядоченные вершины в причинно-следственной истории каждого якоря.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что на этапе (2) все честные узлы верификации создают упорядоченный список анкерных точек, чтобы все списки имели общий префикс. В Shoal мы делаем следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первой упорядоченной точкой привязки.
! [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, включая текущую реализацию в производственной среде, не поддерживает эти функции.
) Соглашение
Несмотря на указанные выше вызовы, решение скрыто в простоте. В 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-м раунде валидатору нужно просто рассчитать новое отображение F', основываясь на причинно-следственной истории упорядоченных якорей в r-м раунде. Затем валидаторные узлы начинают использовать обновленную функцию выбора якорей F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Нет больше задержек
Тайм-аут играет решающую роль во всех основанных на лидере детерминированных частях синхронной BFT реализации. Тем не менее, сложность, которую они вводят, увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ( сети ). Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за тайм-аут неработающему лидеру. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff были перегружены, и тайм-аут истек до того, как они смогли продвинуться.
К сожалению, на основе соглашения лидера ###, такого как Hotstuff
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
9 Лайков
Награда
9
6
Репост
Поделиться
комментарий
0/400
SchrodingerProfit
· 08-11 12:19
Это снова aptos На луну.
Посмотреть ОригиналОтветить0
CodeAuditQueen
· 08-11 05:48
Оптимизация сложных алгоритмов также несет риск повторного входа в вычислительную мощность. Надеюсь, что это не приведет к провалу.
Посмотреть ОригиналОтветить0
metaverse_hermit
· 08-11 05:48
aptos все еще жив tql
Посмотреть ОригиналОтветить0
ReverseTradingGuru
· 08-11 05:47
Опять опять опять обновлено啊 бык啤
Посмотреть ОригиналОтветить0
DeadTrades_Walking
· 08-11 05:31
Повышение эффективности нормально, не забудь отправить результаты.
Shoal框架提升AptosСоглашение эффективности: Bullsharkзадержка大幅Падение40-80%
Каркас 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)
Фон и мотивация
В процессе стремления к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности коммуникации. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, достиг всего 3500 TPS, что значительно ниже целевого показателя в 100k+ 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.
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы войти в r-й раунд, валидатор должен сначала получить n-f вершин, принадлежащих (r-1)-му раунду. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети различные валидаторы могут в любой момент времени наблюдать разные локальные представления DAG.
Ключевым свойством DAG является его однозначность: если два узла проверки имеют в своих локальных представлениях DAG одинаковую вершину v, то у них есть полностью одинаковая причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий порядок сортировки
Можно согласовать общий порядок всех вершин в DAG без дополнительных накладных расходов на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как соглашение, где вершины представляют собой предложения, а ребра — голоса.
Хотя логика группового пересечения в структуре DAG отличается, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Запланированная опора: каждые несколько раундов будет заранее определенный лидер, вершина которого называется опорой.
Упорядочение опорных точек: валидаторы независимо, но с определенностью решают, какие опорные точки упорядочить, а какие пропустить.
Причинно-следственный порядок истории: валидаторы обрабатывают упорядоченный список якорей по одному, сортируя все ранее неупорядоченные вершины в причинно-следственной истории каждого якоря.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что на этапе (2) все честные узлы верификации создают упорядоченный список анкерных точек, чтобы все списки имели общий префикс. В Shoal мы делаем следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первой упорядоченной точкой привязки.
! [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, включая текущую реализацию в производственной среде, не поддерживает эти функции.
) Соглашение
Несмотря на указанные выше вызовы, решение скрыто в простоте. В 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-м раунде валидатору нужно просто рассчитать новое отображение F', основываясь на причинно-следственной истории упорядоченных якорей в r-м раунде. Затем валидаторные узлы начинают использовать обновленную функцию выбора якорей F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Нет больше задержек
Тайм-аут играет решающую роль во всех основанных на лидере детерминированных частях синхронной BFT реализации. Тем не менее, сложность, которую они вводят, увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ( сети ). Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за тайм-аут неработающему лидеру. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff были перегружены, и тайм-аут истек до того, как они смогли продвинуться.
К сожалению, на основе соглашения лидера ###, такого как Hotstuff