Честита Нова Година на всички 
Страхотно е да се завърнем - решени сме да почнем силно новата година 
Всички екипи успяха да изкарат малко време в почивка и нямат търпение да почнат работа. През почивката също поправяхме няколко неща и обмисляхме някои възможни подобрения, включително оптималния размер на възлите и секциите и промени във възрастта на възела и преместването. За първото от тях тествахме с вътрешни тестови мрежи с по-малки възли и по-големи секции. Те вървят доста добре и разкриха един или два други проблема, свързани с комуникациите и предаването, по които работим. Второто е оптимизация на дизайна, която ще третира по-младите възли по различен начин от по-старите. Повече подробности за това през следващите няколко седмици.
Общ напредък
Прекъсването на рутината може да бъде чудесно време да помислим какво може да се направи по-добре и да завържем свободните краища. Ето обобщение на това, което екипът направи след последните новини.
Разделяне на общообхватното съобщение NodeMsg::Propose на четири различни варианта за яснота.
RequestHandover: когато възлите завършат DKG и поискат предаване към текущите Старейшини (възел->Старейшина)
SectionHandoverPromotion: когато Старейшините кажат на тези възли, че са повишени до Старейшини (Старейшина->възел)
SectionSplitPromotion: когато Старейшините казват на тези възли, че са повишени до Старейшини от двете страни на разделянето (Старейшина->възел)
ProposeSectionState: когато Старейшините решат да изхвърлят възли или да приемат нови възли в рамките на раздел (Старейшина->Старейшина)
Това разграничение прави ясно кой подписва и кой получава/обединява подписите.
Премахване на ненужни съобщения
Ние поправихме скъп проблем, при който AE съобщенията многократно проверяваха SectionTree за всяко съобщение, дори когато то вече беше потвърдено.
Оптимизиране на AE
Експериментирахме със забавяне на AE сондирането около разделянията, за да намалим броя на преминаващите съобщения, а също така преработихме познанията за всичките секции в мрежата, за да се насочи към един случаен Старейшина в три произволни Секции на всеки пет минути. Преди това по подразбиране насочвахме всички Старейшини в три секции на всеки 30 секунди. Това доведе до значително намалено използване на процесора и паметта около разделянията и по-дългото време би трябвало да е достатъчно за нашите нужди: в крайна сметка разделянията не се случват на всеки 30 секунди.
Високо използване на памет при изчакване за присъединяване
Проверихме грешка, която причинява високо използване на паметта във възли, докато чакат да се присъединят, както се вижда в скорошните тестови мрежи. Скоро ще бъдем готови да изпробваме това в тестова мрежа на общността. Също така предотвратихме кеширането на сесии за свързване на неприсъединени възли.
Преструктуриране на комуникациите
Грозно заключване в кода за send-streams в sn_node беше преработено. В допълнение, тестваме съобщения за „щастлив път“, чрез които клиентите могат да изпратят съобщение само до един Старейшина, а не до всички тях.
Също така премахнахме кода за проследяване на възли и свързаните заключвания, които бяха потенциални точки на повреда. Виждахме много съобщения като следствие от неуспешни промени в нивото на изпращане/съхранение, които блокираха възлите.
Промени в параметрите за съхранение
Добавен е марж към капацитета за съхранение, при което очакваме минимален обем за съхранение, но възлите могат да съхраняват повече. Това трябва да помогне за облекчаване на грешките „не може да се съхранява“, преди разделяне. Също така настроихме Старейшините да съхраняват данни (преди не съхранява) и да използват техния локален минимален капацитет за съхранение като индикатор кога да се разделят, както се обсъжда във форума.
С това сега имаме следния поток:
- Възлите получават данни.
- Всеки път, когато преминем определено ниво на използвано съхранение на данни (за първи път), позволяваме на нови възли да се присъединят.
2.1 Когато възел поиска да се присъедини, виждаме, че присъединяванията са разрешени и Старейшините започват гласуване за добавяне на възела. - Когато се присъедини нов възел, присъединяванията се деактивират, проверяваме дали сме достигнали
min_capacity
3.1. Не сме достигналиmin_capacity, продължете както обикновено.
3.2. Достигнахмеmin_capacity, почистете излишното хранилище.
3.3 Ако все още сме на или надmin_capacity, задействайте устойчивостта на отказallow_joins_until_split.
3.4. Когато възел поиска да се присъедини, виждаме, че присъединяванията са разрешени и Старейшините започват гласуване за добавяне на възела. - Ново свързващият се възел облекчава натоварването за съхранение на данни.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България