Safe Network новини 🇧🇬 28.7.2022

Тази седмица завършваме прегледа за това как можем да валидираме Секциите и дори самата мрежа, като използваме BLS ключове за подписване, за да създадем проследимост чак до „Началото“, като текущото членство е свързано с префикса на секцията чрез „PrefixMap“, ` и как това се актуализира редовно от AntiEntropy (AE).

Общ напредък

@Joshuef вижда известен напредък при проблемите с паметта, някои от които може да се дължат на заключвания, идващи от traceroute. Заедно с някои подобрения на DBC теста от @bochaco, CI отново започва да изглежда по-здрав.

@Bochaco също разглежда h3 и WASM и как те могат да бъдат интегрирани в клиента. Тук има интересно видео за h3 (HTTP/3) - добра находка @19eddiejohn75.

@Roland е написал PR за преместване на SectionChain в PrefixMap (вижте по-долу). Първо ще му трябва малко тестване.

И @oetyng има две големи промени в ход: извличане на съхранението на данни и опростяване на потока на изпращане на съобщения.

Извличане на съхранението на данни
Преминавайки към по-проста node структура, преди време извлякохме comms модула. Сега преминаваме към „данни“ модула. Първоначално това беше породено от стремеж за премахване на заключвания в структурата на възела, но сега търсим повече предимства. Отделянето им позволява тези компоненти да работят изолирано, което прави тестването им по-лесно и по-бързо. Също така можем да настроим по-малки версии на мрежа, комбинирайки някои модули, а други не. За „възел“ структурата преместваме повечето I/O от нея, което е една стъпка по-близо до потенциално API с „чиста функция“ на „възел“. Това има за цел да улесни разсъжденията ни относно кода и ефектите от промените, намалявайки риска от грешки.

Опростяване на изпращане на съобщение
Това преструктуриране премахва повече от 400 реда код и намалява броя на местата, където извикваме различни функции за изпращане с различни параметри. Тези параметри се оказаха ненужни, както и различните функции за изпращане също не бяха необходими, когато преработихме нещата малко. Също така, това поставя подписването и инстанцирането на WireMsg структурата на едно място.

Как всичко това си пасва

Повече за BLS

Ние използваме генерирането на разпределен ключ (DKG) като ефективен начин за постигане на споразумение между Старейшините. След като сме събрали пет от седем части, създаваме нов ключ за Секцията, който е публичен ключ, както и виртуален частен ключ, който всъщност не съществува, защото това е система без собственик. Не искаме никой да бъде начело, когато постигаме споразумение.

Но всеки отделен Старейшина - или всъщност всеки възел - също може да използва свои собствени двойки BLS ключове, за да създаде произволен брой споделени ключове и те могат да се използват в механизъм, базиран на агенти. В тази система има собственик, който контролира секретния ключ и този собственик е свободен да създава и разпространява дялове в система n-of-m. Например, собственикът на уебсайт може да раздаде споделени ключове на трима доверени служители и да изисква от поне двама да подпишат всички промени в сайта.

Не бихме използвали базиран на агенти механизъм за децентрализиран консенсус, тъй като конкретно не искаме да има собственик на секретния ключ, но можем да го използваме за при споделянето на данни.

Още за PrefixMap, SectionChain и SAP

PrefixMap е просто структура, която картографира всички префикси на секции (00, 01…) към техните текущи удостоверители на правата в секцията (SAP).

SAP е списък със Старейшини в Секция, с техните идентификатори, IP адреси и портове, плюс текущия BLS ключ на Секция. Така че той предоставя цялата информация, необходима на възел или клиент, за да се присъедини към мрежата.

PrefixMap

Префикс                   SAP

00 → {[A(IP, port), B(IP, port), ….F(IP, port)], Sec_key}
01 → {[G(IP, port), H(IP, port), ….M(IP, port)], Sec_key}

….

Всеки възел и клиент има копие на PrefixMap – към тях се изпраща едно веднага щом се свържат или могат да получат такова от приятели или по друг начин. Но не всеки PrefixMap е актуален, така че клиентът или възелът, който осъществява контакт със Секция, трябва първо да актуализира своя PrefixMap с текущия SAP чрез AntiEntropy (AE). Само когато разполага с актуален SAP, може да започне да работи със Секцията.

Но, разбира се, също трябва да знае, че „PrefixMap“ е истински. За целта трябва да провери дали SAP е подписан от валиден ключ на секция (текущият ключ минус 1), както и че този ключ е валиден, защото е бил подписан от предишния и т.н. обратно до „Генезис“ ключа.

Така че другата част от PrefixMap е SectionChain. Това е двоична дървовидна структура, която свързва всички BLS ключове на Секции чак до „Genesis“. В момента това е отделен елемент и ние синхронизираме между ключа в SAP и веригата, но планираме да ги обединим – тогава ще трябва да измислим някои по-добри имена!

В този момент PrefixMap/SectionChain, или както и да го наречем в крайна сметка, ще бъде DAG с Genesis ключа в основата и веригата от SectionKeys и текущия ключ и членство в листата.

Другото нещо, което трябва да споменем е, че ако клиент или възел се свърже отново с мрежата, не е необходимо да актуализира отново целия SectionChain, а само частта, която е нова. Така че секцията, към която се свързва, изпраща тази нова част от веригата – наричана по различен начин ProofChain или част от веригата – към повторно свързващия се възел, за да може просто да го добави към съществуващия си „SectionChain“.

С този дизайн, дори ако някой успее да открадне „Genesis“ ключа и да се представи за мрежата, това ще има все по-малко значение, тъй като мрежата става все по-голяма и по-голяма и DAG има все повече и повече клонове, защото ще трябва да проследяваме ключовете чак до „Генезиса“ все по-рядко.


Преводи:

:uk: English :ru: Russian ; :de: German ; :es: Spanish ; :fr: French

  • Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Redirecting...