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. Несмотря на отделение распространения данных от консенсуса, с увеличением пропускной способности лидер Hotstuff/Jolteon по-прежнему ограничен.
Таким образом, мы решили развернуть Bullshark на Narwhal DAG, который является протоколом консенсуса с нулевыми затратами на коммуникацию. К сожалению, по сравнению с Jolteon, поддерживаемая Bullshark структура DAG с высокой пропускной способностью несет 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 имеют следующую структуру:
Предварительная точка привязки: каждые несколько раундов (, например, в Bullshark каждые два раунда ) будет заранее определенный лидер, вершина лидера называется точкой привязки;
Упорядочение якорей: валидаторы независимо, но определенно решают, какие якоря заказывать, а какие пропускать;
Порядок причинно-следственной истории: валидаторы один за другим обрабатывают свои упорядоченные списки анкорных точек, и для каждой анкорной точки сортируют все предыдущие неупорядоченные узлы в её причинно-следственной истории по некоторым детерминированным правилам.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что на этапе (2) все честные узлы-валидаторы создают упорядоченный список якорей, чтобы все списки имели общий префикс. В Shoal мы делаем следующие наблюдения по всем вышеперечисленным протоколам:
Все валидаторы согласны на первую упорядоченную опору.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя у наиболее практичной части синхронной версии Bullshark задержка лучше, чем у асинхронной версии, это далеко от оптимального.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины нечетной итерации интерпретируются как голосование. В обычных случаях для упорядочивания опорных точек требуется две итерации DAG, однако вершины в причинной истории anchor требуют больше итераций, чтобы дождаться упорядочивания anchor. В обычных случаях вершины в нечетных итерациях требуют три итерации, а вершины не опорные в четных итерациях требуют четыре итерации.
Вопрос 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, включая текущую реализацию в производственной среде, не поддерживает эти функции.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Протокол
Несмотря на вышеупомянутые трудности, как гласит пословица, решение, как правило, скрыто в простоте.
В 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-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
При пропуске якорных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, так как новый экземпляр не может быть запущен до тех пор, пока не будет заказана предыдущая якорная точка. Shoal обеспечивает меньшую вероятность выбора соответствующего лидера для обработки потерянных якорных точек в будущем, присваивая каждой верификационной ноде балл на основе истории недавней активности каждого верификационного узла с использованием механизма репутации. Верификаторы, реагирующие и участвующие в протоколе, получат высокие баллы, в противном случае верификационные узлы будут получать низкие баллы, так как они могут быть неактивными, медленными или злонамеренными.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, ориентируясь на лидера с более высоким счетом. Чтобы валидаторы согласовали новое отображение, они должны достичь согласия по счету, тем самым достигнув согласия по истории, используемой для производного счета.
В Shoal, конвейер и репутация лидера могут естественно сочетаться, так как они оба используют одну и ту же основную технологию, а именно переосмысляют DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле, единственное различие заключается в том, что после сортировки опорных точек в r-м раунде, валидатору просто нужно на основе причинно-следственной истории упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с r+1 раунда. Затем узлы-валидаторы с r+1 раунда используют обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше таймаутов
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированной частью на основе лидера. Однако, вводимая ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, так как важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Перед переходом к следующему лидеру протокол выплачивает полное наказание за задержку по тайм-ауту для вышедшего из строя лидера. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
13 Лайков
Награда
13
6
Репост
Поделиться
комментарий
0/400
SlowLearnerWang
· 8ч назад
задержка снизилась на 40%... этот баг исправили слишком бык?
Посмотреть ОригиналОтветить0
NFTArchaeologis
· 8ч назад
Подобно тому, как надписи на гадательных костях оставляют след на цифровых цепях, рамки Shoal революционизируют грязь.
Посмотреть ОригиналОтветить0
PumpDetector
· 8ч назад
хм, быкошарк становится быстрее, но все еще читая между строк... что-то чувствуется не так, если честно
Посмотреть ОригиналОтветить0
SerumSquirrel
· 8ч назад
40% рост так просто?
Посмотреть ОригиналОтветить0
DegenWhisperer
· 8ч назад
Сколько денег нужно потратить на оптимизацию задержки?
Оптимизация фрейма 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. Несмотря на отделение распространения данных от консенсуса, с увеличением пропускной способности лидер Hotstuff/Jolteon по-прежнему ограничен.
Таким образом, мы решили развернуть Bullshark на Narwhal DAG, который является протоколом консенсуса с нулевыми затратами на коммуникацию. К сожалению, по сравнению с Jolteon, поддерживаемая Bullshark структура DAG с высокой пропускной способностью несет 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 имеют следующую структуру:
Предварительная точка привязки: каждые несколько раундов (, например, в Bullshark каждые два раунда ) будет заранее определенный лидер, вершина лидера называется точкой привязки;
Упорядочение якорей: валидаторы независимо, но определенно решают, какие якоря заказывать, а какие пропускать;
Порядок причинно-следственной истории: валидаторы один за другим обрабатывают свои упорядоченные списки анкорных точек, и для каждой анкорной точки сортируют все предыдущие неупорядоченные узлы в её причинно-следственной истории по некоторым детерминированным правилам.
Ключ к обеспечению безопасности заключается в том, чтобы гарантировать, что на этапе (2) все честные узлы-валидаторы создают упорядоченный список якорей, чтобы все списки имели общий префикс. В Shoal мы делаем следующие наблюдения по всем вышеперечисленным протоколам:
Все валидаторы согласны на первую упорядоченную опору.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя у наиболее практичной части синхронной версии Bullshark задержка лучше, чем у асинхронной версии, это далеко от оптимального.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины нечетной итерации интерпретируются как голосование. В обычных случаях для упорядочивания опорных точек требуется две итерации DAG, однако вершины в причинной истории anchor требуют больше итераций, чтобы дождаться упорядочивания anchor. В обычных случаях вершины в нечетных итерациях требуют три итерации, а вершины не опорные в четных итерациях требуют четыре итерации.
Вопрос 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, включая текущую реализацию в производственной среде, не поддерживает эти функции.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
Протокол
Несмотря на вышеупомянутые трудности, как гласит пословица, решение, как правило, скрыто в простоте.
В 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-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
При пропуске якорных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, так как новый экземпляр не может быть запущен до тех пор, пока не будет заказана предыдущая якорная точка. Shoal обеспечивает меньшую вероятность выбора соответствующего лидера для обработки потерянных якорных точек в будущем, присваивая каждой верификационной ноде балл на основе истории недавней активности каждого верификационного узла с использованием механизма репутации. Верификаторы, реагирующие и участвующие в протоколе, получат высокие баллы, в противном случае верификационные узлы будут получать низкие баллы, так как они могут быть неактивными, медленными или злонамеренными.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, ориентируясь на лидера с более высоким счетом. Чтобы валидаторы согласовали новое отображение, они должны достичь согласия по счету, тем самым достигнув согласия по истории, используемой для производного счета.
В Shoal, конвейер и репутация лидера могут естественно сочетаться, так как они оба используют одну и ту же основную технологию, а именно переосмысляют DAG после достижения согласия по первому упорядоченному якорному пункту.
На самом деле, единственное различие заключается в том, что после сортировки опорных точек в r-м раунде, валидатору просто нужно на основе причинно-следственной истории упорядоченных опорных точек в r-м раунде начать вычисление нового отображения F' с r+1 раунда. Затем узлы-валидаторы с r+1 раунда используют обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше таймаутов
Тайм-аут играет ключевую роль во всех реализациях BFT с детерминированной частью на основе лидера. Однако, вводимая ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, так как важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Перед переходом к следующему лидеру протокол выплачивает полное наказание за задержку по тайм-ауту для вышедшего из строя лидера. Поэтому настройки тайм-аута не могут быть слишком консервативными, но если