Это машинный перевод. Оригинал на английском здесь: Update 26 January, 2023
На этой неделе мы вернемся к возрасту узла и рассмотрим некоторые настройки, чтобы использовать его для большего количества сетевых операций. Чтобы предотвратить любой плач и скрежет зубов, не волнуйтесь, это не та архитектурная реконструкция, на которую уйдут месяцы. Он основывается на том, что уже есть, с точки зрения новых узлов, которые должны проявить себя и перемещаться по сети, но он снимает с этих молодых узлов важные обязанности по обработке данных и ограничивает их теми, которые уже зарекомендовали себя.
Общий прогресс
После длительных и иногда горячих дискуссий в сообществе @JimCollinson и @andrew снова получили электронные таблицы и проработали различные варианты распределения токенов. Мы искренне надеемся, что это послужит основой для дальнейшего продвижения вперед.
@joshuef экспериментировал с тестовыми сетями с еще более маленькими виртуальными машинами и небольшими узлами. Все шло довольно хорошо, но было несколько ошибок, связанных с процессом DKG (голосование старейшин), когда иногда голоса не поступали. В связи с этим @anselme, @maqi и @davidrusu внимательно изучают DKG, что именно вызывает его, в том числе изучают генерацию SAP ( новая запись старейшин, которая создается каждый раз, когда происходит отток) и именно там, где это запускает раунд DKG.
@oetyng упростил процесс присоединения, переместив его в обычные потоки сообщений. После этого процесс перемещения был упрощен за счет того, что он также был присоединен, но к другому разделу и включал доказательство перемещения. @davidrusu обнаружил потенциальную необходимость подтверждения того, что использовалось действительное событие оттока, эта работа приближается.
@bochaco занимается отладкой и доработкой sn_comms, коммуникационного модуля, который он продолжает реорганизовывать.
А Мостафа закончил тестирование алгоритма консенсуса и добавил его в основное репозиторий.
Спасибо @southside за предложение комментировать код ChatGTP. Любой, кто хочет помочь (технические навыки не требуются), должен проверить это сообщение.
Возраст узла и данные
Обязанности в сети основаны на понятии возраста узла.
Возраст узла увеличивается не линейно, а экспоненциально, что означает, что каждое увеличение возраста основано на удвоении того, на чем было основано предыдущее увеличение.
Время в сети измеряется количеством событий, и это измерение является приблизительным, поскольку мы проводим вероятностную оценку.
Таким образом, возраст A наступает после ~n событий, а возраст A+1 наступает после ~2n событий.
Причина, по которой возраст узла измеряется таким образом, связана с эмпирическим наблюдением, что узлы, которые оставались в сети x раз, вероятно, останутся в сети как минимум еще x раз. Таким образом, если вы провели в сети время «t», вполне вероятно, что ваше общее время в сети в конце концов составит не менее «2t».
Это просто означает, что чем моложе узел, тем больше вероятность, что он отключится, а чем старше, тем больше вероятность, что он останется в сети.
Имея очень стабильные и очень нестабильные узлы, хранящие данные в реальном времени, как мы это делаем сейчас, трудно управлять, когда есть много оттока. Если узел отключается, его данные должны быть переданы следующему ближайшему XOR-кандидату, что требует времени. Новые узлы ненадежны и могут быстро отключаться, что означает перемещение большого количества данных и головную боль для старейшин, которым приходится ими управлять.
Первичное и вторичное хранилище
Мы рассматриваем концепции «стабильного набора» узлов (подробнее об этом позже). Но одна идея, которую это дает нам, — это разделение узлов на два уровня хранения в зависимости от возраста и (следовательно) вероятности вспенивания, и, таким образом, возложение на них разных обязанностей.
Например, мы хотели бы, чтобы самые стабильные узлы (скажем, возрастом 10+) отвечали за первичное хранение данных. Эти узлы следят за данными и передают их клиенту по запросу. В ближайшее время они вряд ли заглохнут.
Узлы за пределами такого стабильного набора, те, которые все еще работают над увеличением возраста своих узлов, содержат дополнительные копии данных (вторичное хранилище). При этом они обеспечивают избыточность для поддержки стабильного набора.
Их поведение при обработке этих данных также используется для оценки их качества обычным способом. Но поскольку они содержат только дополнительные копии, старейшинам не нужно так тщательно отслеживать их, и они могут выйти из строя, не вызывая серьезных проблем в сети и не требуя массовой миграции данных.
Это позволило бы нам увеличить число репликаций данных, а также более тщательно тестировать входящие узлы, не жертвуя при этом стабильностью данных. Все благодаря использованию нашей существующей системы возраста узлов. 
Полезные ссылки
Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.
Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!