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

Dimitar · May 14, 2020, 1:32am

SAFE Network новини - 7.5.2020

Накратко

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

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

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

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

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

SAFE API

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

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

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

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

SAFE Програма C#

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

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

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

CRDT

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

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

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

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

Функции в Rust

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

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

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

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

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

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

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

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

Dimitar · May 21, 2020, 3:45am

SAFE Network новини - 14.5.2020

Накратко

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

След някои подобрения пуснахме още един вътрешен тест-скрипт с Трезори от вкъщи и досега изглежда добре.
Пуснахме нова версия на пакета MaidSafe.SafeApp NuGet.
Продължихме работата по внедряването и тестването на поддръжката за празни директории, очаквайте PR.
Прехвърлихме API-то на FilesContainers и CLI командите да се съхраняват / синхронизират / четат, използвайки Sequence типа данни и всички основни ръчни тестове с локална Секция работят отлично

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

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

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

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

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

SAFE API

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

Продължава работата по внедряване и тестване на поддръжката за празни директории. Това наложи малка промяна в начина на съхранение на данните във FileContainer.

Преди това всеки запис на FileItem във FileContainer представляваше файл с линк, съдържащ SAFE URL адрес, идентифициращ обект на неизменна информация. В предложения нов код, FileItem може да представлява файл, директория или Symlink, идентифициран от типа на атрибута от метаданните. Записите в Directory и Symlink не притежават линк, така че те съществуват само във FileContainer.

Допълнителни метаданни също се създават за всеки файл, ако са локално достъпни: original_create_time, original_modified_time и unix_mode_bits. Целта на тези метаданни е да се даде възможност за архивиране / възстановяване, което запазва метаданните на локалния файл.

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

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

По поддръжката на скрити файлове (тези, които започват с .) и относителни символни връзки (линкове в FileContainer) ще работим през следващата седмица.

SAFE Програма C#

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

Пуснахме нова версия на NuGet пакета MaidSafe.SafeApp. В тази най-нова версия преименувахме XorUrlEncoder на SafeUrl и преструктурирахме съответно API-тата. Добавихме и някои нови API-та, за да генерираме URL адресите за ключове, мутационни данни, приложения и неизменни данни. Поправихме няколко проблема във функциите за обвиване на FFI, които причиняваха сривове и опростихме използването на базовите типове кодиране за URL адресите. Можете да проверите файла с промените за пълния списък с промени.

CRDT

Тази седмица внедрихме, преструкторирахме и опростихме типа данни за последователността (Sequence) и поддържаните заявки в safe-nd, а след това адаптирахме SAFE Клиентските библиотеки и SAFE Трезорите съответно. Също така се опитахме да мигрираме командите на FilesContainers API-то и CLI-то, за да се съхраняват / синхронизират / четат, като се използва последователността като основен тип данни (за разлика от AppendOnlyData) - всички основни ръчни тестове с локална Секция работиха отлично!

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

Функции в Rust

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

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

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

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

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

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

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

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

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

Dimitar · May 26, 2020, 3:04am

SAFE Network новини - 21.5.2020

Накратко

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

quic-p2p v0.6.0, включващ IGD, беше пуснат днес.
Новото, все още разработвано, safe-transfers хранилище вече е публично достъпно.
Поддръжката за PUT / GET на празни директории е добавена към CLI-то.
@jimcollinson представя актуализация за напредъка на UX на SAFE Network програмата.
Прогресът на CRDT продължава - вече сме готови да започнем да добавяме действителната CRDT логика към клиента.
Обединихме PR на модела за изтегляне в Маршрутизирането, като направихме актуализациите на секциите по-стабилни и ефективни.

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

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

През последната седмица се съсредоточихме основно върху прилагането на начина, по който Трезорите обработват данни, когато Възрастните се присъединят и напуснат мрежата. Това се оформя добре и около 80% от работата е завършена. Има само още няколко неща, които трябва да се разгледат и разбира се много тестове, преди промените да бъдат публикувани. Това ще се впише добре с най-новите промени в quic-p2p, които въвеждат пренасочване на портове с помощта на IGD. Нова версия на quic-p2p беше пусната днес с тези нови функции. Вече приключихме тестовете за интеграция с Маршрутизацията и Трезорите в последните няколко вътрешни тестови мрежи и очакваме следващите тестове, които ще включват и обработката на данните. Очакваме тест с общността, в който тези функции ще са включени, така че се навъртайте наоколо!

SAFE API

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

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

Междувременно понастоящем локално се тества корекция за NRS пътища във files ls (издание 510).

И накрая, направихме малко преструктуриране в интерфейса на чужди функции (FFI), който представя FilesMap като основен тип данни, а не JSON низ.

SAFE Програма C#

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

Както бе споменато в секцията SAFE API по-горе, тази седмица преструктурирахме отново API-та на Files, за да върнем FilesMap инстанция вместо JSON низ. Това опростява използването на API-тата на Files, тъй като разработчиците могат директно да заявяват данните от FilesMap, вместо да преминават през JSON операции.

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

SAFE Network програма UX

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

Тук сме насочени към функционалността, така че макар да се стремим да добавим в UX-то малко „SAFE“ брандиране, това никога не трябва да е за сметка на използваемостта и функционалността.

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

03f69af4c819fb6edf7c0f52961b872cb03ee001_2_318x500

77be89fc8a9c30f8c48ff3e9107c3d5ed78a7073_2_203x499

88d55c91dbec3e97e80b9562a09dc334c2815130_2_318x500

c820081306f58744dacb22f2251bb6062062565f_2_318x500

CRDT

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

В допълнение към това, мигрирахме NRSContainer и FilesContainers (в safe-api), за да започнем да използваме Sequence типа данни и успяхме да проверим дали всичко рабтестова мрежа.

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

Трансфери

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

Кратко описание

Имаме Актьори и Реплики, които да изпълняват различните стъпки на AT2 алгоритъма. Процес Актьор се управлява от клиент и той инициира прехвърляния от неговия ключ към друг ключ. Репликите се управляват от мрежовите възли - по-точно Старейшините на секция - за да валидират заявката и да използват няколко подписа, за да докажат съгласието си за нейната валидност.

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

Следва

Сега работата ще продължи с тестване и гладене на подробности около обработката на ключовете на секциите за техния Актьор процес.

Връзки

Функции в Rust

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

safe_authenticator и safe_app също се компилират сега, като се извършва преобразуване на тестовите пакети и вече сме в началото на преобразуването на safe_authenticator_ffi.

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

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

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

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

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

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

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

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

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

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

Dimitar · June 4, 2020, 3:53am

SAFE Network новини - 28.5.2020

Накратко

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

В момента разглеждаме премахването (или поне значително намаляване) на използването на Parsec в библиотеката за маршрутизиране.
Почти сме свършили с мигрирането на SAFE Клиентските библиотеки, за да преминем към функции на асинхронизация и да изложим неговото API също асинхронно.
Въведохме подход за поддръжка на символни връзки, което е почти същото като това, което прави git. Също адаптираме кода в safe-api, което извиква основното API на SAFE Клиентските библиотеки. След това трябва да можем да пуснем нова версия на SAFE CLI-то
Очакваният окончателен BLS-DKG PR вече е завършен и се преглежда, като контейнера се счита за готов за използване в мрежата, след като това бъде одобрено и добавено.

Проблеми с форума

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

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

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

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

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

SAFE API

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

Поддръжката за символни връзки идва

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

Този първоначален подход трябва да:

позволи относителни връзки вътре в дървото на директории, при качването им
конвертирате абсолютни връзки в относителни връзки вътре в дървото за качване.
конвертирате връзки извън дървото за качване в реални файлове.

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

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

За момента качването и извличането на символни връзки работи върху Unix платформи. Windows се държи малко по-различно, така че ще ни отнеме малко допълнителна работа през следващата седмица.

Под капака

Работихме и върху адаптирането на кода, който включва основното API на SAFE Клиентските библиотеки, тъй като той е мигриран, за да излага асинхронизиращи API-та. Стремим се да приключим тази седмица и да бъдем готови да пуснем нова версия на SAFE CLI-то, което носи няколко подобрения и нови функции, които да изпробвате.

Поправки

PR 562: коригира NRS способността на вложени подимена.
PR 558: files ls сега откриват NRS URL адреси правилно.

CRDT

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

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

Трансфери

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

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

Разширение на този проблем беше проверката на резултатите от отдалечена група копия (в по-горните слоеве, известни като отдалечена секция). Оказва се, че е и въпрос за членство, макар и не членство в копия / секции, а системно членство. Следователно това е и функционалност, осигурена от горния слой.

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

Функции в Rust

През последната седмица се наблюдаваше бурна дейност със събирането на нещата в асинхронизацията. Цялата SCL се компилира добре и вече CI тестовете преминават успешно.

Завършихме актуализациите на самокодирането, обединени в главната и нова версия на кода (от който зависят SAFE Клиентските библиотеки).

safe-api е актуализиран за новата версия на SCL. Това извади наяве някои други проблеми в кода, включително някои блокиращи поведения в await кода за съобщенията, но вече го коригирахме и преминаваме през някои заключителни тестове с API-тата, преди да включим всичко това в кода.

Това беше много работа, така че е чудесно да видим как завършва (и да се сбогуваме с около 2000 реда код!)

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

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

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

В момента разглеждаме друга голяма промяна за Маршрутизирането - премахването на Parsec.

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

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

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

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

Тази седмица се съсредоточихме върху въвеждането на всички оптимизации, които направихме от наблюдаването на симулациите и тестовете в реална мрежа към главния клон с PR 14. Този PR добавя транспортния слой (quic-p2p) и така завършва контейнера. Като генерален контейнер, той е насочена към потребители от всякакъв тип (Трезори и Клиенти), поради което интегрираният транспортен слой улеснява потребителите, тъй като те не трябва да се притесняват за обмен на съобщения и завършване на BLS сесията - както беше обсъдено в последното седмична актуализация, контейнера поема отговорността за това с помощта на таймери. Този PR в момента преминава през процеса на преглед и е близо до готовност за сливане, и следващата стъпка ще бъде да започнем интеграцията на BLS-DKG с другите части на SAFE Network, още една стъпка по-близо до нашата крайна цел!

Dimitar · June 11, 2020, 6:05am

SAFE Network новини - 4.6.2020

Накратко

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

Пуснахме нови версии на API-то (v0.13.0), CLI-то (v0.13.0) и safe-authd (v0.9.0), които носят няколко подобрения и корекции, напр. командата за качване на файлове сега поддържа качване на празни директории и скрити файлове.
SAFE Клиентските библиотеки вече са напълно настроени за Rust асинхроност/изчакване.
Събрахме и отговорихме на няколко от най-често срещаните въпроси, възникнали от новината за премахването (или значително намаление) на Parsec.
Вече се работи за премахването на Parsec, като първата стъпка е да се прикачи BLS подпис към цялата споделена информация за състоянието.
Самият Parsec контейнер не е напълно изоставен! Току-що пуснахме нова версия с поправки, която актуализира зависимостите.
Сега контейнера BLS-DKG се счита за завършен и се работи за интегрирането му в маршрутизацията.

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

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

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

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

SAFE API

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

Тази седмица пуснахме нови версии на CLI-то (v0.13.0) и safe-authd (v0.9.0), които носят няколко подобрения и корекции, заедно с някои нови функции за файловите команди. Например командата за качване на файлове сега поддържа качване на празни директории и скрити файлове. Както обикновено, можете да използвате CLI-то, за да актуализирате както CLI-то (с $ safe update ), така и safe-authd (с $ safe auth update ) или да следвате инструкциите в Ръководството за потребителя на CLI при инсталирането им за първи път и / или всякакви други инструкции.

Нова версия на safe-api-то (v0.13.0) също е готово тази седмица. То вече използва най-новата версия на Safe-client-libs, която излага API-то си като async. С това завършихме миграцията на всички наши контейнери в хранилищата на safe-api и safe-client-libs, за да използваме Rust синтаксиса async/wait, което ще ни позволи да направим още много подобрения и опростявания на safe-client-libs кодовата база в бъдеще.

Междувременно работата по поддръжката на символни връзки продължава. В най-новия код за разработка (все още няма заявка за изтегляне) е възможно да се получат както относителни, така и абсолютни символни връзки за PUT и GET, а също така да се показват правилно във файлово дърво и файловите списъци. Символните връзки могат да бъдат деактивирани, като се използва нов --follow-link флаг към поставените файлове, което води до старото поведение.

Едно подобрение на скоростта: в Windows писането на символни връзки на хард диска изисква определени разрешения (зависи от точната версия на ОС), така че получените файлове могат да пропуснат символната връзка и да покажат предупреждение в случая. Git също има този проблем и обикновено създава малък текстов файл, съдържащ връзката-цел. И ние можем да използваме този подход. Като потребител на Windows, поддръжката на символната връзка е активирана, като изберете стартиране като администратор при стартирането на команден терминал, или можете да активирате режима за разработчици в Windows 10+.

Следващата ни работа ще бъде разрешаването на относителни символни връзки, когато се използват в пътя на Safe-URL-то.

CRDT

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

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

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

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

Трансфери

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

Сега, когато async/await са обединени в lib-safe-client, актуализираме нашата SCL AT2 реализация за тази настройка и я актуализираме, за да отговорим на последните промени в самите safe-transfers. В момента това включва създаването на местен Актьор за управление/сливане на доказателствата за валидиране от старейшините и ефективно обвиване на всички наши заявки за пари в мрежата. Това, да се надяваме, трябва да капсулира добре тази логическа страна на клиента и да направи някои от нашите клиентски API-та, малко по-ясни.

Що се отнася до инициирането на Актьора, репликите трябва да разкрият API, което позволява на клиентска заявка от доказателства за валидиране на акаунт, от който може да бъде стартиран Актьор. Като допълнение, това поддържа текуща синхронизация от Репликите. Понастоящем работим по въвеждането му.

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

Функции в Rust

Споменахме ли, че SAFE Клиентските Библиотеки вече са напълно настроени за Rust асинхроност/изчакване! Последната седмица беше прекарана в тестване със safe-api-то, CLI-то и трезорите, проучване на някои проблеми и актуализиране на safe-api-то да поддържа собствени времена на работа за консумацията на тези нови API-та за асинхроност. След като всички тестове преминаха успешно, с радост направихме ново издание за API / CLI срещу актуализираните клиентски библиотеки. Все още наблюдаваме някои проблеми с FFI библиотеките, които може да се нуждаят от допълнителна работа за новата настройка на асинхроност/изчакване.

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

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

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

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

Връщаме ли се към търсенето на ново решение?
Въобще не. Премахването на Parsec не означава, че сега търсим друг алгоритъм за консенсус. Разбрахме, че Parsec просто прави твърде много и това, от което се нуждаем, е много по-просто. От известно време анализираме решение, използвайки CRDT, AT2 и BLS, когато е подходящо, за да постигнем само това, от което се нуждаем. През последните няколко седмици и месеца публикувахме ежеседмично изследванията и работата ни по прилагането им и вярваме, че те са повече от адекватни, за да продължим напред без Парсек.
Това ще забави ли Алфата/Флеминг/Бейби Флеминг/…?
Не. Работата по премахването на Parsec продължава паралелно с всяка друга работа, която е необходима за пускането на мрежата. Заявките от екипа на трезорите вече са с най-висок приоритет и бързо се адресират. Освен това маршрутизирането, както е в момента, прави почти всичко, което трябва, просто не е възможно по най-ефективния начин. Така че в най-лошия случай винаги можем да пуснем алфа с него такъв, какъвто е, и да го заменим с версиябез Parsec по-късно.
Напълно ли ще премахнем Parsec?
Най-вероятно да. Но дори и нещата да се объркат ужасно и да се окаже много по-трудно, отколкото сме мислили, винаги можем да отстъпим, за да задържим Парсек наоколо по някакъв намален начин. Но не смятаме, че ще се стигне до това.
Parsec загуби ли време и ресурси?
Абсолютно не. Parsec все още е фантастично постижение в ABFT, само по себе си иновация. Оправдан беше пътят, който избрахме да изминем през 2018 г. и несъмнено ни помогна да стигнем до мястото, където сме днес. Понякога единственият начин да разберете дали нещо е подходящо за вашите развиващи се нужди е да го изпробвате. С времето ни стана по-ясно, какви са недостатъците и ограниченията му за нашите конкретни нужди, докато алтернативите станаха по-ясни и по-зрели. Винаги ще правим това, което е правилно за мрежата и ако това означава да намалим използването на Parsec, това е курсът на действие, който следваме, за да постигнем крайните си цели.

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

Ето напредъка ни и тази седмица в маршрутизирането:

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

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

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

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

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

Тази седмица завършихме процеса на преглед на PR 14 и го обединихме в основния клон!

Това, разбира се, добави транспортния слой (quic-p2p) в контейнера, като гарантира, че потребителите не трябва да се притесняват от обмена на съобщения и завършването на BLS сесията. С обединяването на този окончателен PR, контейнера е завършен и BLS-DKG вече е готов за използване в мрежата. Първата цел е да накарате маршрутизацията да използва директно BLS-DKG контейнера вместо сегашния DKG генератор от Parsec. Работата по интегриране на BLS-DKG с маршрутизацията е в ход.

Dimitar · June 18, 2020, 3:50am

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

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

Обещахме ви нова играчка и днес е при вас

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

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

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

Още един важен момент e достигнат

SAFE API

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

Работата по символните връзки продължава. Последната стъпка е да се даде възможност за разрешаване на символни връзки в SafeUrl пътя. Повечето езици за програмиране имат функция realpath () (или еквивалентна), която премахва . / И заменя ../ и всяка символна връзка в пътя, както е подходящо, за да генерира окончателен истински път. Тази седмица написахме функция realpath (), която разбира метаданните в „FileContainer“ и се извиква в „Safe::fetch ()“ API-то, така че ще работи за всички заявки към SafeUrl за поддробности. Остават някои подобрения и тестове, но се надяваме, че PR-а може да бъде готов в началото на следващата седмица с пълна поддръжка на символните връзки.

CRDT

През изминалата седмица се съсредоточихме върху клиентската страна на CRDT Последователността, като започнахме със създаването на някои първоначални E2E тестове на safe-api хранилището и ги пуснахме срещу тестовата Секция на Бейби Флеминг. Успешно осъществихме множество основни сценарии, работещи за създаване на съдържание от Последователността, добавяне и извличане на данни от нея. Също така мигрирахме FilesContainers и NRS контейнерите, да използват CRDT Последователността (вместо AppendOnlyData типа) и всички тестове на E2E също преминават в Бейби Флеминг секцията.

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

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

Трансфери

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

Интеграцията на SAFE Клиентските Библиотеки напредна добре през последната седмица. Актуализирахме основната библиотека за новите транзакции в стил AT2 и започнахме с основната интеграция на TransferActor . Това ще бъде обвивна структура, която ще премахне голяма част от логиката на заявката и управлението, които преди това се обработваха в API-тата на клиентския слой, което ни дава малко повече модулност. Започнахме да тестваме това и напредваме с актуализирането на тестовете в основната библиотека като цяло.

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

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

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

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

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

Dimitar · June 25, 2020, 1:51am

SAFE Network новини - 18.6.2020

Накратко

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

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

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

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

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

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

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

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

SAFE API

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

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

CRDT

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

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

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

Трансфери

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

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

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

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

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

Най-накрая PR за състоянието на споделените подписи беше окончателно повдигнат и в момента се преглежда. PR за заместване на DKG също е почти готов освен някои подробности, които трябва първо да бъдат изпипани. Създадохме задание в GitHub, в което са изброени всички стъпки, които според нас са необходими, за да премахнем Парсек от маршрутизирането. Изглежда, че има много работа, но вярваме, че по-голямата част от нея е доста проста. Цялото усилие може да се обобщи приблизително така:

Ще осъществим гласуване без Парсект въз основа на съобщения и подписи на BLS. Това ще ни даде консенсус / авторитет, но не и пълен ред. Вярваме, че това е достатъчно за нашите нужди. Полученият механизъм ще бъде много по-опростен и по-ефективен от Parsec.
Преобразуваме всички структури от данни, които се използват за съхранение на одобрена от Секцията информация, в CRDT (Репликирани DataTypes без конфликт), което означава, че всички промени към тези структури ще бъдат комутативни, асоциативни и идентични. По-просто казано, това означава издръжливост на пренареждане и дублиране на съобщения. Това ще ни даде евентуална последователност за много малко системни разходи в сравнение с Parsec.
Освен това, прилагаме промени само ако са одобрени чрез гореспоменатия процес на гласуване. Това ни дава устойчивост към различни видове провали и атаки, защото всяка промяна трябва да бъде одобрена от кворума на Старейшините на Секциите.

Dimitar · July 1, 2020, 3:51am

Накратко

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

@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, която представлява ядрото на концепцията за Секциите.

Dimitar · July 9, 2020, 4:10am

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 съвместим, което означава, че вече може да се използва във възможно най-големия набор от среди и платформи, включително някои много ограничени вградени устройства.

Dimitar · July 16, 2020, 2:14am

SAFE Network новини - 9.7.2020

Накратко

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

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

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

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

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

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

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 и други хранилища.

Dimitar · July 23, 2020, 4:25am

SAFE Network новини - 16.7.2020

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

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

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

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

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

SAFE API

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

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

Вижте списъка с промени за акцентите в новите функции и корекции на грешки, които са в новите издания и разбира се, вижте подробното Ръководство за потребителя на 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 за изпълнение на тестовете спрямо реална мрежа До сега трябваше да стартираме ръчно тези тестове преди да пуснем нова версия, докато само на 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 да са одобрени от секцията, беше обединена тази седмица , Това ни дава възможност да продължим със задачата за основна промяна на даването на права на трезорите. Поради родителския отпуск на Адам (огромни поздравления за него ), работата е заменена от PR 2160, който беше обединен днес. Вече сме стъпка по-близо до внедряването на гласуване въз основа на съобщения, което замества текущото гласуване, базирано на парсек.

Dimitar · July 30, 2020, 3:51am

SAFE Network новини - 23.7.2020

Накратко

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

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

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

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

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

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

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

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

Dimitar · August 6, 2020, 7:07am

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) ще маркира новата версия и ще стартира версии за нас. Всичко това автоматично

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

Dimitar · August 23, 2020, 1:44am

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. Проведе се ползотворен дебат относно потенциалния подход за преместване и го документирахме и актуализирахме.

Dimitar · August 24, 2020, 3:52am

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, което както беше казано по-горе ще опрости кодовата база много както в маршрутизацията, така и при трезора. Както може би осъзнавате, всичко това е вътрешно преструктуриране, ползите от което могат да бъдат трудни за наблюдение от крайните потребители, но ние сме много обнадеждени, че това ще ни позволи по-лесно да намерим и решим всички проблеми, които ще открием в бъдеще, както и да направим по-лесно да се поддържат и развиват съществуващите функции.

Dimitar · August 26, 2020, 1:41am

SAFE Network новини - 20.8.2020

Накратко

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

Вижте страхотния SAFE Network Wallet Bot, разработен от @DeusNexus тук - Телеграм вече е свързан към SAFE CLI!
Имаше огромни усилия за преструктуриране и опростяване на 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” и т.н.

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

Dimitar · September 4, 2020, 3:47am

SAFE Network новини - 27.8.2020

Накратко

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

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

CRDT

safe-fs

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

С приключването на 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_.

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

Dimitar · September 24, 2020, 4:47am

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 постепенно да се появяват отново за тази критична работа по преструктурирането.

Също така приключихме с промените в маршрутизирането, необходими за излагане на 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 бутон от клавиатурата ще ви благодари!

Dimitar · September 24, 2020, 4:49am

SAFE Network новини - 10.9.2020

Накратко

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

Основния PR за преструктуриране премахването на parsec е обединен в главен клон на маршрутизацията.
Интеграцията 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 в главния клон

Все още има текуща работа за разрешаване на няколко останали проблеми с премахването на 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).

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

Dimitar · September 24, 2020, 4:51am

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, която започнахме.

Topic		Replies	Views
MeetUp Sofia, October 12-13 at 5 PM – 7 PM Events bulgaria	4	828	October 13, 2019
Live stream about the Safe Network from Bulgaria Videos	0	442	December 27, 2020
SAFE Network Bulgaria was nominated for the site of the year! Marketing	10	919	October 17, 2019
SAFE business cards Marketing	10	1002	June 14, 2019
MeetUp Sofia, December 14 at 4 PM – 6 PM Events bulgaria	4	778	December 14, 2019