SAFE Network новини - 21.5.2020
Накратко
Ето някои от основните неща тази седмица:
- quic-p2p v0.6.0, включващ IGD, беше пуснат днес.
- Новото, все още разработвано, safe-transfers хранилище вече е публично достъпно.
- Поддръжката за PUT / GET на празни директории е добавена към CLI-то.
- @jimcollinson представя актуализация за напредъка на UX на SAFE Network програмата.
- Прогресът на CRDT продължава - вече сме готови да започнем да добавяме действителната CRDT логика към клиента.
- Обединихме PR на модела за изтегляне в Маршрутизирането, като направихме актуализациите на секциите по-стабилни и ефективни.
Трезори – Фаза 2
През последната седмица се съсредоточихме основно върху прилагането на начина, по който Трезорите обработват данни, когато Възрастните се присъединят и напуснат мрежата. Това се оформя добре и около 80% от работата е завършена. Има само още няколко неща, които трябва да се разгледат и разбира се много тестове, преди промените да бъдат публикувани. Това ще се впише добре с най-новите промени в quic-p2p, които въвеждат пренасочване на портове с помощта на IGD. Нова версия на quic-p2p беше пусната днес с тези нови функции. Вече приключихме тестовете за интеграция с Маршрутизацията и Трезорите в последните няколко вътрешни тестови мрежи и очакваме следващите тестове, които ще включват и обработката на данните. Очакваме тест с общността, в който тези функции ще са включени, така че се навъртайте наоколо!
SAFE API
Поддръжката за празни директории беше добавена тази седмица, след отстраняване на някои проблеми с тестови случаи под Windows. Също така беше повдигната заявка за добавяне на скрити файлове (започващи с.) в PUT. Преди това те бяха изключени без възможност за добавяне.
Междувременно понастоящем локално се тества корекция за NRS пътища във files ls (издание 510).
И накрая, направихме малко преструктуриране в интерфейса на чужди функции (FFI), който представя FilesMap като основен тип данни, а не JSON низ.
SAFE Програма C#
Както бе споменато в секцията SAFE API по-горе, тази седмица преструктурирахме отново API-та на Files, за да върнем FilesMap инстанция вместо JSON низ. Това опростява използването на API-тата на Files, тъй като разработчиците могат директно да заявяват данните от FilesMap, вместо да преминават през JSON операции.
Успоредно с това постигнахме известен напредък в излагането на API-тата за удостоверяване, използвайки връзките от библиотеката safe-ffi. Остава ни да изложим още няколко API-та и да добавим няколко единични теста, за да гарантираме целостта им. След като това бъде завършено, приложението за удостоверяване може да бъде преструкторирано отново, за да използва API-тата от пакета, което означава, че няма да е необходимо да поддържаме връзките в две различни хранилища. Това също ще опрости развитието на SAFE Network програмата в бъдеще.
SAFE Network програма UX
Тази седмица имахме малко забавяне заради продължаващата пандемия и промяната в начина на работа на домашното училище, но въпреки това напредваме. Нищо заслепяващо, но работим по задачите за достъпност, свързани с дизайна, както и продължаваме през UI слоевете отгоре на всичко това.
Тук сме насочени към функционалността, така че макар да се стремим да добавим в UX-то малко „SAFE“ брандиране, това никога не трябва да е за сметка на използваемостта и функционалността.
Може да видите само някои фини и постепенни промени на екраните по-долу, като се стремим към нещо, което се надяваме да бъде много полезно и използвано. И разбира се да не забравяме цялата компонентност зад кулисите, която ще направи нещата по-лесни за подобряване и надграждане!
CRDT
През изминалата седмица продължихме с въвеждането на Sequence типа данни като CRDT. Както бе споменато преди, първите ни стъпки бяха за това всички основни библиотеки да поддържат този тип заявки. Сега добавихме същото към тестовия трезор за safe_client_libs, което ни помага да валидираме цялата логика от страна на клиента за всеки тип заявка.
В допълнение към това, мигрирахме NRSContainer и FilesContainers (в safe-api), за да започнем да използваме Sequence типа данни и успяхме да проверим дали всичко рабтестова мрежа.
Опитахме да стартираме тези E2E тестове и с локална Бейби Флеминг мрежа и сме на същия етап като при по-старите типове данни, което означава, че сега сме готови да започнем да добавяме действителната CRDT логика към клиента, така че проблемите със съдържанието, което не може да бъде намерено в някои несинхронизирани трезори са разрешени.
Трансфери
Следвайки последните няколко седмици проучвания на AT2, създадохме ново safe-transfers хранилище, върху, което все още работим да отчита основните свойства на AT2, приложени в настройките на SAFE Network.
Кратко описание
Имаме Актьори и Реплики, които да изпълняват различните стъпки на AT2 алгоритъма. Процес Актьор се управлява от клиент и той инициира прехвърляния от неговия ключ към друг ключ. Репликите се управляват от мрежовите възли - по-точно Старейшините на секция - за да валидират заявката и да използват няколко подписа, за да докажат съгласието си за нейната валидност.
Секция ще стартира един Актьор за управление на паричния балан на секцията и изплащането на фермерските награди, както и за получаване на плащания за качване на данни.
Следва
Сега работата ще продължи с тестване и гладене на подробности около обработката на ключовете на секциите за техния Актьор процес.
Връзки
Функции в Rust
Последната седмица се наблюдава по-интензивна работа по преобразуване на функциите. Изхвърлихме вътрешния цикъл на събитията, който създаваше проблеми без край. Това лесно може да бъде заменено в потребителската библиотека чрез по-специализирани времена на изпълнение. И сега имаме Safe_core компилиране (след като коригирахме някои основни проблеми в преобразуването на много нишки в self_encryption) и всички тестове също преминават.
safe_authenticator и safe_app също се компилират сега, като се извършва преобразуване на тестовите пакети и вече сме в началото на преобразуването на safe_authenticator_ffi.
Това беше голяма работа (много код за преглеждане), но с напредъка нещата изглеждат по-стегнати, по-изчистени и по-стройни от всякога!
Маршрутизиране
Тази седмица най-накрая публикувахме PR на модела за изтегляне, за който говорихме в предишните новини. След това подобрихме API-то, като добавихме метод за извличане на текущия набор от публични ключове на BLS и добавихме събитие, което се повдига всеки път, когато се променят старейшините на секциите. Това беше поредната заявка за функция от екипа на работещ по Трезорите. Последвахме това с малко преструктуриране, за да опростим допълнително кода и да премахнем ненужните битове.
След това започнахме да работим върху подобряването на начина, по който трезорите обработват съобщенията, чието доверие не могат да установят. Понастоящем това се обработва доста грубо - съобщението се връща обратно към подателя, който след това изчаква малко, преди да го изпрати отново, надявайки се, че трезорът е наваксал и вече е в състояние да обработи съобщението. Ако не, процесът се повтаря. Проблемът е, че по принцип е невъзможно да се определи колко дълго трябва да бъде “краткото време” - или е твърде малко и трезорът все още не може да обработи съобщението, или е твърде дълго, което забавя потока на съобщенията и вреди на работата. Това е всеобщ проблем винаги, когато въвеждаме време в нашата логика и затова обикновено се опитваме да не го използваме. С новият начин ще се отървем от забавянето и вместо това ще изпратим съобщението незабавно, добавяйки всяка допълнителна информация, която получателят трябва да може да го обработи.
BLS - Разпределено генериране на ключове
Миналата седмица приключихме с тестовия си спринт върху контейнера. Със събраната обратна връзка сега работим върху внедряването на някои промени в механизма, благодарение на които потребителят на DKG вече няма нужда да борави с конкретните особености. В настоящия си вид потребителят трябва да извика ръчно API-тата, за да отговори на съобщения и да задейства прехода към другите фази. Актуализираме ги така, че потребителят не трябва да прави нищо ръчно с тях.
Това доведе до използване на вътрешни таймери за DKG за завършване на сесия без никаква намеса на потребителя. По подразбиране потребителите / трезорите, които инициират DKG сесия, трябва да участват в шест DKG фази, между които всяка от съобщенията / отговорите ще бъде многокачествена. В щастливия случай, потребителят не би трябвало да се намесва в процеса, тъй като след като всичките шест кръга съобщения са направени, трезорите могат да завършат сесията самостоятелно без проблем. Докато при неуспешните сценарии (проблеми в реалния свят), шестте кръга на съобщенията може да не бъдат завършени (поради например напускането на трезори или загубата на съобщения) и биха изисквали от потребителя да се намеси в процеса, за да завърши сесията.
Таймерите се въвеждат за смекчаване на тази интервенция, където задаваме конкретно време, за да изчакаме да се обработят всички разменени съобщения. При забавяне DKG може автоматично да провери готовността на Генератора. Ако шестте фази не са завършени и Генераторът не е готов, механизмът ще се принуди да продължи сесията, като го накара да изпълни останалите фази, които могат да бъдат успешни, ако прагът е достигнат, или да се провалят, ако не е. Обърнете внимание, че тази стойност на изчакване трябва да бъде зададена въз основа на броя трезори в групата, тъй като времето, необходимо за завършване на кръговете за съобщения, ще се увеличи, ако има по-голям брой трезори в сесията.
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: SAFEnetwork България | Facebook
- Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България