Aptos Labs недавно решила две важные открытые проблемы в DAG BFT, значительно снизив задержку, и впервые устранила необходимость в тайм-ауте в детерминированном практическом протоколе. В целом, в случае отсутствия сбоев задержка 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)
Фон
В стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на Падение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff обеспечивал всего 3500 TPS, что значительно ниже нашей цели в 100k+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на соглашениях лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики согласования и предлагает архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты согласования сортируют лишь небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности 160 000 TPS.
Наш Narwhal реализует Quorum Store, который разделяет распространение данных и консенсус, чтобы расширить текущий консенсусный протокол Jolteon. Jolteon — это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и изменение представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Однако консенсусные протоколы на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, с увеличением пропускной способности лидер Hotstuff/Jolteon все равно остается ограниченным.
Таким образом, мы решили развернуть Bullshark на Narwhal DAG, протокол консенсуса с нулевыми затратами на связь. К сожалению, в отличие от Jolteon, структура 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 как протокол консенсуса, в котором вершины представляют предложения, а ребра представляют голоса.
Хотя логика пересечения групп на структуре 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-м раунде валидатору нужно просто начать вычисление нового отображения F' с r+1 раунда, основываясь на причинно-следственной истории упорядоченных опорных точек в r-м раунде. Затем узлы проверки начинают с r+1 раунда использовать обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Нет больше таймаутов
Тайм-аут играет ключевую роль во всех реализациях BFT с частичной синхронизацией, основанных на лидере. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также существенно увеличивает задержку, потому что крайне важно правильно их настроить, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку из-за тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff не справляются с нагрузкой, и тайм-аут истекает до того, как они продвинутся.
К сожалению, протоколы лидеров ), такие как Hotstuff и Jolteon (, по сути требуют задержки, чтобы гарантировать, что каждый раз, когда лидер выходит из строя, происходит корректное восстановление.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
14 Лайков
Награда
14
10
Поделиться
комментарий
0/400
FUD_Whisperer
· 3ч назад
А это увеличение на 80 просто абсурдно.
Посмотреть ОригиналОтветить0
ChainComedian
· 18ч назад
задержка упала так сильно, кажется, можно сделать что-то большое
Посмотреть ОригиналОтветить0
YouMustMakeBigMoneyEvery
· 07-19 04:14
За пределами SOL
Посмотреть ОригиналОтветить0
YouMustMakeBigMoneyEvery
· 07-19 04:14
Фирма HODL💎
Посмотреть ОригиналОтветить0
VirtualRichDream
· 07-19 03:33
задержка Падение这么多 aptos走起来了
Посмотреть ОригиналОтветить0
FOMOSapien
· 07-19 03:33
Уменьшение задержки лучше, чем напрямую A на президента.
Посмотреть ОригиналОтветить0
BearEatsAll
· 07-19 03:30
aptos может быть еще быстрее? бык啊
Посмотреть ОригиналОтветить0
PaperHandsCriminal
· 07-19 03:26
Кому как не дьяволу знать, что за польза в этой задержке падения, всё равно не смогло остановить меня от того, чтобы меня разыгрывали людей как лохов.
Посмотреть ОригиналОтветить0
ApeShotFirst
· 07-19 03:23
Опять рост, не умрёт, задержка - делистинг.
Посмотреть ОригиналОтветить0
BlockchainFries
· 07-19 03:15
Смотря на то, как сильно снизилась задержка, давайте сначала купим небольшую Позицию.
Shoal框架大幅 Падение Aptos上Bullshark Соглашение задержка
Shoal框架:Падение Aptos上 Bullshark задержка的新方案
Aptos Labs недавно решила две важные открытые проблемы в DAG BFT, значительно снизив задержку, и впервые устранила необходимость в тайм-ауте в детерминированном практическом протоколе. В целом, в случае отсутствия сбоев задержка 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)
Фон
В стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на Падение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff обеспечивал всего 3500 TPS, что значительно ниже нашей цели в 100k+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на соглашениях лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики согласования и предлагает архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты согласования сортируют лишь небольшое количество метаданных. В статье Narwhal сообщается о пропускной способности 160 000 TPS.
Наш Narwhal реализует Quorum Store, который разделяет распространение данных и консенсус, чтобы расширить текущий консенсусный протокол Jolteon. Jolteon — это протокол на основе лидера, который сочетает линейный быстрый путь Tendermint и изменение представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Однако консенсусные протоколы на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, с увеличением пропускной способности лидер Hotstuff/Jolteon все равно остается ограниченным.
Таким образом, мы решили развернуть Bullshark на Narwhal DAG, протокол консенсуса с нулевыми затратами на связь. К сожалению, в отличие от Jolteon, структура 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 как протокол консенсуса, в котором вершины представляют предложения, а ребра представляют голоса.
Хотя логика пересечения групп на структуре 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-м раунде валидатору нужно просто начать вычисление нового отображения F' с r+1 раунда, основываясь на причинно-следственной истории упорядоченных опорных точек в r-м раунде. Затем узлы проверки начинают с r+1 раунда использовать обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
Нет больше таймаутов
Тайм-аут играет ключевую роль во всех реализациях BFT с частичной синхронизацией, основанных на лидере. Однако их сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также существенно увеличивает задержку, потому что крайне важно правильно их настроить, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку из-за тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки лидеры в Jolteon/Hotstuff не справляются с нагрузкой, и тайм-аут истекает до того, как они продвинутся.
К сожалению, протоколы лидеров ), такие как Hotstuff и Jolteon (, по сути требуют задержки, чтобы гарантировать, что каждый раз, когда лидер выходит из строя, происходит корректное восстановление.