Знаем, че всички се надявате да получите тестова мрежа отново, но има една или две корекции, които първо трябва да направим, за да сме сигурни, че тестът ще ни осигури ценни данни. Една от тях в частност е да накараме стареенето на възел да работи надеждно. @joshuef обяснява повече за препятствията и как се подготвяме да ги прескочим, докато се насочваме към по-зелени пасища.
Общ напредък
Както винаги се случват много неща, включително някои дълбоки гмуркания в основите на мрежата. Както някои от вас знаят, нашата мрежова библиотека qp2p е базирана на Quinn, Rust внедряване на индустриалния стандарт QUIC, разработен от Google.
Хубавото на приемането на широко използвани компоненти е, че има много очи върху тях и непрекъснато се актуализират, но недостатък е, че не винаги работят точно както искаме. В този случай TLS библиотеката разчита на DNS и това изисква сертифициращ орган (CA), като и двата в стандартната си форма са неприложими за p2p мрежа. Но… Дейвид има хитър план да използва нашия групов консенсус като начин да станем наш собствен CA, което трябва да ни позволи да осигурим трафик и да подпишем с нашите ключове ed25519, поне когато актуализирана версия на rustls излезе, което трябва да стане скоро. В крайна сметка искаме да сведем до минимум използването на qp2p и това ще бъде стъпка в тази посока.
@bzee също се задълбочи в qp2p и добави съкратена версия към stableset_net хранилището, за да подобри ефективността на съобщенията. @davidrusu също работи върху стабилния набор, включително получаване на инструмента Stateright за разтоварване на работната му опашка върху диска, за да ни позволи да тестваме по-сложни модели.
На DBC фронта, @oetyng постигна добър напредък с актуализирането на sn_dbc контейнера, както и с изясняване на езика, който използваме, за да опишем заслепяването (скриване на сумата на транзакцията) и разкриването, за да се улесни проследяването. Сега той работи върху актуализирането на командния поток между клиенти и Старейшини при транзакция с DBC.
@bochaco работи върху разкриване на gRPC към safe_node и добавяне на стъпка в нашия инструмент за тестови мрежи за проверка на стартирани кодове с помощта на такава услуга.
Roland работи усилено по телеметрията, подобрявайки нашата видимост на ниво възел и функция. Следите ни позволяват да видим какво се случва с всяка функция, но в сурова форма те са трудни за четене, така че Роланд ги извлича в OpenSearch, където могат да бъдат обобщени по възел и време, за да ни дадат много подробна картина на това, което се случва и къде се случва.
И след като правните неща са подготвени, @JimCollinson насочва вниманието си към брандирането. Какви трябва да бъдат нашите основни послания и как трябва да ги представим? Има какво да научим от други, които са го направили както трябва, така че ако има компании или лица, които намирате за особено вдъхновяващи, уведомете ни в тази тема.
Напредък към Старееща мрежа
Има няколко неща, които бихме искали да станат по-стабилни за всяка нова тестова мрежа. Основният проблем, който видяхме в последната тестова мрежа, беше, че нашият код за преместване и следователно възрастта на възела не работеха според очакванията.
Основната причина за това беше, че просто нямахме достатъчно отлив на възли преди отварянето на мрежата. Но това отвори въпроса как надеждно да се постигне това и преместването в бъдеще.
Една проста промяна е намаляването на началната възраст на възела, това води до по-бързо преместване… но това само по себе си също идва с различни разходи и компромиси - особено докато не разполагаме с многослойно съхранение на данни. Но също така срещнахме някои други проблеми там.
Видяхме, че предишният ни подход “в две стъпки” към членството ни създаваше проблеми (имаме „Членство“, където се гласува, а също и „SectionPeers“, което трябваше да бъде актуално за промени в членството и се основава на нашите SectionAuthorityProvider (SAP), но тези двете могат да излязат от синхрон). Затова е страхотно, че PR на @qi_ma е добавен, което би трябвало да намали такива разногласия.
Също така се сблъскахме с проблем при решенията за гласуване за членство, които стават невероятно големи и причиняват твърде много трафик, увеличавайки времето за проверка неимоверно. Това беше преработено обратно до разумни нива и също така ни показа някои блокирания, които имахме.
Това блокиране на процеса също е премахнато, така че сега нещата работят много по-гладко около гласуването за членство и DKG.
Сега отново разглеждаме скоростта на преместване и се опитваме да гарантираме, че не виждаме никакви блокиращи цикли, докато възлите се движат из мрежата. След като това е налице, ще бъдем на много по-добро място за справяне с разделянето и съхраняването на данни.
Това само по себе си е страхотно постижение, но няма да спрем дотук. Работата по отделен POC за стабилния комплект е започната, както някои хора тук отбелязаха! Това има за цел да бъде най-простият възел (и може да бъде много по-опростен, ако можем да избегнем голяма част от поддръжката на мрежовите знания и DKG, които идват от нашия „основен“ клон). Все още е рано, но искаме да внедрим тази проста реализация и да я тестваме усилено, за да видим как изглеждат нещата.
И двата пътя са доста вълнуващи и се надяваме, че в близко бъдеще ще доведат до още една, по-“старееща” тестова мрежа!
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България