Shoal框架:инновационное решение для повышения производительности Aptos Блокчейн
Компания Aptos Labs недавно представила фреймворк Shoal, который нацелен на решение двух основных проблем в консенсусе DAG BFT, значительно снижая задержку и впервые устраняя зависимость от тайм-аутов в детерминированном асинхронном протоколе. В общем, Shoal увеличивает задержку 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 отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты консенсуса сортируют лишь небольшое количество метаданных, достигая пропускной способности в 160 000 TPS.
Aptos ранее представил Quorum Store, то есть реализацию Narwhal, которая отделяет распространение данных от консенсуса и используется для масштабирования текущего протокола консенсуса Jolteon. Jolteon сочетает в себе линейный быстрый путь Tendermint и изменения представлений в стиле PBFT, снижая задержку Hotstuff на 33%. Однако консенсусный протокол, основанный на лидере, не может в полной мере использовать потенциал пропускной способности Narwhal.
Таким образом, Aptos решил развернуть Bullshark, протокол консенсуса с нулевыми коммуникационными затратами, на Narwhal DAG. Однако поддержка Bullshark структуры DAG с высокой пропускной способностью привела к 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 как протокол консенсуса, где вершины представляют предложения, а ребра представляют голосование.
Хотя конкретная логика различна, все основанные на Narwhal согласительные протоколы имеют следующую структуру:
Предварительная якорная точка: каждые несколько раундов есть заранее определённый лидер, вершина которого называется якорной точкой.
Точки сортировки: валидаторы независимо, но определенно решают, какие точки сортировки использовать или пропускать.
Упорядоченная причинно-следственная история: валидаторы поочередно обрабатывают упорядоченный список якорей, сортируя неупорядоченные вершины в причинно-следственной истории каждого якоря.
Ключом к обеспечению безопасности является гарантирование того, что все честные узлы-валидаторы создают упорядоченный список опорных точек, который имеет одинаковый префикс. Shoal делает важное наблюдение по всем этим протоколам: все валидаторы согласны с первой упорядоченной опорной точкой.
Проблема задержки Bullshark
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя некоторые синхронные версии имеют меньшую задержку, чем асинхронные, они все еще далеки от оптимальных.
Основные проблемы заключаются в двух вопросах:
Среднее время задержки блока: в обычных случаях, вершины нечетного раунда требуют три раунда для сортировки, вершины четного раунда, не являющиеся анкерами, требуют четыре раунда.
Ситуация с задержкой неисправности: если лидер раунда не смог своевременно передать якорную точку, эта якорная точка будет пропущена, и все неотсортированные вершины предыдущих раундов должны ждать сортировки следующей якорной точки. Это значительно снижает производительность геораспределённой сети, особенно потому, что Bullshark использует время ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Шоал фрейм
Shoal усиливает Bullshark( или любой BFT-протокол на основе Narwhal) через конвейер, позволяя иметь одну опорную точку на каждый раунд и уменьшая задержку всех неопорных вершин до трех раундов. Shoal также вводит механизм репутации лидеров с нулевыми затратами в DAG, предпочитая выбирать быстрых лидеров.
Вызов
В реализации конвейера и репутации лидера в протоколе DAG считается сложной задачей:
Предыдущие попытки изменить核心逻辑 Bullshark, похоже, не удались.
Репутация лидеров может привести к различным сортировкам, в то время как валидаторы должны прийти к согласию по упорядоченной истории, чтобы выбрать будущие опорные точки.
В качестве подтверждения сложности проблемы, в настоящее время реализации Bullshark в производственной среде не поддерживают эти функции.
Протокол
Решение Shoal относительно простое. Оно использует возможность выполнения локальных вычислений на DAG, реализуя функцию сохранения и переосмысления информации предыдущих раундов. Основываясь на том, что все валидаторы согласны с первым упорядоченным якорем, Shoal последовательно комбинирует несколько экземпляров Bullshark для конвейерной обработки, что позволяет:
Первая упорядоченная точка привязки - это точка переключения экземпляра
Историческая причинно-следственная связь якорей используется для вычисления репутации лидеров
Конвейер
V, которое сопоставляет раунды с лидерами. Shoal последовательно запускает экземпляры Bullshark, каждый экземпляр упорядочивает якорную точку и инициирует переключение на следующий экземпляр.
Shoal запустил первый экземпляр Bullshark на первом раунде DAG, пока не был установлен первый упорядоченный якорь (, предполагая, что в раунде r ). Все валидаторы согласны с этим якорем, поэтому можно с уверенностью согласиться на повторную интерпретацию DAG с раунда r+1. Shoal запускает новый экземпляр Bullshark в раунде r+1.
В идеальных условиях это позволяет Shoal сортировать одну опорную точку за раунд. Первая раундная опорная точка сортируется первым экземпляром, затем на втором раунде новый экземпляр сортирует эту раундную опорную точку и так далее.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутация лидера
Когда Bullshark пропускает якорную точку, задержка увеличивается. Технология конвейера в этом случае бессильна, поскольку необходимо дождаться сортировки якорной точки предыдущим экземпляром, прежде чем можно будет запустить новый экземпляр. Shoal назначает баллы каждому узлу проверки через механизм репутации, основываясь на его недавней истории активности. Быстро реагирующие валидаторы получают высокие баллы, в противном случае получают низкие.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать отображение F от раунда к лидеру, отталкиваясь от лидеров с высокими баллами. Чтобы валидаторы пришли к согласию по новому отображению, им необходимо достичь согласия по счету, а затем достичь согласия по истории, используемой для вывода счета.
В Shoal репутация пайплайна и лидера может естественно сочетаться, поскольку они оба основаны на переосмыслении DAG после достижения согласия на первом упорядоченном якоре. Единственное различие заключается в том, что после r-го раунда упорядоченного якоря валидаторы начинают вычислять новое отображение F' с r+1 раунда на основе причинной истории этого якоря. Затем с r+1 раунда используются обновленное F' для выполнения новых экземпляров Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Устранение тайм-аута
Тайм-ауты имеют критическое значение во всех реализациях BFT с детерминированной частичной синхронизацией на основе лидера. Однако они увеличивают сложность, требуют более тщательного управления внутренним состоянием и наблюдения, что делает отладку более сложной.
Таймаут также значительно увеличит задержку, поскольку правильная конфигурация имеет важное значение и обычно требует динамической настройки. Прежде чем перейти к следующему лидеру, протокол должен выплатить полное наказание за задержку таймаута для вышедшего из строя лидера. Поэтому настройки таймаута не должны быть слишком консервативными, но если они слишком короткие, это может привести к пропуску хорошего лидера.
К сожалению, основанные на протоколе лидера (, такие как Hotstuff и Jolteon ), по сути требуют тайм-ауты, чтобы обеспечить прогресс в случае сбоя лидера. Если тайм-аутов нет, даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронный период невозможно различить сбой и медленного лидера, тайм-ауты могут привести к замене всех лидеров валидационными узлами без активного консенсуса.
В Bullshark тайм-аут используется для построения DAG, чтобы обеспечить достаточно быструю добавку якорных точек в DAG честным лидером во время синхронизации.
Мы наблюдаем, что построение DAG предоставляет "часы", оценивающие скорость сети. Пока n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продвигаться вперед. Хотя Bullshark может не сортировать по скорости сети, DAG всё равно растёт с сетевой скоростью. В конце концов, когда безошибочный лидер достаточно быстро транслирует якорную точку, вся причинно-следственная история якорной точки будет отсортирована.
В оценке мы сравнили Bullshark с тайм-аутом и без него:
Быстрый лидер: два метода задержки одинаковы, потому что опорные точки сортируются и не используют тайм-аут.
Ошибочный лидер: без тайм-аута Bullshark задержка ниже, поскольку узлы верификации немедленно пропускают свою опору.
Медленные лидеры: имеют лучшие показатели, чем Bullshark с таймаутом, потому что валидаторы будут ждать опорной точки, в то время как без таймаута можно пропустить опорную точку.
В Shoal избегание тайм-аута тесно связано с репутацией лидера. Повторное ожидание медленных лидеров увеличивает задержку, в то время как репутационный механизм исключает медленных валидаторов из числа лидеров. Таким образом, система может работать с сетевой скоростью во всех реальных сценариях.
Важно отметить, что результаты невозможности FLP свидетельствуют о том, что нет детерминированного соглашения, которое могло бы полностью избежать тайм-аута. Shoal не может обойти этот результат, поскольку теоретически существуют антагонистические события, которые могут помешать сортировке всех якорных точек. Напротив, после настраиваемого количества последовательных пропусков якорных точек Shoal вернется к тайм-ауту. Однако на практике такая ситуация крайне маловероятна.
Универсальная отзывчивость
Статья Hotstuff популяризировала концепцию оптимистичного ответа, что интуитивно означает, что протокол может, в благоприятных условиях (, включать быстрого лидера и синхронизированную сеть ) для работы на скорости сети.
Shoal предлагает лучшую функцию, называемую универсальной отзывчивостью. Конкретно, в отличие от Hotstuff, даже если лидер терпит неудачу в пределах настраиваемого количества последовательных раундов или сеть испытывает асинхронные циклы, Shoal будет продолжать работать с сетевой скоростью.
Универсальная отзывчивость предоставляет строгие и лучшие гарантии прогресса в асинхронный период и при сбоях лидера. Во время синхронизации с медленным лидером эти характеристики нельзя напрямую сравнивать, так как они зависят от скорости лидера. Но учитывая механизм репутации лидера, медленные лидеры в Shoal должны встречаться очень редко.
! [10 000 слов подробное объяснение структуры шоула: как вычитать.]
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
21 Лайков
Награда
21
10
Репост
Поделиться
комментарий
0/400
SelfStaking
· 08-14 15:54
Это сможет спасти Aptos?
Посмотреть ОригиналОтветить0
ForkItAll
· 08-14 11:50
Боже, задержка увеличилась на 40%!
Посмотреть ОригиналОтветить0
GasGrillMaster
· 08-13 08:06
Хороший парень задержка наполовину бык ва
Посмотреть ОригиналОтветить0
MysteriousZhang
· 08-12 04:51
Сорок процентов и смеешь хвастаться? kkk
Посмотреть ОригиналОтветить0
SerumSquirter
· 08-12 04:50
Наконец-то могу продолжить вкладывать деньги сюда
Посмотреть ОригиналОтветить0
ContractCollector
· 08-12 04:48
Эта волна оптимизации задержки действительно крута!
Посмотреть ОригиналОтветить0
LiquidityWitch
· 08-12 04:44
Это слишком жестоко, задержка увеличилась на 40.
Посмотреть ОригиналОтветить0
GateUser-26d7f434
· 08-12 04:41
Ускорение на 40% может работать с Основной сетью?
Посмотреть ОригиналОтветить0
YieldHunter
· 08-12 04:41
с технической точки зрения... 40% неплохо, но покажи мне статистику доходности
Shoal Framework: снижение задержки на 40% и устранение зависимости от тайм-аута в цепочке Aptos
Shoal框架:инновационное решение для повышения производительности Aptos Блокчейн
Компания Aptos Labs недавно представила фреймворк Shoal, который нацелен на решение двух основных проблем в консенсусе DAG BFT, значительно снижая задержку и впервые устраняя зависимость от тайм-аутов в детерминированном асинхронном протоколе. В общем, Shoal увеличивает задержку 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 отделяет распространение данных от основной логики консенсуса, предлагая архитектуру, в которой все валидаторы одновременно распространяют данные, а компоненты консенсуса сортируют лишь небольшое количество метаданных, достигая пропускной способности в 160 000 TPS.
Aptos ранее представил Quorum Store, то есть реализацию Narwhal, которая отделяет распространение данных от консенсуса и используется для масштабирования текущего протокола консенсуса Jolteon. Jolteon сочетает в себе линейный быстрый путь Tendermint и изменения представлений в стиле PBFT, снижая задержку Hotstuff на 33%. Однако консенсусный протокол, основанный на лидере, не может в полной мере использовать потенциал пропускной способности Narwhal.
Таким образом, Aptos решил развернуть Bullshark, протокол консенсуса с нулевыми коммуникационными затратами, на Narwhal DAG. Однако поддержка Bullshark структуры DAG с высокой пропускной способностью привела к 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 как протокол консенсуса, где вершины представляют предложения, а ребра представляют голосование.
Хотя конкретная логика различна, все основанные на Narwhal согласительные протоколы имеют следующую структуру:
Предварительная якорная точка: каждые несколько раундов есть заранее определённый лидер, вершина которого называется якорной точкой.
Точки сортировки: валидаторы независимо, но определенно решают, какие точки сортировки использовать или пропускать.
Упорядоченная причинно-следственная история: валидаторы поочередно обрабатывают упорядоченный список якорей, сортируя неупорядоченные вершины в причинно-следственной истории каждого якоря.
Ключом к обеспечению безопасности является гарантирование того, что все честные узлы-валидаторы создают упорядоченный список опорных точек, который имеет одинаковый префикс. Shoal делает важное наблюдение по всем этим протоколам: все валидаторы согласны с первой упорядоченной опорной точкой.
Проблема задержки Bullshark
Задержка Bullshark зависит от количества раундов между упорядоченными якорными точками в DAG. Хотя некоторые синхронные версии имеют меньшую задержку, чем асинхронные, они все еще далеки от оптимальных.
Основные проблемы заключаются в двух вопросах:
Среднее время задержки блока: в обычных случаях, вершины нечетного раунда требуют три раунда для сортировки, вершины четного раунда, не являющиеся анкерами, требуют четыре раунда.
Ситуация с задержкой неисправности: если лидер раунда не смог своевременно передать якорную точку, эта якорная точка будет пропущена, и все неотсортированные вершины предыдущих раундов должны ждать сортировки следующей якорной точки. Это значительно снижает производительность геораспределённой сети, особенно потому, что Bullshark использует время ожидания лидера.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp)
Шоал фрейм
Shoal усиливает Bullshark( или любой BFT-протокол на основе Narwhal) через конвейер, позволяя иметь одну опорную точку на каждый раунд и уменьшая задержку всех неопорных вершин до трех раундов. Shoal также вводит механизм репутации лидеров с нулевыми затратами в DAG, предпочитая выбирать быстрых лидеров.
Вызов
В реализации конвейера и репутации лидера в протоколе DAG считается сложной задачей:
Предыдущие попытки изменить核心逻辑 Bullshark, похоже, не удались.
Репутация лидеров может привести к различным сортировкам, в то время как валидаторы должны прийти к согласию по упорядоченной истории, чтобы выбрать будущие опорные точки.
В качестве подтверждения сложности проблемы, в настоящее время реализации Bullshark в производственной среде не поддерживают эти функции.
Протокол
Решение Shoal относительно простое. Оно использует возможность выполнения локальных вычислений на DAG, реализуя функцию сохранения и переосмысления информации предыдущих раундов. Основываясь на том, что все валидаторы согласны с первым упорядоченным якорем, Shoal последовательно комбинирует несколько экземпляров Bullshark для конвейерной обработки, что позволяет:
Конвейер
V, которое сопоставляет раунды с лидерами. Shoal последовательно запускает экземпляры Bullshark, каждый экземпляр упорядочивает якорную точку и инициирует переключение на следующий экземпляр.
Shoal запустил первый экземпляр Bullshark на первом раунде DAG, пока не был установлен первый упорядоченный якорь (, предполагая, что в раунде r ). Все валидаторы согласны с этим якорем, поэтому можно с уверенностью согласиться на повторную интерпретацию DAG с раунда r+1. Shoal запускает новый экземпляр Bullshark в раунде r+1.
В идеальных условиях это позволяет Shoal сортировать одну опорную точку за раунд. Первая раундная опорная точка сортируется первым экземпляром, затем на втором раунде новый экземпляр сортирует эту раундную опорную точку и так далее.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp)
Репутация лидера
Когда Bullshark пропускает якорную точку, задержка увеличивается. Технология конвейера в этом случае бессильна, поскольку необходимо дождаться сортировки якорной точки предыдущим экземпляром, прежде чем можно будет запустить новый экземпляр. Shoal назначает баллы каждому узлу проверки через механизм репутации, основываясь на его недавней истории активности. Быстро реагирующие валидаторы получают высокие баллы, в противном случае получают низкие.
Идея заключается в том, чтобы при каждом обновлении счета детерминированно пересчитывать отображение F от раунда к лидеру, отталкиваясь от лидеров с высокими баллами. Чтобы валидаторы пришли к согласию по новому отображению, им необходимо достичь согласия по счету, а затем достичь согласия по истории, используемой для вывода счета.
В Shoal репутация пайплайна и лидера может естественно сочетаться, поскольку они оба основаны на переосмыслении DAG после достижения согласия на первом упорядоченном якоре. Единственное различие заключается в том, что после r-го раунда упорядоченного якоря валидаторы начинают вычислять новое отображение F' с r+1 раунда на основе причинной истории этого якоря. Затем с r+1 раунда используются обновленное F' для выполнения новых экземпляров Bullshark.
! [10 000 слов, объясняющих структуру Shoal: как уменьшить задержку Bullshark на Aptos?] ](https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp)
Устранение тайм-аута
Тайм-ауты имеют критическое значение во всех реализациях BFT с детерминированной частичной синхронизацией на основе лидера. Однако они увеличивают сложность, требуют более тщательного управления внутренним состоянием и наблюдения, что делает отладку более сложной.
Таймаут также значительно увеличит задержку, поскольку правильная конфигурация имеет важное значение и обычно требует динамической настройки. Прежде чем перейти к следующему лидеру, протокол должен выплатить полное наказание за задержку таймаута для вышедшего из строя лидера. Поэтому настройки таймаута не должны быть слишком консервативными, но если они слишком короткие, это может привести к пропуску хорошего лидера.
К сожалению, основанные на протоколе лидера (, такие как Hotstuff и Jolteon ), по сути требуют тайм-ауты, чтобы обеспечить прогресс в случае сбоя лидера. Если тайм-аутов нет, даже упавший лидер может навсегда остановить протокол. Поскольку в асинхронный период невозможно различить сбой и медленного лидера, тайм-ауты могут привести к замене всех лидеров валидационными узлами без активного консенсуса.
В Bullshark тайм-аут используется для построения DAG, чтобы обеспечить достаточно быструю добавку якорных точек в DAG честным лидером во время синхронизации.
Мы наблюдаем, что построение DAG предоставляет "часы", оценивающие скорость сети. Пока n-f честных валидаторов продолжают добавлять вершины в DAG, раунд будет продвигаться вперед. Хотя Bullshark может не сортировать по скорости сети, DAG всё равно растёт с сетевой скоростью. В конце концов, когда безошибочный лидер достаточно быстро транслирует якорную точку, вся причинно-следственная история якорной точки будет отсортирована.
В оценке мы сравнили Bullshark с тайм-аутом и без него:
Быстрый лидер: два метода задержки одинаковы, потому что опорные точки сортируются и не используют тайм-аут.
Ошибочный лидер: без тайм-аута Bullshark задержка ниже, поскольку узлы верификации немедленно пропускают свою опору.
Медленные лидеры: имеют лучшие показатели, чем Bullshark с таймаутом, потому что валидаторы будут ждать опорной точки, в то время как без таймаута можно пропустить опорную точку.
В Shoal избегание тайм-аута тесно связано с репутацией лидера. Повторное ожидание медленных лидеров увеличивает задержку, в то время как репутационный механизм исключает медленных валидаторов из числа лидеров. Таким образом, система может работать с сетевой скоростью во всех реальных сценариях.
Важно отметить, что результаты невозможности FLP свидетельствуют о том, что нет детерминированного соглашения, которое могло бы полностью избежать тайм-аута. Shoal не может обойти этот результат, поскольку теоретически существуют антагонистические события, которые могут помешать сортировке всех якорных точек. Напротив, после настраиваемого количества последовательных пропусков якорных точек Shoal вернется к тайм-ауту. Однако на практике такая ситуация крайне маловероятна.
Универсальная отзывчивость
Статья Hotstuff популяризировала концепцию оптимистичного ответа, что интуитивно означает, что протокол может, в благоприятных условиях (, включать быстрого лидера и синхронизированную сеть ) для работы на скорости сети.
Shoal предлагает лучшую функцию, называемую универсальной отзывчивостью. Конкретно, в отличие от Hotstuff, даже если лидер терпит неудачу в пределах настраиваемого количества последовательных раундов или сеть испытывает асинхронные циклы, Shoal будет продолжать работать с сетевой скоростью.
Универсальная отзывчивость предоставляет строгие и лучшие гарантии прогресса в асинхронный период и при сбоях лидера. Во время синхронизации с медленным лидером эти характеристики нельзя напрямую сравнивать, так как они зависят от скорости лидера. Но учитывая механизм репутации лидера, медленные лидеры в Shoal должны встречаться очень редко.
! [10 000 слов подробное объяснение структуры шоула: как вычитать.]