Шаблон Shoal: Значительное Падение задержки Bullshark на Aptos
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, структура DAG, поддерживающая высокий throughput Bullshark, приводит к 50% падению.
В данной статье описывается, как Shoal смог существенно Падение задержка Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG ассоциирована с определённым раундом. Чтобы войти в r-й раунд, валидатор должен сначала получить n-f вершин, принадлежащих (r-1)-му раунду. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент времени наблюдать разные локальные представления DAG.
Ключевое свойство DAG не является двусмысленным: если два узла-валидатора имеют в своих локальных представлениях DAG одинаковую вершину v, то у них полностью одинаковая причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Введение
Можно достичь согласия по общему порядку всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как протокол консенсуса, где вершины представляют предложения, а ребра представляют голоса.
Хотя логика группового пересечения в структуре DAG различна, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Предварительная точка: каждые несколько раундов (, например, в Bullshark каждые два раунда ) есть заранее определенный лидер, вершина которого называется точкой привязки;
Точки сортировки: валидаторы независимо, но с определённостью решают, какие точки заказывать, а какие пропускать;
Упорядочение причинно-следственной истории: валидаторы обрабатывают список упорядоченных анкерных точек по одному, для каждой анкерной точки с помощью некоторых детерминированных правил упорядочивают все предыдущие неупорядоченные вершины в ее причинно-следственной истории.
Ключом к обеспечению безопасности является гарантировать, что на этапе (2) все честные узлы верификации создают упорядоченный список якорей, чтобы все списки имели одинаковый префикс. В Shoal мы делаем следующие наблюдения относительно всех вышеупомянутых протоколов:
Все валидаторы согласны с первой упорядоченной опорной точкой.
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 для их обработки в конвейере, что делает ) первой упорядоченной якорной точкой и ( причинной историей якорной точки, используемой для расчета репутации лидера.
![Подробное объяснение рамки 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-м раунде рассчитать новое отображение F' начиная с r+1 раунда. Затем узлы валидации начинают использовать обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше времени ожидания
Тайм-аут играет жизненно важную роль во всех реализациях согласованного BFT, основанных на лидере. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что их правильная настройка очень важна и часто требует динамической корректировки, так как она сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки, Jolteon/
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
22 Лайков
Награда
22
5
Поделиться
комментарий
0/400
BlockchainFries
· 07-21 02:44
Подожди, 40% и еще 80%, ты уверен, что это не просто мечты?
Посмотреть ОригиналОтветить0
YouMustMakeBigMoneyEvery
· 07-20 12:23
Еще не приложили усилия. Слишком плохо. Прорыв 6 юаней, увеличьте позицию.
Посмотреть ОригиналОтветить0
HalfBuddhaMoney
· 07-20 09:59
задержка снизилась так сильно, aptos стоит ожидать!
Посмотреть ОригиналОтветить0
SleepyArbCat
· 07-20 09:58
Эта ночь почти закончилась, aptos наконец-то приложил усилия, мяу... если задержка будет еще меньше, смогу поесть.
Shoal фрейм Падение Aptos Bullshark задержка 40%-80%
Шаблон Shoal: Значительное Падение задержки Bullshark на Aptos
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, структура DAG, поддерживающая высокий throughput Bullshark, приводит к 50% падению.
В данной статье описывается, как Shoal смог существенно Падение задержка Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp)
Предыстория DAG-BFT
Каждая вершина в Narwhal DAG ассоциирована с определённым раундом. Чтобы войти в r-й раунд, валидатор должен сначала получить n-f вершин, принадлежащих (r-1)-му раунду. Каждый валидатор может транслировать одну вершину за раунд, и каждая вершина должна ссылаться как минимум на n-f вершин предыдущего раунда. Из-за асинхронности сети разные валидаторы могут в любой момент времени наблюдать разные локальные представления DAG.
Ключевое свойство DAG не является двусмысленным: если два узла-валидатора имеют в своих локальных представлениях DAG одинаковую вершину v, то у них полностью одинаковая причинно-следственная история v.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp)
Введение
Можно достичь согласия по общему порядку всех вершин в DAG без дополнительных затрат на связь. Для этого валидаторы в DAG-Rider, Tusk и Bullshark интерпретируют структуру DAG как протокол консенсуса, где вершины представляют предложения, а ребра представляют голоса.
Хотя логика группового пересечения в структуре DAG различна, все существующие протоколы согласия на основе Narwhal имеют следующую структуру:
Предварительная точка: каждые несколько раундов (, например, в Bullshark каждые два раунда ) есть заранее определенный лидер, вершина которого называется точкой привязки;
Точки сортировки: валидаторы независимо, но с определённостью решают, какие точки заказывать, а какие пропускать;
Упорядочение причинно-следственной истории: валидаторы обрабатывают список упорядоченных анкерных точек по одному, для каждой анкерной точки с помощью некоторых детерминированных правил упорядочивают все предыдущие неупорядоченные вершины в ее причинно-следственной истории.
Ключом к обеспечению безопасности является гарантировать, что на этапе (2) все честные узлы верификации создают упорядоченный список якорей, чтобы все списки имели одинаковый префикс. В Shoal мы делаем следующие наблюдения относительно всех вышеупомянутых протоколов:
Все валидаторы согласны с первой упорядоченной опорной точкой.
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 для их обработки в конвейере, что делает ) первой упорядоченной якорной точкой и ( причинной историей якорной точки, используемой для расчета репутации лидера.
![Подробное объяснение рамки 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-м раунде рассчитать новое отображение F' начиная с r+1 раунда. Затем узлы валидации начинают использовать обновленную функцию выбора опорных точек F' для выполнения нового экземпляра Bullshark, начиная с r+1 раунда.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Нет больше времени ожидания
Тайм-аут играет жизненно важную роль во всех реализациях согласованного BFT, основанных на лидере. Однако введенная ими сложность увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что усложняет процесс отладки и требует больше технологий наблюдаемости.
Тайм-аут также значительно увеличивает задержку, потому что их правильная настройка очень важна и часто требует динамической корректировки, так как она сильно зависит от окружения ) сети (. Прежде чем перейти к следующему лидеру, протокол выплачивает полное наказание за задержку тайм-аута для вышедшего из строя лидера. Поэтому настройки тайм-аута не должны быть слишком консервативными, но если время тайм-аута слишком короткое, протокол может пропустить хорошего лидера. Например, мы наблюдали, что в условиях высокой нагрузки, Jolteon/