Накратко
Ето някои от основните неща тази седмица:
- Завършихме работата по подобряване на Трезорите и пускахме вътрешни тестови мрежи - резултатите изглеждат добре досега!
- Продължаваме по всички фронтове с прехвърлянето на тестове ни от работа с тестова мрежа към работа с реалната мрежа.
- Интегрираме допълнително преструктуриране на мрежовите заявки, което ще отвори вратата към фермерството в мрежата.
- PR-а с DKG заместника в маршрутизирането е добавен.
Трезори – Фаза 2
Тази седмица завършихме с прилагането на подобренията въз основа на обратната връзка, получена от предишния тестнет. Тествахме тези промени във вътрешни тестови мрежи и виждаме много добри резултати. След само още малко тестване ще бъдем готови да обявим поредната версия на тестовете от вкъщи, за да ви покажем всички подобрения, над които работихме. 
Работим и върху това да прехвърлим тестовия ни пакет към реалното маршрутизиране. С него тестовете отнемат много повече време, но това е така, защото в момента създаваме отделна мрежа за всеки тест. Работим по още няколко преструктурирания, които ще използват една и съща мрежа за всички тестове и това ще ускори значително нещата.
SAFE API
Тази седмица беше повдигната заявка за изтегляне за поддръжката на glob(), но понеже сме загрижени за ефективността й и заради необходимостта от допълнителни промени в подкомандите за files ls може да не успеем със сливането й, докато не извършим по-нататъшна работа. Този PR ще премине през обичайния процес на тестване/преглед и ще разгледаме най-добрия начин за действие.
SAFE App C#
Тази седмица възобновихме малко изостанала молба за изтегляне, която се фокусира върху преструкторирането и подобренията на API-то за удостоверяване. С този PR се отдалечаваме от safe-client-libs / safe-authentator-ffi и излагаме API-тата на Удостоверителя от safe-api контейнера. Това ще опрости допълнително API-тата за приложения и удостоверяване и ще улесни поддържането на API-тата в синхрон със safe-cli, safe-api и safe-nodejs.
CRDT
Тази седмица започнахме да правим проучвания как правилно да управляваме разрешенията в CRDT типовете данни, като новия тип данни Sequence. Наличието на разрешения за CRDT данните създава някои предизвикателства, тъй като всички промени в правилата за достъп трябва да се прилагат по един и същи начин във всички реплики (т.е. Старейшини), така че да запазваме сходството на данните. Например, отнемането на разрешения от потребителя за добавяне на елементи към Sequence може да доведе до появата на някои реплики, позволяващи на потребителя да добавя елементи, ако такива действия са били позволени преди заявката за отмяна, т.е. да има реплики, които не са обновили до същото състояние на данните.
Разглеждаме някои налични документи, в които са показани различни решения, за да разберем по-добре не само решенията, но и самия проблем. За тези, които се интересуват да прочетат повече за проблема, този документ може да бъде от полза, поне само за да разберат предизвикателството.
Transfers
SAFE Трансфери План на проекта
SAFE Клиентски библиотеки План на проекта
SAFE Трезор План на проекта
След финализирането на safe_core тестовете срещу AT2 системата, работихме върху интегрирането на допълнително преструкториране в мрежовите заявки, за да отворим вратата към фермерството в мрежата. С приближаването ни до тест мрежа с много секции с AT2 и фермерство, трезорите и секциите в мрежата трябва да обменят съобщения помежду си, за да има поток от данни/плащания. Това поражда нуждата да правим разлика между клиентски съобщения и вътрешно мрежови съобщения. Затова започнахме основно преструкториране на структурата за съобщения, която мрежата ще използва. Накратко това ще приведе в съответствие съобщенията с принципите на CRDT и системите, управлявани от събития.
Това от своя страна доведе до по-нататъшна работа по интеграцията с SAFE Клиентските библиотеки, но тук нещата напредват добре, дори когато откриваме грешки и проблеми с производителността и прецизираме потока на съобщенията. Друга по-съществена промяна в SAFE Клиентските библиотеки е премахването на отговорите от типа „ack“ (които по същество не ни казват нищо) плюс оставяме на клиента да потвърди по избор дали операцията е приключила. (В крайна сметка това би трябвало да доведе до някои опити/проверки/повторни потоци за определени операции, но няма да е необходимо да се прави това. Което трябва да даде на разработчиците на приложения по-голяма гъвкавост в начина им на действие, и от своя страна да се надяваме ще направи Трезора по-отзивчив).
Маршрутизиране
Тази седмица най-накрая обединихме PR-а за заместителя на DKG . Това ни позволява да актуализираме секционните ключове, без да използваме parsec.
За да подобрим качеството на кода, също така добавихме статистически данни за покритие на кода в контейнера и наложихме правилото, че всеки по-нататъшен PR не трябва да намалява процента на покритие. Както споменахме по-рано, постепенно се отдалечаваме от тестване с примерно маршрутизиране във всичките ни хранилища. Това неизбежно означава, че статистическите данни за покритие на кода спрямо производствения код ще започнат ниско, тъй като това никога досега не е било в нашия фокус, но постепенно ще го изграждаме с течение на времето.
Сегашният ни основен фокус е върху задачите за премахване на използването на parsec. Една такава задача, която в момента преминава през процеса на преглед на PR, е гарантирането, че промените към SharedState са одобрени от секцията. Също така започнахме да работим по основен ремонт на повишението на рейтинга на Трезорите, така че да не включва parsec толкова много. Това е предпоставка за друга основна задача, която е да се осъществи гласуване на базата на съобщения - с това ще заменим текущото гласуване, базирано на parsec, което разбира се ни даде консенсус и силен ред, с много по-опростен механизъм, който ни дава консенсус без ред, което според нас е достатъчно.
xor-name
След като пуснахме първата стабилна версия на xor-name контейнера ни миналата седмица, продължихме да надграждаме върху нея и тази седмица, като преструкторирахме множество контейнери, за да започнем да използваме новия xor-name контейнер.
В настоящия момент разполагаме с допълнителни видове XorName и свързаните с тях функционалности, изложени от safe-nd , safe-client-libs и safe-api. За да опростим кода в тези хранилища, сме в процес на премахване на XorName от всяко едно от тях, използвайки вместо това новия специализиран xor-name контейнер. PR-и с черновите, които правят тази замяна във всяко от тези хранилища могат да бъдат прегледани тук, тук и тук съответно.
Сега чакаме да бъде публикувана външна версия на контейнера, която ще ни позволи да продължим с това. След като това е налице, ще продължим работата по преструктурирането на safe-vault и други хранилища.
- Официален сайт на SAFE Network
- Обобщено представяне на SAFE Network
- SAFE Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: SAFE Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската SAFE общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на SAFE Network България: Safe Network България