Shoal框架:инновационное решение для уменьшения задержки Bullshark на Aptos
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(
Фон и мотивация
В процессе стремления к высокой производительности блокчейна снижение сложности коммуникации всегда было в центре внимания, но этот подход не привел к значительному увеличению пропускной способности. Например, ранняя версия Diem, реализованная с Hotstuff, достигла всего 3500 TPS, что значительно ниже целевого показателя в 100000+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на соглашении лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, а компонент консенсуса лишь сортирует небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности 160 тысяч TPS.
Мы ранее представили Quorum Store, наша реализация Narwhal разделяет распространение данных и консенсус, а также то, как использовать его для масштабирования текущего протокола консенсуса 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 является отсутствие неоднозначности: если два узла-валидатора имеют в своих локальных представлениях 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 раунда. Затем узлы валидации начинают использовать обновленную функцию выбора якорей F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Нет больше задержек
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированной частичной синхронизацией на основе лидера. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что очень важно правильно их настроить, и обычно требуется динамическая корректировка, поскольку это сильно зависит от среды ) сети ###. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истек до того, как они продвинулись вперед.
К сожалению, протоколы на основе лидеров (, такие как Hotstuff и Jolteon), по сути, требуют задержки, чтобы гарантировать, что каждый раз, когда лидер выходит из строя,
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
13 Лайков
Награда
13
6
Репост
Поделиться
комментарий
0/400
SandwichDetector
· 14ч назад
Увеличение производительности просто бык, 80% увеличение — это невероятно.
Посмотреть ОригиналОтветить0
NFTRegretful
· 14ч назад
Выглядит неплохо, просто скорость пока недостаточно высокая.
Посмотреть ОригиналОтветить0
BearMarketSurvivor
· 15ч назад
задержка Падение 80% Это настоящая сила на поле боя, ждем боевых результатов.
Посмотреть ОригиналОтветить0
CoinBasedThinking
· 15ч назад
Надежный проект, техническое обновление. Надеюсь, это не окажется пустым обещанием.
Shoal框架提升Aptos Соглашение эффективности Bullshark задержка Падение 80%
Shoal框架:инновационное решение для уменьшения задержки Bullshark на Aptos
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(
Фон и мотивация
В процессе стремления к высокой производительности блокчейна снижение сложности коммуникации всегда было в центре внимания, но этот подход не привел к значительному увеличению пропускной способности. Например, ранняя версия Diem, реализованная с Hotstuff, достигла всего 3500 TPS, что значительно ниже целевого показателя в 100000+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на соглашении лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, а компонент консенсуса лишь сортирует небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности 160 тысяч TPS.
Мы ранее представили Quorum Store, наша реализация Narwhal разделяет распространение данных и консенсус, а также то, как использовать его для масштабирования текущего протокола консенсуса 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 является отсутствие неоднозначности: если два узла-валидатора имеют в своих локальных представлениях 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 раунда. Затем узлы валидации начинают использовать обновленную функцию выбора якорей F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Нет больше задержек
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированной частичной синхронизацией на основе лидера. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что очень важно правильно их настроить, и обычно требуется динамическая корректировка, поскольку это сильно зависит от среды ) сети ###. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истек до того, как они продвинулись вперед.
К сожалению, протоколы на основе лидеров (, такие как Hotstuff и Jolteon), по сути, требуют задержки, чтобы гарантировать, что каждый раз, когда лидер выходит из строя,