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

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

Большое спасибо @stout77 за еще одну обложку :bowing_man:


Обновление от 12 мая 2022 г.

Одной из самых простых, но также наиболее фундаментальных и важных функций в дизайне безопасной сети является «Возраст узлов». По сути, «Node Age» заменяет такие системы, как Proof Of Work, поощряя хорошее поведение, наказывая за плохое и сильно усложняя жизнь злоумышленнику Sybil. Это обеспечивает важную меру качества и постоянной надежности каждого узла, и на этот раз это наша главная тема.

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

Благодаря нашей новаторской работе с DBC, в которой @davidrusu и другие развили концепцию «цифровых денег» в совершенно новом направлении, сделав ее византийской отказоустойчивой и, таким образом, подходящей для децентрализованной сети, мы рады сообщить, что Дэвид Русу возглавит новое подразделение Safe Labs. Это будет наш зонтик исследований и разработок для современной криптографии, сетей и многого другого. Исследования будут в первую очередь ориентированы на безопасность, а не на голубое небо, но мы хотим получить опыт отовсюду, где он может существовать, более формальным и структурированным образом.

@Anselme завершил PR для проверки SAP при передаче и начал изучать византийское поведение при передаче (процесс перераспределения данных о событии оттока).

Дэвид Русу выступил с докладом о бесконфликтных реплицируемых типах данных (CRDT) на встрече CompSci в Торонто, упомянув, что он делал в MaidSafe (естественно!). Большой интерес к теме и много контактов, которые будут установлены. Он возвращается за другим на деревьях CRDT.

@Bochaco завершил PR для проверки разрешения на стороне клиента при выполнении операций с регистрами (изменяемые данные), а также работает над клиентским API потраченной книги.

И @Chriso наблюдал за сбоями тестовой сети, вызванными временным удалением таких функций, как «max-capacity».

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

Тем временем @Qi_ma поговорил с командой о Node Age.

Возраст узла

Каждый узел в сети имеет адрес, который определяется как его идентификатор, который на самом деле является ключом, генерируемым при присоединении к сети. Этот «идентификатор узла» представляет собой очень большое случайное число. Его первые несколько битов (например, 0101101…) определяют, в какой секции будет находиться узел и, следовательно, какие данные он будет обрабатывать, а последние восемь битов (например, 00000101) означают его «возраст узла» — в данном случае 5.

Когда узел впервые принимается в сеть, ему присваивается «Возраст узла» 5, поэтому его идентификатор заканчивается на …00000101 (присоединяющийся узел должен продолжать генерировать ключи ED25519, пока не получит ключ с правильным окончанием и правильным префиксом, как правило, процесс менее секунды).

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

Но у Safe Network нет понятия времени, так как же мы можем отследить, как долго ведет себя узел? Ответ заключается в том, что мы используем события оттока (изменения членства в разделе) в качестве прокси для времени.

Идентификатор оттока — решающий фактор

Каждая секция будет содержать 7 старших (узлы принятия решений) и 60+ взрослых (узлы хранения). Каждый раз, когда узел отключается или присоединяется к разделу, что часто случается со взрослыми, старейшины голосуют за то, что произошло. Каждое событие оттока имеет 256-битный идентификатор, который представляет собой объединенную подпись BLS 5 из 7 старших. Этот «идентификатор оттока» также фактически является случайным числом и не может быть предсказан заранее.

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

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

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

Шанс повышения

Если «идентификатор оттока» делится по модулю на 2 exp «Возраст узла» (идентификатор оттока % 2^age == 0), мыЯ получаю повышение. Таким образом, для нашего нового узла возрастом 5, если «идентификатор оттока» делится на 32 — что происходит в среднем один раз каждые 32 оттока — его «возраст узла» увеличивается до 6 и перемещается в новый раздел. Затем ему, вероятно, придется ждать еще 64 оттока в своем новом разделе, прежде чем он снова получит повышение — продвижение становится экспоненциально труднее, чем дольше оно остается. Это означает, что Elders, самые старые 7 узлов в разделе, существуют уже долгое время и зарекомендовали себя во многих различных разделах, прежде чем получить статус голосования.

Как это работает? В каждом событии оттока старейшины делят «идентификатор оттока» по возрасту, начиная с самого старшего (255) и заканчивая самым младшим (5). Когда один из этих возрастов соответствует набору узлов в нашем разделе, мы перемещаемся до узлов elder_count/2, которые имеют этот Возраст узла. Обычно в этой возрастной группе будет только один, но в случае превышения мы выбираем узлы с «идентификатором узла», ближайшим к «идентификатору оттока».

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

Преимущества возраста узла

Эта схема имеет три основных преимущества. Во-первых, это сопротивление Сивилле. Чтобы контролировать раздел, злоумышленнику необходимо контролировать как минимум трех старейшин. Процесс становления старейшиной долгий и трудный, и невозможно знать, в каком разделе вы окажетесь. Когда сеть большая, соотношение 7 старейшин к 60+ взрослым сделает такие атаки Сивиллы чрезвычайно трудными. Кроме того, новым узлам разрешается присоединяться к разделу только тогда, когда требуется больше памяти, поэтому злоумышленники не могут наводнить сеть новыми присоединителями.

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

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

Процесс перемещения

@Qi_ma работает над реализацией Node Age, включая потоки обмена сообщениями между старейшинами секции, кандидатом на повышение и старейшинами в целевой секции. На этой неделе он выступил перед командой. Вот один из его слайдов.

Старейшины в разделе исходников

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

Узел-кандидат

  • Получает сообщения от старейшин
  • Подтверждает начало процесса переселения
  • Создает новый идентификатор с правильными начальными битами (раздел) и конечными битами (его новый возраст)
  • Загружается в новый раздел [у него есть право сделать это из исходного раздела]

Старейшины в разделе назначения

  • Убедитесь, что информация об исходном разделе актуальна (SAP)
  • Обновите их, если нет, и скажите им отправить повторно
  • Проверьте подписи о перемещении и детали в порядке
  • Голосовать за присоединение кандидата
  • Если все идет хорошо, кандидат присоединяется к новой секции

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

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

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