Тази седмица на гости сме на Габ
Както знаете, той не е човек, който да се хвали
Но той тихомълком отстрани проблем със съобщенията
Чрез съхраняване на Верига на Секция в DAG
Добре, не е Ламборгини или дори Ягуар
Но за мрежовите операции това е наистина страхотно
Прегледайте го ако това е вашата отрова
Общ напредък
@danda създаде UML диаграми за всички хранилиша за Safe мрежата, което улеснява да се види как всички те пасват заедно. За хората, които не са специалисти, възможността да преглеждат имената на блоковете код и как те се свързват дава представа за работата на мрежата. Подобно на това да видите всички зъбни колела в часовника, може да не разбирате всички детайли на терена и броя на зъбите, но може да е добре да видите зъбците под рамката, за да разберете по-добре работата му. Можете да видите оголените, компактни и пълни версии на всеки контейнер, с нарастващи нива на детайлност, със зелени блокове, представляващи черти, сини структури и жълти изброявания. Сайтът се вижда най-добре в Chrome.
„Оголено“ SVG представяне на sn_dbc контейнера
Междувременно @qi_ma и @lionel.faber насочват вниманието си към прилагането на модела на Анти-Ентропията в процеса на генериране на разпределени ключове.
Прехвърляме се към Габриел (@bochaco).
Обработка на състоянието на мрежата
Мрежовите състояния описват процесите, чрез които старейшините следят топологията на мрежата. Тъй като Safe е асинхронен и винаги се променя, това се прави на базата на каквото е необходимо да се знае, при което когато възел се свърже с друг възел, те първо разменят информация за състоянието си към момента чрез обмен на антиентропийни (AE) съобщения.
За да намалим съобщенията, вече имаме DAG за проследяване на всички Вериги на секциите и PrefixMap за съхраняване на текущите SAP на секции. Следва обяснение как това се отразява на проверката на AE и SAP, ако първоначалното съобщение бъде отхвърлено.
Вериги на секции (SectionChain)
Веригите на секции са едни от най-важните инструменти, достъпни за възлите, тъй като те им позволяват да проверят дали част от данни или съобщения са валидни (има мрежови права).
Веригите на секции са свързани със списък с ключове на секции, където ключът на всеки блок във веригата е подписан от ключа на предишния блок, чак обратно до ключа за възникване (първия).
Всеки блок във веригата съдържа ключа на секцията, който Старейшините - в този конкретен момент - са използвали за подписване на всички процедури за споразумение. Всеки път, когато Старейшините се сменят (churn), се генерира нов ключ на секция и се добавя нов блок към Веригите на секциите.
Как това се използва за проверка на съобщения и данни? Е, всяка част от съдържание или информация, подписана от ключ на секция, може да бъде проверена, като погледнете Веригата на секцията. Ако ключът е намерен там, това означава, че част от съдържанието/информацията е била подписана от секцията в миналото и следователно има правомощия в мрежата.
Повторен опит и пренасочване при Анти-Ентропия
Мрежата използва набор от Анти-Ентропни (AE) съобщения за да се синхронизират информацията на възлите относно топологията на мрежата и секцията, към която принадлежат. Всяко съобщение, изпратено до възел или друга секция, трябва да включва текущия ключ на секцията му, за да бъде прието съобщението от получателя. Ако това не е така, получателят ще отхвърли съобщението, връщайки го на подателя в рамките на съобщение „AE-Retry“. Съобщението AE-Retry съдържа актуална информация за своята секция, т.е. текущия Авторитетен доставчик в Секцията (Section Authority Provider - SAP), който изброява текущите Старейшини на секцията и текущия ключ на секцията (вижте главата AE в Бялата книга).
Подобен поток от събития се задейства, когато съобщение се изпрати до неправилна секция, което може да е в следствие от липсата на най-новата информация за топологията на мрежата от изпращача. Получателят също така ще отхвърли съобщението, изпращайки го обратно на подателя в рамките на съобщение AE-Redirect. В този случай съобщението „AE-Redirect“ съдържа SAP на секцията, до която съобщението трябва да бъде изпратено повторно.
Когато подателят получи нов SAP чрез съобщение AE-Retry или AE-Redirect, той първо трябва да провери дали е валиден и доверен SAP, т.е. дали SAP принадлежи на мрежа, на която изпращача вярва.
За да направи това, възелът трябва да провери дали ключът на секцията, намерен в получения SAP, е криптографски проверим със SectionChain чак до ключа за възникване, в противен случай злонамерен възел може да го пренасочи към различна (неБезопасна) мрежа или към злонамерени партньори или секции. Ето защо всяко Анти-Ентропно съобщение също носи Доказателствена верига (ProofChain), така че оригиналният подател може да провери и да се довери на новия SAP.
Доказателствена верига са най-новите няколко блока на Веригата на Секцията - не е необходимо да изпращаме пълната Верига на Секцията, ако наскоро сме били в контакт с друга секция, само промените.
Какво се промени?
Досега всеки възел пазеше копие на своята собствена Верига на Секцията и SAP. Това беше използвано за валидиране на всяко входящо съобщение или нов SAP, получен в AE съобщения, както и за изграждане на Доказателствена Верига при изпращане на AE съобщения до други партньори.
Което беше работеше добре за познатите ни секции, но за далечни, непознати секции създаде доста допълнителна работа.
Да приемем, че изпращаме съобщение и то се връща, казвайки, че трябва да го пренасочим към секция, с която не сме се свързвали преди, включително и SAP на тази неизвестна секция. Знаем за секцията по нейния адресен XOR префикс, но не знаем нищо друго за нея или тя за нас. Не сме виждали нейния SAP преди и нямаме Доказателствена Верига. Така че, преди да можем да изпратим отново съобщението до новата секция, трябва да изпратим допълнителни съобщения за обмен на Веригата на Секцията, което е сложно и податливо на грешки.
Ето защо отскоро работим върху това всички възли да следят Веригите на всички други Секции. Това позволява на всеки възел да предостави Доказателствена Верига на партньори не само когато ги актуализира със SAP на собствената си секция, но и когато съобщение AE-Redirect им казва да направят това за отдалечена секция.
Това премахва част от AE трафика и сложността и също така позволява на възлите да гарантират, че взаимодействат само с партньори, на които се доверяват, че принадлежат към една и съща мрежа, чрез криптографска проверка на всеки ключ на секция, който получават чак до първия ключ в секцията.
Но как можем да съхраняваме тази информация сигурно и ефективно, така че възлите да могат да имат достъп до нея, когато им е необходимо, и така че да се актуализира при разделяне и пренареждане?
Вече внедрихме DAG (насочена ациклична графика), за да следим всички Вериги на Секции и PrefixMap (регистър, съпоставящ префикса на секция към неговия SAP), за да съхраняваме текущите SAP на всички секции.
DAG-а (насочената ациклична графика)
Мрежата започва с първоначален ключ за възникване, който е първият блок в Веригата на Секцията на секция Първа, а ключът на първия възел е подписан от ключа за генериране, за да създаде втория блок в тази Верига на Секцията. Тъй като възлите започват да се присъединяват към тази първа секция, т.е. първоначалната секция, Веригата на секцията продължава да расте.
В един момент, когато първоначалната секцията нарасне с достатъчно членове, за да се раздели на две отделни секции, двете групи възли, които ще станат Старейшини, ще се споразумеят кой ще стане техния собствен ключ на раздел (чрез процеса на DKG). След като всички приключат да се споразумеят за двата нови ключа на секцията, настоящият набор от Старейшини ще постигне споразумение за разделяне на секцията, подписване на двата нови ключа на секции с текущия ключ на секцията и създаване на два клона във Веригата на първоначалната Секцията.
Този процес се повтаря във всеки от двата нови клона, независимо един от друг. Те се разделят на повече секции, създавайки повече клонове в съответните им Вериги на Секции. Това естествено образува DAG, като всеки от върховете съдържа ключ на секция и подпис, направен с ключа на секцията на предходния връх.
Като се има предвид всеки ключ на секция, неговата Доказателствена Верига може да бъде изградена от DAG чрез събиране на всички върхове (ключове на секции и подписи), които са по пътя от ключа за възникване до този ключ на секция. Имайте предвид, че тъй като секциите никога не се сливат, а само се разделят, винаги има уникален път от ключа за възникване до всеки друг ключ на секция в DAG, с други думи, има уникална доказателствена верига от ключа за възникване за всеки даден ключ на секция.
Тази разработка е описана подробно в този PR.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България