Safe Network новини 🇧🇬 15.10.2020

Накратко

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

  • Започнахме да изпълняваме множество вътрешни тестови мрежи, които обединяват всички различни компоненти на мрежата. Това ни помага да проследим проблемите и да ги разрешим.
  • Работата по Authd, CLI и API продължава, за да ги приведат в съответствие с последните промени на клиента и възела.
  • Експериментираме с показателите на динамична стойност за StoreCost, за да направим разходите за запис на данни в мрежата зависими от множество фактори.
  • Насочваме се към нова употреба на CRDT във Византийска обстановка за мрежа без нужда от позволение - прочетете раздела за маршрутизиране за повече подробности за това вълнуващо развитие!

Safe Клиент, Възли и qp2p

Safe Network Трансфери План на проекта
Safe Клиент План на проекта
Safe Network Възли План на проекта

Преструктурирането на authd, CLI-то и API-то продължава. Вече имаме основната комуникация, работеща между authd и CLI, като случайните ключове се генерират и предават между тях. Следващата стъпка тук е възстановяването на основното хранилище за удостоверяване с помощта на стандартните ни API-та (по-рано имахме куп специфични API-та, които добавиха много сложност към кода). Така че сега работим за това, което също засяга използването на API-то от различни типове ключове и го прави по-общо (така че можем да използваме например ed25519 или BLS ключове).

От страна на интеграцията, добавяме още корекции към sn_client и sn_node, продължавайки работата от миналата седмица. С по-стабилното стартиране на Секция с всички актуализации на маршрутизацията, успяхме да обединим всички модули и за да работят като едно цяло. По време на това вътрешно тестване беше разкрита малка грешка в sn_transfers на Actor, която при оправянето й ще замени агрегатора, който въведохме миналата седмица като част от трансферите на AT2. Друга голяма промяна, която предстои, е в преминаването от статични разходи за запис към динамична StoreCost стойност. Това означава, че разходите за запис на данни в мрежата вече ще бъдат динамични, което отчита множество фактори като предлагане / търсене на съхранение в мрежата, брой байтове, които трябва да бъдат записани и т.н. Клиентите ще пускат запитване към мрежата за тази сума преди да изпратят част от данните към нея, ще проверяват за достатъчен баланс и ще заплащат за качването. Експериментираме около показателите, за да започнем с разумна цена за качване в тестовата мрежа.

„qp2p“ също получи своя дял от любовта ни тази седмица. Промените в асинхронното UPnP API са интегрирани в routing и sn_node. Това ни помогна да идентифицираме грешка в UPnP / ехо услугата, която не работеше според очакванията. Двете се правеха последователно, вместо паралелно и тъй като UPnP винаги се проваляше в рутери, които не поддържат UPnP, цялото стартиране винаги се проваляше. Имаме решение за това. Както бе споменато по-горе, започнахме с някои вътрешни тестови мрежи, които включват всички промени тази седмица. Това ни помага да приведем всички модули в действие и да поправим грешките, които биха могли да бъдат пропуснати в тестовете на отделни модули / интеграция. Ако нещата вървят добре (трудно за предвиждане!) ще пуснем тестова мрежа, в която да се включите скоро. :slightly_smiling_face:

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

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

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

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

Що се отнася до CRDT, се насочваме към нова употреба на CRDT Византийска обстановка за мрежа без нужда от позволение. Това означава стриктното използване и конкретните определения на Авторитети. За нас това са Възел, Клиент, Секция и Мрежа. За да осигурим неопровержимост и предотвратяване на измами, ние ще подпишем цифрово Точка <Актьор, u64> и самата Операция (Добавяне (актьор)). Това ни позволява да се сближаваме в периоди на безумно висок отбив (напускане на трезори), което е нещо, което се надяваме никога да не се случи, но може.

Също така въведохме метод, подобен на AT2, който се нарича DSB (Детерминистично защитено излъчване) и който може да ни позволи да направим нещо съвсем различно от сега и Възрастният да управлява този DSB, за да получи мнозинство, за да се присъедини към CRDT на Старейшините. Това намалява много работата за маршрутизацията. Освен това можем да видим, че мнозинството се е съгласило за нов набор от Старейшини (Реплики) и е започнало DKG рунд, за да актуализира SectionChain.

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

Всичко на всичко това е изключително вълнуващото и трябва да ни даде невероятно солиден слой за маршрутизация.

Подмножество от горното означава, че всички данни могат да бъдат BFT, както и да се приложи NetworkAuthority, за да се позволи повторното им публикуване (потребителят ще плати на мрежовия орган).


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