Малко дегустация на нещата, които предстоят тази седмица. Както знаете, механизмите за консенсус са в основата на почти всички децентрализирани мрежи, включително биткойн. Всъщност основната иновация на биткойн е може би консенсусният механизъм на блокчейна. Но винаги има компромис. При биткойн и други блокчейни това е механизмът за обработка на разделянията, което означава, че две версии могат да съществуват дълго време (на теория завинаги) и трябва да бъдат разрешени чрез PoW, което е ахилесовата пета на биткойн.
Затова, ние се стремим да избягваме консенсусните алгоритми (както обикновено се разбират), когато е възможно - мравките използват ли ги? Но има някои случаи, когато при компютърните мрежи те вероятно са необходими. Това е, което Мостафа проучва и върху което ще се задълбочим през следващите седмици.
Общ напредък
В момента обновяваме процеса на CI машината, за да бъде малко по-икономичен и по-сигурен. Това до голяма степен е в ръцете на @chriso и той работи, за да постави всички елементи на място, включително API, EC2 инстанции, функции без сървър и DDoS защита. Вече почти е готово.
Работим върху премахването на възможно най-много блокировки за четене/запис по време на репликация на данни. Това е предимно работа на @joshuef. Джош и @bochaco също до голяма степен завършиха преструктурирането на sn_node, за да въведат отново двупосочни комуникации в кода. Това е нещо, което имахме преди, но стана много сложно. Опростяването на кодовата база означава, че можем да я върнем обратно. Все още се тества, но вече виждаме подобрения в стабилността.
@roland премахва функцията traceroute. Причинява раздуване, не се оказа полезна (и още по-малко с двупосочни потоци), така че се отърваваме от нея.
Механизми за консенсус
Има много механизми за консенсус в компютърните науки. Някои са прости двоични афери, други са сложни многовариантни механизми. Важното е обаче да разберете, че всички те са само инструменти за работа и нищо повече. Тази задача осигурява споразумение между субектите за определен период от време. Но точно както хората трябва да се споразумеят за определени правила, за да се разбират, като например от коя страна на пътя да шофират, не е нужно да се съгласяват за всичко, за да живеят един до друг. За разлика от блоковите вериги, хората не се нуждаят от подреждане в цялата система, нито пък Safe се нуждае от такова подреждане. Така че трябва да изберем правилния инструмент за работата, да го правим само когато е необходимо и, което е важно, да се уверим, че не сме притиснати от този избор.
Safe е асинхронна децентрализирана мрежа. Нещата се променят през цялото време; „състояние“, което означава моментна снимка на текущото разбиране, което имаме за света, почти винаги е различно от гледна точка на всеки отделен възел. И все пак поне за кратко време тези възли трябва да постигнат съгласуваност.
Консенсус е основно дума, която казва, че в даден момент всеки, който има значение, трябва да види същото състояние, за да се случи дадено действие.
И така, как възлите постигат съгласие относно състоянието? Е, това зависи от обстоятелствата, действието и обхвата.
Често в Safe мрежата можем да постигнем съгласие чрез анти-ентропия (AE). Това е прост обмен на информация, за да сме сигурни, че разговаряме с настоящите Старейшини в дадена секция. Като такъв, AE може да се разглежда като прост, двоичен, локален механизъм за консенсус, въпреки че ние просто мислим за него като за проверка дали страните, които трябва да бъдат синхронизирани, са на една и съща страница. Разбира се, това е далеч от пълния ред в биткойн блокчейна обхващащ цялата система.
Когато Старейшините формират споразумение относно курс на действие, ние използваме генериране на разпределен ключ (DKG), за да гарантираме, че голямо мнозинство от Старейшините са съгласни. Това също е вид локален, бинарен (да/не) консенсус, въпреки че не сме склонни да използваме тази дума.
След това имаме репликирани типове данни без конфликти (CRDT), които използваме за променливи данни. Те имат логически часовник, позволяват паралелен достъп и в крайна сметка разрешават разклоненията до едно състояние. Всичко това се случва без консенсус. Форковете са допустими и се саморазрешават.
Но има и други ситуации, в които не можем да толерираме разклонение, дори за наносекунда, и това е мястото, където като асинхронна децентрализирана мрежа определено се нуждаем от консенсус.
И има сиви зони, в които можем да толерираме разклонения за определено време, но в крайна сметка трябва да ги разрешим. Те може да се нуждаят от формален консенсусен механизъм.
И така, къде мравките могат да имат нужда от техническа помощ? Единият е набирането на нови възли от списък от може би стотици кандидати, всички с възраст на възела нула - кой да изберем? Тук може да се наложи да разчитаме на по-висок интелект, който групата може да предостави.
Друг е Членството - управление на това кои възли са в дадена Секция. DKG е тъп инструмент и не се справя много добре с крайни случаи като множество едновременни присъединявания и напускания.
И може да се нуждаем от по-високо ниво на консенсус, за да управляваме DBC в различните секции, за да предотвратим двойно харчене.
Това е, върху което екипът - особено Мостафа и @davidrusu - са фокусирани в момента: прилагане на правилния протокол на точното място в точното време. Още по темата скоро!
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България