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

SAFE Network новини - 12.3.2020

Накратко

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

  • Пуснахме SAFE браузър v0.16.0, който е съвместим с локалната / споделена версия на Трезора. Но не и с версията за Бейби Флеминг.
  • Пуснахме и SAFE браузър v0.17.0-alpha.0, който е съвместим с Бейби Флеминг. Но не и с локалния / споделен трезор.
  • Създадохме инсталационен скрипт за SAFE CLI. Вече е възможно да инсталирате SAFE CLI v0.9.0 с него.
  • Благодарим ви за отзивите относно версия 1 на Бейби Флеминг. Наближаваме бързо към версия 2.

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

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

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

Както може би сте виждали, повечето от тези проблеми се дължат на известно закъснение и голямо използване на паметта от Старейшините (отговарящи за клиентите). Това е така, защото всички клиентски заявки, свързани с харченето на safecoin, бяха изпращани чрез PARSEC за постигане на консенсус, преди да се обработи допълнително заявката. Това може да отнеме известно време в зависимост от размера на заявката, броя на заявките, които се обработват и т.н. Наясно сме с това и ще работим да го подобрим през следващите седмици. Имайки това пред очи, за да помогнем с тестването на останалите функции (API, CLI команди и т.н.), ще премахнем PARSEC от потока за обработка на заявки от клиентите и ще пуснем нова версия на трезора. Тестваме това вътрешно и след като сме готови, ще пуснем следващата итерация на тестовата мрежа Фаза 2a. С по-бързи времена на реакция, би трябвало да можем да пуснем и трезори, хоствани на облачни машини, което значи, че ще имаме и споделена Секция :wink:Останете на линия!

SAFE API

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

През последните няколко седмици успяхме да внедрим още няколко функции към CLI-то. Една от тях е добавянето на files rm команда, която може да се използва за премахване на файл или цял път от съществуващ FilesContainer. Това беше финализирано точно навреме, за да бъде част от Бейби Флеминг миналата седмица, така че можете да го използвате вече със SAFE CLI v0.9.0.

Веднага след пускането на Бейби Флеминг, продължихме с още една функция, която ни дава възможност да изброяваме файлове в дървовидна форма с добавяне на files tree команда, която може да бъде наистина полезна за потребителите, които се опитват да разберат йерархията на файловете в FilesContainer, например:

$ safe files tree safe://hnyynysurwzoiudugs47d7fjx7hwg3i7ch1ryowdm7gpgj4538n1mwqukgbnc
Files of FilesContainer (version 0) at "safe://hnyynysurwzoiudugs47d7fjx7hwg3i7ch1ryowdm7gpgj4538n1mwqukgbnc"
SIZE CREATED MODIFIED NAME
/
6 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z ├── another.md
0 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z ├── noextension
├── subfolder
4 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z │ ├── sub2.md
23 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z │ └── subexists.md
12 2020-03-03T22:31:21Z 2020-03-03T22:31:21Z └── test.md

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

Като паралелна задача и както се очакваше от предишните новини, продължихме с миграцията към използването на Rust async/await в safe-api хранилището, задача, която стартирахме още през ноември 2019 г. и най-накрая я добавихме в основния клон, който мигрира цялата кодова база от safe-api, за да използва async/await. Тъй като се опитваме да направим тази миграция, без да засягаме други компоненти, в тази първа стъпка излагаме SAFE API-тата на Rust като async, но вътрешно те все още се заключват, когато се обаждаме към API-то на safe_client_libs. Следващата ни стъпка е да се опитаме да мигрираме не само safe_client_libs, за да разкрием API-тата на async, но и API-тата на safe-nodejs, за да могат да върнат Promises.

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

И накрая, успяхме да създадем инсталационен скрипт за SAFE CLI. Този скрипт не само изтегля най-новата налична SAFE CLI, но и инсталира CLI в папката ~/.safe/cli/ (C:\Users<user>.safe\cli\ в Windows), като го и задава в PATH, така че можете да стартирате safe файла от всяко място, когато отваряте конзола. Актуализирахме Ръководството за потребителя с инструкции как да използвате този метод на инсталиране на CLI. Вече е възможно да инсталирате SAFE CLI v0.9.0 с помощта на този скрипт.

Обърнете внимание, че има съобщения че скрипта за инсталиране не се добавя към PATH за zsh и fish конзоли, може да се наложи да добавите ръчно към вашия .bashrc еквивалент, ако скриптът не го добави към PATH на вашита конзола.

SAFE Network програма

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

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

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

2c26a9100d3c5b76c93c219845732ea9dfee9f70_2_615x500

Достъп до програма спрямо споделяне

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

09c873d80edc295b49358428dc473d5f2d82180c_2_247x499

Управление на файлове

Сега работим по потоците за публикуване и споделяне на файлове чрез SAFE Network програмата.

3af187e83f3f1759ffc9fa3bfe6754f639ac78b6_2_310x500

Публикуване и споделяне

Относно разработката, след като актуализирахме всички зависимости, за да премахнем болезнената зависимост от openssl (и да използваме основните rust rustls), започнахме да актуализираме SAFE Network програмата, за да работи отново със CI, но също така и да е съвместима с любимата на всички Бейби Флеминг. :baby:

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

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

Тази седмица най-накрая пуснахме SAFE браузър версия 0.16.0, която има няколко подобрения: Възможност за контрол на достъпа за опростяване на уеб разработката, даваща възможност за извличане на API-то и актуализиране на safe-nodejs до 0.8.0. Но внимавайте! Това не е съвместимо с Бейби Флеминг.

За онези безстрашни хора, които искат възможността да тестват сами, предлагаме v0.17.0-alpha.0. Тази версия носи съвместимост с Бейби Флеминг, както и прескача използването на safe-nodejs библиотеката за предотвратяване на достъпа до файловата система без да минава през API-тата на браузъра (благодарим на @shane). Това все още не е напълно завършено. Планираме да дадем възможност на API-тата в браузъра да работят директно с файлови обекти, за да улесним живота на всички. Но засега това поне подобрява сигурността и ни насочва към по-финализирани API-та.

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

След като пуснахме Бейби Флеминг се заехме да актуализираме всички необходими хранилища (quic-p2p, safe_client_libs, safe-api), за да сме готови да поддържаме същия набор от функции на мобилни устройства, както и да актуализираме NuGet пакета ни. Използваме отделен клон baby-fleming-mobile във всички тези хранилища, за да проследим необходимите корекции и промени. След като получим надстройките, работещи върху CI и получим работния набор от местни библиотеки, ще тестваме API-то на C # и мобилните приложения с Бейби Флеминг и ще пуснем новите версии за мобилния удостоверител и браузър.

Маршрутизиране и quic-p2p

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/

SAFE Network новини - 19.3.2020

Накратко

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

  • Пуснахме версия 2 на Бейби Флеминг. :tada: Тази актуализация се състои от нова версия на safe_vault (v0.22.0), която премахва PARSEC за клиентски заявки.
  • Пуснахме SAFE CLI v0.10.0, която включва (наред с други подобрения) нова команда files tree.
  • Пуснахме нов пакет RC MaidSafe.SafeApp NuGet, който поддържа заявки с различен обхват и работи с Бейби Флеминг мрежата.

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

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

Днес пускаме втората версия на Бейби Флеминг, известна още като Трезори Фаза 2a :tada:

Както беше подробно описано в новините от миналата седмица, проблемите с производителността при първата версия на Бейби Флеминг се дължаха основно на всички клиентски заявки при харченето на Safecoin чрез PARSEC за постигане на консенсус, преди да се обработи допълнително заявката. Версия 2, която пускаме днес, премахването PARSEC от потока за обработка на заявка на клиента.

Разбира се, все още ще трябва да постигнем консенсус в този поток и там ще използваме BLS - разпределеното генериране на ключове, за да облекчим натоварването върху PARSEC. Повече за това в раздела BLS - Разпределено генериране на ключове - по-долу. Засега обаче има смисъл да премахнем това ограничение на производителността ви позволим да тествате Бейби Флеминг.

Как да обновите до версия 2 на Бейби Флеминг?

Тази актуализация се състои от нова версия на safe_vault - v0.22.0.

С помощта на CLI можете да инсталирате тази нова версия с помощта на командата safe vault install. Вижте CLI ръководството за пълни инструкции за инсталиране на трезора, както и за инструкции как да пуснете собствена секция от трезори на компютъра си.

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

При качване на данни може да възникнат периодични грешки (AccessDenied или NetDataError - Failed to PUT Sequenced Append Only Data описани тук). Наясно сме с това и разследваме.

Кога MaidSafe ще пусне споделена Секция?

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

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

SAFE API

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

Пуснахме нова версия на safe-api (v0.10.0), както и нов safe-cli (v0.10.0), който включва всички функции, които сме внедрили след излизането на Бейби Флеминг. Актуализирахме Ръководството за потребителя за CLI с инструкции за новата files tree команда.

Тази нова версия на safe-api е първата версия, която излага API-то си като async, което е важна стъпка към пълната поддръжка на асинхронни заявки от тези API-та. Както бе споменато в предишните новини, вътрешно те все още не са асинхронни и това ще бъде следващата ни стъпка в това отношение.

През последните няколко седмици мобилните библиотеки на safe-ffi бяха деактивирани. Проблемът беше свързан с мобилната поддръжка за някои от външните контейнери на Rust. Тази седмица решихме проблема с изграждането на safe-ffi в отделен клон (baby-fleming-mobile). След като имаме стабилни версии на външните контейнери, които работят правилно със собствените си библиотеки, ще обединим кода с главното хранилище. Тези актуализирани библиотеки ще ни помогнат да подкрепим пускането на мобилните приложения за мрежата с една секция.

Финализирахме основен набор от показатели, които да се изпълняват в Бейби Флеминг мрежата. Тези тестове са просто за качване на данни в мрежата (файлове с размер 0.5, 1, 2 и 4 мегабайта). Тестовете бъдат X пъти (търсейки разумен размер на извадката, надяваме се поне ~ 50 пъти), макар че това ще зависи от напредъка за подобряването на качването на данни като цяло. За тези, които се интересуват от това (или да допринесат за повече тестове), можете да проверите PR черновата, която добавя -t или–test аргумент на любимия на всички safe vault run-baby-fleming -t за автоматично стартиране на мрежата, рестартира удостоверителя и създава тестов акаунт за CLI-то. (Забележете, за да работи това се нуждае както от safe командата, така и от authd, да бъдат инсталирани на стандартните им места).

SAFE Network програма

Тази седмица работихме върху някои малки подобрения на SAFE Network програмата, актуализирайки зависимостта от Node.js, за да се подготвим за съвместимо издание с Бейби Флеминг и поправихме теста на E2E.

Актуализацията на Node.js подчерта някои потенциални грешки там, така че разглеждаме и това. Но след като ги оправим, ще можем да я пуснем за да си поиграете с :baby:

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

План за Удостоверителя, План за браузъра

Тази седмица актуализирахме Удостоверителя, за да поддържаме Бейби Флеминг и тествахме програмата на двете платформи (Android, iOS).

Днес пуснахме и нов пакет RC MaidSafe.SafeApp NuGet, за да можем да актуализираме мобилния браузър и да поддържаме Бейби Флеминг. В момента вътрешно тестваме мобилния браузър и ще пуснем нови актуализирани версии и на двете мобилни приложения, след като сме доволни от тях.

SAFE App C#

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

Миналата седмица API за извличане (fetch) на Rust беше актуализирано, за да поддържа извличането на диапазон от байтове от файл, така че тази седмица актуализирахме C# API-тата за fetch и get_immutable_data за да поддържаме и заявки с обхват. Това ще позволи на разработчиците да извличат съдържанието между дадения начален и краен индекс. Пуснахме и нов RC MaidSafe.SafeApp NuGet пакет. Този нов пакет осигурява поддръжка за мрежата с една секция / Бейби Флеминг.

Маршрутизиране и quic-p2p

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

Обединихме и подобрена се доставка на съобщения в присъствието на изоставащи с работата трезори в PR (PR 2068). Друг голям напредък, който постигнахме включва обединяването на работата по опростяване на моментното състояние на машината: одобряването на Старейшини и Възрастни (PR 2071), както и BoostrappingPeer и JoiningPeer в едно (PR 2072). Те много опростяват състоянието на машината и в крайна сметка ще се стремим да го премахнем изцяло. Друго подобрение през тази седмица беше обединяването на идентификатора за регистрация PR (PR 2073). Това намалява нашия код и гарантира, че цялото влизане в контейнера за маршрутизиране идентифицира възела, за който е бил записът в журнала.

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

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

Разчитайки на PARSEC, гръбначния стълб на мрежата, за всички видове консенсус може просто натоварим мрежата по начини, които обикновено не виждаме. Например, данните в SAFE мрежата могат да бъдат бързо променящи се и запитването/извличането на такива данни с консенсус от PARSEC ще отнеме известно време, за да бъдат извлечени. Тази продължителност може да е достатъчна, за да се актуализират данните до по-нова версия от изтеглената. Следователно, за да се сведе до минимум натоварването на PARSEC и да се постигне бърз консенсус за операции като запитване на споделени данни, портфейли с множество подписи и др., сме изправени пред изискването да прехвърлим част от консенсуса върху друг механизъм. Тук идва BLS-разпределеното генериране на ключове, криптографска схема за подписване, която позволява на субектите бързо да постигнат консенсус по даден обект чрез естеството на шестте му фази и принуждават 100% участие от съответните възли. Можете да прочетете повече за работата му и подробности тук и тук. Реализацията на доказателство на концепцията е в процес на работа от екипа, като първоначално ще тестваме със споделени данни от клиенти, въпреки че по-голямата цел е да го използваме за случаи като споменатите по-горе и ще бъде общ контейнер, който ще се използва за постигане на консенсус, без да се разчита напълно на PARSEC през цялото време.

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 26.3.2020

Накратко

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

  • Пуснахме версия 3 на Бейби Флеминг :tada: Тази актуализация се състои от нова версия на safe_vault (v0.23.0), която използва новата версия на quic-p2p, актуализирана, за да използва последната версия на библиотеката Quinn.
  • Пуснахме нови версии на SAFE CLI (v0.11.0) и процеса на Удостоверителя (v0.0.7), които са съвместими с новия safe_vault (v0.23.0) и използваме нови версии на SAFE Клиентските библиотеки, които повтарят процеса на зареждане няколко пъти преди да върнат грешка.
  • @jimcollinson публикува кандидат-дизайни за някои от ключовите потребителски истории, свързани с разрешенията за файлове, навигация на данни и публикуване. Вижте секцията SAFE Network програма UX по-долу.

Бележка от MaidSafe фондацията за актуалната пандемия Covid-19

Фондация MaidSafe - която е регистрирана шотландска благотворителна организация - подкрепя преподаването на науката, технологиите, инженерството и математиката (STEM), както и на изкуството.

Пандемията Covid-19 закрива училища в много части на света и може би се притеснявате дали държите децата си заети и образовани. За да ви помогнем, сме събрали няколко забавни дейности, които са съставени с помощта на STEM указания за преподаване тук, във Великобритания. Дейностите обхващат три възрастови групи с по два проекта за всяка. Като ориентир дейностите на ранното ниво са за деца от 3 до 5 години, първото ниво за деца от 6 до 8 години и второ ниво от 9 до 11 години.

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

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

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

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

Искрено Ваши,

Екипът на MaidSafe

Ако искате да дарите на MaidSafe Foundation, моля, следвайте линка по-долу или използвайте QR кода за достъп до нашия PayPal акаунт. Всички дарения ни помагат да подкрепяме образователни проекти в училищата и общностите.

PayPal

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

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

Днес пускаме третата версия на Бейби Флеминг, известна още като Трезори Фаза 2a :tada:. Актуализирахме quic-p2p, за да използва най-новата версия на библиотеката Quinn и актуализирахме всичките ни контейнери, за да използват новата версия на quic-p2p. Заедно с тази актуализация правим някои сравнителни тестове на CLI командите срещу Бейби Флеминг. Забелязахме, че има някои проблеми в моменти, когато Клиентът (CLI в този случай) не е в състояние да стартира мрежата. Това може да възникне по редица причини, като загуба на пакети, прекъсната мрежова връзка и др. Връщането на грешка веднага щом това се случи, няма смисъл, така че внедрихме малка функция в библиотеките на SAFE Клиента, която стартира процеса на зареждане няколко пъти, преди да върне грешка. Като имаме това място, успяхме да сравним CLI командите срещу Бейби Флеминг в 1000+ повторения. Пуснахме нови версии на Трезора и CLI, моля тествайте ги и пишете за ако намерите грешки.

Как да обновите до Бейби Флеминг версия 3?

Тази актуализация се състои от нова версия на safe_vault (v0.23.0), както и нови версии на SAFE CLI (v0.11.0) и процеса на Удостоверителя (v0.0.7).

Ако никога преди не сте използвали CLI, можете да следвате ръководството тук, за да изтеглите и стартирате нашия скрипт за инсталиране.

Ако сте използвали CLI преди, тогава трябва да го актуализирате, като стартирате:

$ safe update

След това трябва да актуализирате процеса на Удостоверителя:

$ safe auth update

Най-простият начин за актуализиране / инсталиране на новата версия на safe_vault е да стартирате:

$ safe vault install

Всички версии вече трябва да са актуални и можете да стартирате своя собствена Бейби Флеминг мрежа. Вижте CLI ръководството за пълни инструкции.

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

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

Кога MaidSafe ще пусне споделена Секция?

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

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

SAFE API

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

Коригирахме няколко незначителни проблема в safe-cli, причинени от скорошното ни преминаване към async, което въведе някои конфликти в контейнера за самообновяване и свързаните с него команди. Друг малък проблем, който решихме, се отразяваше на safe-nodejs API-то: в неуспех за стартиране на safe-authd. Пуснахме нова версия на този пакет (v0.10.0), което ще ни позволи да имаме нови версии на браузъра и SAFE Network програмата, надяваме се скоро.

Направен е и незначителен рефактор в тестовете на safe-api , което ги прави по-изчистени, като избягват използването на unwrap и вместо тях връщат грешки. Всичко това е благодарение на нова функция на Rust, която позволява тестовете да връщат Result.

Safe-api хранилището също беше адаптирано, за да се актуализира до най-новата версия на quinn (v0.6.0), което донесе някои проблеми в неговото API, но и някои опростявания, от които искахме да се възползваме.

Днес пуснахме нови версии на safe-cli (v0.11.0) и safe-authd (v0.0.7), които са съвместими с новия safe_vault (v0.23.0) от днес. Моля, уверете се, че сте актуализирали своя CLI и authd, ако планирате да използвате тази нова версия на safe_vault. Не забравяйте, че можете да актуализирате CLI с командата safe update, а също така да актуализирате authd с командата safe auth update. Следвайте инструкциите от Ръководството за потребителя на CLI, ако досега никога не сте инсталирали SAFE CLI и / или процеса за Удостоверяване на вашата система.

Вследствие на откриването на този бъг в safe-nodejs и със силата на Бейби Флеминг, обновявахме Node.js тестовете ни, за да работят с локална мрежа. Това само по себе си също е започна мигриране към GitHub actions хранилище, което трябва да ускори изграждането и тестването.

Успоредно с всичко това, вече започнахме с първия проект за внедряване на API за данни тип Sequence в safe-api, както и върху някои основни CLI команди, които ще позволят на потребителите да създават и мутират съдържание директно в Sequence, напр. safe seq put и safe seq append команди. Това е в много ранен етап и все още нямаме какво да споделим, това са първите ни стъпки към внедряването на последователността като тип данни от CRDT направо в нашата кодова база на Бейби Флеминг. За това се фокусираме в подхода на E2E, т.е. планираме да използваме CLI и неговите интеграционни тестове, за да валидираме прилагането на Sequence CRDT реализация в трезора. Надяваме се, че ще имаме още за споделяне след няколко дни, когато напреднем.

И накрая, правим обновление и вътре в SAFE Клиентските библиотеки, като тази седмица обединихме двойка PR-и, премахвайки части от старата функционалност на FFI, която беше силно преплетена в кодовата база, в полза на по-ясното разделяне на проблемите в самото safe-api, това ни даде код, който е малко по-чист и по-достъпен.

SAFE Network програма - UX

MVE проследяване на напредъка на функциите

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

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

И така, ето някои от основните потребителски истории, които си проправят пътя към вас. Кликнете на тях или ги изтеглете, за да ги разгледате в пълен размер:

Съгласие точно навреме

10419824260748ec8381372736a923089adb951c_2_690x265

Промяна на заявка за съгласие точно на време

fd47c4b9987cb45a943ff17ea6148c9b0e229102_2_690x232

Качване на файл

381cfd2c718308143f8c3aaa4130ab848784ff78_2_690x240

Създаване на нова папка

59474ef4018c0a5b9d2cecb4223f6513cd597014_2_690x345

Промяна на името на файл или папка

a943a03fad660e1a9afb6c81d77c08accaebcb9b_2_690x345

Местене на файлове или папки

491c59481e4f208e780bbdf5f01baac4eef428b9_2_690x250

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

77def8bd23acc39d56b85e1e81a31a7dcac1eee9_2_690x210

Публикуване: уникален линк

4c38939173f7ad1b1e8ce8ff0c1e0fe440ab9905_2_690x245

Публикуване: добавяне към съществуващ сайт

ca2bfe2c1e19cca6309cfd8afbfac77b0f09d823_2_690x291

И това е за сега. Както обикновено, ние ще се радваме да чуем мислите, коментарите и неоправдано острите ви критики. :smile:

SAFE Network програма - разработка (декстоп)

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

С оправянето на safe-nodejs API-то навлизаме в процес на финализиране на отдавна разработван PR за SAFE Network програмата, който е пълен с незначителни промени и актуализирани API-та. Той също така включва преминаване към GitHub Actions за тестване и изграждане на кодовата база. Има някои проблеми с конфигурация там, но сме много близо да оправим и това, за да пуснем SAFE Network програмата, съвместима с Бейби Флеминг!

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

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

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

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

Не удостоверен

025428a829f662e5894330874d7e4550b769742b_2_690x79

Удостоверен

2725f7e1baf0082777bf9965a5524dcf5d69f5b3_2_690x74

SAFE App C#

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

Тази седмица изложихме ново FilesContainerRemovePath API от safe-api. Тови API ще позволи на разработчиците да премахнат файл / път от съществуващ контейнер за файлове, използвайки XORURL адреса на файла. Добавихме и някои тестове, за да гарантираме правилното функциониране на това API.

Маршрутизиране и quic-p2p

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

Тази седмица приключихме с голяма задача за обновяване (разделена на няколко PR-а: #2071, #2072, #2073 и #2075). Това е „невидима“ работа в смисъл, че не са внедрени нови функции, но все пак беше важно да се направи. Премахнахме доста несъществени усложнения и технически дълг, който се натрупа с времето. Това доведе до по-опростен код, което е добре, тъй като по-простият код е: по-лесен за тестване, по-лесен за отстраняване на грешки, по-лесен за одит за уязвимости в сигурността и накрая с него по-лесно се включват нови разработчици.

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 2.4.2020

Накратко

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

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

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

Тази седмица осъществихме последната стъпка от Фаза 2а, а именно споделена Секция, разположена върху компютри в DigitalOcean. Тази секция се състои от 8 трезора (7 старейшини и 1 възрастен), всеки от които се намира на отделен компютър, които работят заедно, използвайки Маршрутизирането и комуникират с помощта на quic-p2p, за да обработват и отговарят на заявки, изпратени от браузъра или CLI-то чрез SAFE Клиентските библиотеки. Това е нова версия на различните компоненти, които работят заедно, така че ако все още не сте я изпробвали, преминете към този пост във форума и я тествайте.

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

SAFE API

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

safe-nodejs получи някои актуализации тази седмица. Не на последно място актуализация на най-новата версия на Safe-api 0.11.0, която осигурява съвместимост с най-новите тестови мрежи на Бейби Флеминг (това е включено в най-новите алфа версии на браузъра / safe network програмата, въпреки че все още се борим с някои проблеми с подписването на код там).

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

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

SAFE Network програма (десктоп)

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

Най-накрая SAFE Network програмата получава дългоочаквана актуализация, като тази седмица излиза новата съвместима с Бейби Флеминг алфа версия. Освен настройването на някои CI подобрения за активиране на автоматичните обновления, SAFE Network програмата вече може да:

  • Управлява / инсталира CLI-то и го използва за инсталиране / управление на safe-authd
  • Спира Safe-authd при изключване само ако е отговорна за стартирането му
  • Автофокусира при получаване на заявки за удостоверяване

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

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

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

Десктоп браузърът също получи някои CI подобрения за непрекъсната доставка. Отвъд това, най-новата версия е с актуализирани SAFE API-та и внедрява корекция за сигурност, което позволява contextIsolatio за елементите на уеб преглед в Electron. Това трябва да предотврати някои експлоатационни мерки в сигурността, свързани с JavaScript веригата прототип.

Тази седмица бяха пуснати нови алфа версии на настолния браузър, които включват тези най-нови актуализации, както и съвместимост със споделената секция на Бейби Флеминг. Можете да изтеглите от GitHub тук. Забележете, както беше споменато по-горе имаше някои проблеми с подписването на кода на браузъра и SAFE Network програмата, работата по отстраняването им продължава, така че моля, игнорирайте всички свързани грешки при инсталирането.

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

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

Днес пуснахме нова версия на SAFE Удостоверителя (v0.3.0). Тази актуализирана версия поддържа мрежата с една Секция (версия 3 на Бейби Флеминг), включително споделената секция, пусната от MaidSafe. Можете да изтеглите новото приложение за удостоверяване чрез QR кодовете или връзките, достъпни тук.

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

Сваляне на настройките за споделената секция на MaidSafe Автоматично добавяне на споделената секция на MaidSafe

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

SAFE браузър (мобилни устройства)

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

Днес пуснахме и нова версия на SAFE мобилния браузър (v0.4.0), също съвместима с мрежата с една секция(версия 3 на Бейби Флеминг), включително хостваната от MaidSafe споделена секция. За да изтеглите и започнете да използвате актуализирания мобилен браузър, можете да намерите QR код и връзките за директно изтегляне тук.

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

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

Обновяване на диалога за удостоверяване Състояние на удостоверяването и бутон за удостоверяване

SAFE App C#

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

Тази седмица реконструирахме вътрешната структура на проекта и опростихме връзките въз основа на последните промени в преработката на FFI в safe_client_libs / safe_app, safe_client_libs / safe_authenticator_ffi и safe-api / safe-ffi библиотеките. Тествахме промените и пуснахме стабилен MaidSafe.SafeApp NuGet пакет, съвместим с мрежата с една секция.

Маршрутизиране и quic-p2p

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

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

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

Продължаваме с напредъка, споменат миналата седмица, по работата на PoC за прилагането на DKG схемата. Добавихме тестовете за threshold_signature и threshold_encrypt - тези два теста служат също като примери за демонстриране на това как може да се използва основния контейнер. Ще добавяме още тестове, за да разширим обхвата и да демонстрираме повече случаи на използване. От страна на свързаността на нещата, трезорът, използващ този контейнер, трябва да е запознат с фазите на DKG, през които ще премине, следователно това изисква подобен модел на изпълнение като този на архитектурата ни в SAFE Клиентските библиотеки (където свързаността се управлява от States). Тази яснота ни проправи няколко маршрута, които екипът може да предприеме, за да постигне свързаност и смятаме да тестваме този модел през следващата седмица, за да видим дали това ще бъде ефикасен начин за структуриране на контейнера.

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 9.4.2020

Накратко

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

  • Завършихме преструктурирането в authd (процесът на Удостоверителя), което носи възможност за стартирането му под Windows без администраторски разрешения (започвайки от следващата версия).
  • Командата safe files е завършена и трябва да бъде включена в следващата версия на SAFE CLI.
  • @jimcollinson публикува още няколко примерни дизайна, свързани с SAFE Network App UX (вижте по-долу).
  • Планирането продължава за Трезори Фаза 2b - многосекционна мрежа.

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

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

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

SAFE API

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

През изминалата седмица успяхме да завършим преструктурирането в authd, което променя начина, по който процесът се стартира в системата ви. Това преструктуриране ни позволи да се отървем от две зависимости, които използвахме за тази цел (съответно за Windows и Linux / macOS), и вече имаме един и същ код за всички платформи, тъй като процесът се стартира с помощта на основните Rust помощни програми. С тази промяна също успяхме да поправим проблема, който имахме под Windows, където authd регистрационните файлове не се генерираха на аналогично място, както се прави за Linux и macOS (~ / .safe / authd / logs / safe-authd.log), т.е. authd на Windows ще запише своите регистрационни файлове на C: \ Users \ \ .safe \ authd \ logs \ safe-authd.log в следващата версия.

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

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

И накрая, работата по safe files get напредва, което ще позволи изтеглянето на файлове и директории от SAFE Network FileContainer в локалната файлова система. Тази команда работи подобно на cp или scp в Linux / macOS или копиране в Windows. Кодът вече е завършен и се тества от екипа. Той трябва да бъде включен в следващата версия на SAFE CLI.

SAFE Network програма - UX

MVE проследяване на напредъка на функциите

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

Кликнете върху тях или ги изтеглете, за да ги разгледате в пълен размер:

Бюлетин с информация за достъпа до данни

272b655cc48765d302ff8348eb1875aa81c4d82c_2_439x500

Множество данни в една заявка за достъп

62512b55582e2f2d099094c0b338ace711e45149_2_690x384

Списъци за филтриране и сортиране

ed07934bb0261a6d67e113a8b31a80d6d44e6fb6_2_348x500

SAFE Network програма (десктоп)

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

Работата по SAFE Network програмата до голяма степен беше задържана тази седмица, тъй като @joshuef се гмурна в клиентските библиотеки, за да разгледа някои концептуални работи на CRDT. Това само по себе си включва малко преправяне на нашия код за управление на връзката, за да се даде възможност за по-лесно тестване на обработката на отговорите. След като направихме това, получихме прост набор от GSet тестове и можем да видим, че получаването / обединяването на някои различни CRDT типове данни не би трябвало да доведе до прекалено много проблеми за клиента. Още веднъж това е само бързо доказателство за концепцията, но изглежда обещаващо засега.

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

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

Удостоверител план, браузър план

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

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

SAFE App C#

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

Поправихме доста стар проблем в библиотеката safe_app_csharp. Проблемът водеше до срив на приложението при опит за декодиране на всеки отговор за удостоверяване от приложението за Удостоверителя (мобилния или CLI-то). Поради този проблем не беше възможно да се справяме с различни случаи на грешки. Актуализирахме и тестовете, за да гарантираме правилното функциониране на поправенето API на всички настолни и мобилни платформи.

Премахнахме тестовата настройка на AppVeyor от хранилището и за да опростим допълнително процеса, и използването на единна платформа за целия процес на CI / CD, преместваме кодовото отразяване и настройката за публикуване на API документацията в Azure DevOps.

Маршрутизиране и quic-p2p

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
2 Likes

SAFE Network новини - 16.4.2020

Накратко

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

  • Пуснахме нови версии на SAFE CLI (v0.12.0) и процеса на Удостоверителя (v0.0.8). CLI вече включва подкоманда files get и процесът на Удостоверителя вече не изисква администраторски разрешения под Windows.
  • Пуснахме нова алфа версия на SAFE Network програмата.
  • Пуснахме версия 0.5.0 на SAFE мобилния браузър, която включва необходимите промени за предоставяне на функцията за актуализиране вътре в приложението.
  • Наскоро създадохме общо ръководство за допринасяне към проекта, към което пускаме връзка във файла README.md във всяко хранилище.

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

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

Вече започнахме разработването на следващата фаза на Бейби Флеминг - Трезори Фаза 2б, многосекционна мрежа. Имаме няколко задачи, подредени в плана на проекта и първата заявка за обновление вече е подготвена! Този PR реализира поведението на нови Трезори, присъединяващи се към секцията като Възрастни, които по-късно се повишават към Старейшини, ако се налага. Следващата стъпка е да зададем на възрастните да държат парчета ImmutableData. Започнахме работа и по това. Очакват ни вълнуващи времена напред!

SAFE API

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

По-рано тази седмица пуснахме нови версии на SAFE CLI (v0.12.0) и процеса на Удостоверителя (v0.0.8), които носят няколко подобрения в програмния код, някои корекции на грешки, които наскоро бяха докладвани от общността при тестовете на Бейби Флеминг, както и някои нови функции като възможността за изтегляне на файлове от мрежата локално с въвеждането на подкомандата files get.

Едно важно подобрение, направено в тази нова версия на safe-authd, е, че тя не изисква администраторски разрешения за нейното стартиране в Windows, нито има нужда от инсталиране като Windows услуга, преди да може да бъде стартирана като процес. Сега safe-authd може да бъде стартиран с една команда safe auth start чрез CLI-то под Windows, точно както се прави и на другите платформи.

Както винаги, можете да актуализирате CLI-то си с командата safe update и safe-authd с командата safe auth update. Само една забележка за потребителите на Windows: преди да актуализирате и стартирате новата версия на safe-authd, моля, деинсталирайте първо Windows Service на старата версия на safe-authd, като използвате стария safe-cli (т.е. версия <= v0.11.0). Това може да се направи с администраторски разрешения под Windows и командата safe auth stop последвана от командата safe auth uninstall.

CRDT

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

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

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

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

SAFE Network програма (десктоп)

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

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

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

Удостоверител план, браузър план

Тази седмица работихме върху малка, но вълнуваща функция. Нашата цел беше да подобрим настройката на CI / CD и да интегрираме мобилните приложения с SDK-то на AppCenter за разпространение. Казано по-просто, нашата цел е, ако вече имате инсталирано SAFE мобилно приложение на вашето устройство с тези нови промени и се пусне нова версия на приложението, приложението ще ви подкани автоматично да го актуализирате до най-новата версия. Няма да се налага повече да го изтегляте ръчно от GitHub или AppCenter. Тази седмица успешно тествахме PoC за различни случаи на използване и така внедрихме тази нова функция в мобилния браузър.

Днес пуснахме версия 0.5.0 от мобилния браузър!

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

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

Следващите ни стъпки ще бъдат да обновим мобилния браузър от версия 0.5.0 до 0.5.1. Възнамеряваме да пуснем тази нова версия следващата седмица. Това ще даде на нас и на вас шанс да изпробваме тази функция за автоматично актуализиране на различни устройства. Все още има някои пояснения, които трябва да направим около това как работят по-специално актуализациите под iOS: вярваме, че потребителите на iOS може да се наложи да влязат в AppCenter, за да работи автоматичното актуализиране. Колко удобно ще бъде това в сравнение с текущия процес е нещо, което ще оценим с ваша помощ. Ако всичко върви добре, тогава ще добавим тази функция към мобилното приложение за удостоверяване.

Маршрутизиране и quic-p2p

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

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

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

Като първата голяма стъпка към постигането на работещ DKG контейнер, тази седмица PoC PR беше обединен. Този PR включва някои тестове, които също служат като примери за използване. PR-и с допълнителни тестови сценарии са в процес на разработване тук и тук, проектирани са да гарантират, че контейнера работи както се очаква. Работим и върху някои API актуализации, за да позволим на други контейнери лесно да използват DKG. Успоредно с тях, проучваме използването на инструмент за симулация на Маршрутизирането, подобен на този тук, който използвахме преди. Целта ни с това е да се провери използваемостта на контейнера DKG в рамките на секцията, т.е. да се променя редовно членството.

Софтуерно тестване

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/

SAFE Network новини - 23.4.2020

Накратко

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

  • Пуснахме нов стабилен NuGet пакет от SAFE C# API.
  • Добавихме нова малка функция в мобилния браузър, която позволява на потребителите да преглеждат файловете от FilesContainer. Това ще бъде достъпно от следващата версия.
  • Работихме по адаптирането на dog командата, за да покажем всяка стъпка във веригата за повече подробности.

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

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

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

SAFE API

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

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

Някои други незначителни допълнения се правят в API-тата за анализиране на SAFE-URL адреси, като например разбор и възможност за манипулиране на параметрите на заявките и / или фрагмента. Те не се използват от никоя от функциите, които в момента излагаме в CLI-то, но това е нещо, което ще бъде полезно за разработчиците на приложения при работа с SAFE-URL адреси.

CRDT

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

Напредваме и с AT2 внедряването на safecoin, което включва голямо преструктуриране на SAFE Клиентските библиотеки, за да раздели нещата и да улесни разбирането. С приключването на това ще имаме преобразуване до основната настройка за AT2 (без никакво потвърждение и т.н. … т.е. основно преобразуване на това, което бяхме подготвили за следващата стъпка). Това работи добре и ни поставя в добро положение.

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

Освен всичко това започнахме и някои модернизации на внедряването на фючърсите на SCL Rust, за да направим различните аспекти по-прости. Това само по себе си е доста голяма задача. Но досега я отлагахме, така че е добре да я започнем.

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

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

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

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

Добавихме нова малка функция в мобилния браузър, която позволява на потребителите да преглеждат файловете от FilesContainer. Използвайки това, потребителите вече могат да разглеждат всеки FilesContainer, чрез неговия XOR-URL / NRS-URL адрес и могат да преглеждат файловете от списък.

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

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

SAFE App C#

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

Тази седмица пуснахме нов стабилен NuGet пакет. Обновеният пакет съдържа корекцията за декодиране на удостоверяващото API. Също така актуализирахме API-тата за XorUrlEncoder, за да поддържаме под-имена. Преди това в API-тата на C# не беше възможно да се генерира XOR-URL с под имена; с последните промени сега можете да предоставите под имена, за да генерирате нов XOR-URL адрес. Също така актуализирахме API-тата за XorUrlEncoder, за да използваме C# списък от низове, вместо да използваме JSON низове при генериране на XorUrlEncoder от XOR-URL.

Маршрутизиране и quic-p2p

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 30.4.2020

Накратко

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

  • Днес пуснахме версия 0.5.1 на мобилния браузър и версия 0.3.1 на мобилния Удостоверител
  • Първоначалното изпълнение на Трезори Фаза 2б Възрастни и тяхното поведение по време на обработка на заявки за непроменими данни (Immutable Data) е завършено.
  • Завършихме първия тип данни PoC Sequence, реализирани като CRDT и можем да започнем да ги интегрираме в стека на библиотеките.
  • Вече имаме тестова версия на AT2, която работи добре с CLI-то.
  • В момента се преглежда PR за добавяне на UPnP към quic-p2p - това приближава свързването на трезорите от вкъщи в една секция.
  • @jimcollinson започна да работи върху усъвършенстването на кандидатските дизайни, които споделихме преди време (вижте секцията SAFE Network App UX).

Накратко отбелязваме, че Никита приключи договора си с MaidSafe тази седмица, като последният му принос беше представянето на този PRnP PR в quic-p2p (обсъдено по-подробно в секцията quic-p2p по-долу). Никита работи за MaidSafe в продължение на 4 години и съм сигурен, че ще се съгласите, че имаше огромен принос за нашия проект през това време. Миналата година Никита премина на непълно работно време, за да може да отдели време за собствените си проекти и сега настъпи момента да им се отдаде напълно. Знаем, че той няма да иска да бъде споменат по този начин, но моля, присъединете се към нас, като благодарим на @nbaksalyar за приноса му през годините и му пожелаем големи успехи в бъдеще.

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

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

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

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

SAFE API

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

Извършва се преструктуриране в safe-api хранилището, по-специално в API-то на XorUrlEncoder, който се използва за управление на SAFE-URL адреси. Към него добавяме още няколко функции, така че да може да се използва от всеки разработчик за справяне със SAFE-URL адреси, т.е. както NRS-URL, така и XOR-URL адреси, за да анализира, манипулира и също така да генерира съответните XOR-URL адреси, ако е необходимо. Това не засяга нито една от функционалностите, изложени от CLI-то, а само това специфично API.

CRDT

Както споменахме през последните няколко седмици се опитвахме да получим първи тип данни PoC Sequence, реализиран като CRDT и сега изглежда имаме нещо функционално и достатъчно добро, за да започнем да го интегрираме в библиотечния стек. Ето защо започнахме да работим върху изпълненията, необходими за разкриване на такъв тип последователност от данни в нашите основни библиотеки, като се започне от safe-nd и safe-treult. Планираме да добавим поддръжка за този нов тип данни в пълния стек, без да премахваме или променяме някой от текущите типове данни или поддържани операции, но вместо това първо да го добавим като допълнителен тип данни, който можем да използваме, за да започнем валидиране и тестване на e2e в мрежова среда с една секция.

След като този нов тип данни бъде напълно интегриран и утвърден, ще започнем да мигрираме всички наши клиентски API-та, които използват AppendOnlyData, за да започнат да използват Sequence типа данни. Например в момента FilesContainers и NRS Containers се съхраняват като AppendOnlyData и те ще бъдат мигрирани, за да се използва Sequence тип данни. Това няма да повлияе на излагането на API-то, нито на CLI командите, а само на това как се съхранява това съдържание в мрежата.

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

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

SAFE Network програма - UX

MVE проследяване на напредъка на функциите

Ако сте преглеждали MVE проследяването на напредъка на функциите на SAFE Network програмата, ще забележите доста отметната работа в реда Жизненоважни функции. Това разбира се е добра новина, но също така означава, че трябва да започнем да дърпаме това кученце заедно.

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

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

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

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

  1. Дизайните трябва да дават предимство на използваемостта и функционалността преди всичко друго.
  2. Те трябва да работят добре на различните платформи, използвайки основни елементи на операционните системи, когато става дума за основна използваемост.
  3. Те също трябва да имат познато SAFE усещане, да използват съществуващите активи на марката, да имат достатъчно уникалност за да ориентират потребителите, но не за сметка на 1 и 2.
  4. Трябва да се помисли за адаптиране към многоезичните опции, когато дойде времето.
  5. Разходите за поддръжка трябва да бъдат ниски.
  6. Итеративни, постепенни подобрения, а не големи отскоци.

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

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

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

Функции в Rust

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

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

Браузър план на проекта

Удостоверител план на проекта

Днес пуснахме версия 0.5.1 на мобилния браузър и версия 0.3.1 на мобилния Удостоверител

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

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

Ако в момента имате версия на браузър по-стара от 0.5.0 или все още нямате браузъра на устройството си, можете да изтеглите последната версия, като използвате връзките за изтегляне / QR код-а от файла README.

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

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

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

Можете да изтеглите най-новата версия, като използвате връзките за изтегляне / QR код-а от файла README.

Маршрутизиране и quic-p2p

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/

SAFE Network новини - 7.5.2020

Накратко

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

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

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

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

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

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

SAFE API

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

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

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

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

SAFE Програма C#

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

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

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

CRDT

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

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

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

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

Функции в Rust

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

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/

SAFE Network новини - 14.5.2020

Накратко

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

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

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

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

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

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

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

SAFE API

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

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

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

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

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

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

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

SAFE Програма C#

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

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

CRDT

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

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

Функции в Rust

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

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

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 21.5.2020

Накратко

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

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

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

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

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

SAFE API

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

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

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

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

SAFE Програма C#

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

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

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

SAFE Network програма UX

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

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

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

03f69af4c819fb6edf7c0f52961b872cb03ee001_2_318x500

77be89fc8a9c30f8c48ff3e9107c3d5ed78a7073_2_203x499

88d55c91dbec3e97e80b9562a09dc334c2815130_2_318x500

c820081306f58744dacb22f2251bb6062062565f_2_318x500

CRDT

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

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

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

Трансфери

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

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

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

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

Следва

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

Връзки

Функции в Rust

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

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

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

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

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

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/

SAFE Network новини - 28.5.2020

Накратко

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

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

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

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

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

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

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

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

SAFE API

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

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

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

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

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

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

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

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

Под капака

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

Поправки

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

CRDT

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

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

Трансфери

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

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

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

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

Функции в Rust

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 4.6.2020

Накратко

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

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

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

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

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

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

SAFE API

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

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

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

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

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

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

CRDT

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

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

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

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

Трансфери

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

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

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

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

Функции в Rust

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

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

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

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

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

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

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

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

SAFE API

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

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

CRDT

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

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

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

Трансфери

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 18.6.2020

Накратко

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

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

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

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

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

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

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

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

SAFE API

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

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

CRDT

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

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

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

Трансфери

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

Накратко

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

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

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

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

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

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

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

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

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

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

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

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

SAFE API

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

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

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

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

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

CRDT

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

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

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

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

Трансфери

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

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

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

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/

SAFE Network новини - 2.7.2020

Накратко

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

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

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

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

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

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

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

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

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

SAFE API

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

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

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

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

SAFE App C#

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

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

CRDT

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

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

Трансфери

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

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

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

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

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

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

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

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

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/

SAFE Network новини - 9.7.2020

Накратко

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

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

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

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

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

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

SAFE API

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

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

SAFE App C#

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

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

CRDT

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

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

Transfers

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

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

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

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

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

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

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

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

xor-name

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

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

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

  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 16.7.2020

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

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

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

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

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

SAFE API

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

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

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

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

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

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

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

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

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

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

SAFE App C#

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

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

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

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

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

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

CRDT

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

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

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

Трансфери

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

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

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

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

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

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

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

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


  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/
1 Like

SAFE Network новини - 23.7.2020

Накратко

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

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

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

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

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

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

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

SAFE Network Програма UX

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

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

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

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

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

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

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

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

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

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

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

SAFE API

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

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

SAFE App C#

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

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

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

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

CRDT

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

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

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

Трансфери

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

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

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

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

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

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

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

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


  • Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: https://www.facebook.com/groups/SafeNetworkBulgaria/
  • Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: https://www.facebook.com/SafeNetworkBulgaria/