Приоритеты экосистемы Flow: Основной протокол

Рабочая группа протокола отвечает за безопасность, масштабируемость, прогрессивную децентрализацию и обслуживание различных подсистем протокола.

Она работает на пересечении распределенных византийских систем отказоустойчивости, экономики протокола, языка смарт-контрактов Cadence и управления.

Улучшения производительности и масштабируемости

Одним из главных приоритетов является повышение пропускной способности сети TPS, чтобы лучше поддерживать рост и внедрение приложений с большим объемом транзакций. Хотя повышение пропускной способности имеет решающее значение, важно, чтобы результаты достижения этой цели оставались децентрализованными и безопасными. Крайне важно, чтобы любой прирост производительности не повышал барьер входа для операторов нод.

В сфере производительности есть достаточное количество низко висящих плодов, чтобы ожидать 1000 TPS в ближайшем будущем. Рабочая группа основного протокола сосредоточена на нескольких направлениях работы:

• Усовершенствования кода состояния исполнения (также известного как Ledger) с точки зрения сокращения памяти и повышения скорости выполнения операций и проверки доказательств
• Параллельное выполнение неконфликтных транзакций при сохранении детерминированного и синхронного упорядочивания блока

Другим важным приоритетом для основного протокола является улучшение масштабируемости и производительности хранилища выполнения. Эти направления работы приоритетны для решения проблемы долгосрочного раздувания состояния:

• Сокращение использования памяти и диска за счет оптимизации и сжатия хранимых значений каденции и FVM, улучшения структуры дерева Меркла
• Оптимизация производительности операций хранения путем минимизации количества байтов, считываемых/записываемых во время транзакции, за счет консолидации хранимых значений на основе шаблонов доступа (например, усовершенствования Atree)
• Сокращение размеров доказательств и объема используемой памяти за счет уменьшения глубины деревьев Меркла с использованием альтернативных криптографических решений (например, векторных обязательств)

Обновление протокола с нулевым временем простоя

Обновление и обслуживание программного обеспечения - неизбежная часть любого децентрализованного сервиса, и для Flow это происходит с помощью "sporks". Обычно "sporks" происходят примерно раз в два месяца, и в настоящее время временное время простоя составляет около 90 минут. Операторы нод сообщества и команда разработчиков протокола отвечают за повышение времени безотказной работы сети, сокращение времени обслуживания sporks и достижение состояния скользящих обновлений с нулевым временем простоя.

Текущая цель - перейти к обновлению протокола с нулевым временем простоя, когда не требуется миграция данных, которая обычно происходит только при изменении формата данных. Этого можно достичь с помощью скоординированного по высоте обновления протокола, аналогично стратегиям, используемым другими сетями. В ближайшей перспективе, пока не созреет процесс координируемого на высоте обновления и если произойдет обновление формата хранения данных, может потребоваться "пробка". В связи с этим текущий процесс миграции и sporks также оптимизируется, и в случае, если sporks не связана с обновлением формата хранения данных, она должна быть возможна в течение 30 минут. Сокращение частоты sporks до одного раза в квартал плюс частые скользящие обновления обеспечат более плавное обновление протокола без ущерба для темпов инноваций.

Рабочая группа Core Protocol работает над более конкретными идеями для достижения нулевого времени простоя при миграции состояний и обновит эту страницу в соответствующее время.

Масштабируемая одноранговая сеть для поиска данных

На данный момент основной протокол Flow не предусматривает никаких средств для постоянного хранения всех изменений состояния выполнения, которые он совершает с течением времени. Объем данных слишком велик, чтобы достичь этого, к тому же это было бы пустой тратой ценного внутрисетевые хранилища для хранения исторических данных. Внедрение ноды наблюдателя и архивных нод позволило бы пользователям извлекать данные локально для архивации и проверки. Тем не менее, необходимо экономически выгодное решение для доступа к историческим данным без запуска полноценного архивной ноды, которая в настоящее время требует аппаратного обеспечения уровня центра обработки данных. Существует несколько идей относительно того, кто будет хранить исторические данные, включая:

• Стимулируемые рыночные площадки в децентрализованных протоколах, которые могут предоставлять исторические данные с доказательствами Меркла
• Управляемые сервисные платформы, такие как Coinbase Cloud, Block Daemon, Quicknode, Infura, которые могут запускать архивные ноды.
• Клиенты в одноранговой сети (P2P), которые могут хранить произвольные фрагменты истории сети. Все клиенты в этой добровольной P2P-сети предоставляют данные и функциональные возможности, необходимые для стандартного gRPC & REST API

Сеть P2P может быть спроектирована таким образом, чтобы клиенты, участвующие в этих сетях, могли делать это с минимальной пропускной способностью сети, ресурсами CPU, RAM и HDD. В краткосрочной перспективе исторический доступ может быть предоставлен архивными узлами Dapper Labs. Однако в среднесрочной и долгосрочной перспективе более эффективным будет предоставление исторического доступа через другие протоколы или стимулы сообщества.

Мы приглашаем сообщество предложить дополнительные возможности для протокола синхронизации состояния выполнения Flow. Цель состоит в том, чтобы сделать возможными ценные дополнительные услуги, использующие состояние выполнения, которые выходят за рамки основного протокола, но требуют реализации (небольшой) дополнительной функциональности протокола. Сообщество может внести свой вклад в это направление работы через программу грантов для разработчиков Flow. Если вы хотите внести свой вклад, пожалуйста, свяжитесь с нами.

Улучшение отказоустойчивости в византийском режиме

Byzantine fault tolerance [BFT] означает способность сети безопасно работать даже в присутствии активно вредоносных (они же byzantine) нод в децентрализованной сети, что является ключом к разблокированию операций без разрешения нод. Это требует, чтобы все ноды были устойчивы к любым мыслимым злонамеренным действиям, исходящим от нод без разрешения. BFT можно разделить на три класса атак: атаки на уровне сообщений (включая атаки на выдачу себя за другого или маскировку), атаки на уровне протокола (несколько индивидуально валидных сообщений представляют собой нарушение протокола) и рассылка спама.

В качестве первого шага необходимо заложить основы сетевой структуры для смягчения атак типа "выдача себя за другого" или " маскировка". Новый протокол BFT для репликации состояния выполнения дополнит защиту сети и закроет оставшуюся поверхность для атак на уровне протокола нодами доступа, нодами наблюдателей и архивными нодами, тем самым обеспечивая их беспрепятственную работу.

На последующих этапах основные участники должны сосредоточиться на дальнейшем укреплении протокола репликации состояния выполнения против крупномасштабных спам-рассылок и DDoS-атак, что позволит нам еще больше увеличить число нод доступа, наблюдателей и архивных нод без разрешения.

В настоящее время рабочая группа основного протокола ищет экспертные оценки протокола репликации состояния исполнения на предмет уязвимости к спаму.

Повышение устойчивости консенсуса во время исполнения

Flow использует HotStuff, алгоритм консенсуса на основе лидера. За последние два года в этой области были достигнуты значительные успехи. В частности, протокол Jolteon (июнь 2021 года) улучшает оригинальный HotStuff [v6] в двух важных областях:

• На счастливом пути Jolteon требуется только два дополнительных раунда для завершения блока (против 3 для HotStuff v6)
• Jolteon включает в себя PaceMaker

PaceMaker компании Jolteon использует специальные сообщения для синхронизации представлений BFT, что значительно повышает устойчивость протокола к широкому классу сценариев отказа, включая последовательные отказы лидеров, разделение сети, неблагоприятные условия загрузки и т.д. Ключевые достижения Jolteon также были приняты командой Diem (ранее Facebook), что привело к появлению DiemBFT v4 (август 2021 года).

После всестороннего анализа передовых подходов команда Core Protocol решила принять Jolteon (с некоторыми незначительными изменениями). Более того, генерируемые PaceMaker сертификаты тайм-аута также являются необходимым условием для устойчивого к византийским ошибкам переключения эпох в Flow. Исследование и реализация уже ведутся с начала года.

В настоящее время группа приглашает помочь в дальнейшей модулизации кодовой базы протокола Flow. Особенно полезной была бы автономная реализация консенсуса для исследовательских целей, разделяющая кодовую базу с производственной реализацией Flow (см. подробности здесь). Кроме того, мы благодарны за вклад академического сообщества в оптимальную параметризацию Jolteon PaceMaker (см. подробности здесь).

Беспрепятственные операции с нодами

Целью является полное отсутствие разрешений для всех типов нод, но сеть может позволить активное владение с все более широким набором операторов нод сообщества посредством постепенной децентрализации и поэтапного процесса. Короче говоря, мы стремимся предоставить любому желающему участнику возможность вносить свой вклад и получать выгоду от своих усилий в экосистеме Flow. Это достигается путем постепенной децентрализации - процесса, в ходе которого мы будем постепенно отказываться от контроля. Поэтапный подход позволяет нам сосредоточиться и создать путь к безопасной сети.

С введением ноды наблюдателя и, вскоре, ноды архива, сеть открывает возможности участия для всех без каких-либо ставок. Наличие собственной ноды означает, что вам не нужно полагаться на третьи стороны в вопросах состояния сети. Возможно, вы не получите таких же финансовых выгод, как ноды с полной ставкой, но вы можете увидеть другие преимущества, такие как конфиденциальность, безопасность, сбалансированное распределение нагрузки, снижение зависимости от серверов третьих лиц и децентрализация сети.

Для работы ноды без разрешений для ноды доступа со ставками потребуется новый алгоритм выбора оператора, прозрачный для сообщества. Обширные исследования были направлены на реализацию византийской отказоустойчивости [BFT] для защиты от любых атак, которые могут возникнуть от византийского оператора без разрешения в экосистеме. В будущем это направление работы может разблокировать операции без разрешения для других типов нод (верификация, сбор, консенсус).

В настоящее время рабочая группа ищет экспертную оценку и предлагает вознаграждение за тестирование этой функции. Если вы хотите узнать больше, приглашаем вас связаться с нами!

Внедрение нового алгоритма выбора оператора staked node

Исторически сложилось так, что для того, чтобы стать оператором ноды, необходимо было обеспечить соответствие минимальному стейкингу и требованиям программы. Хотя этот ручной процесс обеспечивал постоянную безопасность сети, сумма $FLOW, необходимая для получения права стать оператором ноды, была чрезвычайно высокой, что исключало многих начинающих операторов. Процесс отбора также не был прозрачным для общественности. Flow должен внедрить процесс отбора операторов нод, который может со временем постепенно ослаблять контроль. Это можно сделать в два этапа:

1. Внедрение автоматизированного распределения слотов ("staking slots")
2. Снижение требований к минимальным ставкам

Идея слотов для ставок заключается в создании автоматизированного процесса включения новых нод в таблицу ставок при управлении максимальным количеством нод для каждого типа нод. Этот процесс может быть расширен в будущем аукционным механизмом для выбора операторов нод полностью беспрепятственным способом.

Снижение минимальных требований к ставкам все еще находится в стадии исследования, чтобы гарантировать, что ставка достаточно высока и не ставит под угрозу безопасность сети.

Поддержка больших размеров состояний

Состояние выполнения Flow хранится в структуре данных merkle trie. Текущая реализация этой структуры в программном обеспечении узла Flow, называемая mtrie, полностью находится в памяти и оптимизирована для высокопроизводительных приложений на Execution nodes. Поскольку состояние выполнения очень велико, существует компромисс между производительностью и аппаратными требованиями ноды. В результате Execution nodes требуется большой объем памяти (512 ГБ оперативной памяти) для хранения всей тройки плюс небольшого количества истории полностью в памяти.

Для других приложений, таких как архивные ноды, объем памяти и спокойные требования к оборудованию важнее, чем производительность, поэтому желательно иметь масштабируемую тройку, оптимизированную для больших наборов данных. Это позволит нодам работать на оборудовании потребительского класса, но с большими дисками.

Мы хотели бы пригласить сообщество внести свой вклад в это направление работы через программу грантов для разработчиков Flow.

Интеграция достижений в области криптографии

В настоящее время основная группа занимается дальнейшим усовершенствованием реализованных криптографических примитивов и протоколов, чтобы повысить устойчивость сети к византийским сбоям. Такие усовершенствования включают в себя интеграцию доказательства владения (PoP) закрытым ключом BLS операторов нод в процесс стейкинга. PoP - это защита, выбранная протоколом для обеспечения безопасности множественных агрегаций подписей BLS и схемы SPoCK на основе BLS. Подписи BLS и реализации пороговых подписей на основе BLS постоянно обновляются, чтобы включить последние достижения в области производительности и улучшить соответствие стандартам. Распределенная генерация ключей случайного маяка на основе метода Pedersen также обновляется, чтобы быть более устойчивой к злоумышленному поведению.

Более того, протокол пытается использовать несколько дополнительных областей криптографии для улучшения безопасности и производительности сети. Одной из таких областей является специализированное доказательство конфиденциальных знаний (SPoCK) на основе BLS, которое расширяется для поддержки агрегаций и оптимизации механизма запечатывания протокола.

Другие возможные темы исследований включают изучение криптоаккумуляторов и векторных обязательств.

В настоящее время председателем рабочей группы Core Protocol является Alex Hentschel, а основными участниками - Dapper Labs, Coinbase Cloud, NCC Group, Halborn и Metrika. Рабочая группа сотрудничает на GitHub Core Protocol и в ближайшем будущем проведет публичную встречу R&D для обсуждения обновлений рабочих потоков, межфункционального мозгового штурма и получения обратной связи друг от друга.