Обновление Safe Network 🇷🇺 26 ноября 2020 г

Это машинный перевод. Оригинал на английском здесь: Safe Network Dev Update - November 26, 2020

Резюме

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

Безопасный клиент, узлы и qp2p

План проекта безопасных сетевых передач
План проекта безопасного клиента
План проекта безопасного сетевого узла

После того, как на прошлой неделе мы добавили подпись операций CRDT последовательности, на этой неделе мы интегрировали это в стек с некоторыми изменениями в sn_node здесь и sn_client здесь и здесь, чтобы все операции были подписаны перед передачей в сеть. Это высветило некоторые другие проблемы, касающиеся локального кэширования последовательностей (когда использовать локальное или сетевое и т. Д.). Мы решили удалить этот кеш на данный момент с помощью этого PR для простоты. Это помогло укрепить набор тестов, позволив нам более четко увидеть некоторые потоки типов CRDT в действии, например, отправка изменений не * немедленно * извлекается из сети, поэтому мы должны дождаться ожидаемых изменений там.

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

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

Lazy Messaging - это когда мы получаем сообщение, которое не можем обработать по какой-либо причине (рассинхронизация, будущий порядковый номер и т. Д.), И мы возвращаем это сообщение отправителю с нашей последней известной историей. Затем отправитель знает, что ему нужно предоставить нам недостающую ссылку (мы также можем сделать обратное (однако без ошибок) и обновить отправителя, если это они отстают). Это избавляет нас от ожидания сообщений до тех пор, пока они не будут заказаны, что может быть использовано для атаки на сеть, и это будет более сложный код. Ленивый обмен сообщениями намного ближе к модели акторов, передающих сообщения, и мы расширили ее для обработки частично упорядоченных событий.

С изменением динамики соединения новых узлов в маршрутизации, см. PR # 2234, мы также начали обновлять sn_node, чтобы узлы брали на себя ответственность за позволяя новым узлам присоединяться к сети. Фактически, старейшины сети теперь будут отслеживать спрос / предложение ресурсов в своей секции и, соответственно, запрашивать маршрутизацию, чтобы позволить новым узлам, стоящим в очереди, присоединиться к их секции.

Мы также начали адаптировать authd и CLI к новой терминологии UI / UX, например, перейти от« Учетных записей »к« Сейфам », а также внести необходимые изменения, чтобы authd сохранял приложения. 'пары ключей в сети, используя Map в качестве типа данных для хранения« Safe ». Мы продолжим выполнение этой задачи, чтобы согласовать все команды CLI и функции аутентификации с этой новой терминологией, а также с новым API sn_client.

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

BRB - Византийское Реответственное вещание

На этой неделе наш консультант продвинул идею Generation Clock, упомянутую на прошлой неделе, и представил команде алгоритм псевдокода для комментариев. Этот гибридный подход накладывает полный порядок на нечастые операции присоединения и выхода, но только частичный порядок на гораздо более частые операции с данными. Говоря простым языком, это означает, что соединение / выход должно быть ограниченным (т.е. мы не можем позволить, чтобы не отвечающие узлы существовали) и использовать форму полного порядка, но мы можем обрабатывать сразу несколько выходов и т. Д., Тогда как обычные операции с данными могут происходить. с высоким уровнем параллелизма, при условии, что каждый из них из другого источника (Актер на языке CRDT). Пока предложение кажется твердым, и следующим шагом будет его реализация в коде и написание тестов. Подробнее об этом на следующей неделе.

Маршрутизация

План проекта

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

Некоторые функции API работают - Указание для запуска раздела и получения возраста и
уведомление о смене ключа во время перемещения - также было завершено на этой неделе. С их помощью узлы теперь будут больше информированы о статусе маршрутизации во время запуска и об использовании обновленной пары ключей.

Во время тестирования мы наблюдали проблему, когда во время начальной загрузки, когда за сообщением NodeApproval сразу следовало другое сообщение, скажем, Relocate, начальная загрузка завершалась * после * обработки NodeApproval. Это привело к тому, что любое последующее сообщение, такое как «Relocate», в буфере промежуточного канала никогда не было извлечено и обработано, т.е. мы теряли это сообщение. Мы объединили исправляющий PR Исправить потерянные сообщения во время начальной загрузки, чтобы решить эту проблему. Он удаляет промежуточный канал, заменяя его простой оболочкой для получателя ConnectionEvent. Таким образом, модель «тяни / толкай» превращается в простую модель «тяни». Таким образом, сообщение никогда не будет получено из канала, если оно не готово к его обработке.

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

Безопасное сетевое приложение и пользовательский интерфейс

Функция отслеживания / Экраны и потоки / Опытный образец

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

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

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

Выглядело это так:

Но можно ли сделать его более плавным? Не могли бы мы сделать это менее пугающим и помочь пользователю быстро установить и запустить Safe без какой-либо посторонней помощи, а затем заставить его подписаться на получение токенов Safe Network Tokens для загрузки.

Вот небольшой интерактивный прототип нового подхода - только счастливый путь - просто чтобы дать вам представление.

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

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

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

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


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

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