Всички в екипа ни се съгласихме, че тази седмица ще бъде подходящ момент да разгледаме какво предлага Safe по отношение на разпределения консенсус. Всъщност няколко от нас смятаха, че това е глупава идея, но свръхмнозинството гласува да продължи напред и това е всичко, което има значение 
(бел.п. това е шега препратка към начина, по който Старейшините в Секция постигат консенсус чрез свръхмнозинство). И така, тази седмица обясняваме как Safe преодолява пропастта между блокчейн и протоколите, които са в основата на разпределените бази данни като Cassandra и AWS DynamoDB.
Общ напредък
@ChrisO изпълни задачата за непрекъснато публикуване за sn и sn_api в хранилището на safe_network. Това означава, че сме отново на място, където можем свободно да обединяваме нови версии и да сме уверени в последващата версия. Това освобождава @chrisO да премине към разглеждане на CLI-то и стабилизирането му, преди да го включи в следващите версии.
Дейвид Русу направи демонстрация на пръстеновите подписите и Safe. Очаквайте скоро новини за това (предупреждение: ще има „тежка математиката“). 
@qi_ma , @yogesh и @lionel.faber преработиха DKG контейнера и safe_network (нашият основен текущ източник на главоболие, тъй като повишенията на Старейшини спират преди да са достигнали седем), за да намалят броя на съобщенията за излъчване и да се увеличи стабилността на стартиране и разделяне на секцията. Работата там продължава, но определено стигаме до основните проблеми.
Имаше и известна работа по разрешаването на приоритизирането на обработката на съобщения за възлите, въпреки че все още се преценява как да се въведе. То трябва да ни помогне да гарантираме, че по-големите промени се обработват по-внимателно от по-малко важните съобщения. Блокирането на съобщения с нисък приоритет неволно присъстваше в не толкова едновременната кодова база, но беше загубено след като освободихме възлите да ползват повече CPU. Надяваме се, че това ще върне малко ред в операциите на възлите.
Разпределен консенсус и как Safe проправя пътя
Ядрото на Safe мрежата и това, което я прави уникално полезна за голямо разнообразие от цели, е как тя постига съгласие между разпределени възли, които може да са ненадеждни.
През 80-те години се смяташе, че децентрализираното споразумение без позоваване на централен оракул е невъзможно, но след това дойде Лесли Лампорт, за да докаже, че всички грешат. Всъщност той се опитваше да докаже, че е невъзможно да има последователност и толерантност към грешки в децентрализирана мрежа, но след това се натъкна на отговор, който се изявява в повишаване на временните лидери и осигуряване на ред на операциите в цялата система.
Полученият алгоритъм беше наречен Paxos, за който Лампорт в крайна сметка спечели наградата Тюринг. Paxos гарантира евентуална последователност в разпределена мрежа, където някои машини може да са ненадеждни. Това означава, че мрежите могат да избегнат една точка на отказ – всеки възел, дори лидер, може да отпадне и системата ще продължи да работи.
Paxos се оказа изключително успешен и породи стотици имитатори и варианти. Използва се предимно за надеждно репликиране на данни между разпределени машини и е основа за облачни бази данни като AWS DynamoDB и Google Chubby.
Той прави това, като се опитва да създаде общ ред на операциите. Има два етапа в операцията на Paxos – обещание и ангажиране. Обещанието е споразумение да се направи нещо, а ангажиментът е действието по извършването му. Повечето възли трябва да се съгласят, преди да обещаят да променят състоянието или да променят разрешенията. Мнозинство също е необходимо, за да се премине от обещание към ангажимент, например запис или промяна на собствеността.
Тъй като разпределените мрежи са асинхронни, редът се поддържа, като на всяка операция се дава числов идентификатор и идентификаторите се увеличават с течение на времето. В случай на конфликт при обещание, най-новият (най-висок ID) обикновено печели.
В Paxos винаги има водещ възел. В случай на заявка, лидерът добавя всяка операция към своя дневник и моли другите сървъри да направят същото. След като получи отговор от повечето сървъри в своя клъстер, той извършва промяната.
Нов лидер се избира, когато настоящият не отговори в рамките на определено време. Когато това се случи, всеки възел може да се издигне до лидер. За да стане лидер, нов кандидат трябва да получи мнозинството от гласовете. След това трябва да актуализира своите регистрационни файлове чрез синхронизиране с други възли. Възлите за гласуване изпращат своите регистрационни файлове със своите гласове, за да улеснят това, но все пак може да отнеме много време за актуализиране, през което време клъстерът е неактивен, което може да бъде проблематично.
Raft (2014), който е базиран на Paxos (или по-точно Multi-Paxos, актуализираната версия) опростява процеса на гласуване и други операции, но по същество е модификация на Paxos. Рафт вече изпревари Паксос по отношение на проектната дейност.
Дотук добре, но въпреки че Paxos/Raft са елегантни решения за разпределения консенсус, тяхното прилагане изисква много екстри, ако трябва да работят както се очаква.
Cloudflare е базиран на Raft и през 2020 г. претърпя голямо прекъсване поради процеса на избор на лидер, който премина в безкраен цикъл. За да се гарантира жизненост, са необходими и оптимизации PreVote и CheckQuorum, както и още много други. Вече не е толкова просто да се постига консенсус.
Разширяването на функционалността на Paxos и Raft и други варианти ги прави сложни, което в технологичната индустрия означава, че стават собственост. Ако само Amazon знае как надеждно да настрои DynamoDB, Amazon няма да разкрие тази тайна набързо.
Но основният недостатък на тези алгоритми е тяхното предположение, че възлите не работят завдно, лъжат или по друг начин се опитват да подкопаят протокола, т.е. не се случват византийски атаки. Ако сте Amazon, може да сте в състояние да гарантирате това, тъй като контролирате собствения си хардуер и софтуер, но за смесени обществени мрежи, няма начин да го гарантирате. Ето защо не чувате много за Paxos в крипто света, въпреки че той е в основата на технологияните Голиати.
Нека влезе Сатоши
Византийските отказоустойчиви (BFT), децентрализираните алгоритми са доминирани от блокчейн, който реши този труден проблем благодарение на гения на Сатоши. Блокчейновете са силно подредени и BFT. Но общият ред е от съществено значение и това блокира или забавя множествения достъп и паралелността. Блокчейновете не са системи с общо предназначение, а такива, предназначени специално за обмен на стойност. Блокчейновете не могат да заменят Paxos и неговите производни, защото са оптимизирани за сигурност и споделяне на транзакции, а не за операции с данни.
Отръпни се Сатоши, Safe мрежата е тук
Safe мрежата е различна. Тя преодолява празнината между вечното съхраняване на транзакциите в блокчейн и разпределеното управление на данни на Paxos и Raft.
Данните се съхраняват завинаги без тежък PoW (доказателство за работа).
Няма общ лидер за атака, дори временен (както е при PoW победителя в блокчейн). Вместо това отчетността се разпределя между супермнозинствата в секциите и те се състоят от постоянно променящи се (но съгласувани) групи.
Също така имаме и въпроса за толерантността към грешки. Paxos и Raft използват концепцията за отказоустойчивост (CFT). Но публичните мрежи изискват византийска отказоустойчивост. Разликата изглежда незначителна, но не е. Толерантността на откази при срив обхваща колко възли могат да се повредят между осъществяването на поддръжката, докато византийската отказоустойчивост е колко възли могат да се повредят във всеки един момент от време. CFT е изчислим, BFT не е.
Safe мрежата е BFT и е проектирана да бъде готова за реални условия, при които нещата се провалят и недоброжелатели дебнат отвсякъде. Възрастта на възлите гарантира, че византийските възли са бързо обезвредени. За разлика от тях, Paxos/Raft са лесно атакувани чрез избирането на лидер, който не отговаря или отговаря твърде бързо. Те също така разчитат до известна степен на часовниците на сървърите, за да управляват консенсуса. Те изглеждат прости (както и Kademlia мрежите), но се нуждаят от много предварителни условия, за да работят, включително надежден хардуер и софтуер, без NAT обход и т.н.
Safe мрежата е напълно децентрализирана. AE, BRB и CRDT премахват изискването за мрежово споразумение за постигане на последователност и няма нужда от пълен ред. Дори Amazon признава, че за големите разпределени системи играта е евентуална последователност, а не пълен ред (скоростта на светлината е твърдо ограничение). Опитът да се постигне пълен ред в огромен мащаб неизбежно води до ниска производителност.
И така, Safe прехвърля множество граници: Неизбежен силен паралелизъм в публична мрежа, BFT с общо предназначение и вечно съхранение на данни.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България