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

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

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

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

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

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

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

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

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

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

Dimitar · October 8, 2020, 2:19am

SAFE Network новини - 1.10.2020

Накратко

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

Файловата система за Safe мрежата направи голяма стъпка напред към публично представяне, като сега беше обединена към главния клон и преминава през последния етап на тестване.
Преименувахме хранилището Safe Client Libs / контейнера safe_core на sn_client.
Поставихме основите за тестване на хаоса в sn_node.
Благодарности към @Scorch за 2 асинхронни приноса в sn_node, PR1105 и PR1090, през последната седмица.
Система за непрекъсната доставка вече е въведена почти на всички наши 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

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

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

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

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

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

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

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

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

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

Dimitar · October 15, 2020, 3:55am

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

Тази седмица актуализирахме 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, които бяха споменати миналата седмица (което отново активира концепцията за „Възлите от дома“) ) … след това ще пуснем тест мрежа!

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

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

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

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

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

Dimitar · October 21, 2020, 11:37pm

SAFE Network новини - 15.10.2020

Накратко

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

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

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

Преструктурирането на 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, цялото стартиране винаги се проваляше. Имаме решение за това. Както бе споменато по-горе, започнахме с някои вътрешни тестови мрежи, които включват всички промени тази седмица. Това ни помага да приведем всички модули в действие и да поправим грешките, които биха могли да бъдат пропуснати в тестовете на отделни модули / интеграция. Ако нещата вървят добре (трудно за предвиждане!) ще пуснем тестова мрежа, в която да се включите скоро.

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

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

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

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

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

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

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

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

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

Dimitar · October 29, 2020, 3:19am

SAFE Network новини - 22.10.2020

Накратко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Още новини…

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

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

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

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

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

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

Dimitar · November 5, 2020, 3:53pm

SAFE Network новини - 29.10.2020

Накратко

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

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

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

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

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

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

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

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

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

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

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

Dimitar · November 12, 2020, 1:01am

SAFE Network новини - 5.11.2020

Накратко

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

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

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

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

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

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

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

Трансфери

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

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

CRDT

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

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

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

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

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

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

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

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

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

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

Dimitar · November 19, 2020, 2:18am

SAFE Network новини - 12.11.2020

Накратко

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

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

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

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

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

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 или мрежа в паметта за симулиране на тестове).

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

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

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

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

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

Dimitar · November 26, 2020, 3:43am

Safe Network новини - 19.11.2020

Накратко

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

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

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

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

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

CRDT

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

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

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

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

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

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

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

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

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

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

Dimitar · December 3, 2020, 3:09am

Safe Network новини - 26.11.2020

Накратко

Работата по sn_node и sn_client продължава, за да се приведат в съответствие с най-новите sn_data_types, като CI вече напълно преминава в sn_node.
Маршрутизацията вече е актуализирана да подава сигнал, когато в мрежата трябва да бъде приет нов възел, работим по sn_node, за да се възползваме от това.
Работата по маршрутизирането за подобряване на откриването на загубени възли беше одобрена и обединена тази седмица.
Промените в лексикона на Safe мрежата, обсъдени преди 2 седмици започнаха да се добавят към UX дизайните. Може да видите предварителен поглед по-долу!

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

След като миналата седмица добавихме 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.

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

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 или избор на сигурни идентификационни данни.

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

Преводи:

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

Dimitar · December 10, 2020, 3:20am

Safe Network новини - 3.12.2020

Накратко

sn_node получи първото си обновление от юли месец!
sn_routing получи първото си обновление от август 2018 г. насам!
Имаме привидно работещи стабилно sn_client тестове.
Решихме основния проблем със стартирането на секция в CI.
Заемаме се с последните няколко останали неуспешни sn_api теста.
Работен прототип на Generation Clock кода определящ подхода за динамично членство се очаква до края на седмицата.
Тази седмица бяха обединени две важни sn_routing PR - мярка за защита срещу атаки за продажба на ключове и извършване на проверка на ресурсите по време на свързване на нови възли

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

Тази седмица отбеляза важно събитие за 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. Двете основни промени, предложени за постигане на това, са:

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

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

Преводи:

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

Dimitar · December 17, 2020, 3:40am

Safe Network новини - 10.12.2020

Накратко

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

Обобщение

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

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

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

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

Преводи:

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

Dimitar · January 7, 2021, 10:52am

Safe Network новини - 17.12.2020

Тестова мрежа

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

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

Как да стартирате локална тестова мрежа на своята машина?

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

Първо, изтеглете най-новия инсталационен файл за CLI чрез нашия скрипт за инсталиране.

След това трябва да актуализирате своя Удостоверяващ демон и Възел до най-новите днешни версии. Можете да направите следното:

$ safe auth install

$ safe node install

Вече можем да стартираме мрежа, използвайки:

$ safe node run-baby-fleming

Това ще стартира 8 възли на вашия компютър: 5 възрастни и 3 старейшини.

Можем също да добавим допълнителни възли към мрежата, това се постига с помощта на safe node join, както следва.

Имайте предвид, че може да се наложи да зададете променливата на RUST_LOG средата, преди да стартирате вашия възел, за да предотвратите записването на твърде много информация в логовете.

## за Linux и Mac OS
$ export RUST_LOG=safe=trace
## Windows (команден ред)
$ set RUST_LOG=trace
## Windows (powershell)
$ $env:RUST_LOG="safe=trace"

И след това стартирайте възела с:

$ safe node join
Storing nodes' generated data at /Users/maidsafe/.safe/node/local-node
Starting a node to join a Safe network...
Launching with node executable from: /Users/maidsafe/.safe/node/sn_node
Node started with hardcoded contact(s): ["127.0.0.1:12000"]
Launching node...
Node logs are being stored at: /Users/maidsafe/.safe/node/local-node/sn_node.log

Сега вашият възел ще се стартира и ще се опита да се свърже с вашата локална мрежа. Можете да следите напредъка му в логовете, които можете да намерите в
~/.safe/node/local-node/sn_node.log.

Преди да преминете през останалите CLI команди не забравяйте да удостоверите и създадете своя Safe.

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

Известен проблем

В тази версия има известен проблем, по който все още работим, за да го отстраним. Първият път, когато упълномощавате приложението CLI с authd, като използвате командата $ safe auth unlock --self-auth (моля вижте този раздел от Ръководството за потребителя за повече информация за тази команда), може да получите грешка при опит за качване на файл или запис на данни в мрежата, например тази грешка може да бъде върната:

[2020-12-17T20:21:06Z ERROR safe] sn_cli error: [Error] NetDataError - Failed to store Public Sequence data: Data error -> Unexpected error: Could not get history for key PublicKey::Ed25519(d802d5..) - ClientError::DataError -> Unexpected("Could not get history for key PublicKey::Ed25519(d802d5..)")

В такъв сценарий, моля, продължете напред и изпълнете отново същата команда, за да отключите ‘Safe’-а отново, и след това опитайте отново с запис на данни в мрежата.

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

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

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

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

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

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

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

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

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

Преводи:

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

Dimitar · January 21, 2021, 12:55am

Safe Network новини - 7.1.2021

Накратко

Честита Нова Година!
Радваме се да съобщим, че работата по динамичното членство е завършена и днес публикувахме няколко контейнера на Византийско надеждно излъчване (BRB) в GitHub . Всички са свързани от централния brb контейнер.
Работихме усилено, дори през празниците, за да подобрим слоя за грешки и съобщения, включително създавайки нов контейнер „sn_messaging“.
Ние сме в процес на подготовка на някои незначителни корекции за нова CLI версия.
Също така сме близо до създаването на CLI и authd с musl, което означава съвместимост с по-голям набор от платформи.
Имаме нов инструмент за стрес тестване за маршрутизирането с PR в процес на проверка. Този нов инструмент е създаден, за да открие ограниченията на маршрутизацията по отношение на начина, по който се справя с промените в членството (разделяне) и вече ни показа някои проблеми.

Относно тестовата мрежа

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

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

Работим за подобряване на историята ни за грешки в библиотеки ни и преминахме към използването на thiserror в node / data_types / client / transfer за осигуряване на по-добра верига за грешки и по-голяма капсулация на функционалността. По-рано използвахме много смесени грешки, изтегляйки много от sn_data_types в други библиотеки. Сега имаме специфични грешки във всяка библиотека, за тази библиотека, и разпространяваме грешки само от долните библиотеки като друга версия на грешките на текущата библиотека.

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

Като част от тези усилия изследваме различни типове сериализация, като крайната цел е да има такъв, който е агностик на езика за програмиране. В момента се фокусираме върху проста JSON сериализация (за разлика от използвания в момента bincode), но също така си играем с Msgpack.

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

В тандем премахнахме „предизвикателствата“ на клиента от първоначалното свързване на възела / клиента. По-рано те се използваха за проверка, че клиентът държи ключове, за да се предотвратят атаки за повторно възпроизвеждане на съобщения. Но с idempotency, идващ от типовете данни AT2 и CRDT, това ще бъде обработено там. Това води до още по-голямо опростяване както за клиента, така и за възела и допълнително изяснява мрежовите операции само като подписани съобщения.

Преди време, за да предотвратим атаки за продажба на ключове в мрежата, премахнахме всички API-та за показвване на SecretKey от sn_routing и ги съхранявахме само в техния контейнер. Установихме обаче, че има многобройни усложнения в дървото на зависимостите, причинени от това премахване, и затова решихме да върнем тези API-та, за да ни позволят да продължим бързо с тестовата мрежа по време на празниците. Решихме да се справим с този проблем веднага и започнахме да преструкторираме контейнерите „sn_transfers“ и „sn_node“, където държим и използваме тези SecretKeys извън „sn_routing“.

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

И в последно работим за премахване на stream от потока от възлите. Това беше въведено за поддържане на комуникации с клиенти, но с последните промени на „qp2p“ можем да разчитаме на обединяване на връзките там, което ще ни свърши работа, и така премахваме много сложност от клиентската обработка на възела. Също така сме в процес на преструктуриране на qp2p примерите в отделни части, за да демонстрираме echo_service и системите за съобщения ясно и отчетливо. Правим пробни пускове с тези примери с ръчно пренасочване на портове към потенциално поддържани рутери, несъвместими с IGD в следващи тестови мрежи.

API и CLI

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

Също така се опитваме да изградим следващото издание на CLI и authd с musl, което, както знаем, ще ни позволи да стартираме тези приложения на много повече платформи, използвайки същите версии на CLI-то. Вече успяхме да ги изградим ръчно (благодарим много на @mav и @tfa за техните забележки и принос към това), така че сега се стремим да ги включим в нашия CI през следващите дни.

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

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

BRB системата се състои от:

Основният BRB протокол за излъчване за членове на кворум за копиране на данни по BFT начин.
Протоколът за динамично членство за възли за динамично присъединяване и излизане от активен кворум.
Опаковки от тип данни, които капсулират съвместими типове данни (напр. CRDT) за прехвърляне чрез BRB.
Изчерпателни тестове за проверка на коректността.
brb_node_qp2p: примерно CLI приложение / възел за ръчно извикване на BRB функционалност.

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

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

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

Предприета е и промяна на API-то за подаване на информация от секция за конкретно име на участник. Това главно се използва в “sn_node” за бъдеща работа по преструктуриране.

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

Преводи:

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

Dimitar · January 21, 2021, 1:02am

Safe Network новини - 14.1.2021

Накратко

Продължаваме да преместваме всички дефиниции на клиентските съобщения и логиката на сериализацията към новия контейнер sn_messaging.
Работата по премахването на управлението на „потока“ във възлите, както беше споменато в актуализацията от миналата седмица, е завършена и обединена
Продължихме да решаваме проблемите, подчертани от новия ни инструмент за стрес тестване на маршрутизацията.
Голямо благодаря към двама членове на общността за PR-ите тази седмица - @mav и @tfa се включиха с множество PR-и в различни хранилища, за да помогнат и подобрят нашата работа. Винаги е вдъхновяващо да получим помощ
Все още работим по тестването и финалното отстраняване на грешки, което се надяваме да означава, че ще можем да пуснем следващата версия на тестовата мрежа скоро.

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

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

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

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

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

API и CLI

Тази седмица успяхме да генерираме успешно „musl“ компилации за CLI и authd в нашия CI и затова всичко е настроено и готово за следващото ни издание. Това означава, че както CLI, така и authd приложенията трябва да са съвместими с която и да е Linux платформа без допълнителни настройки, ще ни е необходима помощ от общността, която да ни помогне да проверим дали това всъщност е така, като го изпробвате на толкова много различни Linux платформи колкото е възможно. Ще пуснем новите версии своевременно.

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

Работата продължи и тази седмица за допълнително полиране на BRB контейнерите. Приложният програмен интерфейс (API) на DataType е променен, така че подробностите за грешка при проверка могат да бъдат върнати на повикващия. В тази връзка и rust-crdt контейнера беше подобрен, така че всеки тип CRDT, който използваме сега, има validate () метод, който може да бъде извикан преди прилагане на операция. За всеки BRB контейнер са направени заявки за изтегляне за CI / CD (Непрекъсната интеграция и Непрекъснато внедряване и доставка). Имаме още няколко промени, които трябва да завършим тази седмица, след което планираме да пуснем първото издание към crates.io.

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

Миналата седмица споменахме как инструментът за стрес тест разкри някои скрити проблеми при маршрутизирането. Тази седмица се заехме да ги издирим и поправим. Един от проблемите беше, че членове на дадена секция, които не са Старейшини не разбират, че се е случило разделение на секцията поради грешка в начина на създаване на „Sync“ съобщенията. Това беше поправено и обединено. В момента работим по още един PR, който решава още няколко от тези проблеми. Останалите проблеми след това вероятно са свързани с начина, по който се справяме с промените в членството в секциите. Надяваме се да ги разрешим чрез интегриране на новия BRB алгоритъм за членство, който също беше споменат миналата седмица. Тази работа ще започне възможно най-скоро следващата седмица, ако всичко върви добре.

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

Преводи:

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

Dimitar · January 28, 2021, 1:51am

Safe Network новини - 21.1.2021

Накратко

Намерихме и обединихме заобиколно решение за проблем с „изоставането“, който се опитваше да остане нерешен.
Публикувахме PR проект за разпределяне на наградите, който е близо до завършване.
Някои неработещи тестове на клиентската мрежа, които ни пречиха да напреднем с тестването на корекцията за проблема със съобщенията „KeySection“ и „DataSection“ (последният проблем, блокиращ публична мрежа за тестове), вече са разрешени и тестването ще бъде възобновено.
Обединихме PR-те на CI / CD във всеки от BRB контейнерите ни, което доведе до автоматизирано покритие на тестовете, създаването на версии и първите ни издания на BRB контейнери в crates.io.
@JimCollinson предоставя поредната завладяваща актуализация за напредъка на Safe Network програмата и потребителското изживяване.

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

Решаване на проблеми със закъснението

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

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

Изглежда, че една проста промяна на времето за изчакване на възела (намалявайки го от 30 сек. на ~ 5 сек … в момента експериментираме, за да намерим оптимални числа) ще доведе до достатъчно деблокиране на възлите, за да можем отново да стартираме тестове на клиентите. Така че, докато проверяваме, за да видим дали има проблем в пула за свързване на qp2p и преструктурираме sn_node до известна степен, сега можем да продължим напред, като тестваме всичко още веднъж.

Разпределяне на наградите

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

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

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

`KeySection` и `DataSection` проблем със съобщенията

В новините от миналата седмица споменахме, че проучваме премахването на възможната дублирана работа извършвана по съвкупното събиране на подписи от “sn_node” по време на обмен на съобщения между “KeySection” и “DataSection”. За тази цел има подготвен WIP PR за натрупване за премахване на подписи. Този PR преминава тестовете на sn_node и продължаваме със sn_client мрежови тестове, за да извършим допълнителна проверка. Въпреки това, поради друга работа по преструктуриране в sn_node и sn_client, извършвана паралелно, sn_client мрежовите тестове са нарушени по други причини, така че работата по проверката трябва да бъде задържана за кратко.

Вярваме, че тази работа за премахване на дублирането ще се справи с проблем с „KeySection“ и „DataSection“ съобщенията, който наблюдавахме по време на вътрешните ни тестови мрежи в края на миналата година, нещо, което би трябвало да можем да проверим чрез „sn_client“ мрежовия тест. Понастоящем това е последното останало, за да можем да стартираме публична тестова мрежа, и поради тази причина не успяхме да напреднем и с вътрешните ни тестове.

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

API и CLI

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

Също така обединихме някои API подобрения, направени от @Scorch, в контейнера qjsonrpc, което прави параметрите на пътя общи. Затова бихме искали да му благодарим за приноса.

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

Вторник отбеляза още един важен момент, когато обединихме PR-те за CI / CD, което доведе до автоматизирано покритие на тестовете, създаване на версии и първите ни публикации на brb контейнери в crates.io.

Основно подобрение, което влезе в тази версия, е поддръжката за обикновенни типове актьори чрез rust черти. Това означава, че кодът вече е достатъчно гъвкав, за да поддържа повечето / всеки криптографски алгоритъм или библиотека с публичен ключ, без допълнителни промени в основните библиотеки. Поддръжката за ed25519 вече е включена, но ще разгледаме и добавянето на BLS поддръжка. Дори хардуерни устройства за подписване ще могат да бъдат добавени в бъдеще.

Допълнителните подобрения включват:

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

Работа в процес на осъществяване:

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

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

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

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

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

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

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

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

Ако си спомните в новините за потребителското изживяване от ноември миналата година ви проведохме чрез предложените промени на лексикона на Safe Network, въвеждайки нова метафора за Safe заменяща Акаунт, токени заменящи Safecoin, и отхвърляне използването на термина Трезор (Vault).

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

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

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

Отключване на Safe Ви

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

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

Работа с токените

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

Печелене на токени

С отпадането на термина Трезор, тук може да видите на практика как можем да използваме глагол като Печелене за да стартирате предлагането на ресурси на мрежата в замяна на Safe Network токени.

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

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

Менюто за действия

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

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

Едно малко напомняне за това как командите също могат да се търсят и стартират. Удобно.

Чувствайте се поканени да разгледате Figma файла, за да видите всички подробности, с множество отделни потоци, проучени и документирани.

Преводи:

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

Dimitar · February 4, 2021, 1:04am

Safe Network новини - 27.1.2021

Накратко

Днес е Денят за поверителност на данните (известен също като Денят за защита на данните в някои части на света). Ние насърчаваме всички в общността ни, както и всички, свързани с други проекти с подобни цели, да се стремят по-силно от всякога да постигнат това. Всеки ден всички се приближаваме с една крачка по-близо. :raise_hands:
PR за наградите сега преминава през допълнителна проверка и тестване - добива на нови монети е много близо!
Най-накрая открихме и поправихме проблема с увисващите връзки, който ни се опъваше от няколко седмици.
Търсенето на проблема с висящите връзки подчерта някои възможни области за подобрение и опростявабе на процеса, ако нещо подобно се покачи отново и затова работим по актуализиране на qp2p и опростяване на неговото API.
С този PR вече обединен, CLI-тп вече е в състояние да проверява баланса на собствения си SafeKey.
Публикувахме нови версии на sn_authd (v0.0.15), CLI (v0.17.2) и sn_node (v0.25.39), като CLI и authd вече са изградени с помощта на MUSL за Linux.

Без публичен тест за момента…

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

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

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

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

Награди

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

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

PR-и от общността

Тази седмица обединихме няколко PR-а, @mav изпрати един PR, който добавя някои липсващи функционалности към клиента, и още едно подобряване на ефективността на извикване на sequence.in_range.

Увисване на връзката

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

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

Опростено qp2p API

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

API и CLI

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

@anon57419684 работи по нова функция за въвеждане на команда reset в CLI, която може да ни позволи да изчистим всички данни и конфигурационни файлове, които приложенията CLI, sn_authd и sn_node съхраняват локално, запазвайки действителните програмни файлове недокоснати. Всеки, който се интересува от това да ни помогне, моля да се присъедини към дискусиите и прегледа на кода тук: WIP: feat(cli): implements 'safe reset' subcommand - #6 by bochaco - Core Libraries - Safe Dev Forum.

Някои подобрения, подадени от @mav в нашето API също са обединени, имаше някои грешки в съобщенията за грешки, които са коригирани, като е добавена и проверка при NRS имената за отхвърляне на наклонени знаци.

Някои примерни qjsonrpc приложения се разработват от @scorch (https://github.com/maidsafe/sn_api/pull/690), което ще помогне на потребителите да разберат как може да се използва qjsonrpc API-то и как приложения, нуждаещи се от JSON-RPC над QUIC протокола могат да бъде създадени. Информация за контекста на това е много добре описана в тази публикация за всеки, който се интересува да разбере повече за това.

С този PR, вече обединен, CLI-то е в състояние да проверява и баланса на собствения си SafeKey, т.е. с authd, което CLI използва за плащане на разходите за цялата операция, извършена от / с него. По този начин, чрез извикване на “$ safe ключове баланс”, без да предоставя своя таен ключ, сега по подразбиране проверява текущия баланс на CLI ключа / SafeKey.

Публикувани са нови версии на sn_authd (v0.0.15), CLI (v0.17.2) и sn_node (v0.25.39) за тези, които ги използват локално. Тъй като CLI и authd инсталационните файлове вече са изградени с помощта на MUSL за Linux платформи, ако сте на Linux моля, уверете се, че сте ги инсталирали, вместо да се опитвате да ги актуализирате с помощта на CLI, можете да намерите пълни инструкции за инсталирането им в CLI ръководството за потребителя.

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

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

Имаше доста дискусии за дизайна около интегрирането на BLS Distributed Key Generation (DKG) в BRB. Надеждата беше, че DKG ще може да се върне обратно към динамичните операции за членство (присъединяване / напускане) на BRB. В крайна сметка обаче установихме, че това не работи, тъй като DKG изисква 100% участие и трябва да се проведе като отделен процес след създаването на групата за гласуване на BRB.

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

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

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

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

Преводи:

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

Dimitar · February 11, 2021, 1:54am

Safe Network новини - 4.2.2021

Накратко

Днешното така очаквано пускане на тестова мрежа трябва да бъде отложено, тъй като не успяхме да въведем получаването на награди навреме, а да го деактивираме от наличния код не помогна.
Възможността да видим разделянето на секции в мрежата през последните дни, с въвеждането на последните подобрения, ни позволи да намерим и смачкаме някои неизвестни досега многосекционни проблеми.
Работата за опростяване на qp2p API-то за вътрешно управление на връзките и потоците, и отнемането на част от натиска от потребителското API вече преминава през допълнителна проверка.
Повдигнат е BRB PR за отстраняване на случайни загуби на пакети, които пречат на BRB операциите, тестван е и се очаква да бъде обединен скоро.
Специални благодарности на членовете на общността @bzee, @mav и @scorch за усилията им през последната седмица и за обединяването на множество техни PR-и.

Състояние на тестовата мрежа - отложена

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

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

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

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

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

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

За начало тази седмица беше обединен PR от @bzee, който позволява програмно конфигуриране на възли. Добра работа!

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

Освен това, отстраняваме грешки и различни проблеми с разделянето на секции сега, след като тази функционалност вече работи (макар и ограничено поради гореспоменатите проблеми), а уеб приложението на @mav node-logger се оказа чудесен инструмент за бързо разглеждане на потоците от съобщения предавани между различните възли и фокусиране на изходните данни от многосекционната мрежа в нещо малко по-четливо от човек.

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

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

API и CLI

През изминалата седмица получихме още няколко PR-а от общността, които бяха обединени и вече са част от нова CLI версия, публикувана днес (v0.18.0).

Благодарение на този PR, изпратен от @mav, валидирането на NRS вече изключва по-голям набор от знаци, които никога не биха имали някаква разумна цел за включване в кой да е URL адрес. Наличието на ограничение на общата дължина на URL адреса на NRS от 255 байта, при което всеки поддомейн не може да бъде по-голям от 63 байта, сега се налага с този PR .

Safe auth CLI командите сега дават приоритет на аргумента --config пред използването на променливи, това също вече е налице в новата версия благодарение на PR #700, също изпратено от @mav.

От страна на qjsonrpc PR #698, подаден от @Scorch се реализира основен клиент/сървър пример чрез използването на API-то на qjsonrpc. Клиентът на qjsonrpc изпраща съобщение ping до qjsonrpc сървър и той отговаря със съобщение ack. Този пример за програма просто и прецизно показва как qjsonrpc може да се използва за изграждане на всяка програма, използвайки JSON-RPC над QUIC. Има много повече дейности и проучвания, направени от @Scorch с още идеи около qjsonrpc - за тези, които се интересуват от повече подробности и / или искат да участват в това усилие, погледнете неговата тема във форума за разработчици.

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

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

Дискусиите за интегриране на BRB с BLS Генериране на разпределен ключ (Distributed Key Generation - DKG) продължиха с няколко възможни опции. Изглежда, че консенсуса се фокусира върху една от опциите. Подробности за тези планове трябва да бъдат публикувани в идните седмица след като започнем работата.

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

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

Преводи:

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

Dimitar · February 18, 2021, 12:28am

Safe Network новини - 11.2.2021

Накратко

Тестовата мрежа все още е на пауза, тъй като работим за завършване на преструктурирането на потока от съобщения, който блокират напредъка на разпределянето на наградите.
Работата по преструкторирането на потока от съобщения отбелязва добър напредък, като е налице проект за PR. Това ще доведе до по-чист, опростен и по-ефективен поток от съобщения.
Мигрирахме внедряването на тедтовата мрежа/премахването на скриптове към terraform, което доведе до драстично подобрение във времето, необходимо за създаване на тестова мрежа от всякакъв размер за вътрешно тестване/външно внедряване.
Докато чакаме внедряването на наградите открихме и премахнахме някои грешки, които иначе биха останали скрити.
В CLI-то е внедрена нова подкоманда $ safe networks set, която ще позволи на потребителите да се свързват по-лесно с мрежите, като просто използват техния IP адрес и порт за зареждане, съответния PR преминава през преглед сега.
Вярваме, че намерихме решение за разклоняването на веригата от секции в sn_routing. Понастоящем това решение се прилага и вярваме, че ще помогне да направим тестовите мрежи достатъчно стабилни, за да ги представим пред общността.
Принос към програмния код продължава да идва от общността!

Състояние на тестовата мрежа - отложена

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

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

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

Подготовка на тестовата мрежа и тестове

В края на миналата седмица се опитвахме да стартираме големи тестови мрежи и бързо стана ясно, че нашият скрипт за това не върши добра работа - отнема 30 минути, за да стартира 20 възела и адски повече за стартиране на 100 възли! За да се справим с този проблем мигрирахме към terraform за управление на стартирането / унищожаването на виртуални машини и възли и с него е много по-добре. Вече можем да стартираме 40 каквито и да е възели за няколко минути. Използвахме това доста интензивно за тестовете и го настроихме, така че да ни позволи да стартираме и персонализираме компилации на възли. Което се оказа много удобно по отношение на тестовете. PR за това преминаване към terraform е на място и е доста щателно тестван, с малко оставаща работа, предвидени преди обединяването.

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

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

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

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

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

QP2P

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

Съобщения

Наскоро преместихме натрупването на съобщения само в sn_routing, като преди това го правехме и в sn_node. За да завършим това преструктуриране променихме много код, но също така премахнахме около 1350 реда.
Резултатът е по-опростен, по-чист и по-ефективен поток от съобщения.

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

API и CLI

Технически дълг, който имахме в sn_api контейнера, беше да направим характеристиката на типа “Грешка” да приложи “std::error::Error”. Това е нещо, което завършихме и обединихме през изминалата седмица с помощта на thiserror контейнер. Променихме и CLI кодовата база, за да използваме anyhow, така че всички функции сега връщат anyhow::Result и обработката на грешки е много по-лесна, без загуба на информация или контекст за основната причина за всяка от разпространените грешки.

В CLI-то е внедрена нова подкоманда $ safe networks set, която ще позволи на потребителите да се свързват по-лесно с мрежи, като просто използват IP адрес за зареждане:порт за начален адрес. Съответният PR включва актуализация на Ръководството за потребителя, така че за всеки, който се интересува от ранните отзиви за тази команда, моля, погледнете описанието тук.

Приносът от общността продължаваше да идва и през изминалата седмица. Има усилие в процес на работа от @bzee, за да направи пакета nodejs съвместим с последната версия на sn_api, както и поправка в CLI за премахване на име на флаг, което причинява конфликт между две различни команди ([поправка: премахване на кратка опция, използвана за тест от b-zee · Заявка за изтегляне # 708 · maidsafe / sn_api · GitHub] (https://github.com/maidsafe/sn_api/pull/708)). PR също беше издигнат и обединен, за да се премахне реализацията на събирането на логове от sn_client, тъй като това трябва да бъде оставено на приложенията или изпълнимите файлове, които използват библиотеката, уверявайки се, че приложенията не получават неочакван изход на stdout или stderr.

Тъй като по-голямата част от зависимостите на нашите хранилища използват tiny-keccak v2.0.2, @mav изпрати PR, за да актуализира всички наши хранилища, за да зависят от същата версия. Много ценим усилията на всеки, който се включи по какъвто и да е начин

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

Извършихме допълнителна работа върху brb_node_qp2p, за да работи с двупосочни потоци и новия (излизащ скоро) qp2p API. Това позволява на всеки възел да изпраща и получава от един и същи порт, вместо да отваря нови връзки през отделен произволен порт за изходящи пакети. В процеса допринесохме няколко малки PR за qp2p. Един по-конкретно улеснява споделянето на „qp2p“ крайна точка между нишките, което би трябвало да е плюс за всеки, който изгражда p2p прогряма с библиотеката.

sn_data_types

Подготвихме дизайн за опростяване на логиката на политиката / разрешенията, регулиращи достъпа до мрежови данни, който в момента преминава през вътрешен преглед. Имаме и PoC за нов Chain CRDT, който може да се окаже по-добър CRDT за нашия Sequence тип данни , това дойде от проблемът, който @mav повдигнат относно Sequence типа данни .

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

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

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

Преводи:

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

Dimitar · February 25, 2021, 1:50pm

Safe Network новини - 18.2.2021

Накратко

Добавен е нов набор от инфраструктурни съобщения, които sn_routing може да използва за по-добра обработка и връщане на грешки по време на разделянето на секциите.
Работата по обработката на невалидни SignatureShares от лоши актьори при трансфери започна, като сега изготвяме санкциите за тези лоши актьори.
Работата по обмена на съобщения е към своя завършек, което означава значително по-малко код и сложност за анализ на входящите съобщения в sn_node и разчистване на пътя за интегриране на възнагражденията.
Пуснати са нови версии на CLI-то (v0.19.0) и authd (v0.1.1), което ги прави съвместими с най-новия sn_node (v0.26.16), както и няколко други подобрения.
Първата примерна програма вече е налична в sn_api хранилището, демонстрираща как да качите файл в мрежата и след това да го достъпите, използвайки нейния XOR-URL адрес.
Направихме стъпки към интегриране на sn_fs и BRB, за да създадем P2P византийско-толерантен прототип на разпределена файлова система.
Модификациите на секционните вериги в sn_routing за справяне с форкове вече са на място, като тестовете ни показват голямо подобрение на стабилността на мрежата, особено при разделянията.
Още фантастични приноси на общността към кодовата база

Състояние на тестовата мрежа - отложена

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

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

Благодарим ви за търпението!

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

“Мързеливи” съобщения

За да се справим по-добре с проблемите при разделянето на секции, както и по време на отпадането на възли, добавихме нов набор от съобщения за инфраструктурата, които sn_routing може да използва за връщане на грешки като DKGINprocess, когато се опитваме да изпращаме съобщения на старейшини в такива ситуации. За да направят това, клиентите / възлите ще предоставят текущия PublicKey за секцията, доколкото той им е известно, и ще можем да предприемем действия, ако това е, например, неактуално. Тези промени са добавени в sn_messaging, sn_client и sn_routing и разглеждаме някои малки преструктурирания, за да опростим нещата с възлите.

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

Наказване на лоши актьори

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

Поток на съобщенията

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

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

API и CLI

Новите версии на CLI (v0.19.0) и authd (v0.1.1) бяха пуснати тази седмица, което включва всички корекции, подобрения и нови функции, внедрени от предишната версия. Както обикновено, те могат да бъдат надстроени съответно с $ safe update и $ safe auth update. Тези приложения са съвместими с най-новата версия sn_node v0.26.16, така че за тези, които надграждат, също така не забравяйте да надстроите и sn_node програмата ($ safe node install или $ safe node update).

@scorch забеляза, че най-новата версия на clippy оплаква под Windows за CLI и authd codebase, и представи поправка за него. Това ни накара да подобрим clippy проверките в нашите CI скриптове, за да се изпълняват не само под Linux, но и под Windows, което трябва да предотврати повторното му подхлъзване.

С добавянето (от @mav) на ново API в CRDT Sequence типовете данни за извличане на запис, посочващ единичен индекс, а не диапазон, @mav сега промени нашия sn_api, за да се използва това ново API за извличане на определена версия на Sequence.

Няколко подобрения бяха направени и в този нов CLI (v0.19.0), който позволява на потребителя да настрои информацията за първоначално зареждане на мрежата чрез IP (v4 или v6) и номер на порт, за повече подробности за тази нова команда, моля, вижте в съответния раздел в Ръководството за потребителя на CLI.

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

CRDT

Дейвид Русу, автор на rust-crdt, както и на нашата реализация на „BRB“, преглежда „LSeq“ кода, след като @mav съобщи за проблеми с него когато се изпълняват много въвеждания. Той замени внедряването на ID, базирано на оригиналната LSeq разработка, с рационално число от num хранилището. Това прави LSeq кода много по-опростен и също така води до по-добро (по-равномерно) разпределение, разрешавайки проблема и позволявайки вмъкване на произволен брой елементи. „LSeq“ също е преименуван на List. Искане за изтегляне.

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

Помните ли sn_fs, нашият прототип на файлова система, използваща дървесния CRDT? Е, тази седмица правихме стъпки към интегриране на sn_fs и BRB, за да създадем прототип на P2P разпределена файлова система, устойчива на византийски атаки, .

Първо отделихме brb_node_qp2p и създадохме brb_node_tree, което демонстрира изпращане на операции crdt_tree чрез brb. След това модифицирахме контейнера sn_fs и го превърнахме в библиотека. Съвсем наскоро създадохме brb_node_snfs контейнер, в който обединяваме всичко. Към днешна дата успяхме да свържем два (или повече) възела и да извършваме операции с директории като mkdir,rmdir. Операциите се отразяват в монтираната файлова система на всеки партньор. Операциите с файлове все още не работят, но трябва да са готови скоро.

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

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

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

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

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

[ДОПЪЛНЕНИЕ от 22 февруари] - Safe браузър

Нещо, което първоначално забравихме да добавим към тези новини

@bzee създаде PR, за да ускори sn_nodejs с най-новите промени в API-то, който е необходим за обновяване на Safe браузъра, за да бъде съвместим с останалата част от Safe мрежата отново. Той също така разглежда ограниченията на текущата библиотека и вижда възможности за подобряване на нещата!.

Благодарим ти @bzee! и извинения за това, че първоначално пропуснахме твоя принос.

Преводи: