Safe Network новини 🇧🇬 20.1.2022

Ключова област на фокус ни в момента е членството, как Старейшините следят Възрастните и другите Старейшини в тяхната секция, така че да могат да се справят с нови присъединявания, разделяния, изхвърляне и повишения. Тази функционалност се намира в хранилището sn_membership. Алгоритмите в това хранилище в момента са подложени на строги тестове, преди да бъдат интегрирани в мрежата. Това не е нова функция като такава, а по-скоро строго затягане на това, което имахме досега, и формализиране на алгоритмите. По-голямата част от екипа ни в момента работи върху някои аспекти на членството.

Общ напредък

Хранилището sn_membership се обработва от @davidrusu. Почти всичките ни тестове минават сега, така че извършваме основно подреждане.

@bochaco разглежда потоците в членството: какъв е редът на събитията, когато се присъедини нов възел или най-възрастният Възрастен бъде повишен?

Един аспект, обхванат от управлението на членството, е предаването на информация към Стерейшините, което уверява, че наскоро повишените Старейшини имат цялата правилна информация, ключове и т.н. @anselme работи върху това и то е почти готово за работа.

Отделно от членството, @chriso подкара безпроблемно тестовете и след като завърши документацията за CLI, започна да пише тази за NRS.

По отношение на данните, @yogesh е фокусиран върху тестването на репликацията на данни, а @joshuef актуализира qp2p до най-новата версия на quinn.

Междувременно @danda се включва в DBC. Интегрирането на Ring CT е почти направено и монетните дворове са следващата стъпка, въпреки че е необходима още работа, за да накараме монетите да работят правилно с Ring CT-вете.

@happybeing направи прекрасен малък PR актуализиране на логовете на възлите. Това ще помогне за спестяване на място на всички стартирани възли и да направи логовете по-лесни за следване с команди като tail -f.

Членство

Операциите за членство обхващат присъединяване на нови възли към секциите, управление на капацитета, изхвърляне на неправилно работещите възли или намаляване на възрастта им, повишаване на Възрастните до сСтарейшини и гарантиране, че новите Старейшини имат достоверна информация.

Напомняме, че секциите имат седем Старейшини и (освен ако бъдещите тестове не показват друго) 60 - 100 възрастни. Възрастните се изхвърлят често, като нови се присъединяват, а стари се местят от други секции . Старейшините трябва да следят членството в секцията, за да знаят кога да позволят на нови Възрастни да се присъединят, както и кога Старейшините се местят и Възрастни се повишеват. Те запазват списък с всички настоящи Възрастни и Старейшини в своята секция.

Членството в секции е ограничено от максималния размер на секцията. Когато имаме такива ограничения в разпределена система, често трябва да прибягваме до консенсус, за да вземем решение между конкуриращи се опции. В нашия случай на членство, Старейшините трябва да решат кои от (многото) възли, които чакат да се присъединят към секцията, трябва да бъдат допуснати.

До този момент не използвахме алгоритъм за консенсус, затова текущите процеси за управление на членството понякога се препъваха, когато възникнат неочаквани събития.

Новото хранилище sn_membership осигурява консенсусен алгоритъм BFT без лидер, осигуряващ добра производителност в евентуален синхронен мрежов модел. След безмилостен режим на тестване, той вече е готов за интегриране в мрежата.

sn_membership работи заедно с антиентропията (AE) и генерирането на разпределен ключ (DKG) за управление на членството в секцията. Ето някои потоци.

Присъединяване на възел

Присъединяващият се възел взаимодейства със Старейшина, обменяйки съобщения JoinRequests, докато не бъде временно приет и получи предизвикателството за доказване на ресурси и го върне към Старейшина.

При старата система, след като премине теста, възелът щеше да бъде допуснат, но това беше риск за сигурността и можеше да причини блокиране (вижте по-долу). Сега Старейшината изпраща предложение за добавяне на възела с помощта на протокола sn_membership до другите Старейшини на секцията. Sn_membership завършва, след като имаме Супер-мнозинство над супер-мнозинство, тоест супер-мнозинство от старейшините виждат, че супер-мнозинството от старейшините са приели това предложение. След като sn_membership стартира, то е гарантирано да завърши (доколкото нашето предположение за евентуално синхронна мрежа не е нарушено).

След като предложението постигне консенсус между Старейшините, Старейшината изпраща обратно одобрението на присъединителния възел.

Повишаване на Възрастен и предаване към Старейшина

Ако Старейшина забележи, че настоящите Старейшини не са седемте най-стари възли, това предизвиква гласуване за повишаване на най-възрастния(ите) и понижаване на най-младите старейшини, за да се проправи път.

Алгоритъмът на предаване към Старейшина, контролиращ този процес, който вече е готов да бъде интегриран в хранилището sn_membership, е както следва.

Един Старейшина получава свръхмнозинство от завършените дялове на DKG, за да провери, че настоящите Старейшини са най-възрастните седем члена.

Старейшината предлага нов набор от Старейшини.

Старейшините следват консенсус в стил „sn_membership“, за да вземат решение за едно съобщение „NewElders“. Тази стъпка е необходима, когато имаме сложна верига от събития, които завършват с множество групи възли, които се състезават, за да завършат DKG и да станат следващите Старейшини.

Списък с текущи членове на секция се предава на новия Старейшина, доставчикът на права на секция (SAP) се актуализира и към веригата на секциите се добавя нов блок.

Ролята на консенсуса

Така че защо е необходим консенсус за членство, когато други части на мрежата разчитат на AE, за да бъдат актуализирани?

Ето един пример. Да кажем, че една секция е почти пълна. Ограничението за размера на секцията е 50 възела (само за пример) и в момента има 49 членове. Нов възел изпраща JoinRequest до Старейшина. При система без консенсус Старейшината проверява капацитета и вижда, че има капацитет, обменя AE съобщения и при условие, че новият възел премине теста Resource Proof, бива приет в секцията.

Но на този етап секцията е готова за разделяне, което, когато множество възли се опитват да се присъединят, може да доведе до противоречиви приоритети:

Да кажем, че в краен случай всичките седем Старейшини получават JoinRequests едновременно от седем различни възела. Всичките седем Старейшини виждат, че има място за още един възел и тъй като всеки от седемте възела е преминал своите тестове за доказване на ресурси, всеки Старейшина ще позволи на новия възел да се присъедини към секцията.

Но след активиране на антиентропията между Старейшините, те откриват, че техните колеги Старейшини няма да приемат новите възли на другия, тъй като това би надхвърлило капацитета на секцията над границата. Старейшините се оказват в ситуация с разделен мозък, при която всеки Старейшина има различен поглед върху членството в секцията.

За да не се случи този проблем, Старейшините постигат консенсус за това кои възли ще бъдат допуснати. Със sn_consensus всеки от седемте Старейшини може да предложи до една промяна. Това означава, че до седем промени (присъединяване/напускане) могат да бъдат решени в един кръг.

В гореописания случай, sn_membership ще означава допълнителна работа в сравнение със Старейшини, които действат самостоятелно, но тази допълнителна работа е видима само когато имаме много конкурентни избори. sn_membership грациозно намалява до вВизантийско Надеждно Излъчване (BRB), когато Старейшините са общо взето съгласни относно действията, които трябва да предприемат, ние плащаме консенсусните разходи само когато Старейшините започнат да имат разногласия. sn_membership е мирен метод за разрешаване на разногласия :slight_smile:


Преводи:

:uk: English :ru: Russian ; :de: German ; :es: Spanish ; :fr: French

  • Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Redirecting...