Shoal фреймворк: значительно уменьшает задержку Bullshark на Aptos
Обзор
Aptos labs решило две важные открытые проблемы в DAG BFT, значительно уменьшив задержку и впервые устранив необходимость в тайм-ауте в детерминированном реальном протоколе. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев — на 80%.
Shoal - это фреймворк, который улучшает любое основанное на Narwhal согласовательное протокол с помощью конвейера и репутации лидеров. Конвейер уменьшает задержка сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидеров дополнительно улучшает проблему задержки, гарантируя, что опорная точка связана с самыми быстрыми узлами проверки. Кроме того, репутация лидеров позволяет Shoal использовать асинхронные конструкции DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять свойства универсального отклика, включая обычно необходимые оптимистичные ответы.
Эта технология очень проста и включает несколько экземпляров базового протокола, работающих последовательно. Поэтому, когда она инстанцируется с помощью Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
Мотивация
В стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff достиг всего 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, структура 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 мы делаем следующие наблюдения относительно всех вышеупомянутых протоколов:
Все валидаторы согласны с первой упорядоченной опорной точкой.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя у синхронной версии Bullshark, как правило, лучше задержка, чем у асинхронной, она все же далека от оптимальной.
Вопрос 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 для их конвейерной обработки, что делает ) первой упорядоченной якорной точкой, а также ( причинно-следственную историю якорных точек, используемую для вычисления репутации лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
При пропуске якорных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, так как новый экземпляр не может быть запущен до заказа якорной точки предыдущим экземпляром. Shoal обеспечивает меньшую вероятность выбора соответствующего лидера для обработки потерянных якорных точек в будущем, присваивая каждому узлу проверки балл на основе истории недавней активности каждого узла проверки с помощью механизма репутации. Участники, которые реагируют и участвуют в протоколе, получат высокий балл, в противном случае узлы проверки будут получать низкий балл, так как они могут быть нестабильными, медленными или злонамеренными.
Его концепция заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, ориентируясь на лидера с более высоким счетом. Чтобы валидаторы согласовали новое отображение, они должны согласовать счет, достигнув согласия по истории, используемой для вывода счета.
В Shoal, конвейер и репутация лидеров могут естественно сочетаться, поскольку они оба используют одну и ту же основную технологию, а именно повторную интерпретацию DAG после достижения согласия по первому упорядоченному якорной точке.
На самом деле, единственное отличие заключается в том, что после сортировки якорей в r-ом раунде, валидатору нужно просто на основе причинной истории упорядоченных якорей в r-ом раунде, начиная с r+1 раунда, рассчитать новое отображение F'. Затем узлы-валидаторы, начиная с r+1 раунда, используют обновленную функцию выбора якорей F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше задержек
Тайм-аут играет жизненно важную роль во всех реализациях BFT с определенной согласованностью на основе лидера. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что увеличивает сложность процесса отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера перед переходом к следующему лидеру. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истекает до того, как они могут продвинуться вперед.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
8 Лайков
Награда
8
5
Поделиться
комментарий
0/400
SchrodingersFOMO
· 08-05 13:55
задержка снизилась так сильно бык бык
Посмотреть ОригиналОтветить0
SchroedingerMiner
· 08-05 12:20
Эта скорость растет быстрее, чем температура моего рига для майнинга.
Посмотреть ОригиналОтветить0
MEVSandwich
· 08-03 18:14
задержка降这么多 感觉要На луну
Посмотреть ОригиналОтветить0
MetaMisfit
· 08-03 17:54
Сижу жду, когда Aptos взлетит... Жду с нетерпением
Ширма Shoal значительно улучшила производительность Bullshark на Aptos, задержка снизилась на 40%-80%
Shoal фреймворк: значительно уменьшает задержку Bullshark на Aptos
Обзор
Aptos labs решило две важные открытые проблемы в DAG BFT, значительно уменьшив задержку и впервые устранив необходимость в тайм-ауте в детерминированном реальном протоколе. В целом, в случае отсутствия сбоев задержка Bullshark была улучшена на 40%, а в случае сбоев — на 80%.
Shoal - это фреймворк, который улучшает любое основанное на Narwhal согласовательное протокол с помощью конвейера и репутации лидеров. Конвейер уменьшает задержка сортировки DAG, вводя опорную точку в каждом раунде, а репутация лидеров дополнительно улучшает проблему задержки, гарантируя, что опорная точка связана с самыми быстрыми узлами проверки. Кроме того, репутация лидеров позволяет Shoal использовать асинхронные конструкции DAG для устранения тайм-аутов во всех сценариях. Это позволяет Shoal предоставлять свойства универсального отклика, включая обычно необходимые оптимистичные ответы.
Эта технология очень проста и включает несколько экземпляров базового протокола, работающих последовательно. Поэтому, когда она инстанцируется с помощью Bullshark, мы получаем группу "акул", которые участвуют в эстафете.
Мотивация
В стремлении к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности связи. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff достиг всего 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, структура 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 мы делаем следующие наблюдения относительно всех вышеупомянутых протоколов:
Все валидаторы согласны с первой упорядоченной опорной точкой.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя у синхронной версии Bullshark, как правило, лучше задержка, чем у асинхронной, она все же далека от оптимальной.
Вопрос 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 для их конвейерной обработки, что делает ) первой упорядоченной якорной точкой, а также ( причинно-следственную историю якорных точек, используемую для вычисления репутации лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.webp(
Репутация лидера
При пропуске якорных точек во время сортировки Bullshark задержка увеличивается. В этом случае технологии конвейера бессильны, так как новый экземпляр не может быть запущен до заказа якорной точки предыдущим экземпляром. Shoal обеспечивает меньшую вероятность выбора соответствующего лидера для обработки потерянных якорных точек в будущем, присваивая каждому узлу проверки балл на основе истории недавней активности каждого узла проверки с помощью механизма репутации. Участники, которые реагируют и участвуют в протоколе, получат высокий балл, в противном случае узлы проверки будут получать низкий балл, так как они могут быть нестабильными, медленными или злонамеренными.
Его концепция заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать предопределенное отображение F от раунда к лидеру, ориентируясь на лидера с более высоким счетом. Чтобы валидаторы согласовали новое отображение, они должны согласовать счет, достигнув согласия по истории, используемой для вывода счета.
В Shoal, конвейер и репутация лидеров могут естественно сочетаться, поскольку они оба используют одну и ту же основную технологию, а именно повторную интерпретацию DAG после достижения согласия по первому упорядоченному якорной точке.
На самом деле, единственное отличие заключается в том, что после сортировки якорей в r-ом раунде, валидатору нужно просто на основе причинной истории упорядоченных якорей в r-ом раунде, начиная с r+1 раунда, рассчитать новое отображение F'. Затем узлы-валидаторы, начиная с r+1 раунда, используют обновленную функцию выбора якорей F' для выполнения нового экземпляра Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше задержек
Тайм-аут играет жизненно важную роль во всех реализациях BFT с определенной согласованностью на основе лидера. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что увеличивает сложность процесса отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, поскольку важно правильно их настраивать, и часто требуется динамическая корректировка, так как это сильно зависит от окружения ) сети (. Протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера перед переходом к следующему лидеру. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что при высокой нагрузке лидеры в Jolteon/Hotstuff перегружены, и тайм-аут истекает до того, как они могут продвинуться вперед.
несчастный