Продължавайки напредъка си в адаптирането на консенсусни протоколи за децентрализирани мрежа за нашите цели, и по-точно за управление на членството в Секциите, тази седмица Мостафа ни превежда през ABBA и MVBA. ABBA е протокол за хвърляне на монети за двоично споразумение. Ако дадена секция се нуждае от нов Възрастен, Старейшините могат да изберат единичен възел, за да предотвратят масово присъединяване, докато MVBA се използва за решаване между конкуриращи се предложения, като например кои възли трябва да бъдат Старейшини в следващата итерация на Секцията.
Общ напредък
@roland работи усилено върху нова помощна програма TestNetwork, която ще улесни настройването на средата за тестове на възли. Можем да окажем на програмата да генерира мрежа с конкретен SAP в префикса и той ще създаде функционална и конфигурируема мрежа с попълнени всички празнини. @oetyng сега преработва кода, за да активира някои тестове от край до край, които бяха деактивирани след работата по двупосочния поток, която беше блокирана за известно време.
@chriso обнови нашата AWS структура и сега просто проверяваме как най-добре да използваме това по време на PR (за да получим повече скорост и надеждност за определени тестове).
@joshuef и @roland продължават да намаляват броя на блокировките за запис, които предприемаме за състоянието на възела. Това са съобщения, които се изпращат между Старейшини и клиенти, които се свързват с тях, за да се уверят, че клиентът разполага с актуална информация за Секцията, преди да се опита да направи заявка. Тези блокировки при запис са друго място, където можем да блокираме изпълнението на код и възелът да се забави. Те също са ненужно усложнение и потенциален източник на грешки. Сега заключваме само AE съобщения, които всъщност ни актуализират (преди това бяха всички AE съобщения). Също така вече не заключваме по време на репликация на данни или проследяване на дисфункция. Така че сме много по-близо до щадящо/разумно състояние на „възела“, което се нуждае само от достъп за „запис“ за малък поднабор от задачи, свързани с мрежови знания.
В допълнение към тази работа, @bochaco също работи върху AE съобщенията и премахването на излишната логика при обработката на AE на клиента.
ABBA и MVBA
ABBA протокол
ABBA или Asynchronous Binary Byzantine Agreement е начин за решаване на проблема с консенсуса в асинхронните мрежи. По-специално, ABBA може да се използва за решаване на въпрос с да/не като група.
В този протокол всяка страна започва с излъчване на своите предпочитания (да/не). Ако няма мнозинство за инициализираните стойности, страните започват схема за хвърляне на прагова монета, която ще доведе до произволен резултат, с който всички могат да се съгласят. ABBA е недетерминиран протокол, изходът му е произволно число. Ако възпроизведем входните събития, може да получим различен изход.
Консистенцията се осигурява от VCBC. Както го представихме миналата седмица, VCBC е протокол за излъчване, който се опитва да разпространи съобщение от възел до мрежата, като всички възли са съгласни върху съобщението, изпратено от възела. VCBC протоколът може да бъде модифициран, за да приема само валидните и правилни предложения.
Използваме VCBC, за да се уверим, че съобщенията, излъчвани от възли, са валидни. VCBC е просто проверка за валидиране. Така че, ако Старейшина излъчи предложение, че последващ възел трябва да бъде допуснат в секцията, другите възли могат да се уверят, че Старейшината не е корумпиран или дефектен и предложението трябва да се вземе на сериозно.
След това можем да използваме ABBA кръгове, за да постигнем съгласие чрез схема за прагово подписване, която продължава, докато мнозинството от Старейшините постигнат консенсус. ABBA винаги ще се прекрати. Той винаги ще генерира произволна двоична стойност, която се използва за вземане на решение. Ако имаме достатъчно гласове, можем да се ангажираме с предложението.
Редът на Старейшините има значение. Представете си, че старейшините са подредени така: [3,5,7,2,1] и 3 е офлайн. След VCBC имаме предложения [-,P5,P7,P2,P1]. Първото предложение е P5. Ние стартираме ABBA за P5. Знаем, че P5 е валиден и всички Старейшини го имат (постоянно излъчване), следователно трябва да се реши след известно време.
Идеята за по-слаба валидност
Вземаме тези готови алгоритми и ги променяме за нашите цели. Тъй като VCBC вече е потвърдил съобщенията за нас, можем просто да изискаме една честна страна да вземе решение само за стойност, за която разполага с придружаващите валидиращи данни. В противен случай се отхвърля.
Това ни позволява да направим протокола на ABBA по-прост.
MVBA протокол
Протоколът Multi Values Byzantine Agreement (MVBA) се използва, когато има повече от едно предложение за постигане на консенсус.
Можем да го използваме, когато няколко Старейшини напуснат или няколко Възрастни отговарят на условията за повишение едновременно, така че има редица възможни версии на следващата версия на Секцията.
При този сценарий всяка страна последователно излъчва своите предложения чрез VCBC и след получаване на достатъчно предложения от честни страни (валидни), протоколът започва да изпълнява двоично споразумение (използвайки ABBA) за всяко предложение. Когато първото предложение бъде решено, процесът приключва.
Проблем с членството
И така, какво се опитва да реши всичко това? Става дума за повишаване и понижаване на Старейшини. Този процес трябва да се случи със съгласието на изключително мнозинство от честните Старейшини и ние искаме да избегнем пълен ред, тъй като това е много изчислително интензивно и не е начинът, по който природата прави нещата. Също така трябва да се справяме с високи нива на едновременност (множество едновременни присъединяващи се/напускащи), без да се налага да чакаме постигане на ред и да можем да обработваме или забраняваме разделяния (форкове).
Нашият подход е да се справим с този проблем с помощта на MVBA протокола. В този сценарий всеки Старейшина предлага списък с изглед на Старейшините, които ще отговарят за Секцията след промяната, и го излъчва на другите Старейшини. Това продължава, докато мнозинството от Старейшините не получат достатъчно предложения от другите възли. След това предложенията се гласуват чрез ABBA протокола, така че един окончателен списък от Старейшини се избира на случаен принцип от предложените.
Разглеждаме задълбочено тази област, както знаете, и има компромиси и избори, които трябва да се направят. Едно подобрение, което можем да направим, е да използваме валидирани предложения. Членството ни позволява да направим това, като по този начин намаляваме времето за постигане на споразумение. Друга област е паралелността. Докато строгият ред не позволява едновременност, има възможности, които са сложни и трябва да се вземат предвид, но вероятно отново ще доведат до много по-малко код. Във всеки случай е добре да имаме възможности, но приспособяването им към специфичния случай на членството ни дава много опции за избор и след това можем да разгледаме компромисите с по-голяма сигурност в този случай на употреба.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България