Обновление Safe Network 🇷🇺 24 марта 2022 г

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

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

Но для того, чтобы это работало, необходимы тонкие механизмы обратной связи. Отдельные муравьи должны иметь возможность подать сигнал, что они находятся под давлением и больше не могут нести, иначе система станет хрупкой, и колония рухнет. @oetyng работает над системой очередей сообщений и обратного давления, которая позволяет узлам сказать: «Боже, отстань, а? Я доберусь до тебя вовремя, но у меня всего шесть ног, две челюсти и крошечный мозг». Код еще не завершен, но тесты уже показывают впечатляющие улучшения стабильности и производительности.

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

Команда MaidSafe разбирается с проектом британского законопроекта о безопасности в Интернете, который был опубликован на прошлой неделе, и с тем, как он может повлиять на нас как на бизнес, а также на Safe Network как проект. Наши опасения по поводу законопроекта, который всегда пытался регулировать Интернет вокруг Facebook, определенно не развеялись новым проектом; во всяком случае, они стали хуже. Поэтому мы работаем над тем, чтобы понять, какую позицию нам, возможно, придется занять, и какие обсуждения нам, возможно, потребуется провести, чтобы помочь правительству понять, что такие проекты, как наш, не являются Facebook, и к нам не следует относиться так, как мы. К счастью, наш менеджер по политике и управлению @Heather_Burns имеет дело с этим законопроектом более трех лет на своей предыдущей работе и понимает его как никто другой. В настоящее время она заперта в темном подвале с более чем 500 страницами юридического текста законопроекта и ящиком Irn Bru и скоро отчитается.

Прорабатывая потоки DBC, @danda и @davidrusu пришли к выводу, что монетный двор в том виде, в котором он был изначально указан, больше не нужен, потому что функциональность — проверка и подпись транзакций — теперь встроена в расходную книгу. Как заметили некоторые прозорливые члены сообщества (привет @happybeing!), это означает, что целые куски кода могут быть удалены, оставляя меньше работы как клиенту, так и старейшинам. Сейчас мы обсуждаем, следует ли сделать расходную книгу отдельным типом данных и, возможно, переименовать ее в «mint», чтобы соответствовать соглашению.

@Chriso изучает лицензирование кодовой базы, которая со временем стала несовместимой. Идея состоит в том, чтобы лицензировать базовую сеть под лицензией GPL3, а небезопасные сетевые ящики лицензировать под MIT/BDS, чтобы не ограничивать клиентские приложения, которые могут быть построены на ней.

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

Обратное давление и очередь сообщений

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

Таким образом, узлы теперь могут дать отпор и сказать: «Эй, я иду сюда, дайте мне передышку, отправьте мне только 10 сообщений в течение следующей секунды». Сеть будет активно следить за тем, что узлы говорят, что они способны делать в данный момент времени, и не будет заваливать их сообщениями, если они находятся в состоянии стресса. Это позволит им восстановиться, как только они закончат свою задачу.

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

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

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

Это еще не работает, но при тестировании изменения дали действительно впечатляющие результаты:

Хранение и чтение 5 МБ со многих клиентов с 50 клиентскими ридерами дало следующее на тестовой ветке:

Время: 30 с
ЦП: ~40 % (кратковременно выше 50 %)
Память: ~60 МБ/Старший (кратко до 125 МБ)

по сравнению с результатами на основном:

Время: 704 с
ЦП: 100%, постоянно
Память: ~2 Гб/Старейшина, все время

Все это означает более счастливых и здоровых муравьев. :ant:


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

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

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