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

SAFE Network новини - 30.7.2020

Накратко

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

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

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

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

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

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

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

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

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

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

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

SAFE API

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

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

CRDT

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

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

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

tree-crdt

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

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

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

Transfers

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 6.8.2020

Накратко

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

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

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

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

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

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

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

CRDT

safe-fs

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

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

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

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

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

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

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

Фермерство

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 13.8.2020

Накратко

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

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

CRDT

safe-fs

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

Фермерство

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

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

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

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

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

Награди

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

SAFE Network App UX

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 20.8.2020

Накратко

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

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

CRDT

safe-fs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 27.8.2020

Накратко

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

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

CRDT

safe-fs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFE Network App UX

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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


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

SAFE Network новини - 3.9.2020

Накратко

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

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

CRDT

safe-fs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFE Network новини - 10.9.2020

Накратко

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

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

CRDT

safe-fs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 17.9.2020

Накратко

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

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

CRDT

safe_fs

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 24.9.2020

Накратко

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

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

CRDT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 1.10.2020

Накратко

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

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

CRDT

sn_fs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 8.10.2020

Накратко

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

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

CRDT

sn_fs

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 15.10.2020

Накратко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 22.10.2020

Накратко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Още новини…

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

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

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

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

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

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


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

SAFE Network новини - 29.10.2020

Накратко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SAFE Network новини - 5.11.2020

Накратко

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

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

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

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

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

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

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

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

Трансфери

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

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

CRDT

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

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

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

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

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

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

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

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

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

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


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

SAFE Network новини - 12.11.2020

Накратко

  • Представяме ви някои големи промени в лексикона на Safe мрежата! Вижте видеоклипа тук или прочетете стенограмата в специалната тема на форума тук.
  • Работим за поддръжката на множество клиенти, използващи един и същ публичен ключ за едновременно свързване и промяна на данни.
  • Допълнителни подобрения на производителността при стартиране на мрежата са обединени в sn_routing.

Актуализиране на лексикона на Safe мрежата

Актуализираме лексикона на Safe мрежата за крайните потребители и заместваме термините Акаунт, Safecoin и Трезор.

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

Актуализиране на лексикона на Safe мрежата: замяна на термините Акаунт, Safecoin и Трезор

Моля, не се колебайте да споделите вашите мисли, коментари и наблюдения в специалната тема на английски или български, където ще намерите и пълна стенограмата на видеоклипа.

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

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

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

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

CRDT

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

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

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

DSB Динамично членство

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

Успоредно с това оригиналния bft-crdts контейнер се разделя на по-малки, по-фокусирани библиотечни контейнери. Идеята е да се сдвоят (а) конкретната реализация на защитено излъчване, (б) данните, които са защитени, и (в) мрежовият транспорт (например QUIC, TCP/IP или мрежа в паметта за симулиране на тестове).

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

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

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

В момента се работи по разрешаване на възел да се присъедини повторно със същото име. Това е проектирано въз основа на Последващо присъединяване към мрежата във RFC за стареене на възли. Намерението е възел, който се опитва да се присъедини със същото име, да бъде незабавно преместен, а възрастта му намалена наполовина, стига половината възраст да е по-голяма от MIN_AGE (в момента 4).

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


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

Safe Network новини - 19.11.2020

Накратко

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

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

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

Връщаме се към създаването на копия на парчетата от Blob данни в sn_node. Започвайки с коефициент от 4 копия, възрастните в мрежата ще носят главна отговорност за тяхното съхраняване. Пренасяме по-старата реализация от предварителни асинхронни хранилища към новата кодова база, като я адаптираме към най-новите промени в съхранението, заявките и т.н. Тази седмица също правим известно разчистване навсякъде, като преследваме основно проблеми с разгъване, очакване и паника от производствения ни код и тестове, като по същество стабилизират кодовата ни база и улавят всички изключения. Това е най-добрата практика и нещо, което отлагаме твърде дълго. Очаквайте допълнителни проверки на CI, които да бъдат добавени през следващите няколко дни в контейнерите ни, за да гарантират, че те няма да се появят обратно в кода.

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

CRDT

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

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

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

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

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

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

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

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

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

В допълнение към това, също така се стремим да направим някои промени, които да ни помогнат да се информираме за точното състояние на маршрутизацията по време на стартиране на мрежата и след това, с тази цел имаме две текущи PR - [Индикация за стартиране на секция и задействане на PromotedToAdult събитие](https: / /github.com/maidsafe/sn_routing/pull/2233) и уведомяване при промяна на ключа по време на преместването. Тези промени са в ход и ще ни помогнат да гарантираме, че маршрутизацията се държи по коректно и трябва да бъдат завършени скоро, след като API дизайна им е съгласуван между възлите и маршрутизацията.


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

Safe Network новини - 26.11.2020

Накратко

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

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

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

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

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

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

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

Също така започнахме да подготвяме authd и CLI за адаптиране към новата UI / UX терминология, например преминахме от “Акаунти” към “Сейфове”, както и да правим необходимите промени, за да може authd да съхранява ‘ключовите двойки’ на програмите в мрежата, използвайки Map като тип данни за съхранение за “Сейфа”. Ще продължим с тази задача, за да приведем всички CLI команди и функции за удостоверяване в съответствие с тези нови терминологии, както и с новия API на sn_client.

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

BRB - Византийско надеждно излъчване

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

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

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

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

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

По време на тестването забелязахме проблем, при който по време на първоначалното стартиране, когато съобщението NodeApproval е последвано незабавно от друго съобщение, например Relocate, стартирането завършва след обработката на NodeApproval. Това оставя всяко следващо съобщение, като Преместване, в буфера на междинния канал и никога няма да бъде извадено и обработено, т.е. загубвахме това съобщение. Обединихме поправящ го PR Отстраняване на загубени съобщения по време на първоначално стартиране, за да разрешим този проблем. Той премахва междинния канал, заменяйки го с обикновена обвивка около приемника ConnectionEvent. По този начин моделът “push/ pull” се променя в обикновен модел “pull”. По този начин съобщението никога не се извлича от канала, ако не е готово да се обработи.

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

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

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

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

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

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

Изглеждаше така:

Но можем ли да направим процеса по-гладък? Можем ли да го направим по-малко плашещ и да помогнем на потребителя бързо да стартира своя Safe, без никаква външна помощ, и след това да го накараме да следва печеленето на Safe Network Tokens за стартиране.

Ето малък прототип на новия подход - само с една опция напред - колкото да ви даде представа за процеса:

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

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

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

Преводи:

:uk: Английски; :ru: Руски; :de: Немски; :es: Испански; :fr: Френски;


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

Safe Network новини - 3.12.2020

Накратко

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

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

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

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

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

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

Повдигнат е PR за Rust-CRDT, за да се приведе LSeq в съответствие с други типове CRDT, които се нуждаят от apply, за да бъдат извикани преди модифициране на самия тип данни. Използваме това в Sequence типа данни, за да гарантираме, че всички операции са подписани.

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

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

BRB - Византийско надеждно излъчване

Продължава работата по Generation Clock подхода към динамичното членство. Работещ прототип на кода се очаква до края на седмицата.

Като паралелна задача bft-crdts контейнера се разделя на отделни контейнери в усилие за модулиране. Идеята е да се дефинират 3 линии: една за внедряване на BRB, една за типовете данни, които трябва да бъдат предадени и защитени, и една за мрежовия слой.

По този начин изпълненията и на трите линии могат да бъдат смесени и съчетани. Например, можем да използваме използваната памет в мрежата за тестови случаи, qp2p impl за маршрутизиране в Safe Network и трета страна може да използва внедряване на TCP / IP сокети за нещо друго. От страна на данните вече имаме внедряване на AT2 банка и внедряване на CRDT orswot.

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

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

Както бе споменато по-горе, sn_node беше публикуван и пуснат за първи път в сегашния си вид тази седмица. За да не изостане маршрутизиращият екип вече също пусна и публикува sn_routing, първото издание от почти 2,5 години насам! Вижте списъка с промените за да придобиете представа за направените промени. Както при sn_node, тези издания не означават, че разработката на sn_routing е приключила, а просто сметнахме, че е достатъчно стабилна, за да обединим вече създадения преди това механизъм за непрекъсната доставка PR. Разработката продължава с добро темпо и сега всеки обединен PR ще доведе до допълнително автоматично генерирано ново издание.

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

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

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

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

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

Преводи:

:uk: Английски; :ru: Руски; :de: Немски; :es: Испански; :fr: Френски;


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

Safe Network новини - 10.12.2020

Накратко

  • sn_client v0.44.0 получи първото си обновление от юли месец насам.
  • Завършихме въвеждането на дублирането на Blob парчетата, когато Възрастен напусне мрежата - нова версия sn_node v0.25.9.
  • Консултантът ни представи завършен, тестван и работещ алгоритъм за динамично членство.

Обобщение

Накратко за напредъкът ни към предстоящата тестова мрежа.

Всички работим здраво свързвайки последните парчета заедно за предстоящата тестова мрежа. Както се може да се очаква, има някои грешки, които изчистваме и някои добавки в последния момент. Едно нещо, което няма да имаме време да включим в тази тестова мрежа, е новото членство в BRB (Византийско надеждно излъчване). Членството в BRB е наистина важна стъпка, но сега се опитваме да тестваме толкова много други движещи се части, че преценихме фокусът ни да бъде максимално бързото стартиране на фаза 1, и след нея ще можем да се съсредоточим изцяло върху BRB.

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

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

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

Тази седмица се опитваме да проследим източника на проблем с препълване на стека, който се появи в sn_node. Първоначално изглеждаше, че няма конкретен източник и използването на стека просто нараства с времето. Първоначално това се случваше само в Windows, където открихме, че размерът на стека по подразбиране е 1 мегабайт, което е ниско в сравнение с Ubuntu, който има 8 MB. Намаляването на размера на стека в Ubuntu ни позволи да повторим това, което е добре. Така че продължаваме да разследваме това и да търсим начини да го предотвратим.

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

BRB - Византийско надеждно излъчване

Добри новини! Нашият консултант създаде работещ алгоритъм за динамично членство. Това е оригинална разработка, която използва Generation Clock с една операция за присъединяване или напускане, разрешена за един актьор, за едно завъртане на часовника. Този алгоритъм вече е написан в код заедно с тестов пакет и всички тестове преминават.

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

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

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

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

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

Преводи:

:uk: Английски; :ru: Руски; :de: Немски; :es: Испански; :fr: Френски;


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