Safe Network новини 🇧🇬 11.3.2021

Накратко

  • След извършихме няколко незначителни преструктурирания и поправки, сега сме в състояние да актуализираме всичките ни Rust хранилища до Tokio v1.
  • Преразгледахме sn_routing тази седмица, за да променим начина, по който се постига консенсус, така че сега се изисква свръхмажоритарност (повече от 2/3) вместо обикновено мнозинство (повече от 1/2). Вярваме, че това е необходимо, за да се направи мрежата устойчива на определени типове атаки.
  • Решихме да приложим Lazy Messaging в sn_node, като работата вече е в ход. Първоначално това беше планирано за след публичния тест, но сметнахме, че си струва да го предвижим напред.
  • @jimcollinson започна тема в Reddit - “Питай ме всичко”, както и тук във форума миналата седмица - все още има време да зададете и вашите въпроси!
  • @jimcollinson създаде първия видеоотговор, от това, което смятаме, че ще бъде цяла поредица в YouTube, за по-големите въпроси, получени от общността - можете да го гледате тук. :movie_camera:
  • @dimitar работи зад кулисите, за да помогне за повишаване на информираността за Safe мрежата в Индия с рекламна кампания във Facebook и Twitter. :heart:
  • Следете редовно “Харесайте този туит” темата във форума за някои отлични насоки за това как да помогнете за популяризирането на Safe мрежата и околните компоненти, с едно щракване на мишката! :bird:

Safe клиент, възли и qp2p

Safe Network трансфери план на проекта
Safe клиент план на проекта
Safe Network възли план на проекта

Миналата седмица дългоочаквана версия на Quinn най-накрая пристигна с важен ъпгрейд: Tokio v1. Досега използването на по-стара версия на Tokio в Quinn ни пречеше да актуализираме всичките ни хранилища до Tokio v1 поради несъвместими версии по време на изпълнение, така че сме в процес на надграждане на всички наши хранилища до Tokio v1. С някои незначителни преструктурирания и поправки успяхме да преминем успешно всички тестове с новата версия на Токио. Тази актуализация също ни помогна да идентифицираме неоткрит по-рано проблем, който оставяше потоците отворени, което в крайна сметка водеше до забавяне на мрежовите комуникации след достигане на горната граница. Екипът на Quinn бързо ни съдейства и проблемът вече е отстранен в qp2p. Връзките в sn_routing отново работят безупречно! Очакваме всички наши хранилища да бъдат актуализирани през следващите няколко дни.

Тази седмица също добавихме още примери към qp2p контейнера, за да демонстрираме по-добре използването на API-то и за да тестваме под стрес qp2p както локално така и в Digital Ocean.

В sn_routing тази седмица решихме да променим начина, по който се постига споразумение, така че сега да се изисква супер мнозинство (повече от 2/3) вместо обикновено мнозинство (повече от 1/2). Това беше необходимо, за да се направи мрежата устойчива на определени видове атаки. Също така увеличихме броя на старейшините в секция от 5 на 7, което означава, че секция все още може да загуби до двама старейшини и да продължи да функционира. Тези промени в момента са в процес на преглед и тестване и очакваме скоро да бъдат обединени.

Тъй като трябва да активираме мързеливите съобщения (вижте подраздела по-долу), разглеждахме как най-добре да постигнем това в sn_node. Възможно е да успеем да намалим някои малки части от това, но разглеждаме и възможността за по-голямо преструктуриране тук, за да опростим нещата. Изглежда, че с премахване на част от кода на “sn_node” (по същество премахването на “Duties”) и с директното анализиране на съобщенията, ще се окажем с нещо, което можем да проверяваме съвсем лесно, като същевременно вероятно ще премахнем _ много_ от комплексността в “sn_node”. Първоначалните усилия в тази област бяха доста положителни. Надяваме се, че това няма да е толкова голяма задача, тъй като основната логика трябва да остане същата, но независимо от това ще подходим към него успоредно с по-леки решения, така че се надяваме да не блокираме нищо.

sn_node Мързеливи съобщения

Мързеливите съобщения в sn_node работят, като леко увеличаваме размера на съобщенията, изпратени между възлите, така че те да включват допълнителна информация за текущото състояние на мрежата, както се виждат от различни наблюдатели в пространството и времето. Алтернативата на този подход би била непрекъснатото запитване за промени - твърдо вярваме, че цената на допълнителните данни на съобщение е повече от компенсирана с намаляването на общия трафик в сравнение с постоянното запитване. Със запитването, дори когато мрежата преминава през тих период, запитването ще трябва да продължи усилено във фонов режим. Други възможни подходи за спиране / пауза на части от мрежата, за да се постигне съгласие, имат много странични ефекти и сложен код, следователно не са ни полезни.

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

Мързеливите съобщения са внедрени в sn_routing от известно време, което се оказва ефективно и надеждно. В sn_node се сблъскахме с някои предизвикателства през последните няколко седмици, опитвайки се да актуализираме възлите с най-новите промени в състоянието на мрежата (след разделяне, покачване на отговорностите, понижение и т.н.). Например, когато дадена секция се раздели, се сблъскваме с предизвикателства, при предаването на необходимата информация на новите старейшини от старейшините на старата секция, като същевременно се справяме с типичния очакван трафик и мрежови събития.

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

Както споменахме, това е допълнителна работа, за която не предполагахме, че ще е необходима преди тест мрежата, но не я смятаме за толкова голяма, че да забави тестовата мрежа твърде значително. И това е още един елемент, отбелязан като завършен в нашия списък със задачи по пътя към бета и стартиране.

CRDT

Започна работа по ограничен тип брояч, който ще ни позволи да ограничим операции върху типовете данни. Това е ценен компонент, който позволява непрекъснато да се увеличават изменяемите данни, като същевременно ги ограничава в отделения. Това означава, че можем да платим за качване на типа данни, след което свободно да го добавяме до ограничена точка, като в този момент потребителят ще плати отново и ще освободи друг набор от оперативно пространство. Разделянето на данни за обработка по този начин разпределя товара в мрежата. Това е оптимизация, но е важна и необходима за стартирането, но не и за Fleming. Хубаво е да видим тези подобрения от сега.

Също така правим промени в Sequence типа данни, тъй като мигрираме, за да използваме новия CRDT MerkleReg, който ще ни позволи да съхраняваме цялата история на добавянията, заедно с разрешаване на разклонения на данни, ако крайният потребител или приложение ги генерира целенасочено, или случайно. Това оказва влияние върху начина, по който нашият API ще бъде представен на крайния потребител, тъй като в зависимост от случая на употреба може да има разклонения / клонове на добавяния, които потребителят може да иска не само да премине, но и да разреши. Следователно, работим по коригиране на нашия API от страна на клиента, за да представим всички възможности на потребителя, без да го усложняваме и без да премахваме гъвкавостта и мощта, която този нов CRDT тип данни внася за програмите и разработчиците.

Общност и маркетинг

@jimcollinson започна тема с въпроси в Reddit и тук във форума, миналата седмица.

Първоначалната цел беше да се съберат редица сочни въпроси и да им се отговори в YouTube. Получи се отлично видео, като отговорите на много въпроси се оказаха доста по-подробни, отколкото може да се включи в едно видео. И така, ето първият видео отговор от това, което вероятно ще се превърне в серия от видеа:

Моля, харесвайте го, споделете го, включете се в обсъждането и се насладете по какъвто начин намерите за добре. И не се колебайте да продължите с въпросите.

Преводи:

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


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