Тази седмица ви представяме нещо като предистория, докато разглеждаме как Веригите на Секциите (SectionChains) и SAP се вписват в промените на PrefixMap, обявени миналата седмица.
Общ напредък
Няма големи разкрития тази седмица, насочени сме повече към постоянното тестване, оптимизация и работа по отстраняване на грешки, която бележи тази фаза от разработката.
@davidrusu търси начини за наблюдение на мрежата и администриране на Node Age, включително как Възрастните могат да докажат на Старейшините, че са живи и жизнени, дори ако няма много мрежова активност.
@bzee продължава да разглежда OpenTelemetry инструмента за наблюдение с отворен код, като някои преструкторирания вече са на място, за да позволят наблюдение през OTLP протокола. Надяваме се, че това ще ни позволи да записваме логове в Elastic сървър, където можем по-лесно да получим преглед на състоянието на тестовите мрежи.
И @joshuef продължава да се занимава с оптимизиране на паметта. Премахнахме някои прекалено настоятелно повторни опити, които потенциално поддържаха връзките живи, и чакащи съобщения в паметта, докато изпращането им се опитваше отново и отново и отново (както в qp2p слоя, така и във възела). Той също така направи други по-малки промени, които спомогнаха за значително намаляване на натоварването на паметта.
@yogesh има PR на място, за да позволи информацията за traceroute да бъде върната на клиента. Това ще изброи всички възли, включени в потока на съобщенията за дадена заявка/cmd, което би трябвало да помогне при отстраняването на грешки.
Вериги на секции и SAP
Веригите на секции (SectionChains) осигуряват запис на смяната на Старейшини в рамките на секция, действайки като доказателство, че текущият набор от Старейшини е валиден. Не можем да вярваме на думата на отделни Старейшини, че те са тези, за които се представят, нито можем да се доверим на текущата група - това би бил очевиден вектор на атака. Вместо това използваме чудесата на криптографията, за да създадем SectionChain, сигурен свързан списък, който доказва, че Старейшините са тези, за които се представят, като свързваме текущия ключ на Секцията по целия път обратно към генезисния ключ.
„Genesis“ ключът може да се разглежда като „доказателство за мрежа“. Това е първият ключ, създаден от първия възел в първата секция – секцията с префикс 0. Веднага щом този първи самотен възел се присъедини към друг възел (опитваме се да не го наречем Ева, тъй като това бързо ще стане объркващо), се създава нов ключ на секцията B, който е подписан от генезисния ключ. Когато се присъедини нов възел C, отново се създава нов ключ на секция, този път подписан от B и т.н.
Работата на „Genesis“ ключа свършва веднага след като той подпише ключ „B“. Въпреки това, той остава изключително полезен като доказателство, че текущият ключ на секция и всички предшестващи го са валидни, не са добавени от нападател, тъй като криптографски е много лесно да се докаже, че текущият ключ на която и да е Секция в крайна сметка е свързан с Genesis ключа, колкото и дълга да е станала Веригата на секция.
Подписване
Но какво имаме предвид под подписване? Подписването означава просто използване на нашия таен ключ за добавяне на някои уникални битове към съобщение или файл. Всеки, който има нашия публичен ключ, може да провери, че ние сме го подписали (и в повечето случаи, че файлът не е променен след подписването).
За да използваме класическия пример, Алис изпраща съобщение до Боб и го подписва със своя таен ключ, което означава, че тя създава уникален „подпис“ чрез комбинация от съдържанието на съобщението и нейния таен ключ. Боб може да бъде сигурен, че е подписано от Алис, защото може да провери подписа с нейния публичен ключ. Подслушващата Ева също има публичния ключ на Алис, но тя е безсилна да измами Боб, като промени съобщението на Алис, тъй като то вече няма да носи валиден подпис.
Вместо индивиди като Алис и Боб, в дадена Секция ние се занимаваме с групови решения, които трябва да бъдат одобрени от супер мнозинство от Старейшини. За да има византийска отказоустойчивост (което означава, че една трета от възлите могат да бъдат нефункционални, без да причиняват повреда), петима от седем Старейшини трябва да подпишат съобщение. Вместо всеки Старейшина през процес като този на Алис и Боб по-горе, много по-ефикасен начин да направите това е чрез генериране на разпределен ключ (DKG), където всеки Старейшина допринася с ключов дял. Веднага след като имаме пет от тези споделени ключове - произволни пет - създаваме валиден ключ за подписване и решението се валидира. Това е еквивалентът на секретния ключ на Секцията, подписващ съобщението, въпреки че при BLS таен ключ не съществува.
Всичко това е чудесно, докато имаме само една Секция, но в крайна сметка, когато мрежата се разрасне, Секцията ще се раздели, за да създаде нови Секции „01“ и „11“ с нови Старейшини и нови SectionKeys, подписани от този на родителската Секция. Тези нови Секции ще претърпят смяна на Старейшини с течение на времето, като всеки път ще се създава нов DKG SectionKey. В крайна сметка се формира дървовидна структура с генезис като корен и всеки клон ражда два нови клона, докато мрежата се разширява.
Важното е, че всеки текущ ключ на Секция във всяка Секция има път надолу по клоновете до генезисния ключ. Това означава, че можем да докажем, че сме в правилната мрежа и че процесът на посрещане на нови възли е валиден на всяка стъпка, поне що се отнася до DKG. Но веднага щом има повече от една Секция, всяка Секция има различен път обратно към „Генезиса“, в който момент веригата на Секциите става DAG (насочена ациклична графика), а не линейна верига.
Секционен Удостоверител (The Section Authority Provider - SAP)
Секционната верига е прост, но жизненоважен инструмент. Всеки възел и клиент притежава SectionChain. Като клиент или възел, той ни казва, че текущата Секция, с която говорим, е криптографски валидна и че сме в правилната мрежа (както е доказано от „Genesis“ ключа), а не в някакво разклонение, но това е всичко .
Когато възел или клиент се присъедини към мрежата, той получава SectionChain и SAP. SAP ни разказва за настоящите Старейшини. Това е списък на текущите Старейшини (всеки Старейшина има уникален идентификатор, IP и порт), подписан от един от ключовете в SectionChain. Това означава, че когато се свържем с възел в този списък, можем да сме сигурни, че е валиден, защото още веднъж сигнатурата може да бъде проследена чак до „Генезиса“. SAP също така съдържа текущия SectionKey.
Както беше обяснено миналата седмица, SAP е включен в PrefixMap, който картографира всеки префикс на Секция към всички ключове в хронологията на тази Секция. Освен че можем да проверим дали всички данни, които обработваме, са правилни (ще имат същия префикс като секцията), това също означава, че когато се движим между Секциите, не трябва да взимаме отново цялата верига на Секциите. Вместо това можем просто да слезем надолу по дървото, доколкото ни е необходимо, докато стигнем до Секция, която вече съществува в нашата верига от Секции, и да я вземем оттам, което очевидно е по-ефективно.
Следващата седмица повече за това как всичко това работи заедно.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България