SAFE Network новини 🇧🇬 30.7.2020

Накратко

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

  • Работим върху автоматизиран процес, който създава трезори, присъединяващи се към вътрешна тест-мрежа, съхраняваща данни и подреждаща трезорите. Това ще ни позволи да увеличим мащаба на тестовете на секциите.
  • Финализирахме първата версия (PR #186 ) поддържаща съвместни промени на Политиката за промени на Последователни (Sequence) елементи и вече може да започнем да правим промени в библиотеките на трезорите и клиентите, за да се адаптират към някои незначителни промени, които направихме към типовете заявки за Последователност.
  • Члена на общността @happybeing проучва опциите за файлова система FUSE в Rust и стартира проектодокумент предлагащ safe-fs API. Дискусията продължава тук.
  • Въведохме завършен процес за непрекъснато обновяване в нашия safe-nd Rust контейнер.

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

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

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

Идентифицирахме два компонента с голямо използване на памет. Един от тях е PARSEC. Вече сме наясно с това и както вие ще сте наясно, неговото премахване и подмяна вече е в ход. Другият компонент със сравнително високо използване на паметта беше quic-p2p. Гмурнахме се в контейнера и установихме, че изпращаме копие от всички съобщения обратно на потребителя на quic-p2p. Това е полезно, когато изпращането на съобщение се провали, но при успешното изпращане не е необходимо да изпращаме обратно копие от него. Премахването на това намали значително използването на паметта.

Ще продължим да работим върху такива корекции и подобрения и ще продължим с тест-мрежите, за да идентифицираме проблеми в мрежата и нейната ефективност. Засега обаче ще правим тези тест-мрежи сами. Работим върху тестова настройка, която създава трезори, присъединява ги към мрежата, съхранява данни и прекъсва също. Това ще ни позволи да увеличим мащаба на нашите тестове и да откриваме слабости възможно най-бързо. Това ще бъде напълно автоматизирано, така че не предвиждаме да се налага пускането на публични тестове д общността в краткосрочен план. Предполагаме, че следващият тест на общността, който ще създадем, ще бъде пълен с новите деца в квартала, т.е. CRDT, AT2 и фермерството, или поне подгрупа от тези неща.

SAFE Браузър / SAFE Удостоверител (мобилни устройства)

Браузер План на проекта
Удостоверител План на проекта

Преструктурирахме приложението за удостоверяване, за да използваме повторно API-тата за удостоверяване от пакета NuGet и да изоставим собствената му реализация чрез FFI обвивката. Тази стъпка премахна много излишни редове код, тестове и изчисти настройката на C /CD.

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

SAFE API

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

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

CRDT

Финализирахме първата версия (PR #186 ) поддържаща съвместни промени на Политиката за промени на Последователни (Sequence) елементи. Този първи подход позволява създаването на различни клонове на последователността за всяка нова политика, която е зададена, напр. ако клиентът работи офлайн, прави промени на данни, без да е наясно, че нова политика е зададена към съдържанието, когато клиентът се върне онлайн и изпрати такива операции в мрежата, те все още ще се прилагат, но в нов клон на Последователността. При извличане на елементите от последователност, елементите, съответстващи на “главния” клон, ще бъдат прочетени по подразбиране, но в крайна сметка можем да позволим на клиентите (чрез различен тип API/заявка) също да извлекат елементи от всеки от другите клонове, които може да се формират от всяка предишна политика.

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

Сега ще започнем да правим промените в библиотеките на safe-vault и клиента, за да се адаптират към някои малки промени, които направихме към типовете заявки за последователност. Например, една от тези промени беше сливането на собствеността и разрешенията, за да бъдат изцяло част от Политиката, а не да бъдат отделни атрибути на последователност. Промяната на собствеността или настройването на разрешения за други ключове вече се извършва чрез просто задаване на нова политика за последователността. Така или иначе ще работим върху разкриването на API-тата, които позволяват на потребителите да имат по-голяма гъвкавост и подробност за промяна на собствеността и задаване на разрешения на последователност.

tree-crdt

Работата ни продължава по описания през миналата седмица експериментален код на tree-crdt. Внесохме предложената оптимизация на изпълнението от crdt-tree документа, както и индекс за бързо търсене на “децата” на възел. Добавихме lamport + актьор времеви маркери, което означава, че този код вече може да работи правилно, когато е използван от отделни процеси (без споделяне на общ часовник). Също отстранихме проблем с дублиращи се операции, влизащи в дневника, ако те имат един и същи времеви маркер, плюс добавихме няколко тестови случая.

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

В сътрудничество, членът на общността @happybeing проучва опциите на файловата система FUSE в Rust и стартира проектодокумент, предлагащ safe-fs API. Дискусията продължава тук.

Transfers

SAFE Трансфери План на проекта
SAFE Фермерство План на проекта
SAFE Клиентски библиотеки План на проекта
SAFE Трезор План на проекта

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

Ние работим интензивно, за да потвърдим, че няма регресия след интегрирането на трансфери, фермерството и произтичащото преструктуриране на съобщенията/модулите на safe-vault, с цел бързо преминаване на това към работещ клон. Започна работа за актуализиране на SCL, за да е съвместим с тези нови фермерски трезори, тъй като бяха направени множество структурни подобрения на модулите на трезорите и мрежовите съобщения.

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

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

От миналата седмица се съсредоточихме върху някои задачи за преструктуриране на функции, за да се подготвим за премахване на PARSEC. Те включват разрешаването на проблем с подобряване на натрупването на подписи на съобщения, за да не се изисква PARSEC (което се оправя главно от PR-а за Маршрутизацията, който уведомява изоставащите старейшини и PR за подпис-агрегатор за избягване смесването на различни подписани public_key) и продължаваща работа по проблем, за промяна на изпращането и получаването на NeighbourInfo, за да не се изисква натрупване (обхванато от PR за маршрутизацията за премахване на SendNeighbourInfo гласове). В нашия списък със задачи не са останали много задачи за преструктуриране на функции, така че официалната работа по премахването на PARSEC се очаква да започне скоро.

Една друга добра новина тази седмица е, че благодарение на току-що пуснатия 0.4.0 prag_crypto, вече няма нужда да се поддържат различни версии на контейнера. Обединеният PR актуализиране на зависимостите и преструктурирания код, за да се опрости използването на rand хранилища премахна още една ненужна сложност.

Непрекъсната доставка

От известно време сме готови да разрешим непрекъснатата доставка (continuous delivery - CD). SAFE Браузърът има автоматизирани издания, но се борихме с GitHub Actions с цел автоматизиране на разпращането на версиите, актуализации на файла с промените, тагове и издания.

През последната седмица взехме наученото от SAFE браузъра и го приложихме към една от нашите Rust библиотеки, с цел CD да отиде там. Това ни забави и ни донесе забавен масив от проблеми, с които да се борим (не можеш да автоматизираш натискането на защитени клонове в GitHub, не можеш да прегледаш собствената си заявка за изтегляне, не можеш лесно да получиш съобщението за ангажиране на PR). Но, ние преодоляхме всичко това и най-сетне имаме ново действие за нашите Rust хранилища за автоматизиране на разпращането на нови версии и генериране на файлове с промените (от конвенционални команди. Това автоматично генерира PR за разпращане на версията и след това имаме друго действие, което обединява това. Което след това (за пореден път в master) ще маркира новата версия и ще стартира версии за нас. Всичко това автоматично :mage:

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


  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/