Обновление Safe Network 🇷🇺 13 января 2022 г

Это машинный перевод. Оригинал на английском здесь: Update 13 January, 2022

Было здорово и приятно видеть, что последняя тестовая сеть сообщества так хорошо работает :tada:. Огромное спасибо всем, кто принял участие :pray: :pray: :pray:. Теперь, когда сеть становится более стабильной, пришло время перейти к более тонким аспектам хранения и извлечения данных, и наши текущие планы изложены ниже. Как всегда, мы пытаемся придумать простые и гибкие базовые механизмы, которые можно легко расширить для поддержки других функций, таких как платежи и фермерство. Самое главное, они не предполагают никаких предположений о сетевой синхронизации.

Общий прогресс

@yogesh удалось исправить логическую проблему при продвижении новых старейшин, уменьшив количество раундов AE и, следовательно, обмен сообщениями со 150 до 15. Это впечатляющая 10-кратная оптимизация, но он уверен, что здесь можно сделать еще больше. на более позднем этапе. Сейчас он и @anselme изучают процессы обработки данных, описанные в основном разделе ниже, а @qi_ma отлаживает процесс подтверждения и обработки ошибок на клиенте.

@Joshuef представил Bors, систему автоматизации, которая интегрирует сразу несколько PR, так что это реально экономит время, когда она работает — что после небольшого возни — большая часть время сейчас, счастливо. Он и @oetyng также работали над переносом реестров на взрослых, упрощением размещения реестров и ослаблением текущего требования отправлять запросы всем семи старейшинам (см. ниже).

@bochaco рассматривает консенсус по членству в потоке маршрутизации и обработку узлов, которые перешли в автономный режим, а также то, как это будет интегрировано с работой DKG, над которой работают @davidrusu и @danda.

@chriso обновлял и приводил в порядок документацию CLI, а @lionel.faber исправлял некоторые сквозные тесты, которые не проходили, обновляя инструмент тестовой сети в процессе.

Обработка данных

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

Действительные данные

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

Каждый элемент данных состоит из имени, содержимого, подписи и ключа раздела.

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

Напоминаем, что секция состоит из семи старейшин, принимающих решения, и многих других (от 60 до 100) взрослых, которые хранят данные и предлагают их по указанию старейшин.

Данные хранятся четырьмя взрослыми, наиболее близкими (с точки зрения исключающего ИЛИ) к его имени.

Вместимость склада

Отступив немного назад, каждый взрослый на самом деле является чьим-то компьютером. Это может быть облачная виртуальная машина, домашний ПК или Raspberry Pi — или даже смартфон, если на нем достаточно памяти. Но сколько памяти достаточно? Это немного сложно, потому что требования со временем, скорее всего, будут расти.

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

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

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

56f116afea9b75720278c2479bdc3435e0ec9c5f

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

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

Так что этот вопрос еще обсуждается.

Проверка поведения взрослых

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

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

Старший кеширование

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

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

Что происходит, когда мы продвигаем узел?

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

Что происходит при перезапуске?

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

Пожилые люди могут удалять данные из своего кеша, но взрослые не могут удалять данные. Взрослые постоянно сообщают о своем уровне старшим, и как только они заполняются на 90%, им больше не отправляются данные.

Хранение данных в качестве клиента

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

Получение данных в качестве клиента

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

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

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

Плата за хранение

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

Затем клиент платит указанную сумму перед сохранением своих данных.


Полезные ссылки

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

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