Оптимизация DAG Соглашения: Как Shoal Framework снижает задержку 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, что значительно ниже целевого показателя в 100k+ TPS.
Недавний прорыв связан с осознанием того, что распространение данных является основной проблемой, основанной на соглашении лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики согласования и предлагает архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты согласования сортируют лишь небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности в 160 000 TPS.
В предыдущей статье мы представили Quorum Store. Наша реализация Narwhal разделяет распространение данных и согласование, а также то, как использовать это для расширения текущего протокола согласования Jolteon. Jolteon — это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и изменения представления в стиле PBFT, позволяя снизить задержку Hotstuff на 33%. Однако протоколы согласования на основе лидера явно не могут полностью реализовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и согласования, с увеличением пропускной способности лидер Hotstuff/Jolteon по-прежнему остается ограниченным.
Таким образом, мы решили развернуть Bullshark, протокол согласования с нулевыми затратами на связь, на Narwhal DAG. К сожалению, по сравнению с Jolteon, DAG-структура, поддерживающая высокий уровень производительности Bullshark, несет 50% затрат на задержку.
В этой статье рассматривается, как Shoal значительно снизил задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в DAG Narwhal связана с определенным раундом. Чтобы войти в раунд 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-f6b6281c928e3fa7a2412a480c9c1806.webp)
Полный порядок
Можно достичь полного порядка для всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как соглашение, где вершины представляют собой предложения, а ребра представляют собой голоса.
Хотя логика группового пересечения в структуре DAG отличается, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Предварительная опора: каждые несколько раундов есть заранее определенный лидер, его вершина называется опорой.
Точки сортировки: валидаторы независимо, но определённо решают, какие точки сортировки учитывать, а какие пропускать.
Упорядочение причинно-следственной истории: валидаторы по очереди обрабатывают упорядоченный список анкерных точек, сортируя все предыдущие неупорядоченные вершины в причинно-следственной истории каждой анкерной точки.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (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 (, по сути, требуют задержки, чтобы гарантировать, что протокол может продвигаться вперед каждый раз, когда лидер выходит из строя. Если задержки нет, даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронный период невозможно отличить вышедшего из строя лидера от медленного лидера, задержка может привести к тому, что узлы-валидаторы будут рассматривать изменения всех лидеров без активности согласия.
В Bullshark задержка используется для построения DAG, чтобы обеспечить добавление контрольной точки честным лидером во время синхронизации
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
11 Лайков
Награда
11
6
Репост
Поделиться
комментарий
0/400
GateUser-c799715c
· 08-09 07:45
Улучшение производительности неплохое~
Посмотреть ОригиналОтветить0
AllInAlice
· 08-09 05:29
это жесткий человек 40% снижение задержки
Посмотреть ОригиналОтветить0
0xSherlock
· 08-09 05:28
задержка эта волна может быть обработана довольно стильно
Посмотреть ОригиналОтветить0
BrokenYield
· 08-09 05:27
meh, очередная "оптимизация", которая, вероятно, создаст больше системных рисков, чем решит... умные деньги уже хеджируют против этого
Оптимизация фреймворка Shoal DAG соглашения значительно снижает задержку Bullshark на Aptos
Оптимизация DAG Соглашения: Как Shoal Framework снижает задержку 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, что значительно ниже целевого показателя в 100k+ TPS.
Недавний прорыв связан с осознанием того, что распространение данных является основной проблемой, основанной на соглашении лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики согласования и предлагает архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты согласования сортируют лишь небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности в 160 000 TPS.
В предыдущей статье мы представили Quorum Store. Наша реализация Narwhal разделяет распространение данных и согласование, а также то, как использовать это для расширения текущего протокола согласования Jolteon. Jolteon — это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и изменения представления в стиле PBFT, позволяя снизить задержку Hotstuff на 33%. Однако протоколы согласования на основе лидера явно не могут полностью реализовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и согласования, с увеличением пропускной способности лидер Hotstuff/Jolteon по-прежнему остается ограниченным.
Таким образом, мы решили развернуть Bullshark, протокол согласования с нулевыми затратами на связь, на Narwhal DAG. К сожалению, по сравнению с Jolteon, DAG-структура, поддерживающая высокий уровень производительности Bullshark, несет 50% затрат на задержку.
В этой статье рассматривается, как Shoal значительно снизил задержку Bullshark.
Предыстория DAG-BFT
Каждая вершина в DAG Narwhal связана с определенным раундом. Чтобы войти в раунд 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-f6b6281c928e3fa7a2412a480c9c1806.webp)
Полный порядок
Можно достичь полного порядка для всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как соглашение, где вершины представляют собой предложения, а ребра представляют собой голоса.
Хотя логика группового пересечения в структуре DAG отличается, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Предварительная опора: каждые несколько раундов есть заранее определенный лидер, его вершина называется опорой.
Точки сортировки: валидаторы независимо, но определённо решают, какие точки сортировки учитывать, а какие пропускать.
Упорядочение причинно-следственной истории: валидаторы по очереди обрабатывают упорядоченный список анкерных точек, сортируя все предыдущие неупорядоченные вершины в причинно-следственной истории каждой анкерной точки.
Ключом к обеспечению безопасности является гарантирование того, что на этапе (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 (, по сути, требуют задержки, чтобы гарантировать, что протокол может продвигаться вперед каждый раз, когда лидер выходит из строя. Если задержки нет, даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронный период невозможно отличить вышедшего из строя лидера от медленного лидера, задержка может привести к тому, что узлы-валидаторы будут рассматривать изменения всех лидеров без активности согласия.
В Bullshark задержка используется для построения DAG, чтобы обеспечить добавление контрольной точки честным лидером во время синхронизации