Safe Network новини 🇧🇬 8.10.2020

Накратко

Ето някои от основните неща тази седмица:

  • Публикувахме sn_fs GitHub хранилището и бихме желали да насърчим по-технически ориентираните членове на общността да опитат да монтират файловата система.
  • sn_api хранилището вече се изгражда спрямо актуализирания sn_client.
  • Работата по интеграцията на възлите и клиентите направи нов скок напред, наред с други неща и PR, въвеждащ DebitProofAggregator за завършване на работата по AT2 Трансферите от страна на клиента, което означава, че кодът за сигурен и успешен паричен превод ще се счита за завършен!
  • Тази седмица имаше значителен напредък в преструктурирането на sn_routing, като основната полза е, че вече можем бързо и лесно да изпълним нашия тестов пакет.

CRDT

sn_fs

Тази седмица екипът напредна с доказателството на концепцията за sn_fs доста добре под Linux (Ubuntu) и няколко смели души дори го изпробваха на macOS. Един незначителен проблем беше идентифициран и отстранен под Linux. За съжаление под macOS бяха съобщени няколко проблема, които все още не са отстранени, така че все още не препоръчваме да го използвате на тази платформа, въпреки че се изгражда и някои основни функционалности работят. Кодът все още не може да бъде изграден под Windows.

Въпреки това, тази седмица имаме удоволствието да представим sn_fs GitHub хранилището публично и бихме желали да насърчим по-технически ориентираните членове на общността да опитат да изградят / монтират файловата система и / или да прегледат кода. Инструкции за изграждане и монтиране можете да намерите в това ръководство. Моля, докладвайте за всички проблеми в страницата му за проблеми в GitHub с всички съответни подробности.

Напомняне: sn_fs е доказателство за концепцията на работа, за да покаже, че crdt_tree е жизнеспособен за изграждане на локална кешираща файлова система. Понастоящем няма мрежова връзка и интеграция със самата Safe мрежа и всичко подлежи на промяна.

Safe Клиент, Възли и qp2p

Safe Network Трансфери План на проекта
Safe Клиент План на проекта
Safe Network Възли План на проекта

Тази седмица актуализирахме sn_api контейнерите (api , cli и authd) с огромните промени, които въведохме при sn_client. Там се промениха много неща, откакто беше safe-client-libs, включително съобщенията и именуването на типовете данни, както и нашата система за трансфер. Това бяха доста промени, но sn_api хранилището вече се изгражда спрямо нашия актуализиран sn_client и гарантираме, че тестовете са готови, за когато имаме този клиент напълно функционален срещу възлите.

Относно интеграцията, модулите Node и Client са получиха множество поправки през тази седмица. С PR # 245 обединен в sn_data_types, бяха отстранени шепа грешки, които засягаха Node по отношение на идентификатори, ключове и подписване на съобщения. Тези промени бяха отразени в Node PR # 1128 и [Client PR # 1271](https://github.com/maidsafe/sn_client/pull/ 1271). След като те бъдат обединени, клиентите ще видят малко повече действия с въвеждането на DebitProofAggregator, който завършва работата по AT2 Трансфери от страната на клиента. Това е последното парче в Трансфери пъзела, което се изисква за натрупване и обединяване на SignatureShares от раздел Старейшини, за да се създаде DebitAgreementProof за сигурен и успешен паричен превод.

Гледайки напред, след като гореспоменатите PR се обединят, трябва да видим повече от половината от e2e тестовете да преминават успешно. С няколко малки корекции и почиствания ще увеличим стабилността на тези два основни модула, за да работят в синхрон. Следващите стъпки след отстраняването на останалите проблеми с тестовия пакет са разширяване на тестовете за интеграцията на фермерството, допълване на целия набор с тестване на хаоса и интегриране на тези актуализации с актуализациите на qp2p IGD, които бяха споменати миналата седмица (което отново активира концепцията за „Възлите от дома“) ) … след това ще пуснем тест мрежа!

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

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

Тази седмица продължихме с преструктурирането на маршрутизирането, за да го направим по-опростено, по-лесно за тестване и по-лесно за разбиране. Първо качихме PR, който премахна някак объркващите типове „FullId“ и „PublicId“. Сега вместо това използваме наложените в бранша PublicKey, SecretKey и Keypair. Това беше последвано от друг PR, за да се изчистят още малко нещата. След това добавихме друг PR, който преструктурира вътрешната логика, използвайки управлявана от команди парадигма и който ни позволява да преструктурираме кода в няколко малки, самостоятелни и свободно свързани части. Най-важното е, че прави кода по-лесен за тестване. Вече написахме куп нови модулни тестове, използвайки този подход с лекота. Това бързо премахва разликата в покритието на тестовете, създадена чрез премахване на старите тестове, базирани на макетна мрежа, които бяха твърде сложни и тромави.

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

Успоредно с това започваме да разглеждаме как новите CRDT-базирани данни за членство могат да бъдат интегрирани в кодовата база за маршрутизация и нейната логика за заетост, което предполага финализиране на вътрешните API-та на нашия PoC код.


  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България