Safe Network новини 🇧🇬 7.1.2021

Накратко

  • Честита Нова Година! :fireworks:
  • Радваме се да съобщим, че работата по динамичното членство е завършена и днес публикувахме няколко контейнера на Византийско надеждно излъчване (BRB) в GitHub :tada:. Всички са свързани от централния brb контейнер.
  • Работихме усилено, дори през празниците, за да подобрим слоя за грешки и съобщения, включително създавайки нов контейнер „sn_messaging“.
  • Ние сме в процес на подготовка на някои незначителни корекции за нова CLI версия.
  • Също така сме близо до създаването на CLI и authd с musl, което означава съвместимост с по-голям набор от платформи.
  • Имаме нов инструмент за стрес тестване за маршрутизирането с PR в процес на проверка. Този нов инструмент е създаден, за да открие ограниченията на маршрутизацията по отношение на начина, по който се справя с промените в членството (разделяне) и вече ни показа някои проблеми.

Относно тестовата мрежа

Благодарим на всички, които отделиха време да изпробват тестовата мрежа пусната преди Коледа. След като целият екип на MaidSafe вече се върна на своите бюра продължаваме да работим по някои проблеми, които идентифицирахме преди пускането, и други, които вие открихте. След като се убедим, че тези проблеми са решени, ще пуснем нова версия, с намерението да стартираме публична тестова мрежа за всеки, който може, да се свърже.

Safe клиент, възли и qp2p

Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта

Работим за подобряване на историята ни за грешки в библиотеки ни и преминахме към използването на thiserror в node / data_types / client / transfer за осигуряване на по-добра верига за грешки и по-голяма капсулация на функционалността. По-рано използвахме много смесени грешки, изтегляйки много от sn_data_types в други библиотеки. Сега имаме специфични грешки във всяка библиотека, за тази библиотека, и разпространяваме грешки само от долните библиотеки като друга версия на грешките на текущата библиотека.

Заедно с всичко това извлякохме sn_messaging от sn_data_types в собствен контейнер, за да отделим слоя за коментари, както и грешките, които ще изпращаме към / от други възли и клиенти. Това е малка стъпка към по-ясно дефиниране на мрежовото „API“ за съобщения и грешки и осигурява по-чисто разделяне на грешките от вътрешните библиотеки към клиента.

Като част от тези усилия изследваме различни типове сериализация, като крайната цел е да има такъв, който е агностик на езика за програмиране. В момента се фокусираме върху проста JSON сериализация (за разлика от използвания в момента bincode), но също така си играем с Msgpack.

Ползата от всичко това е по-чист код и много по-ясни потоци от грешки във всички участващи библиотеки, което е страхотно.

В тандем премахнахме „предизвикателствата“ на клиента от първоначалното свързване на възела / клиента. По-рано те се използваха за проверка, че клиентът държи ключове, за да се предотвратят атаки за повторно възпроизвеждане на съобщения. Но с idempotency, идващ от типовете данни AT2 и CRDT, това ще бъде обработено там. Това води до още по-голямо опростяване както за клиента, така и за възела и допълнително изяснява мрежовите операции само като подписани съобщения.

Преди време, за да предотвратим атаки за продажба на ключове в мрежата, премахнахме всички API-та за показвване на SecretKey от sn_routing и ги съхранявахме само в техния контейнер. Установихме обаче, че има многобройни усложнения в дървото на зависимостите, причинени от това премахване, и затова решихме да върнем тези API-та, за да ни позволят да продължим бързо с тестовата мрежа по време на празниците. Решихме да се справим с този проблем веднага и започнахме да преструкторираме контейнерите „sn_transfers“ и „sn_node“, където държим и използваме тези SecretKeys извън „sn_routing“.

Обобщената работа по събиране на подписите, извършвана от sn_node по време на обмен на съобщения между KeySection и DataSection, вероятно се дублира с работата по натрупване на консенсус при маршрутизацията, тъй като и двете всъщност се извършват от по-старите възли. Проучваме и извършваме известна работа по преструктуриране, опитвайки се да премахнем тази част от контейнера sn_node и да се доверим на консенсусните съобщения от sn_routing.

И в последно работим за премахване на stream от потока от възлите. Това беше въведено за поддържане на комуникации с клиенти, но с последните промени на „qp2p“ можем да разчитаме на обединяване на връзките там, което ще ни свърши работа, и така премахваме много сложност от клиентската обработка на възела. Също така сме в процес на преструктуриране на qp2p примерите в отделни части, за да демонстрираме echo_service и системите за съобщения ясно и отчетливо. Правим пробни пускове с тези примери с ръчно пренасочване на портове към потенциално поддържани рутери, несъвместими с IGD в следващи тестови мрежи.

API и CLI

Фокусирани сме върху промените и подобренията от страна на мрежовата свързаност, но все още работим и за да се погрижим за някои дребни грешки, които са съобщени от общността при използването на тестовата мрежа и вече сме в процес на подготовка на някои незначителни поправки за нова версия CLI-то.

Също така се опитваме да изградим следващото издание на CLI и authd с musl, което, както знаем, ще ни позволи да стартираме тези приложения на много повече платформи, използвайки същите версии на CLI-то. Вече успяхме да ги изградим ръчно (благодарим много на @mav и @tfa за техните забележки и принос към това), така че сега се стремим да ги включим в нашия CI през следващите дни.

BRB: Византийско надеждно излъчване

Радваме се да съобщим, че работата по динамичното членство е завършена и днес публикувахме няколко контейнера на Византийско надеждно излъчване (BRB) в GitHub :tada:. Всички са свързани с централния brb контейнер.

BRB системата се състои от:

  1. Основният BRB протокол за излъчване за членове на кворум за копиране на данни по BFT начин.
  2. Протоколът за динамично членство за възли за динамично присъединяване и излизане от активен кворум.
  3. Опаковки от тип данни, които капсулират съвместими типове данни (напр. CRDT) за прехвърляне чрез BRB.
  4. Изчерпателни тестове за проверка на коректността.
  5. brb_node_qp2p: примерно CLI приложение / възел за ръчно извикване на BRB функционалност.

За тези, които се интересуват от задълбочаване в детайлите, слайдове са на разположение и предоставят допълнителна информация за системата и протоколите.

Маршрутизиране

План на проекта

Както всички знаем, преместването е добро за мрежата, като улеснява стареенето на възлите наред с други неща. Забелязахме обаче, че в някои ситуации прекаляваме с преместването. Например, премествахме се дори когато нямахме достатъчно старейшини поради преместване, а също и премествахме възли, когато те се присъединяват наскоро. За да разрешим проблема, зададохме някои критерии за избягване на преместването с цел поддържане на мрежата стабилна по време на определени сценарии.

Предприета е и промяна на API-то за подаване на информация от секция за конкретно име на участник. Това главно се използва в “sn_node” за бъдеща работа по преструктуриране.

Съставихме стрес тест за маршрутизацията (PR в процес на преглед). Това е малък инструмент, предназначен да открие границите на маршрутизацията по отношение на начина, по който се справя с промените в членството (разделяне). Той генерира произволно разделяне според конфигурируем график. След това периодично извежда различна полезна информация за мрежата и измерва състоянието на мрежата. Този инструмент ще бъде много полезен за предстоящата работа по интегриране на новото решение за динамично членство. Стартирайки го в текущата версия на маршрутизацията, той вече откри някои проблеми, които имаме около преместванията и разделянията, които ще разгледаме скоро. Това всъщност е добре, защото първата стъпка за отстраняване на проблем е да се знае за проблема :smile: Ето екранна снимка от предоставяните от инструмента данни:

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


  • Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България