В этом посте мы рассматриваем модель хранения данных в Internet Computer (IC) и делимся информацией о планах по увеличению объёма доступного хранилища.
Мы начнём с общего обзора типов хранилищ, которые могут предоставлять блокчейны, затем перейдём к уникальным особенностям архитектуры Internet Computer, позволяющим реализовать особые компромиссы, и, наконец, расскажем о ключевых этапах на пути к расширению хранилища.
В контексте хранения в блокчейне можно, грубо говоря, выделить два основных типа: полностью реплицируемое хранилище и распределённое хранилище. Internet Computer использует модель полностью реплицируемого хранилища. В этой модели протокол гарантирует, что все участвующие узлы хранят полную копию данных — так называемое “реплицированное состояние”. Благодаря этому типу хранения возможны прямые операции чтения, записи, обновления и удаления данных в ходе выполнения задач, согласованных между узлами через протокол консенсуса. С точки зрения разработчика смарт-контрактов, это хранилище по своему поведению напоминает оперативную память (RAM) в традиционной программе, доступ к которой сохраняется постоянно.
В модели распределённого хранения, напротив, протокол консенсуса играет роль координатора, определяющего, какие узлы хранят какие части данных, согласованных ранее. Это означает, что каждый узел хранит лишь часть информации, что снижает уровень репликации. Однако такое хранилище не позволяет напрямую считывать данные в процессе реплицированного выполнения, поэтому оно в основном используется для хранения статичных файлов (blobs).
Таким образом, хотя полностью реплицируемое хранилище является более мощным с точки зрения возможных сценариев использования, оно сопряжено с проблемами масштабируемости.
Архитектура Internet Computer включает три ключевых концепции, позволяющие справляться с этими проблемами и обеспечивать высокую ёмкость полностью реплицируемого хранилища: детерминированная децентрализация, высокопроизводительный уровень хранения и возможность масштабирования путём добавления подсетей (subnets).
Рассмотрим, как каждая из этих составляющих способствует масштабируемому полностью реплицируемому хранилищу:
- Детерминированная децентрализация: DAO-система под названием Network Nervous System (NNS) принимает обоснованные решения о том, какие узлы допускать в сеть и какие узлы включать в подсети. Благодаря этому можно достичь целей по разнообразию и децентрализации с меньшим числом узлов на подсеть по сравнению с системами, где в сеть или подсеть может войти любой желающий узел.
- Высокопроизводительный уровень хранения: Недавно архитектура хранения в IC была полностью переработана в рамках этапа развития под названием Stellarator. Среди прочего, это стало значительным шагом к увеличению объёма полностью реплицируемого хранилища на одну подсеть. Уже на старте этого этапа максимальный объём хранилища на подсеть был увеличен до 1 TiB, а новая архитектура также открывает путь к последующим проектам по дальнейшему увеличению ёмкости.
- Масштабирование через добавление подсетей: При необходимости NNS может запускать новые подсети, тем самым увеличивая доступную ёмкость хранилища по требованию.
Благодаря этим архитектурным особенностям Internet Computer с самого начала сосредоточен на оптимизации объёма полностью реплицируемого хранилища. В заключительной части блога представлен более конкретный обзор ближайших шагов в этом направлении.
На момент написания статьи одна подсеть способна хранить до 1 TiB (~1,1 терабайта) полностью реплицированных данных. В настоящее время Internet Computer включает 34 подсети, обслуживающие децентрализованные приложения (dapps), что обеспечивает общую ёмкость реплицированного хранилища в 34 TiB.
От 1 TiB хранилища на подсеть к 2 TiB
Новая архитектура хранилища в Internet Computer была спроектирована и реализована таким образом, чтобы исключить операции, время выполнения которых линейно зависит от размера реплицированного состояния. Вместо этого операции зависят только от объема изменений по сравнению с предыдущим состоянием. С этой точки зрения система уже хорошо подготовлена к увеличению максимального размера реплицированного состояния подсетей.
Тем не менее, остаются известные аспекты, которые необходимо изучить, чтобы открыть путь к увеличению лимита до 2 TiB. Кроме того, в процессе реализации могут быть выявлены дополнительные, пока неизвестные факторы:
- Синхронизация состояния (state sync): Узлы, которые только что присоединились к подсети или отстали от остальных, используют протокол “state sync” для полного обновления до актуального состояния подсети. Также при восстановлении подсети некоторым узлам может потребоваться синхронизировать всё состояние целиком. Необходимо провести бенчмарки, чтобы определить, как протокол работает с объемом в 2 TiB, насколько производительность приемлема во всех возможных сценариях и/или потребуются ли оптимизации.
- Хеширование состояния: Время от времени узлы в подсети должны создавать хеш реплицированного состояния. Обычно это происходит инкрементально (т.е. хешируются только изменения по сравнению с предыдущим состоянием), однако бывают случаи, когда необходимо хешировать всё состояние целиком. Требуются тесты, чтобы оценить, насколько эти крайние случаи допустимы с точки зрения производительности.
При оптимистичном сценарии переход к 2 TiB может стать возможным после проведения обширных тестов и внедрения ряда оптимизаций.
За пределами 2 TiB хранилища на подсеть
Логично задаться вопросом: можно ли пойти ещё дальше? К сожалению, переход за пределы 2 TiB оказывается заметно сложнее, чем увеличение объёма до 2 TiB. Основная причина в том, что при дальнейшем увеличении объёма хранилища в некоторых наихудших сценариях использования возможно переполнение физических дисков узлов. В частности, способ хранения файлов на диске в новой архитектуре и тот факт, что протокол достаточно консервативен в отношении хранения старых состояний, влекут за собой значительные накладные расходы на дисковое пространство.
Таким образом, чтобы увеличить объём до 4 TiB и более, потребуется внести несколько изменений в протокол. Во-первых, необходимо пересмотреть параметры уровня хранения с целью снижения накладных расходов, что, разумеется, может повлиять на производительность выполнения. Во-вторых, потребуется сделать протокол более агрессивным в удалении старых состояний. Очевидно, что оба подхода требуют предельно тщательного проектирования, реализации и всестороннего тестирования. Также потребуется повторно проанализировать все аспекты, затронутые на этапе перехода к 2 TiB, и, возможно, реализовать дополнительные улучшения.
Таким образом, этот шаг находится на более отдалённой перспективе, однако есть уверенность, что он будет достигнут.
Распределённое хранилище в Internet Computer
Наконец, важно отметить, что хотя до настоящего момента основное внимание уделялось созданию масштабируемого реплицированного хранилища, в протоколе нет принципиальных ограничений, препятствующих добавлению поддержки распределённого хранилища (например, для хранения статичных файлов). Этот вопрос будет рассмотрен в отдельной публикации позже.
Заключение
В последние годы Internet Computer постоянно расширяет границы возможного в области реплицированного хранения данных в блокчейнах. Это критически важно для множества сценариев Web3, которые ещё недавно считались невозможными. Один из таких примеров — запуск крупных языковых моделей ИИ полностью в ончейне.
Internet Computer обладает уникальными архитектурными особенностями, которые создают прочную основу для дальнейшего роста объёмов реплицируемого хранилища. Как обсуждалось выше, уже намечены конкретные шаги по увеличению ёмкости хранения.
Кроме того, в ближайшее время начнётся работа по созданию второго класса хранилища — распределённого, предназначенного для хранения статичных данных (blob storage).
DFINITY — НКО, ведущий разработчик Internet Computer