Днес пости постигнахме мини-важно-събитие (на 90% от пътя сме!) с обединяването на API-то и CLI-то в основното хранилище на Safe мрежата, което означава, че няма да има повече несъответствия на версиите. До какво ще доведе това и защо има значение? @ChrisO обяснява всичко по-долу.
Общ напредък
Както вероятно вече знаете, с функции като AE мрежата е проектирана да бъде „CRDT-подобна“ с гарантирана евентуална последователност. Това означава, че ако изпратим съобщение или парче данни и те не се получат веднага, това няма значение, защото просто чакаме или го изпращаме отново. Не се изисква сложно синхронизиране.
Голяма част от работата, която вършим в момента, е да накараме това поведение, подобно на CRDT, да работи правилно. Цикличното поведение, което видяхме при предаване на съобщения от възел до възел, изглежда вече е коригирано.
AE съобщенията казват на клиента дали трябва да актуализира разбирането си за секциите, с които говори. Добавихме няколко подобрения към клиента, така че той предварително да се свърже с всички начални възли, за да получи актуализиран изглед на мрежата, преди да му позволим да продължи, за да задейства всякакви команди. Също така добавихме малко изчакване за пускането на данни в мрежата, тъй като преди командата се връщаше веднага, докато обработката на AE съобщения се случва във фонов режим. Това не е проблем с тестовете на „safe_network“ библиотеката, тъй като всички те държат клиента наоколо, но CLI-то не прави това, така че може да имаме проблеми, при които клиентът не е знаел за част от мрежата, и е пропуснал обработката/повторното изпращане на командата, когато тези AE-съобщения дойдат.
Виждаме и някои аномалии при тестовете на CI (непрекъсната интеграция). Трудно е да се каже дали проблемът е в мрежата или в самите CI тестове. Това е нещо, което тестовите мрежи ни помагат да разберем. Благодарим отново на всички, които се включиха. Трябва да има нова тестова мрежа, който да се тества скоро, тъй като обединяваме API+CLI. Обмисляме и опции за облачен ELK клъстер, за да съхранява логовете нот тестовете на общността и да ги прави достъпни за търсене.
@Jimcollinson продължава да проучва n от m потоци за удостоверяване, използвайки BLS ключови споделяния. За да отключите Сейфа си, можете да изберете да използвате комбинация от парола + фраза (или QR код) с ключ на устройство на телефона си като резерв (2 от 3). Ако забравите паролата си, можете да използвате фразата и ключа на устройството. С основните си идентификационни данни (парола и фраза) можете също да създавате нови ключове на допълнителни устройства, така че ако наистина забравяте лесно, можете да отключите Сейфа си с помощта на множество устройства или резервни пароли. Идеята тук е постигане на гъвкавост за приспособяване на различни модели заплахи за сигурността - балансирани с удобство - и все пак да бъдем толерантни към загуба на идентификационни данни.
На фронта на DBC @danda се задълбочава в деноминациите. Очаквайте повече подробности надолу.
Единично хранилище
През юни извършихме известна работа за обединяването на няколко от хранилищата, които съставляват кода за мрежата, в единно голямо хранилище. Поради това, че кодът в тези хранилища е толкова тясно свързан, нямаше смисъл те да се развиват независимо и всъщност това беше активно проблематично за тях. Това направи трудно отстраняването на грешки и тестването на мрежата, а поддържането на всички версии актуални и синхронизирани беше значителна задача само по себе си. Единното хранилище комбинира целия този код в различни модули от един и същ контейнер, с един номер на версията.
В това начинание обаче няколко хранилища останаха назад, а именно sn_api и sn_cli. API-то и CLI-то всъщност са малко по-различни от споменатите по-рано хранилища, тъй като не са основни компоненти на самата мрежа, а по-скоро целта им е да ни позволят да използваме мрежата. Поради ограничените ресурси, фокусирани главно върху развитието на мрежата, кодът както на API-то, така и на CLI-то беше остарял и изискваше значителна работа за обновяването им. Така че, въпреки че искахме да обединим и тях, всъщност не бяхме в състояние да го направим.
Работихме, за да актуализираме CLI-то и API-то, така че за щастие сега сме в позиция, в която те могат да бъдат обединени, и сме щастливи да кажем, че това е почти готово. sn_api и sn_cli ще бъдат включени заедно с кода за мрежата, така че хранилището safe_network се състои от три контейнера, които ще бъдат актуализирани и внедрени едновременно.
Важно е да знаете, че това всъщност е значителна промяна, а не просто административно удобство. Някои от предимствата:
- Всичко в едно и също хранилище премахва объркването кои версии на CLI-то и API-то са съвместими с различните версия на мрежата. Всички те ще бъдат съвместими във всяко издание.
- Когато кодът за мрежата се актуализира с големи промени, разработчиците ще бъдат принудени да направят актуализация на API-то и CLI-то. Това предотвратява повторното застояването на API и CLI кода.
- Новите версии на мрежата са незабавно достъпни за тестване с CLI-то, което е съвместимо с мрежата.
Относно последната точка: сега, когато видяхме и приветствахме пускането на тестови мрежи от общността, заедно с едновременното пускане на комбинацията от CLI/API/мрежа, можем да създадем много по-кратък цикъл на тестване и издаване, където по същество всяко ново издание в хранилището safe_network е незабавно достъпно за тестване от общността. В крайна сметка това има голям потенциал да ни помогне да вървим по-бързо към кандидат за стартиране.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България