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)
Фон
В процессе стремления к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности коммуникаций. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff достиг лишь 3500 TPS, что значительно ниже целевого значения в 100000+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на протоколе лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики согласования, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, а компонент согласования лишь сортирует небольшое количество метаданных. В статье Narwhal сообщается о производительности 160000 TPS.
Ранее мы представили Quorum Store, то есть нашу реализацию Narwhal, которая отделяет распространение данных от консенсуса, а также то, как использовать его для масштабирования текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, очевидно, что протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, с увеличением пропускной способности лидеры Hotstuff/Jolteon по-прежнему остаются ограниченными.
Поэтому мы решили развернуть Bullshark, протокол консенсуса с нулевыми затратами на связь, на Narwhal DAG. К сожалению, по сравнению с Jolteon, структура DAG, поддерживающая высокую пропускную способность 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 не является нечетким: если два узла-валидатора имеют одинаковую вершину v в своем локальном представлении DAG, то они имеют абсолютно одинаковую причинно-следственную историю 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 мы делаем следующие наблюдения по всем этим протоколам:
Все валидаторы согласны с первой упорядоченной опорной точкой.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными опорными точками в DAG. Хотя синхронная версия Bullshark более практична и имеет лучшую задержку по сравнению с асинхронной версией, она все же далека от оптимальной.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голоса. В обычных случаях для сортировки опорных точек требуется две итерации DAG, однако вершины в каузальной истории опорных точек требуют больше итераций ожидания сортировки опорных точек. В обычных случаях вершины в нечетных итерациях требуют три итерации, а вершины, не являющиеся опорными, в четных итерациях требуют четыре итерации.
Вопрос 2: Ситуация с отказами и задержка. Указанный анализ задержки применим к безотказной ситуации, с другой стороны, если лидер в определенном раунде не успевает достаточно быстро транслировать якорь, то сортировать этот якорь невозможно (, поэтому он пропускается ), следовательно, все несортированные вершины в предыдущих раундах должны ждать, пока следующий якорь не будет отсортирован. Это значительно снижает производительность географически распределенной сети, особенно потому, что Bullshark использует тайм-ауты для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.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-9f789cb669f6fcc244ea7ff7648e48b4.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-1baf540693f376d93cb18ef3193593cc.webp)
Нет больше таймаутов
Тайм-аут играет жизненно важную роль во всех реализованных на основе лидеров детерминистских частичных синхронизаций BFT. Однако сложность, которую они вводят, увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что повышает сложность процесса отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также значительно увеличит задержку, так как их правильная настройка очень важна и часто требует динамической корректировки, так как это сильно зависит от окружения ( сети ). Прежде чем перейти к следующему лидеру, протокол выплачивает полную задержку за тайм-аут для вышедшего из строя лидера.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
13 Лайков
Награда
13
6
Поделиться
комментарий
0/400
CryptoSurvivor
· 08-06 08:15
бык ва, это обновление ускорило aptos.
Посмотреть ОригиналОтветить0
SelfSovereignSteve
· 08-06 08:14
Это обновление быка, повышение на 40% слишком жестко
Посмотреть ОригиналОтветить0
GasFeeCrier
· 08-06 08:13
Отпариваем Санду, теперь проблема с задержкой стабильна
Посмотреть ОригиналОтветить0
MissedTheBoat
· 08-06 08:04
Торговля криптовалютой неудачники наконец-то получили прибыль
Посмотреть ОригиналОтветить0
Tians
· 08-06 07:50
Фирма HODL💎
Посмотреть ОригиналОтветить0
SneakyFlashloan
· 08-06 07:48
удивительный задержка напрямую сократила более чем на половину
Shoal фреймворк значительно Падение задержка Bullshark Aptos Блокчейн
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)
Фон
В процессе стремления к высокой производительности блокчейн-сетей люди всегда обращали внимание на снижение сложности коммуникаций. Однако этот подход не привел к значительному увеличению пропускной способности. Например, реализованный в ранних версиях Diem Hotstuff достиг лишь 3500 TPS, что значительно ниже целевого значения в 100000+ TPS.
Недавний прорыв обусловлен осознанием того, что распространение данных является основным узким местом, основанным на протоколе лидеров, и может извлечь выгоду из параллелизации. Система Narwhal отделяет распространение данных от основной логики согласования, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, а компонент согласования лишь сортирует небольшое количество метаданных. В статье Narwhal сообщается о производительности 160000 TPS.
Ранее мы представили Quorum Store, то есть нашу реализацию Narwhal, которая отделяет распространение данных от консенсуса, а также то, как использовать его для масштабирования текущего протокола консенсуса Jolteon. Jolteon — это протокол на основе лидера, который сочетает в себе линейный быстрый путь Tendermint и изменения представления в стиле PBFT, что позволяет снизить задержку Hotstuff на 33%. Тем не менее, очевидно, что протоколы консенсуса на основе лидера не могут в полной мере использовать потенциал пропускной способности Narwhal. Несмотря на разделение распространения данных и консенсуса, с увеличением пропускной способности лидеры Hotstuff/Jolteon по-прежнему остаются ограниченными.
Поэтому мы решили развернуть Bullshark, протокол консенсуса с нулевыми затратами на связь, на Narwhal DAG. К сожалению, по сравнению с Jolteon, структура DAG, поддерживающая высокую пропускную способность 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 не является нечетким: если два узла-валидатора имеют одинаковую вершину v в своем локальном представлении DAG, то они имеют абсолютно одинаковую причинно-следственную историю 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 мы делаем следующие наблюдения по всем этим протоколам:
Все валидаторы согласны с первой упорядоченной опорной точкой.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Bullshark задержка
Задержка Bullshark зависит от количества раундов между упорядоченными опорными точками в DAG. Хотя синхронная версия Bullshark более практична и имеет лучшую задержку по сравнению с асинхронной версией, она все же далека от оптимальной.
Вопрос 1: Средняя задержка блока. В Bullshark каждая четная итерация имеет опорную точку, а вершины каждой нечетной итерации интерпретируются как голоса. В обычных случаях для сортировки опорных точек требуется две итерации DAG, однако вершины в каузальной истории опорных точек требуют больше итераций ожидания сортировки опорных точек. В обычных случаях вершины в нечетных итерациях требуют три итерации, а вершины, не являющиеся опорными, в четных итерациях требуют четыре итерации.
Вопрос 2: Ситуация с отказами и задержка. Указанный анализ задержки применим к безотказной ситуации, с другой стороны, если лидер в определенном раунде не успевает достаточно быстро транслировать якорь, то сортировать этот якорь невозможно (, поэтому он пропускается ), следовательно, все несортированные вершины в предыдущих раундах должны ждать, пока следующий якорь не будет отсортирован. Это значительно снижает производительность географически распределенной сети, особенно потому, что Bullshark использует тайм-ауты для ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.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-859e732e16c3eee0e2c93422474debc2.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-9f789cb669f6fcc244ea7ff7648e48b4.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-1baf540693f376d93cb18ef3193593cc.webp)
Нет больше таймаутов
Тайм-аут играет жизненно важную роль во всех реализованных на основе лидеров детерминистских частичных синхронизаций BFT. Однако сложность, которую они вводят, увеличивает количество внутренних состояний, которые необходимо управлять и наблюдать, что повышает сложность процесса отладки и требует большего количества технологий наблюдаемости.
Тайм-аут также значительно увеличит задержку, так как их правильная настройка очень важна и часто требует динамической корректировки, так как это сильно зависит от окружения ( сети ). Прежде чем перейти к следующему лидеру, протокол выплачивает полную задержку за тайм-аут для вышедшего из строя лидера.