Safe Network новини - 4.2.2021
Накратко
- Днешното така очаквано пускане на тестова мрежа трябва да бъде отложено, тъй като не успяхме да въведем получаването на награди навреме, а да го деактивираме от наличния код не помогна.
- Възможността да видим разделянето на секции в мрежата през последните дни, с въвеждането на последните подобрения, ни позволи да намерим и смачкаме някои неизвестни досега многосекционни проблеми.
- Работата за опростяване на
qp2pAPI-то за вътрешно управление на връзките и потоците, и отнемането на част от натиска от потребителското API вече преминава през допълнителна проверка. - Повдигнат е BRB PR за отстраняване на случайни загуби на пакети, които пречат на BRB операциите, тестван е и се очаква да бъде обединен скоро.
- Специални благодарности на членовете на общността @bzee, @mav и @scorch за усилията им през последната седмица и за обединяването на множество техни PR-и.
Състояние на тестовата мрежа - отложена
Нашата цел в началото на седмицата беше да активираме наградите в публичната тестова мрежа и да я отворим за общността днес, но все още има няколко необходими промени, за да я стартираме, и не успяхме да ги завършим днес.
Поради това премахнахме потока от награди, за да видим дали ще можем да получим достатъчно стабилна мрежа и постигнахме известен напредък с това, но някои проблеми по пътя ни забавиха.
В момента имаме най-новата версия на тестова мрежа работеща при нас, но времето не ни стигна за да я тестваме обстойно. Очакваме още незначителни проблеми, така че бихме искали известно време да я тестваме при нас, преди да я представим публично.
Тепърва ще обсъждаме подробно и ще решим дали ще пуснем тестовата мрежа с изключени награди или проблемите, с които се сблъскваме, означават, че ще е по-добре да продължим с напълно функционални награди, което очакваме да отнеме още няколко дни (плюс тестване). Стабилността на тестовата мрежа, която имаме сега, с изключени награди, трябва да ни помогне да решим, но така или иначе не предвиждаме да пуснем тестова мрежа този петък, защото предпочитаме да изчакаме до следващата седмица, за да имаме възможност да предоставим техническа поддръжка за общността.
По-голямата част от времето ни тази седмица беше фокусирано върху тестовата мрежа, но ето обобщение на някои от другите неща, върху които работихме…
Safe клиент, възли и qp2p
Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта
За начало тази седмица беше обединен PR от @bzee, който позволява програмно конфигуриране на възли. Добра работа! 
Създадохме нова характеристика на „Подписване“ в „sn_data_types“, за да абстрахираме подписването и проверката за различните ни потоци във възлите/трансферите и тествахме, и коригирахме някои грешки, концентрирани около интеграцията на новите инфраструктурни заявки за маршрутизацията. Това премести операциите за зареждане в самото маршрутизиране, докато преди това се извършваше във възлите. Преди това имаше ограничение за заявки само към старейшини (при това само старейшини от собствената секция) за информация за първоначалното включване към мрежата. Преместването на това в sn_routing означава, че можем да направим запитване към всеки възел и да получим обратно правилната информация за свързване … по същество давайки възможност на клиентите да работят с многосекционна мрежа.
Освен това, отстраняваме грешки и различни проблеми с разделянето на секции сега, след като тази функционалност вече работи (макар и ограничено поради гореспоменатите проблеми), а уеб приложението на @mav node-logger се оказа чудесен инструмент за бързо разглеждане на потоците от съобщения предавани между различните възли и фокусиране на изходните данни от многосекционната мрежа в нещо малко по-четливо от човек.
Също така работим върху потока за събиране на данни, който се изисква за новоповишени Старейшини в секция, които ще трябва да се актуализират с всички данни, които съхраняват останалите Старейшини. Тъй като тези данни биха били сравнително големи по размер, в идеалния случай бихме искали да ги предаваме поточно, така че възелът да не се блокира от тази задача, следователно ще работим малко върху qp2p, за да активираме директното поточно предаване на данни към възлите при поискване.
През последната седмица направихме някои допълнения към qp2p контейнера, за да управляваме вътрешните връзки и потоци, и да премахнем част от натиска върху API-то за потребителя. Тази работа е завършена и в момента преминава през преглед в този PR, като новият API също е интегриран с маршрутизацията и преминава всички тестове. Изчакваме публичната версия на тестовата мрежа да бъде пусната преди обединяването им, но при сегашното закъснение може да решим да ги обединим по-рано. Тестването показа, че тази промяна е направила нещата значително по-опростени и това ще направи отстраняването на грешки при всички други проблеми с p2p мрежите много по-опростени.
API и CLI
През изминалата седмица получихме още няколко PR-а от общността, които бяха обединени и вече са част от нова CLI версия, публикувана днес (v0.18.0).
Благодарение на този PR, изпратен от @mav, валидирането на NRS вече изключва по-голям набор от знаци, които никога не биха имали някаква разумна цел за включване в кой да е URL адрес. Наличието на ограничение на общата дължина на URL адреса на NRS от 255 байта, при което всеки поддомейн не може да бъде по-голям от 63 байта, сега се налага с този PR .
Safe auth CLI командите сега дават приоритет на аргумента --config пред използването на променливи, това също вече е налице в новата версия благодарение на PR #700, също изпратено от @mav.
От страна на qjsonrpc PR #698, подаден от @Scorch се реализира основен клиент/сървър пример чрез използването на API-то на qjsonrpc. Клиентът на qjsonrpc изпраща съобщение ping до qjsonrpc сървър и той отговаря със съобщение ack. Този пример за програма просто и прецизно показва как qjsonrpc може да се използва за изграждане на всяка програма, използвайки JSON-RPC над QUIC. Има много повече дейности и проучвания, направени от @Scorch с още идеи около qjsonrpc - за тези, които се интересуват от повече подробности и / или искат да участват в това усилие, погледнете неговата тема във форума за разработчици. 
BRB: Византийско надеждно излъчване
Повдигнахме PR в brb_node_qp2p, за да коригираме случайна загуба на пакети, която пречеше на BRB операциите. Това прави възела стабилен, в случай че някой член на общността би искал да тества BRB в CLI среда. Основните инструкции за използване са тук (Имайте предвид, че трябва да изградите кода сами, поне засега).
Дискусиите за интегриране на BRB с BLS Генериране на разпределен ключ (Distributed Key Generation - DKG) продължиха с няколко възможни опции. Изглежда, че консенсуса се фокусира върху една от опциите. Подробности за тези планове трябва да бъдат публикувани в идните седмица след като започнем работата.
Маршрутизиране
Направихме първата стъпка към преместването на всички дефиниции на съобщения от sn_routing в sn_messaging контейнера, където ще се намират не само дефинициите на съобщенията, но и всякаква логика, свързана със сериализацията им. Първоначалната версия на това, заедно с унифициран тип съобщения за клиенти и възли, свързващи се към секция, вече е налице в най-новите версии на sn_routing и sn_client. Следващата ни стъпка в това отношение е най-накрая да преместим всички дефиниции на типовете съобщения върху sn_messaging контейнера, което ще ни позволи да отделим действителната sn_routing логика от това, което би станало API-то на мрежата.
Преводи:
Английски; 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: SAFEnetwork България | Facebook
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България