Shoal框架:значительное падение задержки Bullshark на Aptos
Недавно 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, что значительно ниже целевого показателя в 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.
Предыстория 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 имеют следующую структуру:
Запланированная опорная точка: каждые несколько раундов (, как в Bullshark, через два раунда ) будет запланированный лидер, вершина которого называется опорной точкой.
Точки сортировки: валидаторы независимо, но детерминированно решают, какие точки сортировки использовать, а какие пропустить.
Упорядоченная причинно-следственная история: валидаторы последовательно обрабатывают упорядоченный список якорных точек, для каждой якорной точки с помощью детерминированных правил упорядочивают все предыдущие неупорядоченные вершины в ее причинно-следственной истории.
Ключом к обеспечению безопасности является гарантия того, что на этапе (2) все честные узлы верификации создают упорядоченный список анкорных точек, чтобы все списки имели одинаковый префикс. В Shoal мы делаем следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первой упорядоченной якорной точкой.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя у синхронной версии Bullshark, как правило, лучше задержка, чем у асинхронной версии, это далеко от оптимального.
Вопрос 1: Среднее время задержки блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины нечетной итерации трактуются как голосование. В обычных условиях для сортировки опорных точек требуется две итерации DAG, однако вершины в причинной истории опорных точек требуют больше итераций, чтобы дождаться сортировки опорных точек. В обычных условиях вершины в нечетной итерации требуют три итерации, а не опорные вершины в четной итерации требуют четыре итерации.
Вопрос 2: случаи сбоев задержка. Вышеуказанный анализ задержки применяется к случаям без сбоев, с другой стороны, если лидер раунда не сможет достаточно быстро транслировать опорную точку, сортировка опорной точки станет невозможной (, поэтому она будет пропущена ), и все несортированные вершины из предыдущих раундов должны ждать следующей сортировки опорной точки. Это значительно приведет к Падению производительности географической репликации сети, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Shoal фрейм
Shoal решает эти две проблемы задержки, он улучшает Bullshark( или любой другой протокол BFT на основе Narwhal) за счет конвейерной обработки, позволяя иметь опорную точку в каждом раунде и снижая задержку всех не-опорных вершин в DAG до трех раундов. Shoal также вводит механизм репутации лидеров с нулевой затратой в DAG, что делает выбор более предпочтительным для быстрых лидеров.
Вызов
В контексте протокола DAG, конвейеризация и репутация лидеров считаются сложными вопросами по следующим причинам:
Предыдущие попытки изменить основную логику Bullshark в конвейере, по сути, казались невозможными.
Репутация лидеров вводится в DiemBFT и формализуется в Carousel, что представляет собой динамический выбор будущих лидеров на основе прошлых результатов валидаторов, идея о якоре в Bullshark (. Хотя наличие разногласий по поводу лидерства не нарушает безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает основной вопрос: динамический и детерминированный выбор ротационного якоря необходим для достижения консенсуса, и валидаторы должны согласовать упорядоченную историю для выбора будущего якоря.
В качестве доказательства сложности проблемы мы отмечаем, что реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
Протокол
Несмотря на вышеперечисленные проблемы, оказалось, что решение скрыто в простоте.
В Shoal мы полагаемся на способность выполнять локальные вычисления на DAG и реализуем возможность сохранения и переинтерпретации информации из предыдущих раундов. Благодаря тому, что все валидаторы согласны с основным пониманием первого упорядоченного якоря, Shoal последовательно комбинирует несколько экземпляров Bullshark для их обработки в конвейере, что делает ) первым упорядоченным якорем, а также ( причинной историей якоря для вычисления репутации лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.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-0b0928cb6240e994c1514c75e080a4b2.webp(
Репутация лидеров
При пропуске анкерной точки во время сортировки Bullshark задержка увеличивается. В этом случае технология конвейера бессильна, так как новое соединение не может быть запущено до сортировки анкерной точки предыдущего экземпляра. Shoal гарантирует, что в будущем маловероятно, что соответствующий лидер будет выбран для обработки пропущенных анкерных точек, присваивая каждой узловой валидации балл на основе истории недавней активности каждого узла валидации с помощью механизма репутации. Валидации, которые откликнутся и участвуют в протоколе, получат высокие баллы, в противном случае узлы валидации будут получать низкие баллы, так как они могут быть зависшими, медленными или злонамеренными.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, склоняясь к лидеру с более высоким счетом. Чтобы валидаторы согласовали новое отображение, они должны согласовать счет, тем самым достигнув согласия по истории, используемой для производных оценок.
В Shoal, конвейеры и репутация лидеров могут естественно сочетаться, так как они используют одну и ту же основную технологию, а именно, переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле единственное отличие заключается в том, что после сортировки опорных точек в r-м раунде валидатору необходимо просто на основе причинно-исторической информации упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с (r+1)-го раунда. Затем узлы-валидаторы с (r+1)-го раунда начинают выполнять новый экземпляр Bullshark, используя обновленную функцию выбора опорных точек F'.
![Подробное объяснение рамки Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Нет больше тайм-аутов
Тайм-аут играет жизненно важную роль во всех реализациях BFT с детерминированной синхронизацией на основе лидера. Однако их сложность увеличивает количество внутренних состояний, которые нужно управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также будет значительно увеличивать задержку, поскольку важно правильно их настроить, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Протокол будет выплачивать полное наказание за задержку тайм-аута для вышедшего из строя лидера перед переходом к следующему лидеру. Следовательно, настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истек до того, как они смогли продвинуться вперед.
К сожалению, основанный на протоколе лидера ), таком как Hotstuff
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
10
Поделиться
комментарий
0/400
TokenomicsTrapper
· 07-16 23:24
классический венчурный капитал дым и зеркала... 40% ничего не значит, если базовая задержка была ужасной, честно говоря.
Посмотреть ОригиналОтветить0
rekt_but_resilient
· 07-16 17:01
задержка снизилась на 80%? На луну
Посмотреть ОригиналОтветить0
NestedFox
· 07-16 09:09
Восемьдесят градусов улучшения удивительный
Посмотреть ОригиналОтветить0
Blockwatcher9000
· 07-15 13:37
Еще в борьбе с задержкой, да?
Посмотреть ОригиналОтветить0
GasFeePhobia
· 07-14 02:57
40 не слишком сильно, да? Эффект неплохой.
Посмотреть ОригиналОтветить0
MEVHunterBearish
· 07-14 02:55
Это что, полезно? Мы просто бычий, а не с падением.
Shoal框架大幅 Падение Aptos上Bullshark задержка 实现无超时确定性 Соглашение
Shoal框架:значительное падение задержки Bullshark на Aptos
Недавно 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, что значительно ниже целевого показателя в 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.
Предыстория 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 имеют следующую структуру:
Запланированная опорная точка: каждые несколько раундов (, как в Bullshark, через два раунда ) будет запланированный лидер, вершина которого называется опорной точкой.
Точки сортировки: валидаторы независимо, но детерминированно решают, какие точки сортировки использовать, а какие пропустить.
Упорядоченная причинно-следственная история: валидаторы последовательно обрабатывают упорядоченный список якорных точек, для каждой якорной точки с помощью детерминированных правил упорядочивают все предыдущие неупорядоченные вершины в ее причинно-следственной истории.
Ключом к обеспечению безопасности является гарантия того, что на этапе (2) все честные узлы верификации создают упорядоченный список анкорных точек, чтобы все списки имели одинаковый префикс. В Shoal мы делаем следующие наблюдения по всем вышеупомянутым протоколам:
Все валидаторы согласны с первой упорядоченной якорной точкой.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя у синхронной версии Bullshark, как правило, лучше задержка, чем у асинхронной версии, это далеко от оптимального.
Вопрос 1: Среднее время задержки блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины нечетной итерации трактуются как голосование. В обычных условиях для сортировки опорных точек требуется две итерации DAG, однако вершины в причинной истории опорных точек требуют больше итераций, чтобы дождаться сортировки опорных точек. В обычных условиях вершины в нечетной итерации требуют три итерации, а не опорные вершины в четной итерации требуют четыре итерации.
Вопрос 2: случаи сбоев задержка. Вышеуказанный анализ задержки применяется к случаям без сбоев, с другой стороны, если лидер раунда не сможет достаточно быстро транслировать опорную точку, сортировка опорной точки станет невозможной (, поэтому она будет пропущена ), и все несортированные вершины из предыдущих раундов должны ждать следующей сортировки опорной точки. Это значительно приведет к Падению производительности географической репликации сети, особенно потому, что Bullshark использует тайм-аут для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Shoal фрейм
Shoal решает эти две проблемы задержки, он улучшает Bullshark( или любой другой протокол BFT на основе Narwhal) за счет конвейерной обработки, позволяя иметь опорную точку в каждом раунде и снижая задержку всех не-опорных вершин в DAG до трех раундов. Shoal также вводит механизм репутации лидеров с нулевой затратой в DAG, что делает выбор более предпочтительным для быстрых лидеров.
Вызов
В контексте протокола DAG, конвейеризация и репутация лидеров считаются сложными вопросами по следующим причинам:
Предыдущие попытки изменить основную логику Bullshark в конвейере, по сути, казались невозможными.
Репутация лидеров вводится в DiemBFT и формализуется в Carousel, что представляет собой динамический выбор будущих лидеров на основе прошлых результатов валидаторов, идея о якоре в Bullshark (. Хотя наличие разногласий по поводу лидерства не нарушает безопасность этих протоколов, в Bullshark это может привести к совершенно различным порядкам, что поднимает основной вопрос: динамический и детерминированный выбор ротационного якоря необходим для достижения консенсуса, и валидаторы должны согласовать упорядоченную историю для выбора будущего якоря.
В качестве доказательства сложности проблемы мы отмечаем, что реализация Bullshark, включая текущую реализацию в производственной среде, не поддерживает эти функции.
Протокол
Несмотря на вышеперечисленные проблемы, оказалось, что решение скрыто в простоте.
В Shoal мы полагаемся на способность выполнять локальные вычисления на DAG и реализуем возможность сохранения и переинтерпретации информации из предыдущих раундов. Благодаря тому, что все валидаторы согласны с основным пониманием первого упорядоченного якоря, Shoal последовательно комбинирует несколько экземпляров Bullshark для их обработки в конвейере, что делает ) первым упорядоченным якорем, а также ( причинной историей якоря для вычисления репутации лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.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-0b0928cb6240e994c1514c75e080a4b2.webp(
Репутация лидеров
При пропуске анкерной точки во время сортировки Bullshark задержка увеличивается. В этом случае технология конвейера бессильна, так как новое соединение не может быть запущено до сортировки анкерной точки предыдущего экземпляра. Shoal гарантирует, что в будущем маловероятно, что соответствующий лидер будет выбран для обработки пропущенных анкерных точек, присваивая каждой узловой валидации балл на основе истории недавней активности каждого узла валидации с помощью механизма репутации. Валидации, которые откликнутся и участвуют в протоколе, получат высокие баллы, в противном случае узлы валидации будут получать низкие баллы, так как они могут быть зависшими, медленными или злонамеренными.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, склоняясь к лидеру с более высоким счетом. Чтобы валидаторы согласовали новое отображение, они должны согласовать счет, тем самым достигнув согласия по истории, используемой для производных оценок.
В Shoal, конвейеры и репутация лидеров могут естественно сочетаться, так как они используют одну и ту же основную технологию, а именно, переинтерпретацию DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле единственное отличие заключается в том, что после сортировки опорных точек в r-м раунде валидатору необходимо просто на основе причинно-исторической информации упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с (r+1)-го раунда. Затем узлы-валидаторы с (r+1)-го раунда начинают выполнять новый экземпляр Bullshark, используя обновленную функцию выбора опорных точек F'.
![Подробное объяснение рамки Shoal: как уменьшить задержку Bullshark на Aptos?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Нет больше тайм-аутов
Тайм-аут играет жизненно важную роль во всех реализациях BFT с детерминированной синхронизацией на основе лидера. Однако их сложность увеличивает количество внутренних состояний, которые нужно управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также будет значительно увеличивать задержку, поскольку важно правильно их настроить, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Протокол будет выплачивать полное наказание за задержку тайм-аута для вышедшего из строя лидера перед переходом к следующему лидеру. Следовательно, настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истек до того, как они смогли продвинуться вперед.
К сожалению, основанный на протоколе лидера ), таком как Hotstuff