Български (Bulgarian) 🇧🇬 Добре дошли в Safe Forum

Dimitar · June 25, 2020, 1:51am

SAFE Network новини - 18.6.2020

Накратко

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

Благодарим на всички, които допринесоха миналата седмица с тестването на трезорите от дома!
Изследвахме резултатите от тестовата мрежа и сега работим върху области, определени за подобрение.
Има тестова мрежа на общността за тези, които желаят да се включат - вижте публикацията във форума тук.
PR-а за символната връзка на safe-cli-то сега преминава през тестване и преглед. *
CRDT Последователността продължава да напредва с добри темпове и свързаните PR-и са обединени в safe-nd и safe-vault .
Създадохме задание в GitHub, в което са изброени всички стъпки, които според нас са необходими, за да премахнем Парсек от маршрутизирането.

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

Искаме да благодарим на всички за участието им в тест мрежата от миналата седмица. Въпреки че теста беше ограничен до потребители с рутери поддържащи IGD, имахме добро участие от Трезори, с 59 общо присъединили се към секцията. Имаше и голям брой клиенти, както и 2214 неизменни парчета данни, съхранявани в 107 контейнера с файлове. Важна част от теста беше да се демонстрира възстановяването на данни, когато трезорите напуснат мрежата и това показа добри резултати. Мрежата извърши 4193 успешни операции за възстановяване на данни.

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

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

Ще включим тези функции (и повече) в предстоящите тестове. Междувременно сте добре дошли да се присъедините към тест мрежата, управлявана от общността. Поздрави на @tfa, @Traktion, @neo и всички останали, които участват. Посетете тази публикация, за да станете част от историята.

SAFE API

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

Поддръжката на Symlink ще бъде добавена тази седмица. Работата напредна с тестови случаи, документация и коригиране на някои проблеми, свързани с пътя в Windows, които се появиха в тестовете. Голяма заявка за изтегляне беше повдигната в сряда и очаква окончателно тестване и преглед, преди да може да бъде добавена.

CRDT

През изминалата седмица беше постигнат добър напредък по отношение на подготовката за CRDT последователност в първа версия за тестване. Финализирахме и вече обединихме PR в safe-nd контейнер, където този нов тип данни е дефиниран и където основната CRDT логика пребивава , AppendOnlyData също беше премахнат от него, тъй като типът данни на последователността го замества.

Освен това успяхме да финализираме PR-а за safe-vault контейнера, който беше одобрен и обединен днес. Това означава, че вече имаме готов код в Трезора, за да приемаме заявки за съхранение и промяна на CRDT Последователно съдържание. Някои от последните неща, по които работихме, бяха разрешенията и собственикът на последователността да бъдат CRDT и създаването на някои основни тестове за интеграция към първата версия и / или тестова мрежа. Промените, необходими за премахване на поддръжката на AppendOnlyData в safe-vault, вече са готови за преглед в отделен PR.

Сега се опитваме да финализираме PR-ите, необходими за поддържането на този нов тип данни от последователност от страна на клиента, което означава, че safe-client-libs и safe-api контейнерите ще излагат API-тата, за да могат да изпращат заявки за съхраняване и промяна на Последователното съдържание. PR-ите вече са функционални, има нужда само от окончателно почистване и добавяне на някои автоматизирани тестове преди първата тестова мрежа да може да използва този тип CRDT данни.

Трансфери

SAFE Трансфери План на проекта
SAFE Клиентски библиотеки План на проекта
SAFE Трезор План на проекта

Работим усилено върху интеграцията на трансфера на актьори в SAFE Клиентските Библиотеки и Трезори. В първата вече тестовете ни вечепреминават с някои API-та заместители и сега работим върху интегрирането с нашия актуализиран код на Трезорите. Това се нуждае от създаването на нови потоци и съобщения. Вече имаме някои типове заявки на „SimulatedPayout“ за зареждане на акаунти с тестови safecoins монети, симулиращи получаване на заплащане от фермерство. Това е малка, но полезна настройка, която ни доближава до това как мрежата в крайна сметка ще работи.

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

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