Safe Network новини 🇧🇬 25.2.2021

Dimitar · March 4, 2021, 3:25am

Накратко

В петък, 26 февруари (утре) от 21:00 GMT, ще има виртуална среща на Safe общността. Пълни подробности тук.
Идентифицирането на грешки и премахването им продължава, заедно с няколко подобрения на ефективността, докато продължаваме и тази седмица със значителен напредък по пътя към публична тестова мрежа.
През седмицата бяха обединени някои значителни PR-а в sn_routing, по-специално PR # 2323, PR # 2328 и PR # 2336. Пълни подробности по-надолу.
Два допълнителни значими PR в sn_routing, # 2335 и # 2336, критични за стабилна тестова мрежа, вече са повдигнати и трябва да бъдат прегледани и обединени през следващите дни.
@scorch е подаде PR, за да (най-накрая!) разреши „този проблем“, където версиите на самия CLI и външните изпълними файлове като sn_node или sn_authd се объркват.
Вижте отличния анализ на @bzee тук, с който той се стреми да подобри и актуализира обвързванията към Node.js.

Виртуална среща на Safe общността: петък, 26 февруари от 21:00 GMT

Задвижваните от общността маркетингови усилия продължават благодарение на работата на @sotros25, @m3data, @piluso и други. Впечатляващи неуморни усилия от тяхна страна!

Имаше дискусии и стратегии във форума, както и малки zoom срещи през последните няколко седмици, включително тази, в която обсъждаме някои от пазарните проучвания на @sotros25 за свързани проекти.

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

Първите 45 минути от разговора ще бъдат за маркетинговата стратегия на общността. След това ще преминем към по-широка дискусия относно Safe мрежата. Целта е да се помогне за дефинирането на маркетинговата стратегия и също така да се използва съдържанието от тези дискусии като видео за изграждане на информираност и ангажираност.

Моля, имайте предвид, че тази среща ще бъде записана, излъчена и публикувана, така че хората в различни часови зони, няма да я пропуснат.

Пълните подробности и връзката за присъединяване ще бъдат достъпни тук.

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

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

Работата ни тук и тази седмица е свързана със стабилизиране на мрежите. Започнахме седмицата с разследване на някакво странно поведение, наблюдавано само при активиране на някои логове, което в крайна сметка ни доведе до малък проблем при маршрутизирането, където държахме заключване за продължителността на дълго асинхронно обаждане (изпращане на клиентско съобщение), което причинява задържане на отговорите. Беше трудно за разбиране; но след като установихме, че заключване-то е в следствие на if изявлението, просто трябваше да го преместим и да се уверим, че заключване-то се освобождава, след като имаме необходимото там. Това позволи преминаването на отговорите от клиентите.

С завършването на промените в инфраструктурата за съобщения, миналата седмица, възлите вече не включват никаква логика за натрупване на подписи, разчитайки изцяло на способността на маршрутизацията да го направи. По-рано имахме натрупване само при източника, където Маршрутизацията натрупваше подписите на старейшините, преди да ги изпрати към целта им, в резултат на което съобщенията с натрупаните подписи се изпращаше многократно до местоназначението, като дубликатите бяха филтрирани в целевия възел. Премествайки натрупването на подписите към местоназначението им, можем да намалим малко натоварването на старейшините и значително да намалим броя на обменяните съобщения. Добавихме поддръжка за натрупване в дестинацията при маршрутизиране и го използвахме в sn_node за комуникация между секция и съхраняващите информация възрастни. С горните две корекции вече всички тестове на клиенти, преминават при работа с една секция, а кода на възлите е значително опростен. Необходим е обаче последващ PR, за да се обхване допълнителен случай на употреба, който отговаря за обмен между старейшини в една секция и старейшини в друга секция, част от потока от награди (тъй като парите на секциите се управляват от една секция, но се държат / проверяват в друга секция). Вече работим върху това и трябва да бъде обединено преди края на седмицата.

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

Като начало разделянето на парите от секциите ще бъде осъществявано последователно тъй като все още нямаме трансфери тип един към много, а последователното изпращане беше тривиална задача, работеща достатъчно добре за тестовата мрежа. Въпреки това, с преструктурирането на „TransferAgreementProof“ преди няколко месеца в подписан дебит и подписан кредит, вече можем относително лесно да реализираме трансфери тип един към много, като включим набор от кредити. Работа за по-натам :).

Като задача с по-нисък приоритет и успоредно с горното, започнахме да се подготвяме за надстройка до нова версия на Quinn, която ни позволява най-накрая да надстроим до стабилен Tokio v1. Току-що го опитахме и подготвяме PR за тази миграция, която да се случи веднага след публикуването на Quinn версия 0.7.0.

Друго подобрение, което направихме през тази седмица, се отнася до изтриването на лични данни. Преди ново обединените промени в self_encryption и sn_client, изтриването на лични данни означаваше изтриване само на картата с данни към действителните данни, които са самокриптирани и съхранени в мрежата. Последното ни попълнение в екипа, @kanav, внедри подход на рекурсивно изтриване, който изтрива отделните парчета, заедно с парчетата, които съхраняват картата с данни, постигайки изтриване в истински смисъл.

API и CLI

@scorch изпрати PR за премахване на опцията -V от подкомандите на CLI, за да се избегне объркване между версията на самия CLI и версията на външни изпълними файлове като sn_node или sn_authd. Тази промяна включва също добавянето на подкомандата bin-version към подкомандите $ safe node и $ safe auth за извличане на версията на външните изпълними файлове, така че семантиката да е ясна, заедно с разграничението между CLI версия и sn_node или sn_authd версии.

В момента qjsonrpc библиотека е внедрена, за да поддържа стандарта JSON-RPC 2.0. Въпреки това, има определени кодове за грешки, които са дефинирани в спецификацията, които не са били изложени от контейнера. Това означава, че потребителите трябва сами да предефинират едни и същи константи, което не е необходимо, тъй като те в известен смисъл са част от изпълнението. Поради тази причина @scorch също изпрати PR, за да изложи тези кодове за грешки като константи от qjsonrpc.

Както беше споменато в предишния раздел, ние също се опитваме да се подготвим за надстройка до Tokio v1, като по този начин подготвяме CLI и authd контейнерите за такова надграждане, като направихме някои предварителни тестове.

CRDT

Правихме повторения на процесите в CRDT, който е в основата на типа Sequence в sn_data_types. Преди това Sequence беше реализиран с LSeq. Изпробвахме по-опростен Списък, за да разрешим някои проблеми с дълбоки вмъквания, след което преминахме към GList за да поддържаме само растеж. При анализ, всички тези CRDT не правят моделиране на версии, както бихме искали. Те се опитват да линеаризират реда на документите, когато в действителност историята на документите формира DAG. Имаме дизайн на CRDT за регистрация на Merkle-DAG, който ще ни позволи да моделираме вярно историята на документите и да четем най-актуалните версии.

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

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

Опитът ни да интегрираме прототипа на файловата система sn_fs с BRB разкри няколко проблеми. Причината е, че sn_fs получава операции от ядрото на операционната система по-бързо, отколкото те могат да бъдат приложени от BRB. За тази цел сме измислили няколко свързани решения: 1) заобикаляне на мрежовия слой при изпращане на операция към себе си и 2) проследяване кога другите участници са получили ProofOfAgreement, за да можем да избегнем изпращането на следващата операция докато 2/3 от останалите участници не са приложили настоящата операция. Това е необходимо, за да се изпълни изискването за подреждане на източника при BRB. Подреждането на източника означава, че операциите, идващи от един и същ източник (актьор), трябва да бъдат последователно подредени, но операции от много различни участници могат да бъдат обработвани едновременно.

Също като част от интеграцията на sn_fs, модифицирахме контейнера brb_dt_tree, за да поддържа изпращането на множество дървовидни операции в рамките на една BRB операция. Това ефективно ни дава свойствата за атомна транзакция за прилагане на логически свързани CRDT операции по „всичко или нищо“ начин. Възнамеряваме да използваме същия модел в други BRB типове данни.

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

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

Тази седмица обединихме PR промяна на начина, по който се обработват клиентските съобщения, така че сега те могат да бъдат пренасочени през мрежата по същия начин като съобщенията на възела. Това означава, че клиентът може да изпрати заявка извън своята секция и да получи отговор обратно, дори когато клиентът не може да бъде свързан директно от получателя(ите) на заявката поради ограничен NAT или подобни проблеми.

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

И накрая, PR за справяне с форкове вече е в процес на преглед. По време на работата по този PR открихме няколко допълнителни грешки, които не са свързани със справяне с форкове. През цялата седмица бяхме заети с отстраняването на грешки и към днешна дата изглежда, че ги отстранихме всичките. Резултатите от вътрешното стрес тестване изглеждат много обещаващи, плюс това успяхме да стартираме локална хост мрежа с 111(!) възли на една машина и всичко мина гладко. PR с тези корекции в момента е в процес на писане и скоро трябва да бъде готов за преглед.

Преводи:

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

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

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

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