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

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

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

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

На этой неделе мы поняли, что потенциально теряем узлы во время сильного оттока и разделения, когда узел думает, к которому он присоединился, но с оттоком действительный ключ раздела сдвинулся. Узел, думая, что все в порядке, не пытался переподключиться. Итак, @anselme работает над проверкой наших знаний о сети и после их обновления повторяет процесс присоединения для этих потерянных узлов.

Работа DBC продолжается с начальными шагами по хранению SpentBook на месте.

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

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

Еще одна потенциальная блокировка происходила в дисфункции, когда вложенная структура данных читалась неправильно без блокировки mut. :open_mouth: :man_facepalming:

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

Со всем этим мы также наконец-то интегрировали работу DKG-Handover with Generation (которая была намного более стабильной по сравнению с другими недавними изменениями). Мы сокращаем стабильность, предстоят дополнительные тесты/тесты для DataStorage, а также некоторые другие настройки для тестируемых потоков репликации данных (нам нужно расширить пул узлов, которые мы запрашиваем для данных, как и в случае интенсивного оттока, шансы удара по другому только что присоединенному узлу увеличивается, и похоже, что мы начинаем терять сохранение данных!).

Отслеживание дисфункций

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

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

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

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

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

Мы можем проверить производительность узла по сравнению с другими узлами в разделе, но что, если весь раздел не соответствует стандартам по сравнению с другими разделами? Что тогда?

Как вы понимаете, отслеживание дисфункций — сложная задача со многими переменными.

Цели отслеживания дисфункций

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

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

Отслеживание дисфункций связано с оптимизацией, но не только с оптимизацией производительности — это привело бы к централизации. Домашние пользователи не смогут конкурировать с экземплярами ЦОД — они всегда будут относительно нефункциональными.

Где мы

В настоящее время у нас есть упрощенная версия дисфункции.

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

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

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

Как уже упоминалось, некоторая степень «дисфункционального поведения» неизбежна, и прямо сейчас мы экспериментируем с классификацией узлов как хороших (коэффициент успеха 95%+ для данной операции), посредственных (75%) или плохих (30%), поэтому мы может относиться к каждому классу по-разному в зависимости от его серьезности, без жесткого кодирования каких-либо «ожидаемых» значений (PR # 1179). Мы также хотим знать, сколько узлов каждого класса находится в нашем разделе.

Крейт sn_dysfunction находится здесь.

Куда мы идем

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

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

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

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

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

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

Все это приводит нас в область инженерии хаоса, которую используют такие компании, как Netflix и Google, на своих облачных платформах, чтобы гарантировать, что сбои отдельных серверов не не рушить всю систему.

Вероятно, здесь мы тоже можем кое-чему научиться, работая над тем, чтобы сделать Safe Network надежной и надежной.


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

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

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