Накратко
- Добавен е нов набор от инфраструктурни съобщения, които
sn_routingможе да използва за по-добра обработка и връщане на грешки по време на разделянето на секциите. - Работата по обработката на невалидни SignatureShares от лоши актьори при трансфери започна, като сега изготвяме санкциите за тези лоши актьори.
- Работата по обмена на съобщения е към своя завършек, което означава значително по-малко код и сложност за анализ на входящите съобщения в
sn_nodeи разчистване на пътя за интегриране на възнагражденията. - Пуснати са нови версии на CLI-то (v0.19.0) и
authd(v0.1.1), което ги прави съвместими с най-новияsn_node(v0.26.16), както и няколко други подобрения. - Първата примерна програма вече е налична в
sn_apiхранилището, демонстрираща как да качите файл в мрежата и след това да го достъпите, използвайки нейния XOR-URL адрес. - Направихме стъпки към интегриране на
sn_fsиBRB, за да създадем P2P византийско-толерантен прототип на разпределена файлова система. - Модификациите на секционните вериги в
sn_routingза справяне с форкове вече са на място, като тестовете ни показват голямо подобрение на стабилността на мрежата, особено при разделянията. - Още фантастични приноси на общността към кодовата база
Състояние на тестовата мрежа - отложена
Както беше обсъдено миналата седмица, решихме да насочим всичките си усилия, за да включим възнагражденията в следващата тестова мрежа. Възнагражденията в момента да блокирани от свързана работа за коригиране на потоците съобщения, след като превключвихме към натрупване на съобщения само в sn_routing. Вярваме, че сме в последния етап от работата по потока от съобщения, като смятаме, че ни остават някои финални неща за дооправяне (повече подробности по-долу). След като приключим, това освобождава пътя за пълното интегриране на възнагражденията да продължи.
Както при всеки новаторски напредък и ние очакваме, че ще имаме проблеми, открити по време на етапите на интеграция и тестване, така че не искаме да даваме времеви график, който да оказва допълнителен натиск върху екипа. Както винаги, ще ви държим в течение с точен напредък в седмичните новини.
Благодарим ви за търпението!
Safe клиент, възли и qp2p
Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта
“Мързеливи” съобщения
За да се справим по-добре с проблемите при разделянето на секции, както и по време на отпадането на възли, добавихме нов набор от съобщения за инфраструктурата, които sn_routing може да използва за връщане на грешки като DKGINprocess, когато се опитваме да изпращаме съобщения на старейшини в такива ситуации. За да направят това, клиентите / възлите ще предоставят текущия PublicKey за секцията, доколкото той им е известно, и ще можем да предприемем действия, ако това е, например, неактуално. Тези промени са добавени в sn_messaging, sn_client и sn_routing и разглеждаме някои малки преструктурирания, за да опростим нещата с възлите.
Заедно с всичко това допълнително затвърждаваме обработката от клиентите на такива промени в инфраструктурата, така че промяната в процеса на работа ще позволи на клиентите да се включват повторно колкото пъти е необходимо. Наред с това, също смазваме грешки, които възникват с преструктурирането на натрупването на съобщения, направени през предходните седмици.
Наказване на лоши актьори
Работата с невалидни споделяния на подписи от лоши участници в трансферите също е в процес на разработка. Досега ние одобрявахме прехвърляне, когато дяла от валидни гласове достигне „праг + 1“ успешно, игнорирайки всички невалидни гласове, които не са необходими за това обобщаване. Сега ще въведем наказателни механизми в мрежата, за да накажем съответно възлите след проверка. Започваме преструктурирането с sn_transfers, тъй като там се случват натрупванията за преводи на плащания и ще продължим с работа нагоре през слоевете.
Поток на съобщенията
Докато преминавахме към натрупване на съобщения само в sn_routing, трябваше да премахнем уникалната информация от съобщенията, така че Старейшините да подписват едно и също съобщение.
С това моделът на първоизточника и дестинацията трябваше да бъде променен и това го направи по-опростен, като намали интерфейса за съобщенията между sn_node и sn_routing и използвахме същите примитиви над границата.
Тъй като първоначалното свързване на клиентите сега се извършва в слоя sn_routing, тези примитиви на местоположението трябваше да бъдат разширени с клиентски вариант. В sn_routing беше внедрен регистър на свързани клиенти, заедно с предоставяне на публичен ключ и подпис върху адрес на сокет при първоначалното свързване на клиента. Сега има значително по-малко код и сложност за анализ на входящите съобщения в sn_node. Досега са премахнати общо около 1000 реда.
API и CLI
Новите версии на CLI (v0.19.0) и authd (v0.1.1) бяха пуснати тази седмица, което включва всички корекции, подобрения и нови функции, внедрени от предишната версия. Както обикновено, те могат да бъдат надстроени съответно с $ safe update и $ safe auth update. Тези приложения са съвместими с най-новата версия sn_node v0.26.16, така че за тези, които надграждат, също така не забравяйте да надстроите и sn_node програмата ($ safe node install или $ safe node update).
@scorch забеляза, че най-новата версия на clippy оплаква под Windows за CLI и authd codebase, и представи поправка за него. Това ни накара да подобрим clippy проверките в нашите CI скриптове, за да се изпълняват не само под Linux, но и под Windows, което трябва да предотврати повторното му подхлъзване.
С добавянето (от @mav) на ново API в CRDT Sequence типовете данни за извличане на запис, посочващ единичен индекс, а не диапазон, @mav сега промени нашия sn_api, за да се използва това ново API за извличане на определена версия на Sequence.
Няколко подобрения бяха направени и в този нов CLI (v0.19.0), който позволява на потребителя да настрои информацията за първоначално зареждане на мрежата чрез IP (v4 или v6) и номер на порт, за повече подробности за тази нова команда, моля, вижте в съответния раздел в Ръководството за потребителя на CLI.
За тези, които са любопитни да видят как се развива Rust API-то и как ще се изграждат приложения с него, вижте първата примерна програма вече налична в sn_api хранилището, което демонстрира как да качите файл в мрежата и след това да го изтеглите, използвайки неговия XOR-URL адрес. Надяваме се, че това ще вдъхнови други да създадат прости примерни програми за нашето Rust Safe API, да открият възможности за подобрения, когато започнем да ги използваме, както и да бъде добър ресурс за нови разработчици, желаещи да пишат Safe програми.
CRDT
Дейвид Русу, автор на rust-crdt, както и на нашата реализация на „BRB“, преглежда „LSeq“ кода, след като @mav съобщи за проблеми с него когато се изпълняват много въвеждания. Той замени внедряването на ID, базирано на оригиналната LSeq разработка, с рационално число от num хранилището. Това прави LSeq кода много по-опростен и също така води до по-добро (по-равномерно) разпределение, разрешавайки проблема и позволявайки вмъкване на произволен брой елементи. „LSeq“ също е преименуван на List. Искане за изтегляне.
BRB: Византийско надеждно излъчване
Помните ли sn_fs, нашият прототип на файлова система, използваща дървесния CRDT? Е, тази седмица правихме стъпки към интегриране на sn_fs и BRB, за да създадем прототип на P2P разпределена файлова система, устойчива на византийски атаки, .
Първо отделихме brb_node_qp2p и създадохме brb_node_tree, което демонстрира изпращане на операции crdt_tree чрез brb. След това модифицирахме контейнера sn_fs и го превърнахме в библиотека. Съвсем наскоро създадохме brb_node_snfs контейнер, в който обединяваме всичко. Към днешна дата успяхме да свържем два (или повече) възела и да извършваме операции с директории като mkdir,rmdir. Операциите се отразяват в монтираната файлова система на всеки партньор. Операциите с файлове все още не работят, но трябва да са готови скоро.
Трябва да се подчертае, че това е доказателство за концепцията. Има много подробности, които трябва да бъдат разработени, преди да може да бъде използвана реално.
Маршрутизиране
Модификациите на веригата на секциите с цел разрешаване на форкове, както беше обсъдено в новините от миналата седмица, са вече на място. В момента провеждаме вътрешни тестове, използвайки инструмента за стрес тест, за да идентифицираме всички останали проблеми. Изглежда стабилността на мрежата се е подобрила доста, особено при разделянията. Някои проблеми все още остават и сме заети да ги отстраняваме, но като цяло сме оптимисти за този подход.
Също така обединихме PR, за да коригираме експлозия на съобщения, това се случва, когато старейшина излезе офлайн, но останалите старейшини все пак ще се опитат да му изпратят Офлайн гласуване, което, разбира се, няма да бъде доставено и така ще предизвика допълнителни Офлайн гласове.
Обединихме друг PR, за да отговорим с грешка на клиентска заявка, ако има текущ DKG. Продължаващото DKG (разпределено разпределение на ключове) означава, че секцията е на път да премине към нов набор от старейшини и така нещата може да не са напълно стабилни или последователни в този момент, затова е по-добре да уведомим клиента, за да изчака и да опита отново малко по-късно.
[ДОПЪЛНЕНИЕ от 22 февруари] - Safe браузър
Нещо, което първоначално забравихме да добавим към тези новини 
@bzee създаде PR, за да ускори sn_nodejs с най-новите промени в API-то, който е необходим за обновяване на Safe браузъра, за да бъде съвместим с останалата част от Safe мрежата отново. Той също така разглежда ограниченията на текущата библиотека и вижда възможности за подобряване на нещата!.
Благодарим ти @bzee! 
и извинения за това, че първоначално пропуснахме твоя принос.
Преводи:
Английски; 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България