Български (Bulgarian) 🇧🇬 Добре дошли в Safe Forum

SAFE Network новини - 28.5.2020

Накратко

Ето някои от основните неща тази седмица:

  • В момента разглеждаме премахването (или поне значително намаляване) на използването на Parsec в библиотеката за маршрутизиране.
  • Почти сме свършили с мигрирането на SAFE Клиентските библиотеки, за да преминем към функции на асинхронизация и да изложим неговото API също асинхронно.
  • Въведохме подход за поддръжка на символни връзки, което е почти същото като това, което прави git. Също адаптираме кода в safe-api, което извиква основното API на SAFE Клиентските библиотеки. След това трябва да можем да пуснем нова версия на SAFE CLI-то
  • Очакваният окончателен BLS-DKG PR вече е завършен и се преглежда, като контейнера се счита за готов за използване в мрежата, след като това бъде одобрено и добавено.

Проблеми с форума

Може би сте забелязали, че SAFE Network форума беше недостъпен вторник и началото на сряда тази седмица. Това се случи, защото регистрацията на името на домейна изтече и неговата регистрация беше в забранен акаунт на MaidSafe Фондацията, и съответно не бяхме директно сигнализирани, че се трябва да се поднови. В сряда сутринта (Обединеното кралство) домейнът беше прехвърлен в MaidSafe акаунт и подновен (с активирано автоматично обновяване).

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

Трезори – Фаза 2

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

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

SAFE API

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

Поддръжката за символни връзки идва

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

Този първоначален подход трябва да:

  • позволи относителни връзки вътре в дървото на директории, при качването им
  • конвертирате абсолютни връзки в относителни връзки вътре в дървото за качване.
  • конвертирате връзки извън дървото за качване в реални файлове.

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

Така след известно обмисляне прилагаме най-простата схема, която всъщност е почти същата като тази на git. В тази схема всички символни връзки се качват точно такива, каквито са, дори абсолютни пътища до други места във файловата система на потребителя и прекъснати връзки. Ако потребителят качва тези данни за архивни / резервни копия, тогава може да бъде много полезно тези символни връзки да бъдат възстановени правилно при изтегляне. В противен случай, ако потребителят качва файловете за уебсайт или друго обществено използване, тогава потребителят трябва да провери за прекъснати връзки.

За момента качването и извличането на символни връзки работи върху Unix платформи. Windows се държи малко по-различно, така че ще ни отнеме малко допълнителна работа през следващата седмица.

Под капака

Работихме и върху адаптирането на кода, който включва основното API на SAFE Клиентските библиотеки, тъй като той е мигриран, за да излага асинхронизиращи API-та. Стремим се да приключим тази седмица и да бъдем готови да пуснем нова версия на SAFE CLI-то, което носи няколко подобрения и нови функции, които да изпробвате.

Поправки

  • PR 562: коригира NRS способността на вложени подимена.
  • PR 558: files ls сега откриват NRS URL адреси правилно.

CRDT

През изминалата седмица работихме върху преструктуриране в SAFE Клиентските библиотеки, за да преминем най-накрая към функциите на асинхронизация и да изложим нейното API също като async. Това взе приоритет, тъй като е от съществено значение за правилното прилагане на CRDT от страна на клиента. Преструктурирането в SCL прави кода много по-опростен и е съобразен и с нашите нужди от добавяне на тези нови видове заявки за CRDT последователност.

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

Трансфери

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

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

Разширение на този проблем беше проверката на резултатите от отдалечена група копия (в по-горните слоеве, известни като отдалечена секция). Оказва се, че е и въпрос за членство, макар и не членство в копия / секции, а системно членство. Следователно това е и функционалност, осигурена от горния слой.

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

Функции в Rust

През последната седмица се наблюдаваше бурна дейност със събирането на нещата в асинхронизацията. Цялата SCL се компилира добре и вече CI тестовете преминават успешно.

Завършихме актуализациите на самокодирането, обединени в главната и нова версия на кода (от който зависят SAFE Клиентските библиотеки).

safe-api е актуализиран за новата версия на SCL. Това извади наяве някои други проблеми в кода, включително някои блокиращи поведения в await кода за съобщенията, но вече го коригирахме и преминаваме през някои заключителни тестове с API-тата, преди да включим всичко това в кода.

Това беше много работа, така че е чудесно да видим как завършва (и да се сбогуваме с около 2000 реда код!)

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

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

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

В момента разглеждаме друга голяма промяна за Маршрутизирането - премахването на Parsec.

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

Тогава какъв е проблемът с него? Производителността. Може да отнеме от порядъка на десетки секунди, за да се постигне консенсус за едно единствено наблюдение, което е скорост, която просто не се мащабира спрямо нашите нужди. Ето защо решихме преди време да спрем да го използваме за заявки за данни (които прехвърлихме към CRDT), но това не е достатъчно. Също така искаме да премахнем (или поне значително да намалим) използването му в самата маршрутизация. Това всъщност е възможно, без да жертваме нито една от целите, които сме си поставили за Маршрутизирането, защото се оказва, че Парсек прави доста повече, отколкото ни е необходимо. Например, всъщност не се нуждаем от пълен ред на наблюденията. Всичко, от което се нуждаем, е, че действията са съгласувани от кворума на Старейшините на секциите и те да са последователни. Така че върху това ще работим през следващите няколко седмици.

BLS - Разпределено генериране на ключове

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

Тази седмица се съсредоточихме върху въвеждането на всички оптимизации, които направихме от наблюдаването на симулациите и тестовете в реална мрежа към главния клон с PR 14. Този PR добавя транспортния слой (quic-p2p) и така завършва контейнера. Като генерален контейнер, той е насочена към потребители от всякакъв тип (Трезори и Клиенти), поради което интегрираният транспортен слой улеснява потребителите, тъй като те не трябва да се притесняват за обмен на съобщения и завършване на BLS сесията - както беше обсъдено в последното седмична актуализация, контейнера поема отговорността за това с помощта на таймери. Този PR в момента преминава през процеса на преглед и е близо до готовност за сливане, и следващата стъпка ще бъде да започнем интеграцията на BLS-DKG с другите части на SAFE Network, още една стъпка по-близо до нашата крайна цел!

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