Накратко
- Работата по sn_node и sn_client продължава, за да се приведат в съответствие с най-новите sn_data_types, като CI вече напълно преминава в sn_node.
- Маршрутизацията вече е актуализирана да подава сигнал, когато в мрежата трябва да бъде приет нов възел, работим по sn_node, за да се възползваме от това.
- Работата по маршрутизирането за подобряване на откриването на загубени възли беше одобрена и обединена тази седмица.
- Промените в лексикона на Safe мрежата, обсъдени преди 2 седмици започнаха да се добавят към UX дизайните. Може да видите предварителен поглед по-долу!
Safe клиент, възли и qp2p
Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта
След като миналата седмица добавихме Sequence CRDT операции за подписване, тази седмица интегрирахме това в купчината, с някои промени в sn_node тук и sn_client тук и тук, за да получите всички операции, подписани преди да бъдат предадени в мрежата. Това извади наяве някои други проблеми по отношение на локалното кеширане на последователности (кога да се използва локален кеш и кога да се използва мрежата и т.н.). Засега сме решили да премахнем този кеш чрез този PR за простота. Това помогна за укрепване на тестовия пакет, като ни позволи да видим по-ясно някои потоци от тип CRDT в действие, например, изпращането на промени не се изтегля веднага от мрежата, така че трябва да изчакаме очаквани промени там.
С въвеждане на горните промени също отстраняваме някои нови проблеми със стартирането на секции, които бяха повдигнати от тях, с добавяне на някои малки клиентски подобрения тук, за да се предотврати неуспех, ако Старейшина не е наличен (но все още има достатъчно други). С въвеждането на това сега можем да видим подмножество от sn_client тестове да преминават срещу единадесет членове на секцията на CI.
Останалите неуспехи, които наблюдаваме, се дължат най-вече на няколко скрити грешки при избора на дестинации и извличането на парчета данни от копията в блоб данните, които активирахме миналата седмица. Бъдете сигурни, че работим по поправки за тях и отмятаме последния от неуспешните тестове от тестовия пакет на клиента e2e. Търсенето на тези грешки също подчерта, че някои елементи на съобщенията все още липсват и сега се изискват за да приближат контролния поток / обработката на грешки с една стъпка по-близо до това, което наричаме „мързеливи съобщения“. Работи се по това.
Мързеливите съобщения са мястото, където получаваме съобщение, което не можем да обработим по каквато и да е причина (несинхронизирано, бъдещ пореден номер и т.н.) и връщаме с грешка това съобщение обратно на подателя с последната ни известна история. Тогава подателят знае, че трябва да ни предостави липсващата връзка (можем да направим и обратното (без грешка) и да подадем сигнал на изпращача, че той е изостанал, а не избързал). Това ни спестява задържането на съобщения, докато се подредят, защото това може да бъде използвано за атака на мрежата и би изисквало по-сложен код. Мързеливите съобщения са много по-близо до модела на актьора, който предава съобщения, и го разширихме, за да обработва частично подредени събития.
С промяната в динамиката на присъединяване на нов възел в маршрутизацията, вижте PR # 2234, започнахме също така да актуализираме и sn_node, така че възлите да поемат отговорност за позволението на нови възли да се присъединят към мрежата. На практика старейшините на мрежата вече ще следят предлагането / търсенето на ресурси в своя раздел и съответно ще заявяват от маршрутизирането, позволение за добавяне на нови възли към тяхната секция, които са на опашка.
Също така започнахме да подготвяме authd и CLI за адаптиране към новата UI / UX терминология, например преминахме от “Акаунти” към “Сейфове”, както и да правим необходимите промени, за да може authd да съхранява ‘ключовите двойки’ на програмите в мрежата, използвайки Map като тип данни за съхранение за “Сейфа”. Ще продължим с тази задача, за да приведем всички CLI команди и функции за удостоверяване в съответствие с тези нови терминологии, както и с новия API на sn_client.
След като приключим с горните актуализации, поправки и всякакви грешки, които изкочат, ще бъдем готови да запалим нашите вътрешни тестови мрежи отново с пълна газ, да подредим различните модули, да проверим отново стабилността им, да завържем свободните краища и да се надяваме да доставим ранен коледен подарък на всички вас! 
BRB - Византийско надеждно излъчване
Тази седмица нашият консултант усъвършенства идеята за Часовник за генериране, спомената миналата седмица, и представи алгоритъм за псевдокод на екипа за коментар. Този хибриден подход налага пълен ред за редки операции за присъединяване и напускане, но само частичен ред за много по-чести операции с данни. На обикновен език това означава, че присъединяването/напускането трябва да бъде ограничено (т.е. не можем да позволим да съществуват неотговарящи възли) и да се използва форма на пълен ред, но можем да обработваме много листа наведнъж и т.н., докато могат да се появят редовни операции с данни с високи нива на съвпадение, стига всяко да е от различен източник (Актьор на CRDT език). Засега предложението изглежда солидно и следващата стъпка е да го внедрим в код и да напишем някои тестове. Повече за това следващата седмица.
Маршрутизиране
Както беше обсъдено предишните седмици, работата за подобряване на откриването на загубени възли беше одобрена и обединена тази седмица. Това се възползва от функцията за обединяване на връзки в qp2p. Тази промяна означава, че основата на кода за маршрутизация е опростена и сега позволява да се добавят по-сложни интеграционни тестове, за да се проверят характеристиките на готовия код.
Някои API функции работят - Индикация за стартиране на секция и увеличаването на възрастта и
уведомяване, когато ключът е променен по време на преместването - също завърши тази седмица. С тях на място, възлите вече ще бъдат по-информирани за състоянието на маршрута по време на стартиране и използваните актуализирани двойки ключове.
По време на тестването забелязахме проблем, при който по време на първоначалното стартиране, когато съобщението NodeApproval е последвано незабавно от друго съобщение, например Relocate, стартирането завършва след обработката на NodeApproval. Това оставя всяко следващо съобщение, като Преместване, в буфера на междинния канал и никога няма да бъде извадено и обработено, т.е. загубвахме това съобщение. Обединихме поправящ го PR Отстраняване на загубени съобщения по време на първоначално стартиране, за да разрешим този проблем. Той премахва междинния канал, заменяйки го с обикновена обвивка около приемника ConnectionEvent. По този начин моделът “push/ pull” се променя в обикновен модел “pull”. По този начин съобщението никога не се извлича от канала, ако не е готово да се обработи.
Работата за разрешаване на възлите да подават сигнал към маршрутизацията дали приемат нови възли или не, спомената в новините от миналата седмица, също беше завършена и обединена. Маршрутизацията разчита на възлите Старейшини да проследяват всички възрастни възли в секцията и когато открият, че средният капацитет за съхранение (или друг ресурс) стане твърде нисък, те ще изпратят сигнал, така че секцията да започне да приема нови възли. Всички Старейшини трябва да открият това горе-долу по едно и също време, за да може да се постигне консенсус. В допълнение към сигнала, ако секцията вече има бебешори, един от тях ще бъде повишен с увеличаване на възрастта му с едно, което ефективно ще го накара да се премести и веднага да се присъедини отново като възрастен.
Safe Network програма и UX
Проследяване на функции / Екрани и потоци / Включен прототип
Благодарим за всички ваши отзиви за предложените промени в лексикона на Safe. Започнахме да добавяме тези промени в UX потоците и прототипите на Safe Network програмата и ще ги видите да се появяват в различните файлове на Figma, докато работим върху тях.
Макар да не е пряко свързан с езиковите промени, един интересен малък страничен проект, който излезе от тази работа, беше преразглеждането на някои от включените потоци, например, когато потребителят е готов да създаде свой собствен Сейф.
Ако си спомняте, досегашната версия излагаше всички опции, които потребителят имаше за създаване на Сейф (или акаунт, както беше до сега), и му позволяваше да избере подходящ маршрут, с инструкции стъпка по стъпка.
Изглеждаше така:
Но можем ли да направим процеса по-гладък? Можем ли да го направим по-малко плашещ и да помогнем на потребителя бързо да стартира своя Safe, без никаква външна помощ, и след това да го накараме да следва печеленето на Safe Network Tokens за стартиране.
Ето малък прототип на новия подход - само с една опция напред - колкото да ви даде представа за процеса:
Това няма да е единствения път за получаване на Сейф, ще има други алтернативни потоци с по-малко помощ, но за първоначални потребители ще бъде интересно да сравним това със съществуващия подход.
Това също така е модел, който може да се приложи към други области на програмата - като например спечелване на пари за първи път, създаване на SafeID или избор на сигурни идентификационни данни.
Това ни създава малко повече работа от гледна точка на дизайна и логиката на потока, но ако е по-гладко и по-малко смущаващо за потребителя и доведе до повече сейфове и възли в мрежата си струва допълнителния труд.
Преводи:
Английски; 
Руски; 
Немски; 
Испански; 
Френски;
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България