Safe Network новини 🇧🇬 22.10.2020

Накратко

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

  • Вътрешните тестови мрежи продължават да ни помагат да провеждаме обстойни тестове и да откриваме проблеми.
  • Показателите на Dynamic StoreCost са почти установени след първоначалните ни експерименти.
    Някои основни PR-и за преструктурирането на Маршрутизирането тук и тук бяха обединени към основния код тази седмица, улеснявайки четенето и разбирането и следователно отстраняването на грешки, въвеждането на нови хора и участието им.*
  • Наемаме отново CRDT консултанта, който ще ни помогне с основната ни цел - създаване на мрежа без нужда от позволение съставена от автономни агенти, които съвместно съхраняват CRDT данни.

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

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

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

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

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

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

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

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

След това продължихме с обединяването на по-нататъшната работа по почистването, която премахва останалото състояние на машината в маршрутизацията. Това премахна състоянията за първоначално зареждане и присъединяване. Процесът на зареждане вече се случва в Routing::new, така че когато тази функция се върне, възелът вече е свързан към секция.

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

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

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

Тази седмица също прекарахме известно време, работейки върху отделен PoC за динамично членство в секция, използващ разпределено сигурно излъчване (от AT2 документа), за да осигурим византийска толерантност. Нашето bft-crdts внедряване вече поддържа постигане на консенсус за добавяне на партньор, така че задачата ни е да добавим поддръжка за премахване на членове. Член може да бъде отстранен доброволно или принудително, ако се установи, че е повреден. И двата случая изискват рунд от гласувания, за да се постигне консенсус, но последният е по-сложен, тъй като всеки партньор с право на глас също трябва да открие, че партньорът е дефектен. Имаме някои обнадеждаващи предварителни резултати, но това продължава да е работа, която очаква завършване.

Още новини…

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

Спряхме се на 3 промени, които трябва да направим в rust-crdt, за да постигнем тази цел:

  1. Всички причинно-следствени CRDT трябва да бъдат модифицирани, за да отхвърлят операциите, които са доставени извън „причинно-следствения“ ред, и да докладват обобщение на липсващите оперативни операции, необходими за прилагане на дадената операция.
  2. Премахване на вътрешното буфериране на неизправни операции в ORSWOT и Map.
  3. Въвеждане на причинно-следствена бариера, за да върне поведението на буферирането за потребители, които разчитат на автоматичното буфериране, извършено в ORSWOT и Map.

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

  1. Всички причинно-следствени CRDT, присъстващи в rust-crdt, ще бъдат втвърдени, за да отхвърлят неработещи операции.
  2. Всички причинно-следствени CRDT, присъстващи в rust-crdt, ще бъдат модифицирани, за да отговорят с обобщение на зависими операции, които липсват, преди да може да се приложи операция.
  3. ORSWOT и Map ще бъдат модифицирани, за да се премахне вътрешното буфериране.
  4. Ще се приложи CausalityBarrier, за да се добави обратно буфериране по избор.

Забележка - моля, уважете правото на лично пространство на консултанта и не спекулирайте с имена. :slightly_smiling_face:


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