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

Накратко

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

  • @jimcollinson представя още един завладяващ поглед върху напредъка на потребителското изживяване чрез SAFE Network програмата.
  • Поддръжката на Symlink и Sequence CRDT PR-ите са обединени в кодовата база на safe-api-то.
  • Към Ръководство за потребителя на CLI е добавен нов раздел , описващ как новите командите safe seq могат да се използват за съхранение на данни от тип Public Public Sequence. Тези нови команди ще бъдат част от предстоящото издание на SAFE CLI.
  • Работата по SAFE Клиентските библиотеки и AT2 за SAFE Трезорите продължава с добри темпове, като остават само няколко липсващи парчета към мозайката.
  • Извлякохме пространствения модул XOR от Маршрутизирането в отделен контейнер, което позволява използването му от другите части на проекта.

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

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

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

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

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

SAFE Network програма: екрани, потоци и проследяване на настройките (Figma)

За нас е удоволствие да споделим с вас цяла поредеци от екрани, потоци и документация.
Голяма част от това сте виждали и преди, но през изминалите месеци направихме стотици промени, настройки, уточнения и повторения.

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

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

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

SAFE API

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

Поддръжка на Symlink беше добавена в кодовата база тази седмица, след като реши проблем, който се появи при тестване в края на миналата седмица.

След това започна работата по внедряване на „glob ()“, който работи в FilesContainer. Това е експериментална функция, която позволява съвпадение на модел (напр. * .Txt) при разрешаване на SafeUrl. Това може да бъде полезно за филтриране на резултати, когато се използват safe-cli команди, като например files ls или files get.

Няколко API и CLI команди за CRDT Sequence бяха добавени тази седмица и са готови за предстоящата версия на CLI. Тези нови команди позволяват на потребителите да съхраняват Публична Последователност в мрежата и да добавят елементи към нея с помощта на своя XOR-URL. Можете да разгледате новия раздел, добавен към Ръководството на потребителя за , описващ как тези нови safe seq команди могат да се използват за съхранение на данни от тип Публична Последователност.

Като част от внедряването на API-то за последователността и командите, използването на AppendOnlyData е премахнато и сега FilesContainers и NRS Map Containers се съхраняват в мрежата като съдържание тип Public Sequence. Това не засяга нито една CLI команда или API-та, тъй като е просто вътрешна промяна в превключването на реализацията от един тип данни към този нов.

CRDT

През изминалата седмица финализирахме всички PR-и в пълния стек за първата версия на CRDT Sequence, като в същото време премахнахме типа AppendOnlyData.

Както се очакваше миналата седмица, последните стъпки за постигането на всичко това бяха за окончателното почистване на кода на safe-client-libs и safe-api контейнерите, както и за създаване на тестове за нашия тестов набор от CI. Също тествахме всичкото това E2E, използвайки нашия CLI тестов пакет в Бейби Флеминг секцията и всичките ни функционални тестове преминават.

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

Някои от следващите стъпки са свързани с възможността да прикачим AT2 плащане към CRDT операция и върху това започваме работа сега. Друга висяща задача е да трансформираме сегашния тип данни MutableData в нов CRDT Map, което според нас може да бъде направено, след като имаме първата версия на CRDT Sequence, пусната и щателно тествана от общността.

Трансфери

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

Тази седмица бяхме напълно фокусирани върху работата по интеграцията между AT2 SAFE Клиентските библиотеки и SAFE Трезорите. С действие „Симулирани изплащания“, както беше споменато в предишните новини, и двата модула вече са готови за AT2 само с още няколко липсващи части (избиране на ефективни маршрути за плащания, възстановяване на суми и др.), които тепърва ще бъдат написани, заедно с тестването за интегриране. Почти всички потоци, които се занимават с Пари (Качване/Промени), бяха актуализирани, за да работят с основния AT2 механизъм.

Оценяваме възможностите за плащане за данни, които определят, наред с други неща, как секциите използват safe-transfer. Във връзка с това напредваме и с фермерството. Написахме тестове за проверка на BFT свойствата за натрупване на награди. Натрупването на награди е проектирано така, че да позволи възнаграждаването на минимална единица работа, както и да остави на горните слоеве от мрежата да решат какво считат за “работа”.

И накрая, правим съответните актуализации в SAFE Клиентските библиотеки за тези последни промени в процеса по Качване/Промени. След като ги имаме ще проверим всичко спрямо актуализираните Трезори.

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

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

Тази седмица обединихме функцията споделени подписи за състоянието, която обсъждахме в предишни седмични новини. След това се обърнахме към още едно изискване от екипа на Трезорите - оказва се, че понякога е необходимо трезорът да манипулира BLS подписите по начин, който не се поддържа пряко от API-то за маршрутизиране. Решихме, че вместо да правим API-то по-сложно и потенциално объркано, ще позволим на трезора да извършва тези манипулации директно. Но за да избегнем дублирането на потенциално нетривиална логика между Трезорите и Маршрутизирането, решихме, че ще изложим някои BLS помощници на ниско ниво извън Маршрутизирането. По-специално, въведохме Generic Acnatulator Acnatulator, който обработва подробностите по събирането на BLS подписите, валидирайки ги и комбинирайки ги в пълен подпис PR е създаден и в момента се преглежда.

Работата по замяната на DKG напредва добре. Основен проблем при работа с DKG при разделяния е решен в този PR - обяснено накратко - ще позволим на новите Старейшини да гласуват за новата DKG. В момента PR-а се преглежда и оценява спрямо най-новия клон на Флеминг (поради последните промени там, това ще отнеме малко време).

We also extracted the XOR space module out of Routing into its own separate crate , because it’s actually useful for other parts of the project. This crate defines the XorName structure which is a 256-bit long number serving as a unique identifier of nodes and data on the network. It also defines the XOR metric (distance between two names) which plays an important role in message routing. Finally, it provides the Prefix structure which forms the core of the disjoint sections concept.

Освен това извадихме пространствения модул XOR от Маршрутизирането в отделен контейнер, тъй като всъщност е полезен и за други части на проекта. Този контейнер определя структурата на XorName, който е 256-битово дълго число, което служи като уникален идентификатор на Трезори и данни в мрежата. Той също така определя показателя XOR (разстояние между две имена), който играе важна роля в маршрутизирането на съобщенията. И накрая, той осигурява структурата на Prefix, която представлява ядрото на концепцията за Секциите.

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

SAFE Network новини - 2.7.2020

Накратко

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

  • Пуснахме версия v0.4.0 на MaidSafe.SafeApp от NuGet пакетът, привеждайки C# API-тата в синхрон с safe-api .
  • Пуснахме версия 1.0 на xor-name контейнера, който наскоро беше разделен от Маршрутизирането.
  • CRDT Последователността вече се счита за готова за включване в следващата версия на тест-мрежата от трезори от дома.
  • След поредната седмица на голям напредък, ние сме много по-близо до интегрираната AT2 реализация между SCL и Трезорите.
  • Споделихме някои допълнителни актуализации и подробности за потребителското изживяване на SAFE Network App чрез Figma.
  • Добавихме поддръжка за съхраняване на „Private Sequence“ и добавяне на данни към него с помощта на API-то и CLI-то. Това ще бъде достъпно в следващата версия.

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

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

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

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

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

SAFE Network програма: екрани, потоци и проследяване на настройките (Figma)

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

SAFE API

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

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

Забелязахме също и странно поведение със символни връзки под Windows CI, което заслужава по-нататъшно разследване - оказа се, че трябва да прескочим обръча за конфигуриране на Git за символни връзки на Windows CI кутии. Можете да прочетете малко повече за откритията на @danda за това тук.

През последните няколко дни успяхме да добавим и поддръжка за съхранение на Private Sequence и добавяне на данни към него с помощта на API-то и CLI-то. Например, нов “Private Sequence” може да се съхранява в мрежата с $ safe seq store “my private note” --private , командата за добавяне към него е точно същата като тази за добавяне към Public Sequence`. Актуализирахме CLI Ръководство за потребителя с пример за това.

SAFE App C#

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

Пуснахме нова версия на MaidSafe.SafeApp NuGet пакета, за да приведем API=то на C# в синхрон с safe-api . Обновеният пакет включва няколко нови API-та (създаване / получаване / добавяне) за работа с API последователности на данни и включва опция за подробна символната връзка в API файловете. Вижте файла changelog, за да прочетете за всички нови функции / подобрения.

CRDT

Миналата седмица приключихме с внедряването на CRDT Sequence, така че през последните няколко дни го прекарвахме през E2E тестове. Всичко изглежда добре, така че сега това се счита за готово за пускане на първа версия, за да може общността да започне да си играе с него. Това ще бъде част от следващата тестова версия на трезорите от дома.

Започнахме да разглеждаме възможностите за мигриране на съществуващия тип MutableData към CRDT, който се очаква да поддържа не само частни данни, но и публична негова версия, която не беше налична при сегашния тип MutableData . Това ще бъде тип данни с ключова стойност, но реализиран като CRDT. Към момента нямаме много повече да споделим, но ще ви държим в течение с напредъка си.

Трансфери

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

Тази седмица работихме над синхронизирането на кода на Трезорите и SAFE Клиентските библиотеки. По този начин открихме и поправихме няколко грешки (свързани с работата с PublicKey на Секцията, с Трезорите и някои грешки, свързани с безопасните трансфери) и добавихме още тестове към съответните хранилища за същите. Репликите вече ще използват SectionProofChain (верига от стари PublicKeys в секцията) от Маршрутизирането, за да валидират трансфери, подписани с по-ранен ключ на секция. Също така прехвърлихме код към най-новото и основно хранилище и преструктурирахме кода на SAFE Клиентските библиотеки в нещо много по-лесно смилаемо.

Все още има някои малки проблеми, които трябва да се преодолеят, но изглежда, че сме много по-близо до интегрираната AT2 реализация между SCL и Трезорите.

След като оценихме няколко различни алтернативи за потока на плащания, избрахме една и започнахме да работим по Request структурата Request , за да я поддържаме. Това дава по-добра категоризация на видовете заявки, което прави по-ясно кога, къде и за какво трябва да се обработи плащане. (Остава ни и да изчистим типовете заявки, тъй като имаме типове, които не са необходими за прилагане от страна на мрежата.) След като това е налице, ще можем да продължим работата по разпределения AT2 Актьор управляван от Секция, което след това ще позволи хранилището за safe-farming да бъде интегрирано в safe-vault и получаването на награди може да бъде включено в тестовата мрежа.

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

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

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

Работата по замяната на DKG продължава, поради някои непредвидени усложнения. Но изглежда, че всички провали на теста вече са отстранени и повечето задачи са изпълнени, така че не би трябвало да отнеме много повече време за добавянето му.

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

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

Накрая пуснахме версия 1.0 на xor-name контейнера, която беше отделена от Маршрутизирането преди две седмици, след като го полирахме малко. Дори направихме контейнера no-std съвместим, което означава, че вече може да се използва във възможно най-големия набор от среди и платформи, включително някои много ограничени вградени устройства.

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

SAFE Network новини - 9.7.2020

Накратко

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

  • Завършихме работата по подобряване на Трезорите и пускахме вътрешни тестови мрежи - резултатите изглеждат добре досега!
  • Продължаваме по всички фронтове с прехвърлянето на тестове ни от работа с тестова мрежа към работа с реалната мрежа.
  • Интегрираме допълнително преструктуриране на мрежовите заявки, което ще отвори вратата към фермерството в мрежата.
  • PR-а с DKG заместника в маршрутизирането е добавен.

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

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

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

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

SAFE API

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

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

SAFE App C#

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

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

CRDT

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

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

Transfers

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

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

Това от своя страна доведе до по-нататъшна работа по интеграцията с SAFE Клиентските библиотеки, но тук нещата напредват добре, дори когато откриваме грешки и проблеми с производителността и прецизираме потока на съобщенията. Друга по-съществена промяна в SAFE Клиентските библиотеки е премахването на отговорите от типа „ack“ (които по същество не ни казват нищо) плюс оставяме на клиента да потвърди по избор дали операцията е приключила. (В крайна сметка това би трябвало да доведе до някои опити/проверки/повторни потоци за определени операции, но няма да е необходимо да се прави това. Което трябва да даде на разработчиците на приложения по-голяма гъвкавост в начина им на действие, и от своя страна да се надяваме ще направи Трезора по-отзивчив).

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

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

Тази седмица най-накрая обединихме PR-а за заместителя на DKG . Това ни позволява да актуализираме секционните ключове, без да използваме parsec.

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

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

xor-name

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

В настоящия момент разполагаме с допълнителни видове XorName и свързаните с тях функционалности, изложени от safe-nd , safe-client-libs и safe-api. За да опростим кода в тези хранилища, сме в процес на премахване на XorName от всяко едно от тях, използвайки вместо това новия специализиран xor-name контейнер. PR-и с черновите, които правят тази замяна във всяко от тези хранилища могат да бъдат прегледани тук, тук и тук съответно.

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

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

SAFE Network новини - 16.7.2020

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

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

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

Моля вижте публикацията за нея и се присъединете, всички са добре дошли.

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

SAFE API

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

Днес пуснахме нови версии на safe-api, safe-cli, safe-authd, safe-ffi и jsonrpc-quic, всички в подкрепа на днешните нови трезори от версията за домашен тест :tada:

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

Започнахме да проучваме възможни подобрения в дизайна на SAFE File API-то.

По-специално, скорошен изследователски документ (и видео вижте 35:30 мин) привлече вниманието ни, който може да доведе до драматично подобрение на ефективността, да помогне за опростяване на API-то ни и решаване на предизвикателства за съвместно редактиране. Документът е озаглавен Високо достъпна операция за преместване на репликирани дървовидни и разпределени файлови системи и описва подробно официално доказан тип данни на CRDT Tree, който е подходящ за използване за файловата система и с последвала евентуално последователност, решава дългогодишен проблем с операциите при преместване, който засяга дори Dropbox и Google Drive , когато се извършват едновременни актуализации. Подходящ е и за работа офлайн.

Основната идея за дизайна ни е да добавим Tree като SAFE тип данни и да внедрим FileTree като специализация, точно както FileContainer е специализация на Sequence . Важната разлика е, че всяка директория и файл се съхраняват поотделно в „дървото“, вместо всички сериализирани заедно като плоска JSON карта в един запис Sequence . Това прави актуализациите и извличанията много по-ефективни за всяка нетривиална структура на директория.

По-нататък бихме искали да включим елементи на Safe.NetworkDrive за бърз локален достъп и използване офлайн, както и интеграция на собствена файлова система чрез FUSE.

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

За момента това остава, че разглеждаме идеи и дизайн на високо ниво. Има много неща за решаване. Първото предизвикателство би било прилагането на алгоритъма CRDT-Tree в Rust. Понастоящем съществува само под формата на формална логика на Isabelle/HOL. Ако някой от членовете на общността владее Isabelle/HOL и може да помогне да го преведе на Rust или дори псевдо-код, това може да помогне за ускоряване на нещата.

Успоредно с това се опитваме да разкрием FFI API-тата на Удостоверителя от safe-ffi контейнера. Това ще обедини нашите API-та за всички платформи. През последните няколко седмици се сблъскахме с проблем с FFI API-тата, когато се опитвахме да се свържем с реалната мрежа, докато тестовите API-та работеха добре. Тази седмица решихме този проблем и вече можем да продължим с последния кръг на тестване и преглед.

SAFE App C#

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

Както споменахме в раздела за SAFE API, разрешаването на проблемите с връзките в safe-ffi направи възможно тестването на новите API-та за удостоверяване в API-то на C#. Това означава, че през следващите седмици ще пуснем нова версия на NuGet пакета, който ще съдържа всички нови API-та, включително API-то за последователност на данни и API-то за удостоверяване. След пускането на този пакет ще бъде лесно да актуализирате приложенията за удостоверяване и SAFE мобилния браузър, за да работят с най-новия трезор.

Тези скорошни промени вече се оказаха много полезни и за първи път можем лесно да настроим нашия CI за изпълнение на тестовете спрямо реална мрежа :tada: До сега трябваше да стартираме ръчно тези тестове преди да пуснем нова версия, докато само на CI тестовете бяха в състояние да стартират.

SAFE Браузър / SAFE Network програма

Доскоро Браузърът и SAFE Network програмата бяха донякъде пренебрегвани, докато акцентът беше върху различните тестови мрежи и разработването на AT2. Но след напредъка с най-новите трезори и основните промени в SAFE API-то, вече работим върху нови версии и за двете, които да са съвместими с най-новия трезор и тестовата мрежа.

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

CRDT

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

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

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

Трансфери

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

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

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

Сега фокусът е върху SCL + трезорите да бъдат тествани тези промени.

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

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

Като част от работата за подобряване на качеството на кода, започнахме да разделяме няколко блока с код на маршрутизация в отделни контейнери. Първия контейнер, който разделихме тази седмица, е safe-network-signature-accumulator, който е посветен на общо агрегиране на BLS подписи за SAFE мрежата. Ще се разделят повече кодови блокове, когато това стане стабилно, за да се намали сложността на логиката на маршрутизиране. Слагането в ред на това е нещо, което смятаме, че е от съществено значение за стартирането, тъй като всеки малък модул може да бъде внимателно тестван и документиран с по-голяма яснота, отколкото когато е смесен с друг код.

Както бе споменато в новините от миналата седмица, първата задача за премахване на използването на parsec, осигуряваща промените на SharedState да са одобрени от секцията, беше обединена тази седмица , Това ни дава възможност да продължим със задачата за основна промяна на даването на права на трезорите. Поради родителския отпуск на Адам (огромни поздравления за него :tada:), работата е заменена от PR 2160, който беше обединен днес. Вече сме стъпка по-близо до внедряването на гласуване въз основа на съобщения, което замества текущото гласуване, базирано на парсек.


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

SAFE Network новини - 23.7.2020

Накратко

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

  • Актуализирахме SAFE Браузъра с нова бета версия.
  • Пуснахме нов RCMaidSafe.SafeApp NuGet пакет.
  • В момента се работим върху съвместимостта на мобилните приложения на браузъра и Удостоверителя с най-новите Трезори и CLI.
  • Гласуването на базата на съобщения беше успешно добавено в сряда и е голяма стъпка към премахването на PARSEC.
  • Теста от миналата седмица ни помогна да затворим течовете на паметта на две места - работата продължава, за да намерим точния източник/източници и да ги поправим.
  • Публикувахме новото хранилище за SAFE фермерството :tada: Това все още е библиотека от ранен етап, която използваме като част от AT2 промените в трезорите.

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

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

Миналата седмица пуснахме няколко тест мрежи с някои подобрения, над които работихме след първата тест мрежа. В първата мрежа приемахме до 22 трезора, които се свързваха от домовете на потребителите. Мрежата получи 2956 парчета данни от 47 акаунта, съхранени в 414 контейнера за уникални файлове.

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

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

SAFE Network Програма UX

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

Проследяване на напредъка на функциите / Екрани, и движение на потребителя

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

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

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

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

SAFE браузър (десктоп)

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

Актуализирахме SAFE браузъра с нова бета версия заедно с актуализирания safe-nodejs.

Включихме и по-разрешителни заглавия на CORS, за да помогнем при извличането при използване на JavaScript, актуализация, която да доведе Electron зависимостите до версия v8.4.0, и други по-малки актуализации на зависимостите на браузъра.

Успяхме да поправим някои счупени CI тестове в тази версия, което позволи тестовете ни за Ubuntu да работят от край до край отново, което би трябвало да ни позволи да активираме автоматизирани актуализации на сигурността чрез Dependabot, след като добавим тези промени в основното хранилище.

SAFE API

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

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

SAFE App C#

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

Днес пуснахме нов RC MaidSafe.SafeApp NuGet пакет, който включва актуализирани API-та за удостоверяване, които са изложени от safe-api/safe-ffi, където преди това използвахме safe-client-libs/safe-authentator-ffi.

Вече започнахме да преструктурираме мобилното приложение за удостоверяване, за да използва този пакет. Приложението за удостоверяване има собствена FFI обвивка, докато за макетните API-та safe_app_csharp има отделно копие на същия код. С новия пакет можем лесно да премахнем излишния код и да използваме повторно API-тата за удостоверяване. Преструктурирането също ще направи приложението съвместимо с най-новите трезори и CLI-то.

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

CRDT

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

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

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

Трансфери

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

През последните седмици споменахме, че работата по фермерския аспект на икономиката на SAFE Network е в ход - сега можем да споделим тази работа с вас с публикуването на новото хранилище за фермерството :tada: Това все още е библиотека от ранен етап, която използваме като част от AT2 промените в трезорите, осигуряваща някаква логика за изчисляване на награди и позволяваща на трезорите да използват това, за да генерират изплащания от своя портфейл в секцията.

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

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

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

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

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

Също като изискване от тестващия екип, трезорите се нуждаят от събитие, за да ги уведоми, че са повишени във възрастен, следователно, за да могат да се разграничат между трезори на бебешори и възрастни. PR 2162 решава това чрез пускането на събитие, когато бебешорите са повишени във възрастни по време на разделяне на секция. Също така започнахме работа по оптимизиране на контейнера, като добавихме още непроменени тестове, които поддържат проверка на логиката на тези бързо движещи се части по време на ревизия. Следва да разглеждаме # 2122, който премества натрупването на подписи в раздела извън PARSEC.


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

SAFE Network новини - 30.7.2020

Накратко

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

  • Работим върху автоматизиран процес, който създава трезори, присъединяващи се към вътрешна тест-мрежа, съхраняваща данни и подреждаща трезорите. Това ще ни позволи да увеличим мащаба на тестовете на секциите.
  • Финализирахме първата версия (PR #186 ) поддържаща съвместни промени на Политиката за промени на Последователни (Sequence) елементи и вече може да започнем да правим промени в библиотеките на трезорите и клиентите, за да се адаптират към някои незначителни промени, които направихме към типовете заявки за Последователност.
  • Члена на общността @happybeing проучва опциите за файлова система FUSE в Rust и стартира проектодокумент предлагащ safe-fs API. Дискусията продължава тук.
  • Въведохме завършен процес за непрекъснато обновяване в нашия safe-nd Rust контейнер.

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

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

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

Идентифицирахме два компонента с голямо използване на памет. Един от тях е PARSEC. Вече сме наясно с това и както вие ще сте наясно, неговото премахване и подмяна вече е в ход. Другият компонент със сравнително високо използване на паметта беше quic-p2p. Гмурнахме се в контейнера и установихме, че изпращаме копие от всички съобщения обратно на потребителя на quic-p2p. Това е полезно, когато изпращането на съобщение се провали, но при успешното изпращане не е необходимо да изпращаме обратно копие от него. Премахването на това намали значително използването на паметта.

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

SAFE Браузър / SAFE Удостоверител (мобилни устройства)

Браузер План на проекта
Удостоверител План на проекта

Преструктурирахме приложението за удостоверяване, за да използваме повторно API-тата за удостоверяване от пакета NuGet и да изоставим собствената му реализация чрез FFI обвивката. Тази стъпка премахна много излишни редове код, тестове и изчисти настройката на C /CD.

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

SAFE API

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

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

CRDT

Финализирахме първата версия (PR #186 ) поддържаща съвместни промени на Политиката за промени на Последователни (Sequence) елементи. Този първи подход позволява създаването на различни клонове на последователността за всяка нова политика, която е зададена, напр. ако клиентът работи офлайн, прави промени на данни, без да е наясно, че нова политика е зададена към съдържанието, когато клиентът се върне онлайн и изпрати такива операции в мрежата, те все още ще се прилагат, но в нов клон на Последователността. При извличане на елементите от последователност, елементите, съответстващи на “главния” клон, ще бъдат прочетени по подразбиране, но в крайна сметка можем да позволим на клиентите (чрез различен тип API/заявка) също да извлекат елементи от всеки от другите клонове, които може да се формират от всяка предишна политика.

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

Сега ще започнем да правим промените в библиотеките на safe-vault и клиента, за да се адаптират към някои малки промени, които направихме към типовете заявки за последователност. Например, една от тези промени беше сливането на собствеността и разрешенията, за да бъдат изцяло част от Политиката, а не да бъдат отделни атрибути на последователност. Промяната на собствеността или настройването на разрешения за други ключове вече се извършва чрез просто задаване на нова политика за последователността. Така или иначе ще работим върху разкриването на API-тата, които позволяват на потребителите да имат по-голяма гъвкавост и подробност за промяна на собствеността и задаване на разрешения на последователност.

tree-crdt

Работата ни продължава по описания през миналата седмица експериментален код на tree-crdt. Внесохме предложената оптимизация на изпълнението от crdt-tree документа, както и индекс за бързо търсене на “децата” на възел. Добавихме lamport + актьор времеви маркери, което означава, че този код вече може да работи правилно, когато е използван от отделни процеси (без споделяне на общ часовник). Също отстранихме проблем с дублиращи се операции, влизащи в дневника, ако те имат един и същи времеви маркер, плюс добавихме няколко тестови случая.

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

В сътрудничество, членът на общността @happybeing проучва опциите на файловата система FUSE в Rust и стартира проектодокумент, предлагащ safe-fs API. Дискусията продължава тук.

Transfers

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

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

Ние работим интензивно, за да потвърдим, че няма регресия след интегрирането на трансфери, фермерството и произтичащото преструктуриране на съобщенията/модулите на safe-vault , с цел бързо преминаване на това към работещ клон. Започна работа за актуализиране на SCL, за да е съвместим с тези нови фермерски трезори, тъй като бяха направени множество структурни подобрения на модулите на трезорите и мрежовите съобщения.

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

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

От миналата седмица се съсредоточихме върху някои задачи за преструктуриране на функции, за да се подготвим за премахване на PARSEC. Те включват разрешаването на проблем с подобряване на натрупването на подписи на съобщения, за да не се изисква PARSEC (което се оправя главно от PR-а за Маршрутизацията, който уведомява изоставащите старейшини и PR за подпис-агрегатор за избягване смесването на различни подписани public_key) и продължаваща работа по проблем, за промяна на изпращането и получаването на NeighbourInfo, за да не се изисква натрупване (обхванато от PR за маршрутизацията за премахване на SendNeighbourInfo гласове). В нашия списък със задачи не са останали много задачи за преструктуриране на функции, така че официалната работа по премахването на PARSEC се очаква да започне скоро.

Една друга добра новина тази седмица е, че благодарение на току-що пуснатия 0.4.0 prag_crypto, вече няма нужда да се поддържат различни версии на контейнера. Обединеният PR актуализиране на зависимостите и преструктурирания код, за да се опрости използването на rand хранилища премахна още една ненужна сложност.

Непрекъсната доставка

От известно време сме готови да разрешим непрекъснатата доставка (continuous delivery - CD). SAFE Браузърът има автоматизирани издания, но се борихме с GitHub Actions с цел автоматизиране на разпращането на версиите, актуализации на файла с промените, тагове и издания.

През последната седмица взехме наученото от SAFE браузъра и го приложихме към една от нашите Rust библиотеки, с цел CD да отиде там. Това ни забави и ни донесе забавен масив от проблеми, с които да се борим (не можеш да автоматизираш натискането на защитени клонове в GitHub, не можеш да прегледаш собствената си заявка за изтегляне, не можеш лесно да получиш съобщението за ангажиране на PR). Но, ние преодоляхме всичко това и най-сетне имаме ново действие за нашите Rust хранилища за автоматизиране на разпращането на нови версии и генериране на файлове с промените (от конвенционални команди. Това автоматично генерира PR за разпращане на версията и след това имаме друго действие, което обединява това. Което след това (за пореден път в master) ще маркира новата версия и ще стартира версии за нас. Всичко това автоматично :mage:

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


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

SAFE Network новини - 6.8.2020

Накратко

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

  • Създадохме инструмент за автоматизация на тестовите мрежи, който напълно ще автоматизира създаването на машини, стартирането на трезори и въвеждането на разделяне в мрежата.
  • Продължихме с работата по проектирането и внедряването на прототип, за да се демонстрираме осъществимостта на използването на crdt-tree тип данни като основа за локално присъединима файлова система (чрез FUSE).
  • @happybeing, един от най-активните членове на общността форкна проекта Rust polyfuse и създаде FUSE обвивка, която може да послужи за отправна точка за извикване в кода на нашата файлова система Rust, когато е готов.

Благодарности на @Sascha за предоставяне на корицата за новините за тази седмица!

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

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

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

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

CRDT

safe-fs

Продължи работата по проектирането и внедряването на прототип, за да се демонстрира осъществимостта на използването на типа данни от crdt-tree като основа за локално монтирана файлова система (чрез FUSE).

Конкретното предизвикателство е да проектираме поддръжката на твърди връзки, ключова характеристика на файловите системи на Unix, която позволява на множество имена на файлове да се позовават на един файл inode (метаданни и съдържание). Предложено е решение тук.

След това открихме, че ino (u64) не е необходимо да съществува между монтиранията, така че те могат да се съхраняват в локална структура на данни извън (споделен) crdt-tree.

С обработването на такива проблеми беше изграден експериментален (бърз) клас прототип на файловата система, който реализира основните характеристики на файлова система и по този начин демонстрира, че дизайнът работи на практика.

Членът на общността @happybeing форкна проекта Rust polyfuse и създаде FUSE обвивка, която може да послужи за отправна точка за извикване в кода на нашата Rust файлова система, когато е готова.

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

Достигането на тази цел ще доведе до прилагане на crdt-tree и API-то на файлова система в Rust, след което да се интегрира с FUSE обвивка.

Фермерство

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

SAFE Клиентски библиотеки и интеграция на Трезора

Непрекъснато напредваме с интеграцията тук прилагайки най-новите промени във фермерството. Актуализирахме както трезорите, така и SCL с най-новите промени от master клоновете, които внесоха някои проблеми, когато преминахме към новия XorName контейнер. Но проследихме това и след още един малък проблем, свързан с извличането на AT2 историята на транзакции за клиенти, имаме почти пълен поток от съобщения между тях.

В момента разглеждаме някои проблеми от страна на клиента, при които клиентът виси, докато чака реакции на TransferValidation. Изглежда, че това е свързано с използването на quic-p2p, който е леко остарял по отношение на Rust, така че също надградихме тази библиотека, за да бъде напълно асинхронизирана, което да се надяваме трябва да ни отблокира в клиента, а също и да опрости част от safe_core кодът значително .

Store cost and Rewards Разходи за съхранение и награди

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

За първите тестови мрежи с фермерство ще използваме много по-опростен подход, при който има обикновена статична цена за съхранение ( 1 байт = 1 nanosafecoin ) и опростено възнаграждение въз основа на възрастта, изплащана при всяко преместване ( 2^възраст safecoins ).

Сега работата продължава с изглаждането на първоначалните няколко момента на мрежа и солидността на разпределения AT2 актьор, известен още като Фонда с пари на секцията.

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

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

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

Така че с връщането на Адам обратно, първо преглеждаме извършената работа по време на отпуска му. Забелязани са няколко подобрения и обединихме работата на изпращане само на повишение, за коригиране на новите старейшини, изпращане DKG съобщение директно до участниците и Премахване на обработката на събитията от Началното зараждане на мрежата. И продължаващата работа по премахване на кеша на отскачащи_непознати_съобщения ще бъде обединена скоро.

Също така започнахме да проучваме последната останала работа по преструктурирането на функции (Премахване на опашката за преместване и да направим преместването независимо от реда на събития за разгръщане) преди да преминем към премахването на PARSEC. Проведе се ползотворен дебат относно потенциалния подход за преместване и го документирахме и актуализирахме.


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

SAFE Network новини - 13.8.2020

Накратко

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

  • Финализирахме първата реализация на новото quic-p2p async API, още една огромна стъпка в опростяването на кодовата ни база. В момента работим за надграждането на библиотеките ни с новите API-та.
  • Подготвихме представяне на най-новия прогрес на SAFE Network App UX.
  • Започна работа по прилагането на CRDT дървото в Rust.
  • @JPL актуализира SAFE Network Primer, за да включи всички най-нови разработки.
  • Миналият петък беше последният ден на @ravinderjangra в MaidSafe. Пожелаваме му всичко най-добро в бъдеще и му благодарим за участието му в развитието на SAFE мрежата през последните 2 години, особено за всичко, свързано с мобилните приложения и API-тата!

CRDT

safe-fs

Тази седмица започна работата по прилагането на CRDT дървото в Rust. Вчера бе постигнат важен напредък, когато кодът правилно изпълни двете проблемни условия за съвместимост, описани (и решени) в документа. Допълнителни уточнения и тестови случаи са в процес на разработка.

Фермерство

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

SAFE Клиентски библиотеки и интеграция на Трезорите

С приключването на разработката на async quic-p2p тази седмица, сега работим за повишаване на скоростта на библиотеките с по-новите API-та от quic-p2p. Преди SAFE Клиентските библиотеки имаха два варианта за комуникация - send, който изпраща заявка и чака отговор и send_only, който просто изпраща команда и не чака отговор (повече като стреляй и забрави стратегия). Сега всичко това е преместено в quic-p2p и е направено много по-просто чрез асинхронизиране/очакване на парадигмата, като същевременно прави и клиентските библиотеки по-леки. С този напредък вече няма да виждаме блокиращата грешка от quic-p2p, която се случи по-рано по време на интеграцията, както беше споменато в предишните новини.

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

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

Награди

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

SAFE Network App UX

Проследяване на функциите / Екрани и движение на потребителя

Първо, ако разгледате Фигма файлове по-горе, за да се запознаете с най-новите промени, трябва да забележите прилично подобрение на производителността ~~ след безмилостното ни досаждане на разработчиците на Фигма ~~.

Няколко различни новини, които да споделим с вас:

Разрешенията за приложения вече са Възможности

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

Досега наричахме това Разрешения за приложения. Но за да не антропоморфизираме приложенията и да опишем по-точно какво се случва, променяме това на Възможности.

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

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

Плаващи бутони за действие сега с описания

Използваме плаващи бутони за действие (FAB) в множество различни контексти. Въпреки че материалните указания предпочитат само една икона, като се има предвид броят на различни контексти, ние смятаме, че подобрява яснотата и използваемостта, за да включи описание на действието във FAB, така че ще видите тази промяна на различни екрани и потоци.

Подкана за влизане от външни приложения

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

Публикуване на снекбар на таймера

И последно малко обновление. Направихме промяна в процеса на публикуване, който включва снекбар с таймер за обратно отброяване, което дава на потребителя малък период за изчакване, преди да бъдат публикувани вечните данни. Това е като алтернатива на краткия прозорец за ‘отмяна’, който преди това бяхме въвели, и по-точно отразява случващото се зад кулисите.

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

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

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

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

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

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

Сега се опитваме да направим същата миграция в библиотеката за маршрутизация, за да използваме не само новото async quic-p2p API, но и да изложим собственото си API като async, което както беше казано по-горе ще опрости кодовата база много както в маршрутизацията, така и при трезора. Както може би осъзнавате, всичко това е вътрешно преструктуриране, ползите от което могат да бъдат трудни за наблюдение от крайните потребители, но ние сме много обнадеждени, че това ще ни позволи по-лесно да намерим и решим всички проблеми, които ще открием в бъдеще, както и да направим по-лесно да се поддържат и развиват съществуващите функции.


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

SAFE Network новини - 20.8.2020

Накратко

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

  • Вижте страхотния SAFE Network Wallet Bot, разработен от @DeusNexus тук - Телеграм вече е свързан към SAFE CLI! :clap:
  • Имаше огромни усилия за преструктуриране и опростяване на SAFE Клиентските библиотеки през последните няколко седмици, като около 18 000 реда код бяха премахнати и вече имаме по-опростена, по-ясна и чиста кодова база.
  • Работата по излагане на async API-то за маршрутизиране продължава безпроблемно със същите опростявания на кода, които наблюдавахме в други хранилища през последните месеци.

CRDT

safe-fs

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

В тази връзка получихме дисертация с автор кандидат докторант, написал разпределена файлова система, която се реализира чрез crdt-tree алгоритъма. Още по-добре е, че файловата система е реализирана в Rust като FUSE файлова система. Не бихме могли да желаем нещо по-добро съответстващо на нашите усилия.

Затова отделихме известно време тази седмица във внимателно проучване на документа, водихме си бележки и го оценихме спрямо собствените ни дизайнерски решения, като също така изпробвахме и прегледахме кода му. Открихме 2-3 идеи, които може би ще можем да включим в нашия дизайн.

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

SAFE Клиентски библиотеки и Трезор

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

SAFE Клиентски библиотеки и Трезор - интеграция

Преструктуриране (с мачете)

През изминалата седмица в SCL работихме върху финализирането на някои по-големи преструктурирания и опростявания на кодовата ни база базирани върху последния quic-p2p async напредък.

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

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

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

Това драстично опростява нещата. „Програмите“ просто стават „клиенти“ (повече за това как ще работи по-долу), използвайки секретни ключове по същия начин като всеки друг клиент. Вече не се нуждаем от слоя за „удостоверяване“ сега, когато нямаме програми. Което отново означава по-малко код както в SCL така и в трезорите (където разрешенията на програмите бяха проверявани преди).

Така че с тези (доста обстойни) промени успяхме да намалим SCL кодовата база с около 18 000 реда код през последните няколко седмици. Получихме кодова база, която е много по-проста, по-ясна и по-чиста. По-лесна за документиране и по-лесна за преглед.

Нови “програми” и “удостоверител”

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

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

Това беше голямо преструктуриране. Но ползите вече са изобилно ясни. С изчезналите 18 000 реда код, сме свободни да се движим много по-бързо в SAFE Клиентските библиотеки. Сега продължаваме с финализирането на интеграцията с актуализираните Трезори и quic-p2p, за да се върнем към работа върху тест-мрежите.

Асинхронизация при Трезорите и тестове

Интеграцията на асинхронното маршрутизиране започна и в Трезорите, паралелно на усилията ни за маршрутизирането.

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

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

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

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

Работата за премахване на гласуването за SendNeighbourInfo, както бе споменато в предишните новини, вече е обединена, като всички неуспешни тестове са поправени, заедно с PR за ( коригиране на неправилно присвоен ключ на секция към не-старейшини).

Междувременно, изпълнението на работата по преместване на преструктурирането за (Премахване на списъка за преместване и въвеждането на преместване независимо от реда на събитията за преместване) напредва добре. Също така започнахме да използваме тестовата рамка от Трезорите, за да проверим поведението на маршрутизацията при реално използване на мрежата.

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

Стандартизация

Вече прокарваме процеса на стандартизация малко по-напред. Ще превключим bincode към MsgPack за сериализация (както @mav посочи преди време, bincode е само Rust). Ще стандартизираме на base32z за четимо от хора кодиране.

Това се основава на преминаването към QUIC от Crust, което ни даде стандартизиран защитен транспортен слой.

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

По-важното е, че това трябва да ни позволи да видим как всичко работи на едно ниво, т. е. Трезорът получава съобщение X, след това прави Y до X и изпраща съобщение Z до друг Трезор. Или клиентът изпраща съобщение от A до 7 трезора (неговите старейшини), които приемат A и се съгласяват с B, след това изпращат съобщение C до отдалечена секция, за да “направи D” и т.н.

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


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

SAFE Network новини - 27.8.2020

Накратко

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

  • CRDT Tree хранилището вече е публично достояние и контейнера е публикуван на crates.io :tada:
  • Продължава преструктурирането на кодова база за Маршрутизирането и Трезорите, за да се използва асинхронизация.
  • Работата по преструктурирането на преместването на маршрутизирането и премахването на Парсек ще бъде комбинирана в един PR, като това вече е в последните етапи на разработване.
  • Подготвихме предварителен преглед на ‘Менюто за работа‘ от потребителския интерфейс на SAFE Network програмата.

CRDT

safe-fs

Прекарахме седмицата в писане на тестове за потвърждаване коректността Tree CRDT типовете данни, както и незначително преструктуриране, за да направим API-то по-чисто и да намалим броят на clone() повикванията. Всички аспекти на CRDT (идемпотентност, комутативност, асоциативност) вече преминават тестовете, както и други специфични Tree тестове, посочени в академичния труд. В GitHub е създадено crdt_tree хранилище и контейнера е публикуван на crates.io :tada:

С приключването на Tree CRDT, фокусът ни вече може да се насочи към слоя на файловата система, който ще го използва.

SAFE Клиентски библиотеки и Трезор

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

SAFE Клиентски библиотеки и интеграция на Трезора

През последната седмица работихме върху някои по-малки промени, за да сме готови за новия асинхронен quic-p2p, и някои подреждания на CI хранилището, както и върху подобряването на обработката на съобщения в клиента. Основната работа по преструктурирането ни доведе до точка, в която можехме да получаваме отговори на заявки от целия раздел, макар че това доведе до проблем, ако не се получаваше отговор от Старейшина (не се получаваше какъвто и да е отговор … въпреки че всъщност имахме шест ). Затова използвахме някои от future опциите на Rust, за да проверим кои отговори имаме, когато постъпят, и след това да изберем най-подходящите отговори от тези, които получаваме от старейшините. Това ни приближава до ‘кворум‘ версия на отговора и означава, че можем да го върнем веднага щом го получим, без да се налага да чакаме всички 7 старейшини да отговорят.

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

Асинхронизация на Трезорите и тестове

Преструктурирането на кодовата база за маршрутизацията и Трезорите, за да се използва асинхронизация, напредва добре. Успяхме да започнем да използваме новото асинхронизирано API на quic-p2p и имаме излагане излагане на async API-то при Маршрутизирането, което Трезора използва за получаване на мрежови съобщения. В момента се опитваме да завършим свързването на логиката за обработка на съобщенията за маршрутизация в това ново изпълнение. Досега успяхме да накараме клиентите и трезорите да разговарят помежду си и почти приключихме с повторното активиране на процеса на първоначално стартиране, над който ще работим през следващите няколко дни.

Тъй като работим паралелно върху целия стек, от quic-p2p, през маршрутизиращ слой и Трезорите, докато напредваме и тестваме всички тези промени, правим корекции на всеки от тези слоеве, ако е необходимо, което е същото, което наскоро направихме с новото асинхронно API на quic-p2p при тестване на трезорите, които се опитват да стартират първоначално.

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

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

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

По време на работата от миналата седмица за използване на рамката за тестване на Трезорите за проверка на поведението на маршрутизацията при реална употреба на мрежата, открихме някои проблеми. Първият беше свързан с dkg_voter и беше разрешен с PR за записване на завършен DKG section_key_index. Друг проблем е, че нулираме parsec консенсуса на SectionInfo и OurKey, но това вече не са parsec събития, което означава, че не са силно подредени спрямо други събития. Това ще бъде решено, след като премахнем parsec.

Също така работим за подобряване на устойчивостта на DKGVoter срещу злонамерената атака в Акомулиране на DKGOldElders съобщения PR, който бе обединен днес.

Работата по преструктурирането на преместването продължава, като Адам прави голям напредък там. Докато разрешавахме неуспешни тестове, осъзнахме, че би имало смисъл да се премахне parsec едновременно, в същия PR, тъй като разделянето на работата се оказва особено сложно и е загуба на ресурс, да се опитваме да го накараме да работи докато parsec е все още на място. И така, окончателният PR, който все още не е готов да бъде официално повдигнат, ще съдържа както работата по преместването на преструктурирането плюс премахването на парсек. Адам ще почива през следващата седмица, така че тази работа ще бъде предадена на Qi за финализиране.

SAFE Network App UX

Проследяване на функциите / Екрани и движение на потребителя

Тази седмица ви показваме предварителна функция, която е по средата на процеса на проектиране. Няма да я намерите в линка към Екрани и движение на потребителя публикуван по-горе, но тя отмята доста от задачите по пътя към Минималното устойчиво изживяване (MVE), което изграждаме, и може да се окаже доста полезен модел на дизайна, особено когато започнем прехода към потребителските интерфейси за работния плот.

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

Достъп до Менюто за действие се осъществява от големия бутон долу вляво …


Елементите в това меню могат да бъдат кликнати / докоснати чрез основните елементи на менюто по начина, по който може да очаквате …

Но тук започва забавата, тази лента за въвеждане в горната част ни позволява да възприемам по-текстови подход, търсейки в елементите от менюто и командите:

И може да стигнем още по-далеч, като напишем по-специфична команда на естествен език. В този пример превеждаме някои средства от портфейла си на приятел:

Което след това ще ни придвижи до края на потока на плащане, с коригиращо обобщение, готово за изпращане:

Освен това виждане история на това, което сме търсили тук, за бърз достъп до скорошни действия:

Освен това може да фиксираме команди към началния екран на менюто, за още по-бърз достъп до команди, които искаме да са ни под ръка:

Освен това, малка екстра, която може да забележите при отворено меню за действие, е, че бутонът за затваряне в долния ляв ъгъл може да се влачи / придвижва, за да излезе потребителят от сесията.

Идеята е да разширим този жест до самия бутон в менюто за действие, позволявайки на потребителя да го задържи и придвижи бързо, за да излезе бързо от почти всяко място в приложението.


И така, надяваме се да сте харесали до къде сме стигнали. Менюто все още е доста грубо, но ще бъде усъвършенствано и обновено през следващите седмици. Кажете ни какво мислите!

Стандартизация

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

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

Тези промени ще бъдат направени през следващите дни/седмици.


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

SAFE Network новини - 3.9.2020

Накратко

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

  • Завършихме с промените в Маршрутизацията, необходими за работата на async API-то, като остават само някои незначителни проблеми, които трябва да бъдат отстранени, преди да ви потвърдим, че тази задача е изпълнена.
  • Повдигнахме PR за премахване на parsec, като работим за разрешаване на неуспешни CI тестове.
  • Променяме името на мрежата на Safe Network (за разлика от досегашното SAFE Network).

CRDT

safe-fs

Тази седмица фокусът се върна към файловата система, която ще интегрира CRDT дървото с FUSE. Внедрено и тествано е решение, което кодира едновременно replica_id и inode идентификатор в едно 64-битово неподписано цяло число, използвано от FUSE API-то. Това решение изисква по-малко справки и по-малко код от оригиналния дизайн. Подробности

Извършихме и някои тестове на конфликти на имена на файлове между реплики. В CRDT дървото името на файла е само метаданни и може да бъде дублирано. Но във файловата система не е добре да имате два записа в директорията с едно и също име. Засега работим със стратегия за разрешаване, която последният записва, за да запази оригиналното име на файл и всеки губещ се преименува на „<име на файла>.conflict. <replica_id>“. Подробности

И накрая, работата по внедряването на файловата система в Rust + Fuse започна. Засега използваме библиотеката polyfuse, но това може да се промени. С напредването на тази работа най-накрая ще бъде възможно монтирането и записването в локална файлова система, базирана на crdt_tree, което беше нашата цел от Фаза 1.

Safe Клиентски библиотеки и quic-p2p

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

Започнахме да документираме Safe Клиентските библиотеки, напредвайки с Rust doctests (документация, която се проверява от компилатора и може да бъде тествана като част от CI) за големи части от API-то там. Въпреки че самият SCL все още няма да бъде напълно стабилен, докато не получим напълно актуализиран quic-p2p там, това ни дава някои гаранции за кода, който сега използваме за CI още веднъж. Поправени са и някои други проблеми с качеството на кода, както и някои преструктурирания там.

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

Успоредно с това, също започнахме да надграждаме останалите ни хранилища, за да използваме async quic-p2p, като по този начин ги правим и асинхронни. BLS-DKG е хранилище, върху което работим в момента - започнахме да го актуализираме до асинхронизиране, като го приспособим към новите API-та и функции на quic-p2p.

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

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

Адам постигна голям напредък в работата по премахване на парсек (плюс преструктурирането на преместването), преди да излезе в отпуск в края на миналата седмица, и повдигна PR процес за премахване на парсек. Има някои неуспешни тестове поради огромния обхват на преструктурирането, които трябва да бъдат разрешени, преди да се счита за готов за цялостен преглед и обединяване.

След като Адам е в отпуск тази седмица, Qi се зае със задачата да разреши тези неуспешни тестове, като повдигна PR WIP за премахване на parsec за пребазиране и разрешаване на откритите проблеми . В този момент модулните тестове преминават успешно, като Qi сега работи върху неуспешните тестове за интеграция. Напредъкът е стабилен и се надяваме да видим тези CI :white_check_mark: постепенно да се появяват отново за тази критична работа по преструктурирането.

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

Променяме името на Safe мрежата

Както повечето от вас знаят, името на мрежата е съкращение, образувано от фразата: Secure Access For Everyone (Безопасен достъп за всеки). Досега, когато говорихме за мрежата, изписвахме това с главни букви, като SAFE мрежата.

Но в други области ще го видите с малки букви, например Safecoin или MaidSafe.

Няма строги правила относно начина, по който трябва да се използват съкращения, и никога досега не сме го стандартизирали, но сега отправяме призива да започнем да използваме името изписано като Safe Network . Надяваме се и вие да го направите.

Може да изглежда тривиално, но има няколко причини, поради които смятаме, че си струва да го направим:

  • Safe Network и Safe е много по-ергономично. Използването на абревиатурата с главни букви не е подходящо в много обстоятелства, тъй като става по-малко четимо и по-малко разбираемо. Напр. #SAFENetwork срещу #SafeNetwork, SAFEID срещу SafeID.
  • Значението на съкращението е вградено в дефиницията на самата дума; Все още можем да обясним, че е съкращение, когато имаме нужда, но не жертваме ергономията за общо ползване.
  • Думата safe олицетворява и проекта, което е добре. И това е „Safe Network“, написана така, както се произнася, което искаме да спазваме.
  • Намираме се в технологичен свят, който страда от изобилие от съкращения и инициализъм и понякога може да направи нещата почти непроницаеми. Така че, ако нямаме нужда да изведем съкращението, не трябва.
  • Всъщност вече го използваме по този начин на много места: Safecoin, MaidSafe, SafeID, имена на хранилища и т.н. Би било хубаво да нямаме този странен микс.

Така че щастливи Safe хора вашият shift бутон от клавиатурата ще ви благодари! :wink:

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

SAFE Network новини - 10.9.2020

Накратко

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

  • Основния PR за преструктуриране премахването на parsec е обединен в главен клон на маршрутизацията. :tada:
  • Интеграцията safe_fs FUSE напредва добре, след като внедрихме в паметта (локална) файлова система с доказателство за концепция, използвайки crdt_tree, която поддържа редовни операции с директории и файлове, плюс символни връзки и твърди връзки.
  • Превключването на safe_vault контейнера, към парадигмата async / await, вече е в ход, като прехвърлянето почти е направено, а интеграцията с другите асинхронни контейнери напредва добре.

CRDT

safe-fs

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

Може би по-вълнуващо, работата напредва по интегрирането на safe_fs FUSE. Успяхме да внедрим доказателство за концепцията в паметта (локална) на файловата система, използвайки crdt_tree, която поддържа редовни операции с директории и файлове, плюс символни връзки и твърди връзки. Остава много работа, но е добро постижение да бъдете в състояние да монтирате файловата система и да взаимодействате с нея.

Safe Клиентски библиотеки и qp2p

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

През последната седмица отбелязахме по-нататъшен напредък в quic-p2p (сега: qp2p), като потоците бяха изложени, за да позволят прослушване на мрежовите събития. Повторното използване на потоци за множество съобщения, което беше добавено наскоро, изискваше дължината на съобщението да бъде известна предварително. За да улесним това изискване, заедно с други метаданни, като флагове за съобщения, сега сме формализирали заглавията на съобщенията, които ще бъдат изпращани по мрежата, преди да се изпратят самите съобщения. Форматът е следния:

Version Message length User message flag Reserved
2 bytes 4 bytes 1 byte 2 bytes

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

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

Успоредно с това, оправихме някои проблеми по отношение на Непрекъсната Доставка, хващайки проблем с генерирането на промени в Safe-ND (сега: sn_data_types) и поправихме генерирането на GitHub версии. Това повече или по-малко завършва първия CD процес за едно от нашите Rust хранилища, така че ще се стремим да го разпространим към другите, тъй като наистина опростява нещата там.

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

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

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

Тази седмица обединихме основното преструктуриране за премахване на parsec в главния клон :tada:

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

Успоредно с това работата по излагането на async API-то вече се основава на най-новия главен клон. След като бъдат разгледани някои последни незначителни проблеми, този PR ще бъде прегледан и обединен. Намерението ни е, че всяка по-нататъшна неуспешна работа по разследване / разрешаване на тестове за маршрутизация ще се основава на премахването на parsec и async API-то. Това ново async API вече се използва за тестване на трезори и клиенти, което доказва, че сме на прав път.

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

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

Стандартизация

Преди няколко седмици споменахме, че предприемаме някои задачи за преименуване на хранилища и контейнери, за да ги стандартизираме. Всеки, който следи нашата дейност в GitHub, ще забележи, че през последната седмица направихме голяма крачка напред, тъй като по-голямата част от нашите хранилища и Rust контейнери сега са актуализирани до snake_case, с префикс sn_, ако е специфична за Safe Network, и двойка (засега), преименувана за да е по-точна (safe-network-signature-aggregator → bls_signature_aggregator и safe-nd → sn_data_types).

Останалите хранилища и контейнери ще бъдат актуализирани през следващите дни, ако приемем, че можем да се договорим как да ги наречем :smiley:


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

SAFE Network новини - 17.9.2020

Накратко

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

  • Успяхме да клонираме crdt_tree хранилището и да го изградим с cargo build в прототипа на safe_fs файловата система, окуражаващ резултат в развитието му.
  • Новите ни асинхронни компоненти си взаимодействат повече всеки ден, като Safe Клиента вече може да получава събития и грешки от мрежата, а трезорите вече обслужват събития.
  • Напълно асинхрония трезор направи огромна стъпка тази седмица с този PR, който беше повдигнат и сега преминава през нашия процес за преглед.
  • Днес беше повдигната значителна корекция на грешки в маршрутизирането - PR, което разрешава почти всички грешки от премахването на parsec.

CRDT

safe_fs

Работата по прототипа (само на локално ниво) на safe_fs файловата система продължава и тази седмица. Добавена е поддръжка за специфични за OS (POSIX, Windows) атрибути на inode, напр. uid, gid, режим на POSIX и скрит, само за четене, компресиран, криптиран в Windows. Те трябва да направят safe_fs по-полезни като решение за архивиране / възстановяване на локални файлове.

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

Safe Клиентски библиотеки, Трезори и qp2p

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

Safe Клиентът вече може да слуша мрежата, използвайки qp2p потока, който е инициализиран в мрежовия bootstrap. Мрежовите заявки все още ще използват свои собствени потоци, за да поддържат обработката на отговорите гладко. Но това ни дава възможност да получаваме събития (напр. „TransactionValidated“) или грешки (напр. „InvalidTransaction“) от мрежата.

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

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

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

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

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

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

Създадохме PR, поправящ някои от грешките, останали след премахването на parsec. Той ремонтира модула DKG, като поправя някои крайни случаи и го улеснява, като същевременно решава някои проблеми около преместванията. Тестовите неуспехи спаднаха доста с този PR, но все още не са на нула. Има още работа за вършене, но изглежда се свързва добре с работата по CRDT, която започнахме.


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

SAFE Network новини - 24.9.2020

Накратко

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

  • Преименувахме контейнера safe-vault на sn_node.
  • В sn_node отново активирахме CI системата за множество от нашите тестове, което ни дава всички node тестове на всички платформи и почти всички e2e тестове.
  • В Маршрутизирането разрешихме останалите неуспешни единични тестове от премахването на parsec, остават само няколко неуспешни теста за интеграция, с които да се справим.
  • Маршрутизиращият PR за излагане на асинхроното API вече е обединен в главния клон. :tada:

CRDT

sn_fs (досега наричана safe_fs)

Тази седмица беше направено допълнителна настройка на поддръжката на файловата система. Също така беше взето решение предстоящия контейнер да се нарече sn_fs за съгласуваност с други контейнери, които споделят префикса “sn_”.

Safe Клиентски библиотеки, Възли (досега наричани Трезори) и qp2p

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

Тази седмица приключихме дискусиите дали safe-vault е най-доброто и най-точното име за контейнера. Тези дискусии по този контейнер всъщност продължиха няколко седмици, като бяха обсъдени няколко предложения. Спряхме се на sn_node, тъй като вярваме, че той показва точно това, което е тази контейнер, в най-опростения смисъл - това е “възел” в Safe мрежата. Всеки, който е запознат с peer-to-peer мрежите, ще разбере този технически точен термин и какво означава той.

И така, при Възлите тази седмица преструктурирахме малко обработката на клиентските събития и след това ги обединихме в основния контейнер. С това и след някои други малки поправки на тестовете, отново активирахме системата CI за подмножеството от тестове, което ни даде всички тестове на възли на всички платформи и тестове от край до край (e2e) на Ubuntu и Windows. Това е чудесно, тъй като не само ни връща към правилното тестово покритие за по-солидни PR отзиви, но всъщност това е нещо, което никога досега не е работило правилно срещу самите възли като част от CI. Занапред ще стабилизираме това на всички платформи (понастоящем macOS е проблематичен) и ще дадем възможност за тестове от страна на клиента срещу възлите, докато ги задействаме отново.

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

Маршрутизация

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

В Маршрутизирането тази седмица работата по отстраняване на някои грешки около DKG и преместване, споменати в новините от миналата седмица, бяха обединени, оправяйки повечето неуспешни тестове. В допълнение към това имаше още два PR-а (корекция на преструктурирането по премахването на parsec и симулиране на натрупване на dkg_result), които също бяха обединени, разрешавайки всички останали проблеми от тестовете, оставяйки само няколко неуспешни теста за интеграция.

Освен това обединихме работата, която извършихме по излагане на асинхронния API :tada:. Няколко корекции и подобрения бяха направени, за да го направим готов през последните дни и седмици и вече имаме асинхронното API за маршрутизация на място и функциониращо, образувайки Секция, когато се използва с реализацията ни на възел.

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

Safe Network програма и UX

Проследяване на опциите / Екрани и потоци

Тази седмица продължихме работата по интегрирането на функцията Action Menu в прототипа за проектиране на Safe Network програмата. Ще видите как започва да се оформя във Figma файла през следващите седмици, тъй като дизайнът е усъвършенстван и подобрен.

Също така бяхме доволни да си сътрудничим с други дизайнери в Decentralization Off The Shelf семинар тази седмица.

С помощта на екипи като нашия този проект има за цел да изгради библиотека от дизайнерски модели, които решават проблеми, общи за децентрализираните мрежи.

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


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

SAFE Network новини - 1.10.2020

Накратко

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

  • Файловата система за Safe мрежата направи голяма стъпка напред към публично представяне, като сега беше обединена към главния клон и преминава през последния етап на тестване.
  • Преименувахме хранилището Safe Client Libs / контейнера safe_core на sn_client.
  • Поставихме основите за тестване на хаоса в sn_node.
  • Благодарности към @Scorch за 2 асинхронни приноса в sn_node, PR1105 и PR1090, през последната седмица. :clap:
  • Система за непрекъсната доставка вече е въведена почти на всички наши Rust контейнери, което означава по-чести версии за вас!

CRDT

sn_fs

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

Safe Клиент (досега наричан Safe Клиентски библиотеки/safe_core) Възли и qp2p

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

Още една промяна на име контейнер и хранилище тази седмица - Safe Клиентски библиотеки вече е преименуван на sn_client. Тези „библиотеки“ преминаха през огромна трансформация през последните месеци с масивно преструктуриране и опростяване от екипа, както е документирано в седмичните новини, и ни остава само контейнера safe_core. Преименувахме както хранилището, така и контейнера на sn_client, за да го приведем в съответствие с това, което сега представлява, и с другите преименувани хранилища и контейнери. С това задачата за преименуване вече е повече или по-малко завършена, като единствените неизпълнени действия са да се публикуват няколко от преименуваните контейнери, а именно sn_routing, sn_client и sn_node, които задържаме, докато ги счетем за достатъчно стабилни за публикуване на нова версия.

Тази седмица напредваме повече в интеграцията на възел / клиент, премахвайки грешки, докато активираме e2e тестовете един по един, за да увеличим покритието на кода. Открихме няколко проблеми в Replica Management, които ни пречеха да накараме клиентите да плащат за запис на данни. Поради това се заехме да рационализираме AT2 тестовете за трансфер, като се фокусирахме главно върху операциите за прехвърляне и премахнахме всички и всякакви несъответствия в Секцията. След като оправим това, следващите стъпки ще бъдат да обхванат операциите на слоя данни и да въведат тестване на хаоса, за да засилят цялостта навсякъде. Положихме основите на същото в PR # 1124, който въвежда нов флаг за хаос в контейнера, за да позволи тестване на хаоса. Веднъж активиран, той отчита нивото на хаоса от променливата на средата SAFE_CHAOS_LEVEL, която диктува вероятността хаосът да бъде предизвикан в мрежата чрез произволно пускане на съобщения / неизпълнение на операции.

От друга страна работихме по добавянето на някои функции към qp2p, следвайки парадигмата async / await. По време на миграцията към използване на async / await във всички наши контейнери, мигрирахме само модулите, които бяха незабавно необходими. След като приключихме видяхме добри резултати и се интегрира добре с останалите слоеве. Сега, след като вече започнахме да тестваме системата от край до край, скоро ще ни трябват функции като използване на протокола IGD и ехо услуга за автоматично пренасочване на портове, което е важен компонент при стартиране на тестови мрежи. Тези функции са внедрени и тяхната интеграция в момента се тества с останалите слоеве.

Благодарности към @Scorch за PR1105, което не само оптимизира, но и кара модула за съхранение на парчета да следва асинхронната парадигма в sn_node. Освен това @Scorch също има PR, обединен през тази седмица, който прави заявения файл I / O async :clap:

Винаги е много мотивиращо за екипа, когато видим подобен принос и осъзнаем колко много означава този проект за всички нас :muscle:

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

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

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

Наред с горното, продължава и работата по опростяване на кодовата база чрез пълното премахване на id.rs файла и въведем подръжкавъв възлите на Keypair и SocketAddr за възлите. Първият етап от това беше да се отървем от чертите на id в контейнера bls_dkg - това вече е обединено. Частта за маршрутизация на това преструктуриране продължава, като PR се очаква да бъде повдигнат скоро.

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

Непрекъсната доставка

Още в края на юли внедрихме система за непрекъсната доставка (CD) в един от нашите Rust хранилища за първи път. След първоначалната настройка се убедихме, че системата е стабилна и носи голяма полза за проекта. Тази седмица завършихме разпространението на CD за всички, освен за едно от нашите Rust хранилища :tada:

Чудите се какво означава този процес на CD системата? Когато всяка заявка за изтегляне се обедини, за да се управлява в хранилище с активиран CD, нашата автоматизация на CD системата се включва. CD генерира дневник за промени, съдържащ всички валидни актуализации, добавени от последното издание, установява до коя версия трябва да се актуализира контейнера , и генерира PR актуализация до тази версия. Тя автоматично обединява този PR и създава съответстващ GitHub таг и издание на нова версия. И накрая, самия контейнер се публикува в crates.io. Всичко това автоматизирано, без да е необходима човешка намеса. Това означава, че ще започнете да виждате много по-чести издания, доближавайки този цикъл на обратна връзка с общността, доколкото е възможно.

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

Имайте предвид, че не сме обединили PR на CD системата за sn_routing, [ sn_client](MaidSafe · GitHub sn_client / pull / 1268) и sn_node все още, като ги задържаме, докато тези хранилища, които в момента са в период на промяна, се считат за стабилни и могат да започнат автоматизирани издания.


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

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 общност: SAFEnetwork България | Facebook
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България
1 Like

SAFE Network новини - 15.10.2020

Накратко

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

  • Започнахме да изпълняваме множество вътрешни тестови мрежи, които обединяват всички различни компоненти на мрежата. Това ни помага да проследим проблемите и да ги разрешим.
  • Работата по Authd, CLI и API продължава, за да ги приведат в съответствие с последните промени на клиента и възела.
  • Експериментираме с показателите на динамична стойност за StoreCost, за да направим разходите за запис на данни в мрежата зависими от множество фактори.
  • Насочваме се към нова употреба на CRDT във Византийска обстановка за мрежа без нужда от позволение - прочетете раздела за маршрутизиране за повече подробности за това вълнуващо развитие!

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

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

Преструктурирането на authd, CLI-то и API-то продължава. Вече имаме основната комуникация, работеща между authd и CLI, като случайните ключове се генерират и предават между тях. Следващата стъпка тук е възстановяването на основното хранилище за удостоверяване с помощта на стандартните ни API-та (по-рано имахме куп специфични API-та, които добавиха много сложност към кода). Така че сега работим за това, което също засяга използването на API-то от различни типове ключове и го прави по-общо (така че можем да използваме например ed25519 или BLS ключове).

От страна на интеграцията, добавяме още корекции към sn_client и sn_node, продължавайки работата от миналата седмица. С по-стабилното стартиране на Секция с всички актуализации на маршрутизацията, успяхме да обединим всички модули и за да работят като едно цяло. По време на това вътрешно тестване беше разкрита малка грешка в sn_transfers на Actor, която при оправянето й ще замени агрегатора, който въведохме миналата седмица като част от трансферите на AT2. Друга голяма промяна, която предстои, е в преминаването от статични разходи за запис към динамична StoreCost стойност. Това означава, че разходите за запис на данни в мрежата вече ще бъдат динамични, което отчита множество фактори като предлагане / търсене на съхранение в мрежата, брой байтове, които трябва да бъдат записани и т.н. Клиентите ще пускат запитване към мрежата за тази сума преди да изпратят част от данните към нея, ще проверяват за достатъчен баланс и ще заплащат за качването. Експериментираме около показателите, за да започнем с разумна цена за качване в тестовата мрежа.

„qp2p“ също получи своя дял от любовта ни тази седмица. Промените в асинхронното UPnP API са интегрирани в routing и sn_node. Това ни помогна да идентифицираме грешка в UPnP / ехо услугата, която не работеше според очакванията. Двете се правеха последователно, вместо паралелно и тъй като UPnP винаги се проваляше в рутери, които не поддържат UPnP, цялото стартиране винаги се проваляше. Имаме решение за това. Както бе споменато по-горе, започнахме с някои вътрешни тестови мрежи, които включват всички промени тази седмица. Това ни помага да приведем всички модули в действие и да поправим грешките, които биха могли да бъдат пропуснати в тестовете на отделни модули / интеграция. Ако нещата вървят добре (трудно за предвиждане!) ще пуснем тестова мрежа, в която да се включите скоро. :slightly_smiling_face:

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

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

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

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

Що се отнася до CRDT, се насочваме към нова употреба на CRDT Византийска обстановка за мрежа без нужда от позволение. Това означава стриктното използване и конкретните определения на Авторитети. За нас това са Възел, Клиент, Секция и Мрежа. За да осигурим неопровержимост и предотвратяване на измами, ние ще подпишем цифрово Точка <Актьор, u64> и самата Операция (Добавяне (актьор)). Това ни позволява да се сближаваме в периоди на безумно висок отбив (напускане на трезори), което е нещо, което се надяваме никога да не се случи, но може.

Също така въведохме метод, подобен на AT2, който се нарича DSB (Детерминистично защитено излъчване) и който може да ни позволи да направим нещо съвсем различно от сега и Възрастният да управлява този DSB, за да получи мнозинство, за да се присъедини към CRDT на Старейшините. Това намалява много работата за маршрутизацията. Освен това можем да видим, че мнозинството се е съгласило за нов набор от Старейшини (Реплики) и е започнало DKG рунд, за да актуализира SectionChain.

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

Всичко на всичко това е изключително вълнуващото и трябва да ни даде невероятно солиден слой за маршрутизация.

Подмножество от горното означава, че всички данни могат да бъдат BFT, както и да се приложи NetworkAuthority, за да се позволи повторното им публикуване (потребителят ще плати на мрежовия орган).


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

SAFE Network новини - 22.10.2020

Накратко

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

  • Вътрешните тестови мрежи продължават да ни помагат да провеждаме обстойни тестове и да откриваме проблеми.
  • Показателите на Dynamic StoreCost са почти установени след първоначалните ни експерименти.
    Някои основни PR-и за преструктурирането на Маршрутизирането тук и тук бяха обединени към основния код тази седмица, улеснявайки четенето и разбирането и следователно отстраняването на грешки, въвеждането на нови хора и участието им.*
  • Наемаме отново CRDT консултанта, който ще ни помогне с основната ни цел - създаване на мрежа без нужда от позволение съставена от автономни агенти, които съвместно съхраняват CRDT данни.

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

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

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

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

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

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

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

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

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

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

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

Извършихме още тестове и експерименти с CRDT PoC, този път експериментирайки с различни видове механизми за съобщения, когато се гласува за отстраняване на старейшина. Опитваме се да използваме proptest, за да ни помогне да докажем / валидираме, че тези механизми могат да работят по очаквания начин в крайни случаи.

Тази седмица също прекарахме известно време, работейки върху отделен PoC за динамично членство в секция, използващ разпределено сигурно излъчване (от AT2 документа), за да осигурим византийска толерантност. Нашето bft-crdts внедряване вече поддържа постигане на консенсус за добавяне на партньор, така че задачата ни е да добавим поддръжка за премахване на членове. Член може да бъде отстранен доброволно или принудително, ако се установи, че е повреден. И двата случая изискват рунд от гласувания, за да се постигне консенсус, но последният е по-сложен, тъй като всеки партньор с право на глас също трябва да открие, че партньорът е дефектен. Имаме някои обнадеждаващи предварителни резултати, но това продължава да е работа, която очаква завършване.

Още новини…

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

Спряхме се на 3 промени, които трябва да направим в rust-crdt, за да постигнем тази цел:

  1. Всички причинно-следствени CRDT трябва да бъдат модифицирани, за да отхвърлят операциите, които са доставени извън „причинно-следствения“ ред, и да докладват обобщение на липсващите оперативни операции, необходими за прилагане на дадената операция.
  2. Премахване на вътрешното буфериране на неизправни операции в ORSWOT и Map.
  3. Въвеждане на причинно-следствена бариера, за да върне поведението на буферирането за потребители, които разчитат на автоматичното буфериране, извършено в ORSWOT и Map.

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

  1. Всички причинно-следствени CRDT, присъстващи в rust-crdt, ще бъдат втвърдени, за да отхвърлят неработещи операции.
  2. Всички причинно-следствени CRDT, присъстващи в rust-crdt, ще бъдат модифицирани, за да отговорят с обобщение на зависими операции, които липсват, преди да може да се приложи операция.
  3. ORSWOT и Map ще бъдат модифицирани, за да се премахне вътрешното буфериране.
  4. Ще се приложи CausalityBarrier, за да се добави обратно буфериране по избор.

Забележка - моля, уважете правото на лично пространство на консултанта и не спекулирайте с имена. :slightly_smiling_face:


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

SAFE Network новини - 29.10.2020

Накратко

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

  • Safe мрежата получи Наградата за най-вълнуващия dWeb проект от Noonies 2020. :tada: Нашите благодарности към всички гласували.
  • Добавихме първите си проптестове към sn_routing и sn_data_types и сме ентусиазирани от помощта, която ще донесат на проекта.
  • Напредъка по вътрешните ни тестове продължава, като фокусът леко се превключва към подобряване на производителността.
  • Извършваме по-значимо преструктуриране и втвърдяване на кода в sn_routing, главно около DKG процеса.

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

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

Продължавайки с работата от миналата седмица, внедрихме промяна, която премахва PublicId и ClientFullId от sn_data_types, вместо просто да разчитаме на Keypairs за идентифициране на клиенти и възли. Тази промяна е разпространена в различните контейнери и вече е налице.

След като приключихме с това преминахме към по-задълбочено тестване на нашите типове данни, започвайки с настройването на proptests за типовете данни за последователността - вж. нашият PR тук, който в момента преминава през процеса ни за партньорска проверка.

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

Тази седмица също завършихме внедряването на флаговете --fresh и --clean, които ни помагат да предотвратим използването на по-стари qp2p конфигурации. Флагът „–fresh“ запазва по-старите конфигурации на диска, без да ги използва. Флагът “–clean” изчиства всички по-стари конфигурационни файлове на диска. И двата флага използват конфигурацията по подразбиране или новата конфигурация, предадена чрез други аргументи на командния ред. Това вече си проправя път чрез тестване и преглед в sn_node и qp2p.

Междувременно работим по укрепване на системата за трансфери за постигане на последователност, ефективност и анонимност. :hammer_and_wrench:

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

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

Тази седмица обединихме доста работа от преструктурирането, обхващаща предимно DKG частта от маршрутизирането. Работата по преструктурирането, допълнителните тестове и DKG поправката премахна модула rng, и го замени с rand::thread_rng и преструктурира някои други модули и помощни функции за опростяване на кода. Работата по извличане на по-голямата част на DKG логиката от Approved в DkgVoter допълнително опрости дългия ʻApproved.rs` и разшири тестовия DKG пакет да обхващат повече сценарии.

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

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

safenetwork.tech обновления на английския сайт

Малко информация относно няколко актуализации на английския уебсайт safenetwork.tech, направени тази седмица.

Първо, добавихме базираната в Обединеното кралство фирма за крипто брокерство BC Bitcoin като нова опция за покупка и продажба на MAID. Може да забележите, че връзката към техния сайт се е добавена на страницата Safecoin, както и в няколко от страниците с често задавани въпроси.

Вторият пакет с обновления PR, който беше обединен днес е опит да приведем съдържанието на сайта малко повече в съответствие с текущото състояние и посока на проекта. Този уебсайт (и други) са пренебрегнати в последно време, тъй като фокусираме цялата си енергия към целите на Флеминг, което знаем, че разбирате. Сметнахме, че си струва да отделим малко време, за да направим няколко бързи актуализации, които бяха предложени във форума няколко пъти наскоро. Осъзнаваме, че все още се изискват няколко допълнителни актуализации, наистина смятаме, че голяма част от съдържанието може да претърпи основен ремонт, но не искаме да се разсейваме прекалено много сега, така че ще се върнем към това в близко бъдеще, когато времето позволява. Някои от ниско висящите плодове, които бяха откъснати:

  • премахване на споменаванията за PARSEC,
  • премахване на остарели изображения от пресата,
  • превключване на социалните връзки в Twitter и Facebook към актуалните акаунти,
  • премахване на връзки към блога,
  • премахване на опцията за регистрация за бюлетина и
  • различни текстови актуализации, за да се опитаме да отразим по-добре текущото състояние на проекта.

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

SAFE Network новини - 5.11.2020

Накратко

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

  • Въвеждането на проптестовете даде плод и някои важни проблеми бяха идентифицирани тази седмица.
  • Значителни подобрения в производителността на процеса на стартиране на мрежата са добавени тук, с допълнителни предложени подобрения в процес тук.
  • Нашият CRDT консултант отново започна да работи с нас тази седмица и се насочи директно към подобряването на детерминираното защитено излъчване (DSB) с поддръжка за динамично членство.
  • Поздрави на члена на форума @treslumen за приноса му към sn_api тук. :clap:

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

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

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

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

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

Също така с радост приехме PR от член на форума @treslumen, той премахва някои остарели кодове след последните актуализации на sn_client. Благодарим на @treslumen за това, много оценяваме помощта :+1:

Трансфери

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

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

CRDT

Тази седмица нашият CRDT консултант започна работа за подобряване на детерминираното сигурно излъчване (DSB) с поддръжка на динамично членство. Динамичното членство е процес, при който новите партньори могат сигурно да се присъединят или да напуснат група от връстници (секция) чрез гласуване/съгласие на съществуващи членове.

Случаят с напускане е най-интересен, защото включва откриване кога даден партньор е дефектен и след това другите членове гласуват за изключването му. Участник може да се счита за дефектен по много причини, включително ако не реагира, да използва грешен протокол, да изпраща лоши данни или да изпраща невалидни подписи.

Напомняне, че DSB е византийски протокол за устойчивост на измами (BFT), който в момента се използва за осигуряване на AT2 трансфери. Също така е полезен за подсигуряването на CRDT алгоритми.

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

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

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

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

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

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

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


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