Aptos Labs решило две важные открытые проблемы в DAG BFT, значительно Падение задержки и впервые в детерминированном реальном протоколе устранило потребность в тайм-ауте. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, в случае сбоев - на 80%.
Shoal является фреймворком, который улучшает любую основанную на Narwhal соглашение о консенсусе (, такую как DAG-Rider, Tusk, Bullshark ), с помощью конвейера и репутации лидера. Конвейер снижает задержку сортировки DAG, вводя опорные точки в каждом раунде, а репутация лидера дополнительно улучшает проблему задержки, обеспечивая связь опорных точек с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронные конструкции DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal обеспечить универсальные свойства отклика, включая обычно требуемый оптимистичный ответ.
Эта технология очень проста и включает в себя последовательный запуск нескольких экземпляров основного протокола. Таким образом, при инстанцировании Bullshark мы получаем группу "акул", которые участвуют в эстафете.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Фон
При стремлении к высокой производительности блокчейн-сетей, люди всегда обращали внимание на Падение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, обеспечивал всего 3500 TPS, что значительно ниже целевого значения в 100k+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на протоколах лидеров, и может извлечь выгоду из параллелизации. Система Narwhal разделяет распространение данных и основную логику консенсуса, предлагая всем валидаторам одновременно распространять данные, в то время как компонент консенсуса только упорядочивает небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности 160,000 TPS.
Ранее представленное Quorum Store является реализацией Narwhal, которая отделяет распространение данных от консенсуса, чтобы расширить текущий консенсусный протокол Jolteon. Jolteon - это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, снижая задержку Hotstuff на 33%. Тем не менее, консенсусный протокол на основе лидера не может в полной мере использовать потенциал пропускной способности Narwhal.
Поэтому было решено развернуть Bullshark на Narwhal DAG, который представляет собой протокол согласия с нулевыми накладными расходами на связь. К сожалению, структура DAG, поддерживающая высокую пропускную способность Bullshark, приводит к 50% Падение по сравнению с Jolteon.
В данной статье описывается, как Shoal значительно уменьшает задержку Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы попасть в раунд r, валидатор должен сначала получить n-f вершин раунда r-1. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться по меньшей мере на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент видеть разные локальные представления DAG.
Ключевым свойством DAG является неразмытость: если два узла проверки имеют одинаковую вершину v в локальном представлении DAG, то они имеют полностью одинаковую причинно-следственную историю v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Полный порядок
Можно достичь полной последовательной согласованности всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как согласованный протокол, где вершины представляют собой предложения, а ребра — голоса.
Все существующие консенсусные протоколы на основе Narwhal имеют следующую структуру:
Предварительная точка привязки: каждые несколько раундов есть заранее определённый лидер, вершина которого называется точкой привязки.
Упорядочение якорных точек: валидатор независимо, но с определенностью решает, какие якорные точки заказывать, а какие пропускать.
Упорядоченная причинно-следственная история: валидаторы обрабатывают упорядоченный список контрольных точек один за другим, сортируя все предыдущие неупорядоченные вершины в истории причинно-следственной связи каждого контрольного пункта по детерминированным правилам.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что в шаге (2) все честные узлы-валидаторы создают упорядоченный список якорных точек, который имеет одинаковый префикс. Shoal делает следующие наблюдения по всем этим протоколам:
Все валидаторы согласны с первой упорядоченной якорной точкой.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя некоторые версии синхронизации имеют лучшую задержку по сравнению с асинхронными версиями, это далеко не оптимально.
Вопрос 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-м раунде, валидатору нужно просто на основе причинно-следственной истории упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с r+1-го раунда. Затем узлы-валидаторы начинают выполнять новый экземпляр Bullshark, используя обновленную функцию выбора опорных точек F' начиная с r+1-го раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Нет тайм-аута
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированной частью на основе лидера. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что увеличивает сложность отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что важно правильно их настроить, что обычно требует динамической корректировки и сильно зависит от окружения ) сети ###. Перед переходом к следующему лидеру протокол будет выплачивать полное наказание за тайм-аут за неудавшегося лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если они слишком короткие, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истек до того, как было достигнуто продвижение.
К сожалению, протоколы, основанные на лидерах, такие как Hotstuff и Jolteon (, по своей сути требуют задержки, чтобы гарантировать, что протокол будет продвигаться каждый раз, когда лидер выходит из строя. Без задержки даже упавший лидер может навсегда остановить протокол. Поскольку во время асинхронного периода невозможно отличить сбойного лидера от медленного лидера, задержка может привести к тому, что проверяющие узлы изменят всех лидеров при отсутствии активного консенсуса.
В Bullshark задержка используется для построения DAG, чтобы гарантировать, что честные лидеры достаточно быстро добавляют точки привязки в DAG для сортировки во время синхронизации.
Мы наблюдали, что конструкция DAG предоставляет «часы» для оценки скорости сети. При отсутствии задержек, как только n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продолжаться. Хотя Bullshark может не сортировать ) с сетевой скоростью из-за проблем с лидерами (, DAG все же растет с сетевой скоростью, хотя некоторые лидеры имеют проблемы или сеть асинхронна. В конечном итоге, когда достаточно быстрые лидеры без сбоев транслируют якорные точки, вся каузальная история якорных точек будет отсортирована.
В нашей оценке сравнивалось, было ли Падение у Bullshark в следующих случаях:
Быстрый лидер: как минимум быстрее, чем другие валидаторы. Оба метода обеспечивают одинаковую задержку, так как якорь упорядочен и не использует тайм-ауты.
Ошибочные лидеры: без тайм-аута Bullshark обеспечивает лучшее время задержки, так как узлы проверки сразу же пропускают его.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
10 Лайков
Награда
10
4
Репост
Поделиться
комментарий
0/400
HashRateHermit
· 5ч назад
задержка улучшена на 80%? Эта волна быка!
Посмотреть ОригиналОтветить0
SelfRugger
· 5ч назад
80% задержка уменьшена, Ма Дэ посмотрел и закричал бык
Посмотреть ОригиналОтветить0
CommunitySlacker
· 5ч назад
бык啤 задержка都优化80%了
Посмотреть ОригиналОтветить0
Hash_Bandit
· 5ч назад
черт, это как когда мы оптимизировали сложность майнинга btc в 2013 году... серьезные хэшрейт приросты, брат
Shoal框架：Aptos上Bullshark задержка оптимизация прорыв
Shoal框架:如何 Падение Aptos上Bullshark的 задержка
Aptos Labs решило две важные открытые проблемы в DAG BFT, значительно Падение задержки и впервые в детерминированном реальном протоколе устранило потребность в тайм-ауте. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, в случае сбоев - на 80%.
Shoal является фреймворком, который улучшает любую основанную на Narwhal соглашение о консенсусе (, такую как DAG-Rider, Tusk, Bullshark ), с помощью конвейера и репутации лидера. Конвейер снижает задержку сортировки DAG, вводя опорные точки в каждом раунде, а репутация лидера дополнительно улучшает проблему задержки, обеспечивая связь опорных точек с самыми быстрыми узлами проверки. Кроме того, репутация лидера позволяет Shoal использовать асинхронные конструкции DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal обеспечить универсальные свойства отклика, включая обычно требуемый оптимистичный ответ.
Эта технология очень проста и включает в себя последовательный запуск нескольких экземпляров основного протокола. Таким образом, при инстанцировании Bullshark мы получаем группу "акул", которые участвуют в эстафете.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp)
Фон
При стремлении к высокой производительности блокчейн-сетей, люди всегда обращали внимание на Падение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, Hotstuff, реализованный в ранних версиях Diem, обеспечивал всего 3500 TPS, что значительно ниже целевого значения в 100k+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на протоколах лидеров, и может извлечь выгоду из параллелизации. Система Narwhal разделяет распространение данных и основную логику консенсуса, предлагая всем валидаторам одновременно распространять данные, в то время как компонент консенсуса только упорядочивает небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности 160,000 TPS.
Ранее представленное Quorum Store является реализацией Narwhal, которая отделяет распространение данных от консенсуса, чтобы расширить текущий консенсусный протокол Jolteon. Jolteon - это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, снижая задержку Hotstuff на 33%. Тем не менее, консенсусный протокол на основе лидера не может в полной мере использовать потенциал пропускной способности Narwhal.
Поэтому было решено развернуть Bullshark на Narwhal DAG, который представляет собой протокол согласия с нулевыми накладными расходами на связь. К сожалению, структура DAG, поддерживающая высокую пропускную способность Bullshark, приводит к 50% Падение по сравнению с Jolteon.
В данной статье описывается, как Shoal значительно уменьшает задержку Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы попасть в раунд r, валидатор должен сначала получить n-f вершин раунда r-1. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться по меньшей мере на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент видеть разные локальные представления DAG.
Ключевым свойством DAG является неразмытость: если два узла проверки имеют одинаковую вершину v в локальном представлении DAG, то они имеют полностью одинаковую причинно-следственную историю v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Полный порядок
Можно достичь полной последовательной согласованности всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как согласованный протокол, где вершины представляют собой предложения, а ребра — голоса.
Все существующие консенсусные протоколы на основе Narwhal имеют следующую структуру:
Предварительная точка привязки: каждые несколько раундов есть заранее определённый лидер, вершина которого называется точкой привязки.
Упорядочение якорных точек: валидатор независимо, но с определенностью решает, какие якорные точки заказывать, а какие пропускать.
Упорядоченная причинно-следственная история: валидаторы обрабатывают упорядоченный список контрольных точек один за другим, сортируя все предыдущие неупорядоченные вершины в истории причинно-следственной связи каждого контрольного пункта по детерминированным правилам.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что в шаге (2) все честные узлы-валидаторы создают упорядоченный список якорных точек, который имеет одинаковый префикс. Shoal делает следующие наблюдения по всем этим протоколам:
Все валидаторы согласны с первой упорядоченной якорной точкой.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя некоторые версии синхронизации имеют лучшую задержку по сравнению с асинхронными версиями, это далеко не оптимально.
Вопрос 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-м раунде, валидатору нужно просто на основе причинно-следственной истории упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с r+1-го раунда. Затем узлы-валидаторы начинают выполнять новый экземпляр Bullshark, используя обновленную функцию выбора опорных точек F' начиная с r+1-го раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp###
( Нет тайм-аута
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированной частью на основе лидера. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что увеличивает сложность отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что важно правильно их настроить, что обычно требует динамической корректировки и сильно зависит от окружения ) сети ###. Перед переходом к следующему лидеру протокол будет выплачивать полное наказание за тайм-аут за неудавшегося лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если они слишком короткие, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истек до того, как было достигнуто продвижение.
К сожалению, протоколы, основанные на лидерах, такие как Hotstuff и Jolteon (, по своей сути требуют задержки, чтобы гарантировать, что протокол будет продвигаться каждый раз, когда лидер выходит из строя. Без задержки даже упавший лидер может навсегда остановить протокол. Поскольку во время асинхронного периода невозможно отличить сбойного лидера от медленного лидера, задержка может привести к тому, что проверяющие узлы изменят всех лидеров при отсутствии активного консенсуса.
В Bullshark задержка используется для построения DAG, чтобы гарантировать, что честные лидеры достаточно быстро добавляют точки привязки в DAG для сортировки во время синхронизации.
Мы наблюдали, что конструкция DAG предоставляет «часы» для оценки скорости сети. При отсутствии задержек, как только n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продолжаться. Хотя Bullshark может не сортировать ) с сетевой скоростью из-за проблем с лидерами (, DAG все же растет с сетевой скоростью, хотя некоторые лидеры имеют проблемы или сеть асинхронна. В конечном итоге, когда достаточно быстрые лидеры без сбоев транслируют якорные точки, вся каузальная история якорных точек будет отсортирована.
В нашей оценке сравнивалось, было ли Падение у Bullshark в следующих случаях:
Быстрый лидер: как минимум быстрее, чем другие валидаторы. Оба метода обеспечивают одинаковую задержку, так как якорь упорядочен и не использует тайм-ауты.
Ошибочные лидеры: без тайм-аута Bullshark обеспечивает лучшее время задержки, так как узлы проверки сразу же пропускают его.