SAFE Network новини - 7.5.2020

SAFE Network новини - 7.5.2020

Накратко

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

  • Изпълнихме първия си вътрешен тест с Трезорите, които работят от вкъщи и се свързват в една секция с добри резултати.
  • RFC-0052 беше актуализиран, за да направи RFC-а и кода съвместими и да направи някои области по-ясни за други изпълнители в бъдеще.
  • Актуализирахме SAFE App C# CI-то, за да публикуваме автоматично документите на API-то в GitHub Pages. Най-новите документи са качени тук.
  • Нашата реализация на AT2 (която изглежда като солиден заместител на текущата реализация на Safecoin) вече има тестове, преминаващи успешно през SAFE Клиентските библиотеки, Трезорите и safe-nd.
  • Актуализирахме safe_core библиотеката, за да използваме функции и асинхронизация/изчакване, и вече сме в процес на работа с SAFE удостоверителя.

Трезори – Фаза 2

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

Тази седмица направихме малко отклонение, за да опитаме нещо ново. С добавянето на новите функции в quic-p2p, той вече може да извлича публичния IP адрес на локална мрежа и да препраща определен порт на компютъра към целия Интернет чрез рутера. Сигурен съм, че вече сте се досетили какво се готви. Трезори от вкъщи. Интегрирахме тези нови функции на quic-p2p с SAFE Трезора и с някои малки поправки и преструктуриране стартирахме първия си вътрешен тест днес с Трезори работещи от вкъщи. Видяхме добри резултати и забелязахме, че могат да се направят някои подобрения. Видяхме и някои проблемни точки също, например рутери, които не поддържат IGD, но ей, това се очакваше. Ще работим върху някои подобрения на този фронт през следващата седмица.

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

SAFE API

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

Тази седмица голямо преструктуриране на XorUrlEncoder беше завършено. XorUrlEncoder е преименуван на SafeUrl, тъй като сега капсулира както URL адреси от типа NRS, така и XOR. Също така, RFC-0052 беше актуализиран за изясняване на някои неясни области, предоставяне на примери и коригиране на номенклатурата, така че кодът и RFC-а да бъдат синхронизирани.

API-то и CLI-то също са актуализирани, за да поддържат рекурсивната разделителна способност на NRS URL адресите за всички операции.

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

SAFE Програма C#

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

Тази седмица поправихме генерирането на документация за API-то и актуализирахме CI-то, за да публикува автоматично актуализираните документи на GitHub Pages. Най-новите документи на API-то са хоствани тук. Актуализирахме файла README, за да посочим най-новите документи.

Въз основа на последните промени в Safe-api, работим върху няколко подобрения и преструктуриране в SafeUrl / XorUrlEncoder API-тата. Промените включват разкриване на повече API-та от safe-api и опростяване на съществуващите API-та за C# разработчици. Ще актуализираме и API-то за проверка за да връща всички предприети стъпки за получаване на някои данни от мрежата.

CRDT

Базовата актуализация на внедряването на AT2 към Safecoin изглежда добре, като тестовете преминават през SAFE Клиентските библиотеки, Трезорите и safe-nd. Сега преминаваме към измислянето на нови API-та, които трябва да дадат възможност на Клиентите да формулират своите транзакции (включително всички необходими зависимости от тази транзакция) и да предадат това на Старейшините за валидиране. След което Клиента получава BLS подпис от всеки старейшина (ако те валидират транзакцията), като това трябва да е всичко, от което клиентът се нуждае за да пусне искане за трансфер.

Тук има някои зависимости по отношение на получаването на ключовете от Секциите, но не очакваме те да блокират напредъка като цяло.

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

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

Функции в Rust

Миналата седмица продължихме с напредъка на SCL, като актуализирахме Само-криптирането. Тази седмица с радост съобщаваме, че добавихме функционалност към библиотеката safe_core, позволяваща използването на асинхронизация/изчакване, и вече работим с safe_authenticator. Това не е бърза работа, нито вълнуваща, но ни дава много по-чист код, както и потенциални ползи от използването на основните Rust функции.

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

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

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

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

BLS - Разпределено генериране на ключове

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

Докато се насочваме към завършването на DKG контейнера, го тестваме щателно и изчерпателно, както с транспортния слой, така и без него (тестова мрежа), преди да можем да започнем да го използваме в мрежата на живо. Миналата седмица тествахме процеса с грешки на ниво мрежа като изключващи се трезори, забавяне на съобщенията, разделяне на секции и т.н. В момента преминаваме към следващата стъпка, като добавяме злонамерени Трезори в тестовете и ги караме да изпращат фалшиви стойности по време на сесия. DKG би трябвало да може да се справи с това ефективно, като отстранява тези злонамерени участници, тъй като бихме искали 100% от участниците да не бъдат злонамерени, а отзивчиви по време на сесията.

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