Safe Network новини 🇧🇬 4.3.2021

Dimitar · March 10, 2021, 10:06am

Накратко

Миналия петък отвореното към всички събиране на общността Safe Chat постигна голям успех! Благодарим много на всички участващи и по-специално @sotros25 и @m3data за отличните им презентации.
@jimcollinson ще отговаря на всякакви въпроси в Reddit - моля, включете се!
Съсредоточихме се в отстраняването на грешки в многосекционните мрежи тази седмица, като въведохме няколко нови метода за обработка на грешки, докато отстраняваме проблемите, които могат да доведат до провал на мрежите.
Нови версии на sn_api (v0.20.0), sn_authd (v0.2.0) и CLI (v0.20.0) току-що бяха публикувани, което го прави съвместими с най-новия sn_node.
Завършихме разработката на MerkleReg, спомената миналата седмица, и започна работата по интегрирането му в sn_data_types.
Тази седмица станахме свидетели на прехвърлянето на първите файлове от един SNFS възел на друг чрез BRB.
В маршрутизирането най-накрая обединихме PR за справянето с форкове.
Също така при маршрутизирането обединихме три отделни PR-а (# 2349, # 2351 и # 2336) за прилагане на корекции за различни проблеми, възникнали по време на стрес тестването. Сега се счита, че маршрутизацията е готова за стабилна тестова мрежа.

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

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

Все по-близо и по-близо…

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

Още корекции

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

Справяне с основния проблем

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

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

Safe браузър

Също така отделихме и малко време на Safe Browser, за да изтупаме праха от хранилището му (мина известно време откакто сме го пипали!), актуализирахме зависимости, така че няма да имаме куп проблеми със сигурността, когато сме готови да продължим работата върху него. (Изглежда, че @bzee напредва добре с napi преобразуването на sn_nodejs, което е страхотно!). Това не е вълнуваща новина, но е едно нещо по-малко, с което да се справим, когато сме доволни от стабилността на тестовата мрежа.

API и CLI

Нови версии на sn_api (v0.20.0), sn_authd (v0.2.0) и CLI (v0.20.0) току-що бяха пуснати с някои подобрения в начина, по който файловете и NRS контейнерите се съхраняват в мрежата, както и с новите подкоманди bin-version за идентификация и възлите за заявка към тяхната версия. Както обикновено, можете да използвате CLI-то за обновяване ($ safe update и $ safe auth update) или да инсталирате най-новото CLI, както е описано в Ръководство за потребителя. Тези нови версии са съвместими с най-новите sn_node v0.28.1.

Както споменахме миналата седмица мигрирахме Sequence типа данни, за да поддържаме неизменяема политика, която премахва всички сложности, които внася в CRDT подхода ни. С това, което вече е на разположение, през изминалата седмица успяхме да адаптираме всички наши API-та и типове съобщения, за да премахнем възможността за променящи се политики.

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

CRDT - Реплицирани типове данни без конфликти (Conflict-free Replicated Data Types)

Завършихме разработката на MerkleReg, споменат миналата седмица: rust-crdt # 111 и започнахме работа по интегрирането му в sn_data_types. Като напомняне, MerkleReg ще бъде новия подкрепящ CRDT към Sequence типа. Той поддържа разклонена история, която може да бъде обходена (подобно на историята на git разклонение).

Също през тази седмица беше установено, че CRDT на GList / List има проблем с вмъкването между индексите, използващи един и същ идентификатор, оправихме го бързо с rust-crdt # 112.

BRB: Византийско надеждно излъчване

Интеграцията на Safe Network файловата система (SNFS) с BRB се оказа много ползотворна при откриването на някои липсващи функции в BRB:

Клиентът не е бил уведомен, когато е приложена операция. Клиентите се нуждаят от тази информация, за да изпратят отново потенциално изпуснати пакети. Това е решено с въвеждането на пакети тип Доставено: brb # 27.
Когато операция се изпълнява от BRB върху клиент, той разчита на мрежовия стек, за да изпраща пакети до себе си. Това би довело до състезателни условия при изключително конкурентни клиенти, когато операции се изпълняват в бърза последователност. Сега прескачаме това като обединяваме тези пакети към самите себе си и ги обработваме, преди да се върнат на клиента: brb # 29.
За да се справим с изпуснати пакети, добавихме API за повторно изпращане на пакети, за които все още не сме получили отговор: brb # 29.

SNFS - Safe Network файлова система

Добри новини! Тази седмица видяхме първите файлове, прехвърлени от един SNFS възел на друг чрез BRB.

Първоначално изпълнихме BRB предаването синхронно с FUSE операцият, но това се оказа твърде бавно. Беше направено подобрение на операциите да се подреждат в опашка и незабавно да се връщат към FUSE. След това отделна нишка системно изпраща операции на връстници в реда на източника и гарантира, че всяка от тях е приложена. Това е необходима стъпка към файлова система, която може да се използва офлайн и след това да се синхронизира с мрежата, когато връзката бъде възстановена. С тази промяна на място, файловата система се усеща (от гледна точка на скоростта) като използването на обикновена файлова система на операционна система, като например ext4 под Linux със SSD. Може би все още не е толкова бързо, но е близо.

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

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

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

Тази седмица най-накрая обединихме PR за справянето с форкове. Същността на този PR е нова реализация на структурата от данни SectionChain, която сега е пълен CRDT. Това означава, че гарантира (в последствие) последователност, независимо в какъв ред се прилагат операциите, как са групирани или дори дублирани. Дори ако в него са вмъкнати множество отделни ключове, в крайна сметка всеки ще се съгласи кой е най-новият и по този начин кои са настоящите старейшини (тъй като всеки ключ на секция е уникално свързан с една група старейшини). И всичко това се постига, без да се използва сложен консенсусен механизъм. Точно това искахме, когато премахнахме Parsec и сега най-накрая го постигнахме.

След това последваха три отделни PR-а (# 2349, # 2351 и # 2336) прилагащи корекции за различни проблеми, възникнали по време на стрес тестовете ни. Ето някои от най-забележителните:

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

След тези поправки вътрешните мрежи, с които работим, изглеждат много по-стабилни. Затова вече смятаме, че маршрутизацията е готова за тестова мрежа!

Общност и маркетинг

Safe разговори

Първият от нашите Safe разговори с отворени врати към общността беше в петък и беше удоволствие! Докато дневният ред беше съсредоточен върху темата за приноса на общността към маркетинга на мрежата, с няколко отлични презентации от @sotros25 и @m3data, дискусиите бяха по-обширни, както можете да си представите.

Не само беше страхотно да видим лицата си - въпреки че камерите не бяха задължителни! - изглежда събитието се оформя като важна среда за сътрудничество и изграждане на големи планове!

Ако още не сте го направили можете да видите разговора тук:

Несъмнено ще организираме повече такива срещи, така че оглеждайте се и ще ви уведомим предварително за следващата.

Аз съм UX дизайнер, който помага за изграждането на новия Интернет: Питай ме всичко!

@jimcollinson подхвана Питай ме всичко в Reddit, както и във всички останали Safe социални канали всъщност.

Той ще отговори на възможно най-много въпроси и като запази някои от най-задаваните и най-интересните въпроси за видео в YouTube, за да направи отговорите по достъпни, лесни за споделяне и да се надяваме да се задържат в умовете на хората за малко по-дълго.

Моля, присъединете се!

Safe Network програма - потребителско изживяване

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

Едно такова място е помощната програма за създаване на покани, където съществуващите потребители могат да помогнат на приятелите си да влязат в Safe мрежата.

Работата за опростяване на този поток също ни накара да разгледаме процеса на покана като цяло и да го оформим донякъде.

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

Накратко, онова, това беше предназначено да улесни живота, докато всичко работи както е предвидено, но може да усложни нещата при проблеми.

В същото време бихме отложили и друга полезна функция за покана докато стартираме мрежата с минимални функции: възможността да добавяме допълнителни средства към покана, когато е подарена на приятел.

Но вече не! Можем да направим компенсацията за инфлация по-разбираема и стабилна, но изискваща намеса от потребителя, ако просто продължим напред и представим ръчни допълвания на средства.

Така че получаваме две неща наведнъж. Ще имаме по-разбираемо управление на поканите и ще можете да добавяте толкова токени, колкото искате към поканите.

Помогнете на приятел да влезе в мрежата и го почерпете, всичко наведнъж.

Преводи:

Английски; Russian ; German ; Spanish ; French

Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum

Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...

Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България