На финала сме да пуснем новото интегрирано CLI и API за тестване от общността, но има няколко крайни случая, които все още причиняват проблеми - и историята ни казва, че това, което може да се обърка, ще се обърка. Така че работим по изглаждането им, преди да интегрираме CLI-то както трябва.
В последните новини споменахме, че DKG причинява (несвързани) проблеми, като възлите понякога не успяват да бъдат повишени до Старейшини и понякога разделянето не се случва както трябва. Част от вината се крие в съобщенията, които пристигат извън ред и не се обработват правилно по време на DKG. @lionel.faber обяснява как поправяме това с Анти-Ентропия.
Общ напредък
Повечето от командите на CLI-то вече работят добре, но някои все още не са последователни. Също така трябва да добавим CLI-то към новия процес на автоматизирано освобождаване.
@Anselme се задълбочи в NRS, включително започна да внедрява поддръжка на сухо изпълнение за пакетиране на операции. Той също така помага на @danda и David Rusu в работата им по доказателството за плащане и частни транзакции. Ако сте следили новините ни, ще знаете, че те проучват най-добрите начини за внедряване на DBC по начин, по който транзакциите могат да бъдат бързи и непроследими, като същевременно могат да бъдат одитирани и да поддържат множество DBC изходи. Момчетата следват няколко пътя и досега най-обещаващият подход изглежда е версията на Ring Confidential Transactions (RingCT), използвана от Monero, която може да се използва за предоставяне на доказателство за плащане. Дейвид Русу направи презентация на екипа за това, която скоро ще възпроизведем тук.
Разрешаване на проблеми с DKG с помощта на Анти Ентропия
Генерирането на разпределени ключове (DKG) е начинът, по който управляваме процеса на консенсус между възлите. Необходим е ключ за извършване на действията. Този ключ се разделя на ключови дялове, като всеки възел с право на глас има единичен уникален дял. Ключът за подписване може да бъде генериран само след като определен брой дялове (да речем 5 от 7) са получени и обединени.
През последните няколко седмици се занимавахме с няколко проблема, които възникват по време на DKG в процеса на повишаване на най-старите възли от Възрастни в Старейшини. Когато дадена секция реши, че Възрастен трябва да бъде повишен, се провежда кръг на DKG и по-възрастните кандидати генерират ключ на секция и ключов дял.
Добавянето на DKG е поетапен процес с шест отделни фази: инициализация, принос, оплакване, обосновка, ангажимент и финализиране. Ключовете трябва да бъдат генерирани, обменени, обобщени и съгласувани. Със съобщения, преминаващи напред-назад във всяка фаза. Докато пълен ред на съобщенията не се изисква за DKG като цяло, възелът може да обработва само съобщения, свързани с текущата му фаза на DKG.
Въпреки това, асинхронният характер на мрежата означава, че съобщенията могат да пристигат в произволен ред и в децентрализирана мрежа е естествено някои съобщения да идват много по-късно или дори изобщо да не идват поради прекъсвания в мрежата, например.
Тези естествени събития не трябва да влияят на DKG способността на възлите и подобно на други мрежови операции, решението за неподредени DKG съобщения е (ако вече не сте се досетили) Анти-Ентропията. AE активно дава на участниците необходимата им информация и предотвратява извършването на действия, докато участниците не са готови.
Има две определени ситуации, при които се изисква AE за DKG съобщения.
DKG съобщенията пристигат извън фазата
Когато възел получи DKG съобщение, което е част от фаза, която той все още не е достигнал, той трябва да задържи това съобщение и да продължи да се опитва да го приложи, докато в крайна сметка (и да се надяваме) не достигне точка, в която съобщението може да бъде приложено.
Вместо да оставим това на произвола, можем да поискаме подателят на DKG съобщението да ни изпрати списъка със съобщения, които вече е обработил. Можем да проверим тези съобщения, като използваме подписа на подателя и след това да ги приложим локално, за да стигнем до същата фаза и след това да приложим съобщението, което задържаме. Това позволява на възлите, които са изостанали в DKG процеса, да настигнат останалата част от мрежата.
За да покажем защо това е по-ефективно, помислете за следното.
Да приемем, че редът на необходимите съобщения е
1.1, 1.2, 1.3, 2.1, 2.2, 2.3...
където всяко съобщение е
<phase>.<message_no>
Например, Initialisation.message1, Initialisation.message2, Contribution.message1 и т.н.
Да кажем, че имаме два възела A и B. Възел A е във фаза 2, а възел B е във фаза 1.
Има две възможности:
Проба и грешка
# Етап 1
B(фаза 1) получава 2.1 -> Не е готов -> съхранява 2.1
# Етап 2
B(фаза 1) получава 1.2 -> прилага 1.2
B(фаза 1) -> прилага 2.1 от съхранение -> Не е готов
# Етап 3
B(фаза 1) получава 1.3 -> прилага 1.3
B(фаза 2) -> прилага съхранение на 2.1 формуляр -> OK -> премахване на 2.1 от съхранение
Тук колкото по-дълго отнема да пристигнат 1.2 и 1.3, толкова повече опити и грешки се случват.
AE
# Етап 1
B(фаза 1) получава 2.1 -> Не е готов -> Пита A за всички съобщения
B(фаза 1) получава 1.1, 1.2, 1.3, 2.1 -> Прилага ги всички -> OK
B (фаза 2)
Така AE е много по-ефективен и ще намали броя на неочаквани потоци от съобщения.
DKG съобщения, пристигащи за сесия, която все още не е започнала
Преди да започне DKG сесия, участващите възли трябва да подпишат списъка с участници заедно с веригата от секции, за да гарантират, че всички те участват в една и съща DKG сесия. Новият ключ се добавя към веригата от секции, така че всички участващи възли трябва да се споразумеят за дължината му.
В случай, че даден възел не е получил достатъчно подписи за стартиране на DKG сесията, но DKG съобщенията са започнали да идват (например, ако възникнат проблеми с връзката по време на тази първоначална фаза), възелът може след това да поиска обобщения подпис на DkgStart съобщението, което може да бъде проверено спрямо ключа на секцията, след което DKG сесията може да бъде инициализирана и съобщението(а) да се приложи както по-горе.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България