Artery Storage и VPN

Общие принципы работы в деталях

В общем

Распределенная децентрализованная система хранения данных Artery Storage имеет достаточно сложную архитектуру, объединяющую в себя ноды, выполняющие разную, но одинаково полезную для всей сети работу. Эта работа оценивается вне зависимости от роли, а только исходя из предоставленных в сеть ресурсов (про то, как вычисляется вознаграждение, мы расскажем позже).

При этом ноды объединяются в группы (не более 16 тысяч нод в группе), называемые кластерами. Обмен данными и сообщениями по большей части происходит внутри кластера, что позволяет равномернее распределять нагрузку по сети. Кластеры формируются на основе адресов владельцев нод и начинают разделяться, когда общее количество активных нод в каком-либо кластере подходит к выше указанному пределу.

Хотим также обратить внимание, что данный документ касается в основном 1-ой версии Artery Storage, про нововведения в обновлении мы будем рассказывать отдельно.

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

Согласно выполняемому функционалу, ноды-участники сети можно разделить на 2 типа — хранящие (storage) и управляющие (control). Причем вне зависимости от выполняемой роли все они имеют несколько клонов — так, чтобы потеря одной и хранимых ей данных не приводила к выходу всей сети из строя. Для простоты изложения будем считать, что управляющие ноды как бы «выше рангом», чем хранящие.

Хранящие ноды занимаются долгосрочным хранением пользовательских данных и данных, необходимых для работы сети. Их можно разделить на два подтипа: «горячие» и «холодные». Основное различие состоит в том, что горячие ноды имеют внешний адрес и принимают входящие соединения и запросы от сети напрямую, а холодные работают в пассивном режиме — т.е. выходят в сеть, подключившись к другим нодам (не важно какого типа) и используя их сетевой адрес (система различает ноды по основному признаку — адресу владельца — SDK адресу в Artery Blockchain). Также холодные ноды никогда не могут получить повышение ранга и перейти в разряд управляющих.

Основная задача этих нод — хранить пользовательские данные и следить за их удалением в случае истечения срока хранения (привязан к тарифу пользователя в blockchain).

Начиная с выхода Storage Node версии 2, хранящие ноды также примут на себя бо́льшую часть нагрузки по поддержанию соединений с клиентами-мессенджерами и приему/передаче от них событий и сообщений, а также разделят пул хранимых блоков на 2 (вообще видов блоков больше, но об этом ниже): блоки файлов и блоки сообщений.

Управляющие ноды хранят информацию, необходимую для поиска блоков, следят за их временем жизни, отвечают за разделение сети на кластеры, помогают в адресации нод и хранении информации об их роли (новые ноды всегда начинают как хранящие). Также, начиная с версии 2, они начинают выступать в роли брокера событий записи сообщений и хранят специальные реестры находящихся онлайн мессенджеров (в рамках кластера). При этом каждый кластер имеет свою группу управляющих нод, количество которых поддерживается автоматически. Т.е. если одна из нод отсутствует более часа, либо их становится менее 5, одна из хранящих нод повышается рангом, И на нее начинают выгружаться данные по состоянию кластера. Если потерянная нода возвращается ранее чем через сутки, она синхронизирует данные, и роль сохраняется. Если прошло больше времени, нода понижается до хранящей как минимум на 1 неделю.

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

Также управляющая нода может быть понижена до хранящей, если у нее начинает заканчиваться место для хранения метаданных (здесь и далее это данные о кластере хранилища).

Аналогия управляющих нод — картотека книг в библиотеке. Хранящих — книжные шкафы и полки.

Внутри системы идет постоянное взаимодействие: подключение и отключение нод участников сети (пиров, peers), обмен блоками, передача событий. Чтобы принять в этих процессах участие, нужно войти в сеть и найти ее участников. Такой процесс называется поиск узлов, или peers discovery. С него всегда начинается инициализация ноды и выход в сеть.

Обмен внутри сети на данный момент происходит с использованием JSON RPC over HTTP. События передаются через веб сокеты. В недалеких планах стоит частичный переход на поддержку gRPC и Protobuf (к сожалению не все платформы их легко поддерживают) Для увеличения производительности и уменьшения задержек.

Все операции записи подтверждаются цифровой подписью автора запроса. В качестве алгоритма используется secp256. Ключи для подписи создаются на основе seed-фразы пользователя (владельца ноды или производящего запись / удаление данных) в Artery Blockchain.

Инициализация ноды

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

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

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

Блоки данных

Блок данных — это минимальная единица хранения информации в рамках Artery Storage. В версии 1 размер блока был фиксированный и составлял 50 килобайт. С переходом на версию 2 эти ограничения были сняты, теперь блоки могут быть любого размера в пределах 1 МБ. Это позволит повысить плотность хранения данных (особо важно для сообщений мессенджера) с одной стороны и снизить накладные расходы на хранение больших файлов за счёт уменьшения размера индекса с другой.

Любой блок имеет заголовок, хранящий следующую информацию:

- версия заголовка;

- тип блока;

- метод шифрования, используемый в блоке;

- размер блока;

- его хэш.

Существуют блоки 4 типов:

- индексный блок (хранит информацию о загруженных данных конкретного пользователя, для поиска такого блока нет необходимость знать его хэш);

- блок данных хранилища;

- блок контактов чата;

- блок сообщения (имеет дополнительно временную метку, которая помогает упростить обработку таких блоков).

Методы шифрования могут реализовываться конкретными приложениями, использующими Storage, и помечаться ими в заголовке. При этом для разных задач и разными разработчиками могут использоваться разные методы (Artery Network использует Salsa20 и эллиптические кривые).

Начиная с версии 2 допускается хранение незашифрованных блоков, Что позволит в будущем реализовать возможность «делиться» файлами в публичный доступ, а также хранить общедоступные данные (аватарки для приложений, стикеры и т.п.) в Artery Storage.

Запись файлов

Т.к. изначально основным назначением Artery Storage было хранение пользовательских файлов, для их сборки из блоков и сохранения доступа даже в случае утери устройства, с которого они размещались, был разработан специальный «индексный» формат блоков. В которых хранится информация о том, какие файлы разбиты на какие блоки и в каких директориях они лежат (на текущий момент, вложенная структура папок не поддерживается).

В качестве формата был выбран JSON.

При этом для каждой папки хранится список файлов входящих в нее. А для каждого файла — на какие блоки он разбит (важен порядок записи блоков — файл собирается в той же последовательности, в которой разбирался)

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

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

Запись блоков

Для записи клиент запрашивает у управляющей ноды группу адресов активных нод, готовых принять блок (можно запросить сразу ноды на 100 блоков). После чего отправляет им нужные блоки и сообщает об этом управляющей ноде (если эту информацию не передать — блоки будут удалены во время оптимизации (compacting) хранилища нодой). Также передается информация какие ноды не приняли блок (в дальнейшем это влияет на их вознаграждение)

При этом запись возможна в двух режимах — сильном и слабом. В слабом (weak) режиме 1 блок записывается на одну ноду. Дальнейшее его распространение происходит механизмом размножения. Занимает больше времени и может привести к потере данных. В сильном (strong) режиме блок сразу записывается на несколько нод (операция выполняется параллельно), что снижает нагрузку на сеть за счет отсутствия необходимости размножения блоков и повышает надежность, т.к. вероятность потери данных из-за выхода ноды из строя сразу после записи, сильно снижается. Слабый режим предназначен для заливки данных с устройств с малым количеством ресурсов или плохим интернет-соединением.

Удаление блоков

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

Изменение блоков

Изменение блоков не предполагается. Если файл в хранилище меняется — изменившиеся блоки удаляются и записываются клиентом заново. Это связано с тем, что изменения размеров хотябы одного блока файла, вызывает последовательное изменение всех остальных блоков. (Хотя конкретная реализация клиента может пересчитывать только один блок, на текущий момент предусмотрена только полная перезапись всего файла)

Размножение блоков

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

Урезание блоков

Аналогично размножению, в случае если копий становится более 16–6 из них удаляются по запросу управляющей ноды.

Запись сообщений в чат (Storage 2)

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

Также, в отличии от записи обычного блока, порождается события записи в чат. Которое доставляется подписавшимся на него приложениям (через функционал брокера событий управляющих нод)

Присутствие онлайн и опции мессенджера (Storage 2)

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

Контроль доступных ресурсов

Управляющие ноды подключаются к нодам blockchain и следят за 4 событиями — оплата тарифа, оплата Storage, оплата VPN и окончание тарифа. Эти данные записываются в метаданные кластера и в дальнейшем используются в следующих случаях:

- запись блока — если тариф не оплачен или закончилось место — данные не обновляются и будут удалены при очистке пространства

- запрос нод для блока — если места недостаточно для размещения данных, запрос отклоняется

- проведение сжатия данных — блоки неактуальных аккаунтов удаляются с нод

Сжатие данных

Когда у хранящей ноды начинает заканчиваться место (по умолчанию — осталось менее 10% выделенного места), она начинает проводить очистку данных, проходящую в несколько этапов:

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

- очистка потерянных блоков и лишних копий — постепенно (чтобы не перегружать управляющие ноды) проверяется есть ли указанный блок в метаданных. Если его нет — блок удаляется. Если его копий более 10 — блок удаляется.

Хранение информации и статистики для Artery VPN

Одна из функций управляющих нод — хранение информации о времени нахождения онлайн нод-хранителей, управляющих нод и нод Artery VPN.

В первую очередь учитывается время онлайн (с квантованием в 10 минут). А также «баллы» за предоставление места для Artery Storage, А именно секунды онлайн × объем дискового пространства в ГБ. Данные суммируются постоянно, А для выплат используется их разница за недельный период. При этом значение уменьшается в случае наложения штрафов за неотдачу блока, несовпадение контрольной суммы и т.п.

VPN и построение маршрута

При выходе клиента в сеть VPN у управляющих нод запрашивается случайная, находящаяся онлайн, горячая нода VPN. После чего клиент устанавливает с ней соединение, указывая какой длины цепочку он запрашивает (не более 6 нод). Соединение шифруется с использованием ECDH и Salsa20. Нода выбирает следующую (холодную или горячую) и перекидывает соединение на нее, уменьшая счетчик цепочки на 1. И так пока не будет достигнут конец цепочки (последняя нода всегда горячая). В конце трафик пользователя выпускается во внешнюю сеть. При этом с точки зрения сетевого протокола инкапсулируемого внутри шифрованного канала — это 1 скачок (изменение ttl на 1) от входящего устройства до исходящей точки (хотя по факту канал совершает несколько скачков). Раз в интервал от 30 до 120 секунд начальная точка рвет соединение и перестраивает цепочку заново (инициатором также может выступать само устройство, сменив ноду для входа в сеть).

При этом входящая точка учитывает объем полученного трафика и передает его на управляющие ноды (она единственная кто знает SDK адрес Artery Blockchain отправителя данных).

Выплаты за Storage / VPN

Раз в неделю компания выгружает информацию о накопленных баллах и времени, проведенном онлайн VPN-нодами, и загружает эту информацию в блокчейн для проведения выплат. Т.е. выступает третьим лицом в процессе учета, гарантирующем корректность данных (если позволить любому записывать такие данные в сеть, то их ценность теряется). Но в планах стоит доработка Artery Blockchain введением специальной multisig транзакции — транзакции которая может быть подписана целой группой участников. В таком случае, предполагается отправка этой транзакции управляющими нодами в рамках одного кластера (несколько нод подписывают транзакцию с информацией о статистике по части участников и отправляют ее в blockchain). В определенный момент времени вся эта информация обрабатывается и происходит выплата.