С протичаща дейност в няколко различни, но свързани области, решихме, че е подходящо време за обобщение на цялостното състояние на проекта, обхващащо основните направления на работа ни, къде се намират и как се свързват.
Общ напредък
@yogesh работи по настройката на сървъра на ElasticSearch/Kibana, за да ни позволи по-лесно да наблюдаваме работещите клиенти, и финализира документите за „traceroute“.
@joshuef откри процес в sn_node, който използва около 1/3 от процесорното време и вероятно е ненужен, тъй като сме внедрили тази функционалност другаде, така че той тества какво ще се случи, ако го премахнем.
@oetyng и @davidrusu работят по задачата за концептуализиране на създаването и изплащанията на Genesis DBC, които екипът разработва тази седмица (вижте по-долу), докато @anselme е в последните етапи на преструктуриране на DKG с премахването на многонишковостта за опростяване, както и премахване на прекъсвания (вижте по-долу).
Разбивка на активността
Членство, AE и консенсус - как всичко се свързва заедно
Членството и Анти-Ентропията (AE) са свързани с поддържането на актуалността на системата, докато консенсусът се използва за вземане на решения, които променят състава на секция и/или данните, които тя съхранява.
Всяко системно съобщение, което се изпраща през мрежата, съдържа ключа на секцията. Клиентът изпраща това, което смята, че е текущият ключ на секция, когато за първи път комуникира със секцията, и ако ключа е остарял, Старейшините на секцията му изпращат текущия ключ в доставчика на права за секция(SAP), който също съдържа списък на Старейшините в секцията, така че да може да актуализира своите записи, преди да опита отново. Това е AE.
Сега обмисляме да добавим и Членството в този обмен на информация, за да затворим празнината между това, което възлите разбират и върху което гласуват, и това, което се споделя в SAP. Може би си спомняте, че членството е начинът, по който Старейшините следят Възрастните и другите Старейшини в тяхната секция, така че да могат да се справят с нови присъединявания, разделяния, напускане и повишения.
Особено когато разглеждаме плащания към отделни Възрастни, ще бъде по-бързо, ако знаем къде са те - Възрастните напускат по-бързо от Старейшините и може да са били преместени в друга секция или повишени. В допълнение, Възрастните имат „възраст на възела“ и заплащането им ще бъде пропорционално на това. И така, търсим как да включим малко информация за текущото поколение Възрастни в секцията към съобщенията за съхранение и плащания.
Възрастните могат да поискат своите плащания по всяко време, дори ако са преминали в нови секции и т.н., тъй като DBC се преиздава към техния публичен ключ и те могат да докажат, че са били в секцията в този конкретен момент, като част от това конкретно поколение. Така че тази мярка е по-скоро за намаляване на броя на обменяните съобщения.
Освен че включихме Членството в процеса на обмен на информация, въведохме и механизъм за консенсус в начина, по който работи. Членството използва консенсус за приемане и премахване на членове в секция по синхронизиран начин. Той гарантира, че всички Старейшини имат еднакъв поглед за реда на присъединяванията и напусканията в секцията. Това е за предотвратяване на несъответствия в списъка с членове на всеки Старейшина, тъй като регистърът на промените на членовете е верига с възможност само за добавяне, където е необходим консенсус със свръхмнозинство за добавяне на нов елемент.
Време за извикване при изчакване - увеличаване на неминуемостта при DGK рундове
По принцип DKG не използва консенсус, вместо това участниците в DKG се уверяват, че никой не лъже, като изпращат подписани съобщения и след като получат всички съобщения на другия, те изпращат набор със съобщенията на всички и се уверяват, че всички са подписали един и същи набор. Ако има едно несъответствие, те спират да участват в този кръг на DKG, той се счита за неуспешен и никога не постигаме никаква форма на консенсус по този кръг. Това гарантира, че DKG кръг с измамни членове никога не достига до финал, защото в крайна сметка не искаме измамници като старейшини.
Много DKG рундове могат да се осъществяват едновременно и това е състезание между тях за достигане на финала (или прекратяването им). Когато имаме завършен DKG, консенсусът за предаване може да започне и да вземем решение за следващите Старейшини. Тъй като предаването използва консенсус, то гарантира, че е избран само един DKG резултат, така че можем да имаме множество едновременни завършвания на DKG, но само едно от тях ще бъде избрано за предаване.
Разпределеното генериране на ключове (DKG) е начинът, по който Старейшините създават ключа на секция по сигурен начин, при който всеки Старейшина знае само своя собствен ключ. При тестване открихме няколко случая, при които DKG непоследователно се проваляше и се стартираше отново поради прекъсвания при изчакването на съобщения.
Обновяваме нашия DKG с по-чиста реализация без прекъсвания. Например, ако най-старите седем възела в секция не са текущите Старейшини, те ще се опитат да изпълнят DKG, за да създадат нов ключ на секция. Ако не участват всички кандидати за Старейшини, позволяваме на този DKG да не се прекрати и това е добре, защото не искаме неактивните възли да стават Старейшини. Можем да изчакаме ново изтичане на членове да се случи отново и да задействаме друг DKG. Приемаме едновременното състезание при DKG, за да назначим новите Старейшини. Консенсусът при предаването ще реши кой ще спечели в крайна сметка.
@anselme прекара много време в почистване на DKG, премахване на ненужни типове съобщения от DKG кода и интегриране на новия DKG. Сега изглежда много по-добре и скоро ще можем да го тестваме.
Промени на възела
Направихме някои промени в sn_node кода. Сега трябва да предадете пътя на файла с контактите към всеки възел, който се присъединява към мрежа (--network-contacts-file). Вместо възелът да очаква контакти да бъдат намерени някъде, други инструменти отговарят за осигуряването на пътя до възела.
Актуализирахме sn_launch_tool, за да направим това, така че ако го използвате (или CLI, който го използва), инструментът вече предоставя на всеки присъединяващ се възел пътя към --network-contacts-file.
--network-contacts-file е просто файл, който дава на присъединяващ се възел или стартиращ клиент информацията, от която се нуждае, за да се присъедини към мрежата. Тази информация се намира в SAP и SAP частта на PrefixMap.
За нови възли използваме файла PrefixMap на Genesis възела, за да предоставим тази информация (той се намира на ~/.safe/node/local-test-network/sn-node-genesis/prefix_map), но инструментът също копира това файл до местоположението, където след това клиентите/CLI ще го намерят по подразбиране (~/.safe/prefix_maps/default).
Можем да използваме един и същ PrefixMap, за да позволим както на възел да се присъедини към мрежа, така и на клиент да се свърже към мрежата, тъй като съдържа SAP, към които те могат да се свържат. От тяхна гледна точка това е същото като списък с мрежови контакти.
В бъдеще клиентите и възлите може да поддържат други типове файлове и формати. Каквито и да се промени там, те винаги ще се нуждаят от списък с мрежови контакти, за да се присъединят/свържат към мрежа.
Както описахме в новините тук, PrefixMap наскоро еволюира от прост файл, който картографира префиксите на секции към текущите SAP, до по-сложна структура, която включва пълния секционен ключ DAG/дърво - така че този файл вероятно ще бъде преименуван скоро.
Финализиране на изплащането на 70% награди от мрежата
70% от SNT токените в крайна сметка ще бъдат създадени от мрежата в процеса на качване на данни от клиентите.
Когато клиентите качват данни, те първо трябва да платят на секциите, където ще се съхраняват данните. Тези плащания се споделят между възлите във всяка секция (най-вероятно между Старейшините и Възрастните, съхраняващи дадените данни, пропорционално въз основа на възрастта.)
Въпреки това, определена част (която предстои да бъде решена) от плащанията също ще доведе до създаване на нови SNT токени под формата на DBC. Общата стойност на новия DBC ще бъде същата като сумата на плащането. Новият DBC ще бъде споделен между всички възли в секцията.
За да изберем онези плащания, които ще доведат до нови SNT токени, се извършва тест, например някакъв вид съвпадение, включващо хеш на плащането и префикса на адреса на секцията. Вероятността за преминаване на теста ще зависи от желаната скорост на създаване на SNT (досега известно като мрежова скорост на фермерство).
Старейшините проверяват всяко плащане, за да видят дали преминава този тест. Стимулът за тази проверка (която е бърза и изисква минимални ресурси) е шансът да спечелят SNT. Повечето плащания няма да преминат теста и ще продължат както обикновено, но когато има съвпадение, Старейшините използват това плащане, за да изсекат „Genesis DBC“. Този „Genesis DBC“ е чисто нов и увеличава общата сума SNT токени, налични за харчене. Общата им сума е същата като сумата на плащането за качване и стойността й е разделена между всички възли в секцията, претеглени по „възраст на възела“.
За да бъде изразходван DBC, той трябва да се преиздаде към публичните ключове на новия собственик(ци). За целта предаваме Genesis DBC обратно на клиента и го караме да преиздаде нови DBC на възлите - плюс един DBC за себе си като стимул. Размерът на този стимул трябва да бъде разработен.
След като DBC са преиздадени, възлите получатели се уведомяват и вече могат да изразходват своя DBC както и когато желаят.
Изсичането на нови SNT токени става само със съхранението на нови данни. SNT трансферите не водят до създаване на нов DBC.
Вероятно ще променим името „Genesis DBC“, тъй като има много такива DBC, така че думата „genesis“ е объркваща.
Финализиране на фермерството/плащане за съхранение
Тъй като концепцията за емисия на токени се развива добре, можем също да видим как нашите планове за плащания за данни пасват и за щастие виждаме, че пасват доста добре. Това е поток, за който говорихме преди, при който клиентите искат оферти от секцията за даден набор от данни и след това извършват съответните плащания за това. Хубавото е, че това по своята същност е групирано, така че един набор от преиздавания на DBC може да работи за всякакво количество данни.
Този процес ни дава разписка, с която можем да потвърдим, че дадена част от данните е платена, и която можем да прикачим към данните, което ефективно ги прави „Валидни в мрежата“, т.е. те могат да бъдат качени повторно, без да се налага повторно плащане, например.
След това тази разписка ще бъде част от процеса на изплащане в мрежата, както е описано по-горе.
Използване на клюкарски кръгове за членство в секция и актуализиране на PrefixMap между секции
Въвеждаме подход на клюки при създаването на нов SAP, за да гарантираме, че мрежата е винаги достъпна от всички секции. Този механизъм гарантира, че информацията се разпространява логаритмично (много бързо и ефективно). Когато старейшина получи нов SAP от всяка част на мрежата, той ще избере двама произволни старейшини от която и да е секция и ще препрати съобщението към тях. AE ще гарантира, че възлите се актуализират и в двете посоки и също така ще прекрати клюкарския кръг. Това са „междусекторни клюки“ и се отнасят само до старейшините.
Вътрешно в секцията имаме промени в членството, които включват възрастни. Тези промени ще следват същия модел, за да се гарантира, че всички членове са в крак с всички промени в членството. Това са „вътрешни клюки“.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България