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, что значительно ниже нашей цели в более чем 100000 TPS.

Но недавний прорыв связан с осознанием того, что распространение данных является основным узким местом на основе протокола лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты консенсуса только упорядочивают небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности 160000 TPS.

В предыдущей статье мы представили Quorum Store. Наша реализация Narwhal отделяет распространение данных от консенсуса и показывает, как мы используем это для масштабирования текущего протокола консенсуса Jolteon. Jolteon — это основанный на лидере протокол, который сочетает линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, очевидно, что протокол консенсуса, основанный на лидере, не может в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на то, что распространение данных отделено от консенсуса, с увеличением пропускной способности лидеры Hotstuff/Jolteon по-прежнему остаются ограниченными.

Поэтому мы решили развернуть Bullshark на Narwhal DAG, это протокол консенсуса с нулевыми коммуникационными затратами. К сожалению, по сравнению с Jolteon, DAG-структура, поддерживающая высокий throughput Bullshark, имеет 50% падение.

В этой статье будет рассмотрено, как Shoal значительно Падение задержка Bullshark.

Предыстория DAG-BFT

Давайте сначала разберемся с соответствующим фоном. Подробное описание Narwhal и Bullshark можно найти в статье DAG meets BFT.

Каждая вершина в Narwhal DAG связана с определенным раундом. Чтобы войти в раунд r, валидатор должен сначала получить n-f вершин, принадлежащих раунду r-1. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут наблюдать разные локальные представления DAG в любой момент времени.

Ключевым свойством DAG является его однозначность: если два узла-валидатора имеют в своих локальных представлениях DAG одинаковую вершину v, то у них абсолютно одинаковая причинно-следственная история v.

![Подробное объяснение фрейма Shoal: как уменьшить задержку Bullshark на Aptos?]###https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(

) Полный порядок

Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как механизм консенсуса, где вершины представляют собой предложения, а ребра — голоса.

Хотя логика групповых пересечений в структуре DAG различна, все существующие на основе Narwhal соглашения имеют следующую структуру:

1### Запланированная опорная точка: каждые несколько раундов ), как в Bullshark, каждые два раунда (, будет заранее определенный лидер, вершина лидера называется опорной точкой;

2. Точки сортировки: валидаторы независимо, но определенно решают, какие точки привязки заказывать, а какие пропускать;

3. сортировка причинно-следственной истории: валидаторы по очереди обрабатывают упорядоченный список якорных точек, для каждой якорной точки, с помощью некоторых детерминированных правил сортируют все предыдущие неупорядоченные вершины в ее причинно-следственной истории.

Ключом к обеспечению безопасности является гарантирование того, что на этапе )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 решает эти две проблемы задержки, он усиливает Bullshark### или любой другой протокол BFT на основе Narwhal( через конвейер, позволяя иметь одну опорную точку в каждом раунде и снижая задержку всех не опорных вершин в DAG до трех раундов. Shoal также вводит механизм репутации лидера с нулевыми затратами в DAG, что делает выбор склонным к быстрым лидерам.

) вызов

В контексте протокола DAG, конвейер и репутация лидера считаются сложными проблемами по следующим причинам:

1### Ранее попытки изменить основную логику Bullshark через обработку конвейера, казалось, были невозможными по своей сути.

2. Репутация лидера была внедрена в 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 с детерминированной частичной синхронизацией, основанных на лидере. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.

Тайм-аут также будет значительно увеличивать задержку, потому что их правильная настройка очень важна и обычно требует динамической корректировки, так как она сильно зависит от окружения ( сети ). Перед переходом к следующему лидеру протокол будет выплачивать полное наказание за задержку тайм-аута для вышедшего из строя лидера. Таким образом, настройки тайм-аута не могут быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки, Jolt