По-голямата част от екипа е зает с преструктуриране на Authority, това е кодът, който ни казва кои участници какви действия могат да извършват и какво ниво на достъп изискват. Прехвърляме ви към младия човек, на име @dirvine, да ви обясни допълнително.
Общ напредък
Продължаваме и с други поправки.
@anselme поправи грешка в sn_sdkg хранилището, която включваше рекурсивна обработка на гласовете. С това възел, изпълняващ DKG самостоятелно, ще достигне рекурсивно прекратяване при обработка на първия им глас в едно повикване! (Не е добре).
@bochaco продължава да отстранява грешки в комуникациите между възлите, заедно с @qi_ma, и също така коригира проблемите, открити с команди с една процесорна нишка и заявки в тръбопровода за непрекъсната интеграция (CI).
Междувременно @bzee и @chriso продължават да проучват работата на Quinn, Rust версията на протокола Quic за установяване и поддържане на връзки между възли, с оглед на преструктуриране на qp2p.
Преструктуриране на Authority
В момента имаме Authority за всяко съобщение и това правомощие е разделено между възел, клиент, секция и section_part. Това е както объркващо, така и податливо на грешки. Съвсем наскоро се заровихме в Authority, какво означава и какво ни предоставя.
Първата стъпка в това почистване е да премахнем пълномощията за съобщения и да се съсредоточим върху „Операции“-те. С това имаме предвид, че операцията в съобщението е мястото, където искаме да проверим авторитета и също така да можем да го приложим директно към данните. Тази част ни спестява, 1: наличието на правомощия (подписи) два пъти и 2: гарантираме, че всяка промяна на данни (включително съхранение) има съответния Authority.
Да изясним това малко. За съхраняване на парчета или контейнер (регистър) изискваме клиентите да платят. Когато са платили, всеки Старейшина връща част от подписа. След това клиентът събира подписа, за да създаде подпис на секция. Подписът на тази секция остава с данните и прави данните „NetworkValid“. Така че няма смисъл да подписваме цялото съобщение, само частта, която казва Store ABC, където ABC е името на данните. Така че всяка част от данните вече има SectionAuthority и не ни интересува в какво съобщение или формат получаваме подписаната операция.
И какво от това, може да попитат някои. Ами по същество това, което правим сега, е доста вълнуващо от няколко гледни точки:
- Отново по-малко код
- По-конкретни типове данни
- Премахване на изискването за каквито и да е подписи на съобщения (уговорка след минута).
- И най-важното… виж по-долу
Проницателният може в този момент да забележи голяма печалба за децентрализираните мрежи тук. С елементите на данни SectionSigned и SectionTree от няколко актуализации назад имаме мрежови агностични валидни данни. т.е. всяка мрежа, която също се доверява на нашето „SectionTree“, дори по-голямата част от нея (в случай на мега хакване) може да валидира и да се довери на данните „NetworkValid“. Тази функция позволява на данните да се преместват в други мрежи или дори в Safe II, кой знае?
Ние обаче имаме съобщения с подписи на възли и смятаме това за „доказателство“. Възлите изпращат съобщения един на друг и клиенти с данни или предложения (като възел X е мъртъв или възел Y иска да се присъедини и т.н.) и ние третираме техните съобщения като инфраструктурни команди (т.е. преходни) или команди за обслужване на клиенти (“дайте ми данни”). Тъй като тези съобщения водят до последствия в мрежата, ние изискваме от възлите да са коректни. Ако се установи, че се държат лошо, трябва да имаме неопровержимо доказателство за лошо поведение, за да можем да ги накажем. Подписаното съобщение ни дава неопровержимо доказателство за поведението на възел.
Като вземем всичко това предвид, текущото преструктуриране е доста бързо, отнема само няколко дни, но ни купува много простота и в същото време ни дава повече гъвкавост при съхраняване/препубликуване на данни. Представете си, че намирате някои стари данни на вашия възел, те не са в мрежата, но трябва да бъдат. След това не трябва да плащате, за да ги съхранявате, трябва просто да кажете тук са SectionSigned данни, ТРЯБВА да ги съхранявате. Това е договорът на мрежата с планетата.
Не само това, клиентите, които плащат за съхранение, всъщност плащат, за да получат SectionAuthority за данните, което ги прави NetworkValid. Сега това означава, че те могат да добавят пълномощията на секцията към своите данни и да изберат да ги съхранят по всяко време, когато желаят. Те също могат да ги публикуват отново, ако мрежата по някакъв начин ги е провалила.
Има 3-ма или 4-ма от нас, които работят върху това тази седмица и вече виждаме подобрения в яснотата и вероятно откриваме някои странни грешки, докато премахваме стария код (съобщенията все още имат много стар код там). Това е наистина чисто преструктуриране, което ще направи ловенето на грешки толкова по-просто, тъй като прави мрежовите операции по-прости. Освен това прави мрежата по-лесна за обяснение.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България