Репликаторы – решение Solana для хранилища петабайт данных в блокчейне

Узнайте об одной из 8 ключевых технологий, которые делают Solana самым производительным блокчейном в мире.

Solana – самый производительный permissionless блокчейн в мире. На текущих итерациях Solana Testnet сеть из 200 физических отдельных узлов поддерживает устойчивую пропускную способность более 50 000 транзакций в секунду при работе с графическими процессорами. Это достижение требует внедрения нескольких оптимизаций и новых технологий, в результате чего был достигнут прорыв в пропускной способности сети, который свидетельствует о новом этапе в разработке блокчейна.

8 ключевых технических инноваций, которые делают сеть Solana возможной:

  • Proof of History (POH)— часы перед консенсусом;
  • Tower BFT — PoH-оптимизированная версия PBFT;
  • Turbine — протокол распространения блоков;
  • Gulf Stream — протокол пересылки транзакций без Mempool;
  • Sealevel — параллельно исполняемые смарт-контракты;
  • Pipelining — блок обработки транзакций для оптимизации проверки
  • Cloudbreak — база данных горизонтально масштабируемых учетных записей;
  • Archivers — распределенное хранение реестра.

В этой статье мы рассмотрим механизм Archivers, распределенное хранилище реестра Solana для хранения петабайтов данных блокчейна. Мы представили Proof of Replication в 2017 году на Filecoin. В 2018 году мы создали нашу версию PoRep для Solana с использованием технологии VDF и оптимизировали ее для пакетной проверки.

При полной загрузке сеть Solana будет генерировать 1 Гб/с * 365 дней = 4 петабайта данных каждый год. Если каждый узел в сети должен хранить все эти данные, это ограничит возможных участников сети несколькими централизованными узлами, которые поддерживают такую ​​емкость хранилища. Наша технология Proof of History может быть использована для смягчения этой проблемы, позволяя быстро проверять реализацию Proof of Replication и позволяя распределять регистры по принципу распределения торрентов по миллионам узлов репликатора по всему миру. Репликаторы не являются участниками консенсуса и имеют очень низкие требования к оборудованию.

На высоком уровне сеть репликаторов Solana работает следующим образом: репликаторы должны сигнализировать сети, что у них есть X свободных байтов для хранения данных. На некоторой частоте сеть делит историю реестра на части, чтобы определить частоту репликации (в настоящее время мы ожидаем целевую частоту около 100x) и отказоустойчивость (достигается с помощью кода восстановления) на основе количества идентификаторов репликаторов и общего доступного хранилища репликаторов. Как только репликатору назначены данные, каждый репликатор загружает свои соответствующие данные из согласованных валидаторов. С некоторой частотой репликаторам будет предложено доказать, что они хранят данные, в этот момент они должны выполнить доказательство репликации (PoRep). Репликаторы получают ~3% от инфляции за их усилия.

Proof of Replication в глубину

Основная идея Proof of Replication заключается в том, чтобы зашифровать набор данных с помощью открытого симметричного ключа с использованием шифрования CBC, а затем хэшировать зашифрованный набор данных. Этот метод подробно описан в Техническом отчете Filecoin Proof of Replication. К сожалению, проблема этого подхода заключается в том, что он уязвим для атак.

Например, нечестный узел хранения может передавать шифрование и удалять его после хэширования. Простое решение состоит в том, чтобы заставить хеш выполняться после расшифровки или, возможно, в случайном порядке. Это гарантирует, что все данные присутствуют во время генерации доказательства, и также требует, чтобы валидатор имел в наличии все зашифрованные данные для проверки доказательства каждой идентичности. Место, необходимое для проверки, становится (Количество ключей CBC)*(размер данных).

Мы совершенствуем этот подход путем случайной выборки зашифрованных блоков с большей скоростью, чем скорость шифрования, и записи хэша этих выборок в регистр PoH. Таким образом, блоки остаются в одном и том же порядке для каждого PoRep, проверка может передавать данные и проверять все доказательства в одном пакете. Таким образом, мы можем проверить несколько доказательств одновременно, каждое на своем собственном ядре CUDA.

С новым поколением видеокарт сеть Solana может поддерживать до 1500 идентификаторов репликации или симметричных ключей для каждой видеокарты. Общее пространство, необходимое для проверки, составляет (2 блока CBC)*(количество ключей CBC), с количеством ядер, равным (количество ключей CBC). Ожидается, что размер блока CBC составит 1 Мб.

Затем мы должны построить взаимодействие между валидаторами и репликаторами, которое гарантирует, что репликаторы генерируют доказательства, а валидаторы фактически проверяют PoReps.

Чтобы начать создание PoReps реестра, клиент репликатора делает следующее:

  1. Клиент регулярно подписывает хэш PoH
  2. Подпись используется в качестве источника случайного числа для выбора конкретного фрагмента реестра.
  3. Подпись используется для создания симметричного ключа CBC, клиент кодирует часть реестра этим ключом.

Поскольку каждый клиент использует один и тот же хэш PoH, подписи случайным образом распределяются между всеми клиентами. Затем клиенты непрерывно выбирают зашифрованный образец:

  1. Клиенты регулярно подписывают хэш PoH
  2. Подпись используется в качестве источника случайного числа для выбора 1 байта из 1 Мб данных.
  3. Образцы хешируются с помощью алгоритма SHA256

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

Валидаторы, в свою очередь, проверяют доказательства клиентов:

  1. Валидатор объявляет, сколько PoReps он может проверить, основываясь на количестве ядер GPU.
  2. Периодически валидаторы будут подписывать хеш PoH
  3. Подпись используется для выбора фрагмента реестра и проверки маски для выбора образцов для проверки, вплоть до емкости валидатора.
  4. Валидатор загружает доказательства, которые не прошли проверку

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

Использование репликаторов в сети Solana, наряду с такими инновациями, как Proof of History, Sealevel и Gulf Stream, в совокупности создают самый производительный блокчейн в мире. Тестет Solana работает уже сегодня. Вы можете увидеть его по адресу https://explorer.solana.com. В целях экономии мы используем только несколько узлов. Однако во многих случаях мы распространили его более чем на 200 физических различных узлов (не на совместно используемом оборудовании) в 23 центрах обработки данных в AWS, GCE и Azure для сравнительного анализа.

Среда выполнения также работает уже сегодня, и разработчики могут развернуть код в тестовом режиме уже сейчас. Сегодня разработчики могут создавать смарт-контракты на C, и мы активно работаем над набором инструментов Rust. Rust будет основным языком для разработки смарт-контрактов Solana. Набор инструментов Rust общедоступен в качестве Solana Javascript SDK, мы продолжаем работу над пакетом разработки ПО.

Вскоре Solana запустит общедоступную бета-версию, стимулирующую валидаторов для запуска узлов через Tour de SOL — аналог “Game of Stakes” Cosmos — которая ставит перед общественностью задачу протестировать пределы сети Solana, зарабатывая при этом токены.