Safe Network новини 🇧🇬 15.9.2022

Тази седмица разглеждаме въпроса за контрола. Кой какво може да направи и какви идентификационни данни се изискват за това? Темата изкача напред, докато търсим да опростим кода, премахвайки шаблони за филтриране на съобщения, които вече не използваме, и гарантирайки, че основите са логични и лесни за разбиране.

Общ напредък

@anselme внедри слой за клюки за обработка на пропуснати случаи, когато новата DKG система не успее да се прекрати и сега разглежда случаите, в които имаме едновременно разделени DKG, които прекъсват заедно. Като изключим това, DKG изглежда доста стабилен вече.

И @roland до голяма степен завърши преминаването от SectionChain (сигурен свързан списък) към новия дизайн на Section DAG. Още малко тестове и сме там.

@qi.ma търси потенциални бъгове във „FilesContainers“, тъй като наскоро тестовете на общността подчертаха някои съмнителни сблъсъци на версиите.

Също така проучихме някои проблеми с връзката на клиента от възлите, които изглежда изпускат някои отговори. Премахваме и ненужните стъпки за сериализиране около „OperationId“, което допълнително облекчава натоварването върху възлите.

Контрол

Ако разгледаме авторитета от гледна точка на сила, може да си помислите, че Старейшините, хитрите стари сивобради, биха имали най-голям авторитет. В края на краищата, те са тези, които контролират всичко, което се случва в тяхната Секция, включително притежаването на силата за живот и смърт върху другите възли. Ще сгрешите. Когато става въпрос за извършване на промени в мрежата, отделните възли нямат никакви индивидуални правомощия. Възрастните никаква власт, докато Старейшините имат власт само като колектив, чрез гласуване с минимален праг за взимане на решение.

Всъщност най-силният актьор е клиентът - клиентът е крал, така да се каже. Това е така, защото клиентът може да прави неща като редактиране на променливи данни (контейнери), които притежава, и подписване за повторното издаване на DBC. Възлите всъщност са само пратеници, предаващи информация за операции и решения напред-назад и най-вече изпълняват това, което им се каже.

Защо това има значение? Е, има значение, защото искаме ясни разделителни линии за това кой какво може да прави. Доколкото е възможно, ние искаме пълномощията да бъдат имплицитни в типовете данни и операциите и това да се контролира от криптография, а не от сложни йерархии, и искаме възможно най-простите структури за оторизация.

Типове данни

Разрешенията са вградени в типовете данни.

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

Променливи данни
Съхраняването на контейнери изисква SectionAuth, докато промяната им изисква ClientAuth - само собственикът трябва да може да променя своите данни. И така, внедрено в този тип данни е, че той изисква клиентски подпис, преди да може да бъде променен. ClientAuth е валиден клиентски подпис.

Другият тип променливи данни е SectionTree, което е дърво, разклонено от Генесиса. Тук ситуацията е малко по-различна, тъй като всъщност има множество собственици (всички секции), но всяка Секция може да добави лист само към своя конкретен клон със своя SectionAuth.

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

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

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

Операции с данни

В REST API условията операциите с данни изглеждат така:
GET операциите не изискват никакво разрешение.
Операциите PUT изискват SectionAuth за съхранение и комбинация от ClientAuth и SectionAuth за плащане.
POST операциите изискват ClientAuth за промяна на контейнери, SectionAuth за промяна на отделните листа на SectionDAG

Прехвърлянето на токени изисква комбинация от ClientAuth и SectionAuth.

Мрежови операции

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

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

А за DKG е жизненоважно съобщенията, изпратени между Старейшини с техните дялове от гласове, да получат опълномощение. Опълномощението на съобщението е това на подателя и се проверява спрямо неговия подпис върху съобщението. Това се нарича NodeAuth.

Добре, но за какво е всичко това?

Като се фокусираме върху опълномощението и премахваме ненужните проверки, особено в съобщенията, ние опростяваме операциите, доколкото е възможно, и разчитаме на криптографията и типовете данни, за да свършат тежката работа вместо нас. Все още имаме някакво ненужно подписване на съобщения, висящо от предишни версии на мрежата и всички те имат разходи за производителност, както и създават объркване. Чистият, прост дизайн е ефективен дизайн.


Преводи:

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

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