Quorum Store: горизонтальное масштабирование консенсуса на блокчейне Aptos
Авторы статьи: Брайан Чо и Александр Шпигельман
Резюме
- Команда Aptos Labs запустила Quorum Store, первую развернутую реализацию мемпула Narwhal.
- Quorum Store значительно повышает пропускную способность консенсуса за счет устранения ограничивающего фактора лидера.
- Quorum Store отделяет распространение данных от упорядочивания метаданных, позволяя валидаторам транслировать данные асинхронно и параллельно.
- Стресс-тесты Quorum Store показали 12-кратное и 3-кратное улучшение показателя TPS в тестировании консенсуса и сквозной обработки, соответственно.
Команда Aptos Labs рада представить вашему вниманию Quorum Store — первую развернутую реализацию мемпула Narwhal. Quorum Store значительно повышает пропускную способность консенсуса за счет устранения ограничивающего фактора лидера. Вместо того, чтобы полагаться на одного лидера при трансляции больших объемов данных в рамках протокола консенсуса, Quorum Store отделяет распространение данных от упорядочивания метаданных, позволяя валидаторам транслировать данные асинхронно и параллельно.
Уязвимое место в консенсусе блокчейна
Большинство развернутых в настоящее время блокчейнов реализуют консенсус, основанный на лидерах. В этих протоколах лидер управляет прогрессом и отвечает за распространение пользовательских транзакций в рамках согласованных предложений. В результате ресурсы лидеров используются чрезмерно, в то время как остальные валидаторы в основном простаивают. Это значит, что общая пропускная способность системы определяется способностью лидеров транслировать данные. Обратите внимание, что смена лидеров не может решить эту проблему, а лишь передает данное ограничение от одного лидера к другому.
Narwhal: Отделение процесса распространения данных от консенсуса
Как впервые было замечено в Narwhal, распространение данных может и должно быть отделено от логики консенсуса. Ключевая идея Narwhal заключается в том, что валидаторы могут непрерывно передавать пакеты транзакций друг другу параллельно. Затем, когда лидеры предлагают блоки на основе консенсуса, они указывают набор (ранее совместно используемых) пакетов для включения в блок. Это сокращает объем данных, необходимых для совместного использования в каждом предложении блока, поскольку лидеру не нужно перечислять и отправлять транзакции в каждом блоке, а вместо этого он может просто указать идентификаторы пакетов (метаданные).
Допустим, один валидатор может транслировать T транзакций в секунду. Тогда пропускная способность любого консенсуса на основе лидера ограничена T. Однако с Quorum Store n валидаторов могут транслировать nT транзакций в секунду, соответственно увеличивая ограничение на пропускную способность консенсуса.
Как и прежде, логика консенсуса отвечает за обеспечение общего порядка транзакций. Однако с Quorum Store лидеры включают в свои предложения только метаданные. Эти метаданные упорядочиваются в согласованном порядке и сопоставляются с соответствующими пакетами транзакций перед исполнением. В результате показатели задержки передачи данных и пропускной способности консенсуса при высокой нагрузке значительно улучшаются. Более того, сложность сообщений протокола консенсуса становится гораздо менее важной для общей производительности. Таким образом, для поиска компромисса между низкой задержкой и низкой стоимостью связи, используется Jolteon, который улучшает показатель задержки Hotstuff на 33%.
Обеспечение работоспособности системы с подтверждением доступности (proof of availability)
Коварная часть в процессе отделения распространения данных от упорядочивания метаданных заключается в обеспечении того, чтобы у всех валидаторов были транзакции, необходимые им для исполнения. Например, если злонамеренный валидатор отправляет данные, и метаданные, соответствующие этим данным, упорядочиваются на основе консенсуса, то все честные валидаторы должны иметь возможность извлекать эти данные.
С этой целью Quorum Store предоставляет подтверждение доступности (proof of availability), которое гарантирует, что данные, лежащие в основе подтверждения, будут доступны в системе до указанного срока действия.
Обзор архитектуры
Ниже представлен обзор высокоуровневой конвейерной архитектуры валидатора, включающий следующие 4 компонента:
- Мемпул отвечает за хранение набора потенциальных пользовательских транзакций
- Основная функция Quorum Store заключается в извлечении пакетов транзакций из Мемпула, их трансляции и формировании доказательств их доступности
- Консенсус извлекает доказательства из Quorum Store, упорядочивает их и отправляет на Исполнение
- Исполнение использует Quorum Store для сопоставления доказательств с пакетами транзакций и их исполнения
Готовность к внедрению
Возможность реализации была протестирована в децентрализованной сетевой среде на 100 валидаторах в более чем 30 различных странах, в ходе тестирования сеть подвергалась нагрузке для подтверждения низкой задержки передачи данных, высокой пропускной способности, а также подтверждения приемлемой рыночной цены газа. 12-кратное и 3-кратное повышение показателя TPS было достигнуто при тестировании только консенсуса (без Исполнения) и сквозной обработки, соответственно. Ознакомьтесь с нашими воспроизводимыми контрольными тестами производительности для получения подробной информации по проверке результатов на всех этапах.
Масштабирование консенсуса
Одним из главных преимуществ Quorum Store является возможность горизонтального масштабирования. Распространение данных по своей природе может осуществляться параллеьно, а это значит, что оно может быть линейно масштабировано с увеличением количества оборудования. Чтобы масштабировать консенсус, нам нужно лишь добавить больше машин для работы Quorum Store. В настоящее время каждый валидатор работает на одной машине. Вместо этого каждый валидатор может запустить несколько машин, одна из которых будет выполнять консенсус для упорядочивания доказательств, а остальные — параллельно запускать Quorum Store. Посмотрите рисунок 7 в Narwhal, чтобы наглядно увидеть эксперимент с линейной масштабируемостью по количеству машин, в ходе которого удалось достичь 600 тыс. TPS.
Протокол и реализация
Теперь перейдем к рассмотрению протокола и некоторых практических соображений. Для лучшего понимания некоторые детали оптимизации и реализации были опущены. В двух словах, чтобы сформировать доказательство доступности, все валидаторы параллельно повторяют следующие действия:
1. Извлечение транзакций из мемпула.
2. Распределение транзакций по пакетам в зависимости от цены на газ, затем выбор времени истечения срока действия каждого пакета транзакций.
3. Передача пакетов транзакций всем другим валидаторам.
4. Сохранение полученных пакетов, подпись их дайджестов, отправка подписи обратно.
5. Сбор кворума подписей для формирования доказательства доступности.
Подписи
Когда валидатор подписывает пакет транзакций, он дает обещание сохранять пакет до указанного времени истечения срока действия и отвечать на запросы о пропущенных пакетах от других валидаторов.
Гарантии доказательства
Доказательство доступности пакета данных — это кворум подписей, рассчитанных по доле 2f+1. Доказательство доступности гарантирует, что по крайней мере f+1 честных валидаторов предоставили подпись. Это означает, что по крайней мере f+1 честных валидаторов сохранят пакет до истечения срока его действия. Таким образом, доказательство гарантирует, что непросроченный пакет данных будет доступен в системе таким образом, что любой валидатор, которому не хватает данных, сможет получить их от других честных валидаторов.
Извлечение данных
После упорядочивания консенсусом доказательства передаются на исполнение. На этом этапе Исполнение запрашивает Quorum Store сопоставить доказательства с соответствующими транзакциями. В обычном случае Quorum Store будет хранить транзакции локально, поскольку каждый честный создатель пакета транслирует его всем. Однако в худшем случае Quorum Store потребуется извлечь транзакции от удаленного валидатора. Доказательство доступности гарантирует, что достаточное количество удаленных валидаторов хранит данные, но, если делать это наивно, можно увеличить задержку передачи данных. С этой целью мы внедряем оптимизацию для предварительного извлечения удаленных данных, как только впервые появится консенсус-блок, содержащий доказательства. Таким образом, к моменту запроса блока Quorum Store уже локально хранит все транзакции.
Баланс нагрузки
Quorum Store идеально сбалансирован по нагрузке. Поскольку все валидаторы транслируют пакеты данных и агрегируют доказательства параллельно, использование ресурсов между валидаторами одинаково, что приводит к распространению данных со скоростью сети. Обратите внимание, что поскольку все валидаторы должны получить все пакеты для исполнения, вышеупомянутый “наивный” механизм получения является оптимальным. Другие криптографические инструменты, такие как коды стирания, используемые для распространения и извлечения/восстановления данных, только добавят сложности и не дадут никаких преимуществ с точки зрения распределения нагрузки.
Контроль обратного потока
Благодаря Quorum Store консенсус стал самым производительным компонентом нашей конвейерной архитектуры. Чтобы он не перегружал другие компоненты системы, каждый валидатор регулирует скорость создания локальных пакетов на основе отставания, подобно классическим системам контроля перегрузок, таким как TCP. Кроме того, консенсус применяет принцип справедливости между пакетами, созданными разными валидаторами, чтобы гарантировать, что валидаторы получат справедливую долю пространства блока.
Кэш-память
Чтение пакетов данных из постоянного хранилища, например, с жесткого диска, может быть дорогостоящим. Мы реализуем подход с параллельным кэшом памяти, который позволяет Исполнению параллельно считывать данные из Quorum Store. Кэш содержит подмножество пактов данных, которые Quorum Store сохраняет в памяти.
Квота
Для предотвращения DDoS-атак применяется квота как для кэша в памяти, так и для хранилища. Перед подписанием и сохранением пакета данных валидатора v валидаторы проверяют память v и баланс его хранилища. Если оба баланса в порядке, пакет сохраняется в хранилище и сохраняется в кэше. В противном случае он может быть сохранен или проигнорирован, в зависимости от баланса хранилища.
Сбор ненужных данных
Чтобы убедиться, что честные валидаторы не превышают свои квоты, мы собираем просроченные пакеты данных. Чтобы гарантировать быстродействие, нам нужно, чтобы для каждого заказанного пакета b честный валидатор был способен (1) получить транзакции b и выполнить их или (2) синхронизировать состояние с состоянием, включающим их. Для этого просроченные пакеты очищаются на основе временных меток в зафиксированных блоках. Валидатор фиксирует блок, когда получает сертификат подтверждения кворума, указывающий на то, что большинство валидаторов выполнили его. Эти сертификаты кворума используются при синхронизации состояния, чтобы убедить валидаторов в том, что состояние действительно. Поэтому, если валидатор не может получить пакет данных из-за того, что все честные валидаторы очистили данные, гарантируется, что достаточно честных валидаторов исполнили пакет и имеют сертификат кворума для соответствующей синхронизации состояния.
