Навършваме 18 години днес…
Това е крайъгълен камък. Но той бележи началото на нещо много по-голямо от комбинираните усилия през всичките тези години.
Имаме нещо доста специално на път.
Нещата стават много реални и както намеква @JimCollinson, задава се вихрушка след няколко седмици. Така че не забравяйте да се присъедините към нас за това много важно събитие на живо следващата седмица.
Новини за разработката
Въпреки че предизвикахме съдбата, ValentinesNet все още е силен, така че ако всичко е наред, ще го поддържаме, докато не ни свърши мястото или не пуснем нов възел с критична промяна. Продължаваме с актуализациите в движение, като локалните тестове преминават доста добре и се надяваме да ги изпробваме в текущата тестова мрежа. По принцип това, което ще се случи, е, че идентификаторите на възлите и данните ще бъдат безпроблемно запазени дори когато софтуерът sn_node се актуализира.
Научихме някои полезни уроци от текущата тестова мрежа, така че, както винаги, благодарим на всички вас, тестващите. Един от проблемите беше с репликацията, където непрекъснато трупаме чакащи съобщения от възли, които всъщност не могат да бъдат получени, което означава, че данните всъщност никога не се записват или извличат. Така че работим върху това. Също се задълбочаваме в толерантността към грешки, където възлите се държат неправилно, но не се изтриват от таблиците за маршрутизиране на партньорите, както би трябвало да бъде. Така че започнахме да разглеждаме откриването и поставянето в черен списък на неправилно работещи възли.
Благодарим за новите и продължаващи теми във форума. @happybeing, @danda и други работят върху идеи за API на файлова система FUSE , @josh тестваше sn_manager, което вече ни помогна да изгладим няколко UX бучки и имахме още добри дискусии в нишката за регистри. Марк също намери полезна публикация за ускоряване на времето за изграждане на Rust, и тъй като го забравихме последно седмица ( 
) тук се споменава неговият PR за разкриване на MerkleReg и добавяне на register_inspect, който сега е обединен. Всичко това са страхотни неща, момчета, и въпреки че не можем да се включваме през цялото време, наистина са полезни.
Що се отнася до регистрите, искаме да запазим нещата опростени засега, като регистрите съдържат указатели към парчета и да видим докъде можем да стигнем с това. От една страна, това прави прост модел с заплащане-веднъж-редактиране-безплатно-до-пълния му модел. Все още не сме използвали много регистри освен прости папки и искаме да тестваме този подход, за да проверим неговите ограничения и доколко може да се активира чрез API. След това, ако не се получи за нас или за разработчиците на приложения, ще го преразгледаме.
В DAG одит-та sn_auditor @anselme разполага с основно доказателство за концепцията, работещо сега, така че можем да проследяваме анонимизирани разходи, CashNotes и входове и изходи на транзакции чак до Genesis и да показваме заявки като JSON. Тъй като тази графика ще стане доста голяма и запитването й ще бъде доста тежко, предвиждаме специални DAG възли, които да ги държат, като операторите може би предлагат достъп до API на всеки, който иска да ги запитва срещу заплащане. Ето SVG визуализация на няколко разходи в проста мрежа.
Общ напредък
Освен че стартира DAG POC, @anselme работи върху сериализация и десериализация, така че да можем да поддържаме множество методи за сериализация като цяло. Той също така се зарови в грешки, наблюдавани в CI, свързани с проверката за осребрени „CashNotes“ вече изразходвани. feat: custom serde for unique keys by grumbach · Pull Request #1329 · maidsafe/safe_network · GitHub и подобрена производителност при обхождане на DAG с по-добро паралелизиране.
@bzee успешно стартира доказателството за концепцията на WASM в браузъра и се свързва с възли 
, след много отстраняване на проблеми с компилация и конфигурация. Това далеч не е просто, тъй като всичко е доста грубо около ръбовете, но поне сега знаем къде се крият някои проблеми.
При изданията @roland е добавил механизъм за повторен опит за неуспешни изтегляния на версия. Roland също така работи върху по-доброто интегриране на демона на мениджъра и кода за преработване, за да контролира процесите и услугите на възлите по по-унифициран начин.
Също така при изданията, @chriso се справи с някои задачи за управление на изданията, свързани с надграждането на мрежата, и коригира проблем в CI чрез качване на двоични файлове на изданията в S3 по-рано в процеса на публикуване. Това предотвратява грешки при тестване на надстройки. Той продължи да добавя към функционалността node_manager с подкоманда faucet, която ще позволи операции за управление на тестова мрежа като добавяне, стартиране, спиране и надграждане на крана.
@joshuef също е задълбочен в изданията, като подобрява работния поток на изданията и работи по проблеми като настройки на клонове по подразбиране и поведение на сливане между git канали. Целта е плавен поток за развитие на „алфа“ канала, като същевременно поддържате „основния“ стабилен. Той също така е помислил за контрола върху цените и как те могат да бъдат поставени в ръцете на операторите на възли, както в тази дискусия във форума.
@dirvine води дискусии относно идеи за подобрения като прекратяване на възли, когато дискът се запълни и премахване на неотговарящи възли от таблици за маршрутизиране по време на репликация, както беше споменато по-горе. Това ще помогне да се избегнат неприятности като възли, които се появяват онлайн, но всъщност не функционират правилно от гледна точка на клиента.
@bochaco обедини PR за преместване на метаданни от записи в папки в отделни части, като положи основите за функции като проследяване на локални промени и синхронизиране. След това той започна друг PR за внедряване на проследяване на локални промени за папки. Това ще формира основата на възможностите за синхронизиране.
@jason_paul започна да проучва рефакторинг на file.rs в по-модулни поддиректории по функция, включително първоначален пример за правене на кода по-логичен и поддържаем.
Междувременно @qi_ma се фокусира върху анализирането на регистрационни файлове на възли, където възлите са надхвърлили ограниченията за запис. Той промени параметрите за ограничение и съкращаване, за да повиши ограниченията и да предотврати повторното извличане на съкратени записи по време на репликация. Това трябва да помогне за облекчаване на някои от проблемите със съхранението, които виждаме.
И в допълнение към другите новини @jimcollinson’s започна да проучва потенциални подходи за измерване на фактори за ефективност на плащанията като транзакции в секунда, време за потвърждение и време до окончателност. Това ще позволи количествено сравнение с други проекти.
О, и ние също бихме искали да приветстваме нов член на екипа (ако вече не сте се сблъскали с нея). @Rachel (известна още като Atomic654) ще бъде нашият специализиран мениджър на общността, който ще помага във всички по-широки социални мрежи. Посрещнете я сърдечно!
Източници:
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България