SAFE Network новини - 4.6.2020

Новини
1

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 се счита за завършен и се работи за интегрирането му в маршрутизацията.

3ed75c5622f4b8257cf4809cd04596dc7c924f65
3ed75c5622f4b8257cf4809cd04596dc7c924f65830×430 93.6 KB

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