Shoal Framework: Как уменьшить задержку Bullshark на Aptos?
Обзор
Aptos labs решило две важные открытые проблемы в DAG BFT, значительно снизив задержку и впервые устранив необходимость в приостановке в детерминированном реальном протоколе. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев - на 80%.
Shoal — это фреймворк, который усиливает основанный на Narwhal консенсусный протокол с помощью конвейера и репутации лидера. Конвейер уменьшает задержка сортировки 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 отделяет распространение данных от консенсуса, чтобы расширить текущий протокол консенсуса Jolteon. Jolteon — это основанный на лидере протокол, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Однако основанные на лидере протоколы консенсуса не могут в полной мере использовать потенциал пропускной способности Narwhal.
Таким образом, было решено развернуть Bullshark на Narwhal DAG, протокол консенсуса с нулевыми затратами на связь. Однако структура DAG Bullshark приводит к 50% задержке.
В данной статье рассказывается о том, как Shoal значительно уменьшает задержку Bullshark.
Предыстория 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-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на связь. Проверяющие в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как протокол консенсуса, где вершины представляют предложения, а ребра представляют голоса.
Все существующие протоколы консенсуса на основе Narwhal имеют следующую структуру:
Резервная опора: каждые несколько раундов есть заранее определенный лидер, вершина лидера называется опорой.
Точки сортировки: валидаторы независимо, но детерминированно решают, какие точки привязки заказывать, а какие пропускать.
Упорядоченная причинно-следственная история: валидаторы обрабатывают упорядоченный список якорных точек один за другим, сортируя все предыдущие неупорядоченные вершины в причинно-следственной истории каждой якорной точки.
Ключ к обеспечению безопасности заключается в том, чтобы на шаге 2 все честные узлы-верификаторы создали упорядоченный список якорей, все списки делились одним и тем же префиксом. В Shoal мы наблюдали, что все верификаторы согласны с первым упорядоченным якорем.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя некоторые версии синхронизации имеют лучшую задержку, чем асинхронные версии, но это далеко не оптимально.
Основные два вопроса:
Средняя задержка блока: в обычных случаях, вершина нечетного раунда требует три раунда, а вершина четного раунда, не являющаяся анкеровкой, требует четыре раунда для сортировки.
Ситуация с неисправностью задержка: если один раунд лидера не смог вовремя транслировать опорную точку, то передние несортированные вершины должны ждать сортировки следующей опорной точки, что значительно снижает производительность географической репликационной сети.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Фреймворк Shoal
Shoal улучшает Bullshark через конвейер, позволяя иметь одну опорную точку на каждом раунде, уменьшая задержку всех неподдерживаемых вершин до трех раундов. Shoal также вводит механизм репутации лидера с нулевыми затратами, предпочитая выбор быстрых лидеров.
Вызов
В протоколе DAG вопросы конвейеризации и репутации лидера считаются сложными.
Предыдущие попытки изменить основную логику Bullshark в конвейере, похоже, были невозможны.
Репутация лидера может привести к совершенно другим порядкам, и валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности проблемы, текущие реализации Bullshark в производственной среде не поддерживают эти функции.
Протокол
Shoal полагается на выполнение локальных вычислений на DAG, что позволяет сохранять и переосмыслять информацию из предыдущих раундов. Используя понимание того, что все валидаторы согласны с первым упорядоченным якорем, Shoal последовательно комбинирует несколько экземпляров Bullshark для конвейерной обработки, что позволяет:
Первая упорядоченная якорная точка — это точка переключения экземпляра
Историческая причинно-следственная связь якоря используется для расчета репутации лидера
конвейер
Shoal запускает экземпляры Bullshark один за другим, каждый экземпляр заказывает анкер, что приводит к переключению на следующий экземпляр.
Сначала Shoal запускает первый экземпляр Bullshark в первом раунде DAG, работающем до тех пор, пока не будет определена первая упорядоченная якорная точка (, например, в раунде r ). Все валидаторы согласны с этой якорной точкой, поэтому можно с уверенностью согласиться на переинтерпретацию DAG с раунда r+1. Shoal запускает новый экземпляр Bullshark в раунде r+1.
В идеальных условиях это позволяет Shoal заказывать одну якорную точку за раунд.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
репутация лидера
Когда Bullshark перескакивает опорную точку, задержка увеличивается. Shoal назначает баллы каждому узлу-валидатору через механизм репутации, чтобы в будущем с меньшей вероятностью выбирать медленных лидеров.
При каждом обновлении баллов необходимо детерминированно пересчитывать отображение F от раунда к лидеру, отдавая предпочтение лидерам с высокими баллами. Чтобы валидаторы достигли согласия по новому отображению, они должны согласовать баллы.
Потоковая линия и репутация лидеров могут естественно сочетаться, поскольку они используют одну и ту же основную технологию, а именно переосмысляют DAG после достижения согласия по первой упорядоченной опорной точке.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Не требуется задержка
Тайм-аут играет ключевую роль в реализации BFT с определенностью на основе лидера, но вводит сложность и значительно увеличивает задержку.
Shoal наблюдает, что конструкция DAG предоставляет "часы" для оценки скорости сети. Пока n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продолжаться. В конечном итоге, когда безошибочный лидер достаточно быстро передает якорные точки, вся причинно-следственная история якорных точек будет отсортирована.
Избегание задержки тесно связано с репутацией лидера. Повторное ожидание медленных лидеров увеличивает задержку, в то время как механизмы репутации исключают медленных валидаторов из числа лидеров.
Общий ответ
Shoal предоставляет свойства универсального отклика, которые могут работать на сетевой скорости даже в случае сбоя лидера или асинхронности сети. Это лучше, чем концепция оптимистичного отклика Hotstuff.
Оценка
Реализованы Bullshark и Shoal, и проведено сравнение с Jolteon. Основные выводы:
Безвременной Baseline Bullshark показывает лучшие результаты при сбоях.
Потоковая линия Shoal и механизм репутации лидеров значительно улучшили задержку Bullshark.
Из 50 неудач в 16 случаях задержка Shoal была на 65% ниже, чем у Baseline Bullshark.
Jolteon не может расширяться более чем на 20 проверочных узлов, пропускная способность составляет примерно половину от Bullshark/Shoal.
В целом, Shoal значительно улучшил задержку Bullshark, и при высокой нагрузке должен соответствовать задержке Jolteon в режиме «от конца до конца».
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp)
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp)
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-cc09a26f7c3d94ee785de75e47bf42fb.webp)
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-6461c85fe1553879062fd7628f50f553.webp)
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
5
Репост
Поделиться
комментарий
0/400
governance_ghost
· 08-10 03:14
80% задержка уменьшилась, цок-цок, мы, игроки apttas, выиграли на этой волне!
Посмотреть ОригиналОтветить0
ForkItAll
· 08-10 03:09
aptos хорошо справился, tps сразу так много повысилось
Посмотреть ОригиналОтветить0
DaisyUnicorn
· 08-10 03:08
Маленькая акула наконец-то свободно плавает~ Техническое обновление превратилось в весеннюю воду.
Посмотреть ОригиналОтветить0
SignatureCollector
· 08-10 02:59
А это aptos На луну
Посмотреть ОригиналОтветить0
OnChainSleuth
· 08-10 02:45
Бык, а Aptos эффективность значительно повысилась.
Рамка Shoal значительно улучшает производительность Блокчейн Aptos, снижая задержку на 40%-80%
Shoal Framework: Как уменьшить задержку Bullshark на Aptos?
Обзор
Aptos labs решило две важные открытые проблемы в DAG BFT, значительно снизив задержку и впервые устранив необходимость в приостановке в детерминированном реальном протоколе. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев - на 80%.
Shoal — это фреймворк, который усиливает основанный на Narwhal консенсусный протокол с помощью конвейера и репутации лидера. Конвейер уменьшает задержка сортировки 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 отделяет распространение данных от консенсуса, чтобы расширить текущий протокол консенсуса Jolteon. Jolteon — это основанный на лидере протокол, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Однако основанные на лидере протоколы консенсуса не могут в полной мере использовать потенциал пропускной способности Narwhal.
Таким образом, было решено развернуть Bullshark на Narwhal DAG, протокол консенсуса с нулевыми затратами на связь. Однако структура DAG Bullshark приводит к 50% задержке.
В данной статье рассказывается о том, как Shoal значительно уменьшает задержку Bullshark.
Предыстория 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-f6b6281c928e3fa7a2412a480c9c1806.webp)
Общий порядок
Можно достичь согласия по общей последовательности всех вершин в DAG без дополнительных затрат на связь. Проверяющие в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как протокол консенсуса, где вершины представляют предложения, а ребра представляют голоса.
Все существующие протоколы консенсуса на основе Narwhal имеют следующую структуру:
Резервная опора: каждые несколько раундов есть заранее определенный лидер, вершина лидера называется опорой.
Точки сортировки: валидаторы независимо, но детерминированно решают, какие точки привязки заказывать, а какие пропускать.
Упорядоченная причинно-следственная история: валидаторы обрабатывают упорядоченный список якорных точек один за другим, сортируя все предыдущие неупорядоченные вершины в причинно-следственной истории каждой якорной точки.
Ключ к обеспечению безопасности заключается в том, чтобы на шаге 2 все честные узлы-верификаторы создали упорядоченный список якорей, все списки делились одним и тем же префиксом. В Shoal мы наблюдали, что все верификаторы согласны с первым упорядоченным якорем.
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя некоторые версии синхронизации имеют лучшую задержку, чем асинхронные версии, но это далеко не оптимально.
Основные два вопроса:
Средняя задержка блока: в обычных случаях, вершина нечетного раунда требует три раунда, а вершина четного раунда, не являющаяся анкеровкой, требует четыре раунда для сортировки.
Ситуация с неисправностью задержка: если один раунд лидера не смог вовремя транслировать опорную точку, то передние несортированные вершины должны ждать сортировки следующей опорной точки, что значительно снижает производительность географической репликационной сети.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Фреймворк Shoal
Shoal улучшает Bullshark через конвейер, позволяя иметь одну опорную точку на каждом раунде, уменьшая задержку всех неподдерживаемых вершин до трех раундов. Shoal также вводит механизм репутации лидера с нулевыми затратами, предпочитая выбор быстрых лидеров.
Вызов
В протоколе DAG вопросы конвейеризации и репутации лидера считаются сложными.
Предыдущие попытки изменить основную логику Bullshark в конвейере, похоже, были невозможны.
Репутация лидера может привести к совершенно другим порядкам, и валидаторы должны согласовать упорядоченную историю для выбора будущих якорей.
В качестве доказательства сложности проблемы, текущие реализации Bullshark в производственной среде не поддерживают эти функции.
Протокол
Shoal полагается на выполнение локальных вычислений на DAG, что позволяет сохранять и переосмыслять информацию из предыдущих раундов. Используя понимание того, что все валидаторы согласны с первым упорядоченным якорем, Shoal последовательно комбинирует несколько экземпляров Bullshark для конвейерной обработки, что позволяет:
конвейер
Shoal запускает экземпляры Bullshark один за другим, каждый экземпляр заказывает анкер, что приводит к переключению на следующий экземпляр.
Сначала Shoal запускает первый экземпляр Bullshark в первом раунде DAG, работающем до тех пор, пока не будет определена первая упорядоченная якорная точка (, например, в раунде r ). Все валидаторы согласны с этой якорной точкой, поэтому можно с уверенностью согласиться на переинтерпретацию DAG с раунда r+1. Shoal запускает новый экземпляр Bullshark в раунде r+1.
В идеальных условиях это позволяет Shoal заказывать одну якорную точку за раунд.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
репутация лидера
Когда Bullshark перескакивает опорную точку, задержка увеличивается. Shoal назначает баллы каждому узлу-валидатору через механизм репутации, чтобы в будущем с меньшей вероятностью выбирать медленных лидеров.
При каждом обновлении баллов необходимо детерминированно пересчитывать отображение F от раунда к лидеру, отдавая предпочтение лидерам с высокими баллами. Чтобы валидаторы достигли согласия по новому отображению, они должны согласовать баллы.
Потоковая линия и репутация лидеров могут естественно сочетаться, поскольку они используют одну и ту же основную технологию, а именно переосмысляют DAG после достижения согласия по первой упорядоченной опорной точке.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Не требуется задержка
Тайм-аут играет ключевую роль в реализации BFT с определенностью на основе лидера, но вводит сложность и значительно увеличивает задержку.
Shoal наблюдает, что конструкция DAG предоставляет "часы" для оценки скорости сети. Пока n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продолжаться. В конечном итоге, когда безошибочный лидер достаточно быстро передает якорные точки, вся причинно-следственная история якорных точек будет отсортирована.
Избегание задержки тесно связано с репутацией лидера. Повторное ожидание медленных лидеров увеличивает задержку, в то время как механизмы репутации исключают медленных валидаторов из числа лидеров.
Общий ответ
Shoal предоставляет свойства универсального отклика, которые могут работать на сетевой скорости даже в случае сбоя лидера или асинхронности сети. Это лучше, чем концепция оптимистичного отклика Hotstuff.
Оценка
Реализованы Bullshark и Shoal, и проведено сравнение с Jolteon. Основные выводы:
Безвременной Baseline Bullshark показывает лучшие результаты при сбоях.
Потоковая линия Shoal и механизм репутации лидеров значительно улучшили задержку Bullshark.
Из 50 неудач в 16 случаях задержка Shoal была на 65% ниже, чем у Baseline Bullshark.
Jolteon не может расширяться более чем на 20 проверочных узлов, пропускная способность составляет примерно половину от Bullshark/Shoal.
В целом, Shoal значительно улучшил задержку Bullshark, и при высокой нагрузке должен соответствовать задержке Jolteon в режиме «от конца до конца».
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp)
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp)
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-cc09a26f7c3d94ee785de75e47bf42fb.webp)
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-6461c85fe1553879062fd7628f50f553.webp)