Нищо важно за докладване тази седмица на технологичния фронт, така че ето общ доклад за напредъка, без обичайното дълбоко гмуркане. Има какво да съобщим обаче за екипа ни и с радост приветстваме нов член. Мостафа е опитен блокчейн разработчик, който идва от Малайзия.
Добре дошъл в отбора, Мостафа!
“Здрасти, тук е Мостафа. Аз съм софтуерен инженер. Приятно ми е да се запознаем.”
Веднъж, когато бях студент, реших да посетя древен храм на огъня (сграда на повече от 2000 години), който се намираше на диво място. Намирането на храма на огъня беше трудно, затова помолих някои местни хора да ми помогнат. Интересното е, че те го нарекоха „Дяволската къща“ и когато ги попитах защо те казаха, „тъй като хората не могат да построят такова нещо, трябва да е дяволът“. Това си спомних наскоро, когато прочетох историята за дяволските мостове в Европа. Мостовете, които са построени преди векове и все още функционират. Хората ги наричат дяволски мостове, защото не могат да повярват, че човек ги е построил, трябва да е дяволът.
Никой не знае кой е построил моста на дявола или храма на огъня, но те все още стоят. Нека изградим дяволска мрежа!
Общ напредък
Работата по SectionTree вече е завършена 
Напомняне от @roland защо внедрихме отново някои части от SectionTree…
SectionTree(по-раноNetworkPrefixMap) е структура от данни, която капсулира текущите ни познания за мрежата. Може да се разглежда като дърво, където всеки възел е „SectionKey“, подписан от своя „SectionKey“ родител, с изключение на първия възел („genesis_key“). Листата на дървото също държат SAP на секцията, докато изхвърлят SAP на нелистата.Тъй като всеки
Клиент/Възелможе да има различен мрежов изглед,SectionTreeможе да варира значително между участниците. Освен това е необходимо да изпратите части от дървото („SectionTreeUpdate“, което обединява доказателствената верига + SAP) до всеки, който го поиска, и да сте сигурни, че няма да обърка дървото си, докато се опитва да го актуализира.
SecuredLinkedListбеше използван преди това за конструиране наSectionTree, но имаше няколко проблема, които доведоха до неправилни вмъквания, и не беше съвместим с CRDT. Следователно той беше повторно внедрен като CRDT (по-специално „MerkleRegister“), а старият „SecuredLinkedList“ беше заменен с новия „SectionsDAG“. Сега можем да сме сигурни, че се държи според очакванията, независимо от реда или продължителността на актуализацията!
@roland вече премина към тестване за генериране на разпределен ключ (DKG) с @anselme. Както беше обяснено през последните няколко седмици, имаше проблеми с процеса на DKG, който не винаги се прекратява. След известно интензивно тестване сега това изглежда доста стабилно и @anselme пише малко документация за тестовия процес.
Бележка от Anselme относно предстоящия DKG…
Предстоящият DKG, по-издръжлив и без таймери
DKG процесът в момента е активен процес, използващ таймери, които в случаи на тежка мрежова активност често ще се провалят поради изчакване. Наскоро работихме върху нов DKG, който не използва таймери, а вместо това позволява забавяне на съобщенията, както и поддържа изпращане на големи пакети. Когато възлите не получават съобщения известно време, те “клюкарстват” знанията си на другите с надеждата да ги накарат да ускорят или дори да получат актуализации от тях, ако изпратената информация е остаряла. По този начин в крайна сметка всеки възел ще достигне до DKG прекратяване.
Вече приемаме и едновременни DKG с тази нова реализация. Сега е състезание между DKG и който набор от кандидати стигне до края, преди останалите да получат шанс да станат новия набор от Старейшини. Някои DKG сесии може да са спрени или да приключат със закъснение, но ние не ги считаме за провали, те са участвали в състезанието и просто са загубили. Искаме следващият набор от Старейшини да бъде възможно най-надежден, така че избирането на победител в това DKG състезание също е начин за нас да изберем най-добрите възли. В крайна сметка, след разделяне на секцията, тези DKG сесии стават остарели и когато кандидатите разберат, че са загубили състезанието, те знаят, че могат да спрат.
Друго динамично дуо @bochaco и @chriso отстранява грешки в DBC тестовете. Те откриха проблем, при който SAP (списък с текущи Старейшини) се премахва по погрешка по време на процеса на тестване на клиента, което дестабилизира мрежата.
Междувременно @bochaco продължава да работи върху другия основен поток от дейности в момента, рационализирайки процесите на съобщения и използвайки единични нишки, където е възможно.
@joshuef и @davidrusu също работят върху аспекти на рационализирането на съобщенията, Джош проучва извличането на модула comms от кода node, за да види дали това може да се поддаде по-добре на многопоточност, докато Дейвид разделя част от кодът, споделен от sn_node и network_knowledge хранилищата, което се надяваме да елиминира някои от грешките при присъединяване на възли, които виждаме.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България