Safe Network новини 🇧🇬 11.2.2021

Накратко

  • Тестовата мрежа все още е на пауза, тъй като работим за завършване на преструктурирането на потока от съобщения, който блокират напредъка на разпределянето на наградите.
  • Работата по преструкторирането на потока от съобщения отбелязва добър напредък, като е налице проект за PR. Това ще доведе до по-чист, опростен и по-ефективен поток от съобщения.
  • Мигрирахме внедряването на тедтовата мрежа/премахването на скриптове към terraform, което доведе до драстично подобрение във времето, необходимо за създаване на тестова мрежа от всякакъв размер за вътрешно тестване/външно внедряване.
  • Докато чакаме внедряването на наградите открихме и премахнахме някои грешки, които иначе биха останали скрити.
  • В CLI-то е внедрена нова подкоманда $ safe networks set, която ще позволи на потребителите да се свързват по-лесно с мрежите, като просто използват техния IP адрес и порт за зареждане, съответния PR преминава през преглед сега.
  • Вярваме, че намерихме решение за разклоняването на веригата от секции в sn_routing. Понастоящем това решение се прилага и вярваме, че ще помогне да направим тестовите мрежи достатъчно стабилни, за да ги представим пред общността.
  • Принос към програмния код продължава да идва от общността! :heartbeat:

Състояние на тестовата мрежа - отложена

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

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

Все още очакваме да пуснем тестова мрежа възможно най-скоро, като фокусът се измести отново върху възнаграждаването. Потенциално ще направим още малко тестове, като използваме работата ни „без награди“, за да видим дали ще можем да открием още някой друг проблем.

Подготовка на тестовата мрежа и тестове

В края на миналата седмица се опитвахме да стартираме големи тестови мрежи и бързо стана ясно, че нашият скрипт за това не върши добра работа - отнема 30 минути, за да стартира 20 възела и адски повече за стартиране на 100 възли! За да се справим с този проблем мигрирахме към terraform за управление на стартирането / унищожаването на виртуални машини и възли и с него е много по-добре. Вече можем да стартираме 40 каквито и да е възели за няколко минути. Използвахме това доста интензивно за тестовете и го настроихме, така че да ни позволи да стартираме и персонализираме компилации на възли. Което се оказа много удобно по отношение на тестовете. PR за това преминаване към terraform е на място и е доста щателно тестван, с малко оставаща работа, предвидени преди обединяването.

На един етап през седмицата сравнително редовно виждахме вътрешните тестови мрежи да опитват разделяне и да се провалят. Започнахме да търсим грешки за отстраняване с по-малки по размер секции (например 3 старейшини, в секция с 5 възела), за да задействаме повече разделения, но това не помогна. Оказа се, че не виждаме разделяния, тъй като нашият код изисква Старейшините да местят секциите, но това всъщност не се изисква (за момента). Както при всички вероятни неща, дори тези невероятни събития изглеждаха доста често … и се случваше така, че всички наши старейшини попадаха в едната половина на секцията и така формираха нова секция за себе си, без да е необходима промяна на ключовете, и кода ни не се задействаше.

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

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

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

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

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

QP2P

През последната седмица тествахме новото qp2p API с всички наши контейнери. Първоначално имаше някои проблеми, но всички вече са разрешени и сме на последния етап на преглед и обединяване. Ще включим тези промени по време на цялостното тестване и те ще бъдат част от следващото издание на тестовата мрежа.

Съобщения

Наскоро преместихме натрупването на съобщения само в sn_routing, като преди това го правехме и в sn_node. За да завършим това преструктуриране променихме много код, но също така премахнахме около 1350 реда.
Резултатът е по-опростен, по-чист и по-ефективен поток от съобщения.

Понастоящем се работи по това, като проект за PR проследява напредъка. Това ще ни помогне да продължим напред с потоците на съобщенията като цяло, но също много важно и с възнагражденията, които бяха задържани малко от тези обновления.

API и CLI

Технически дълг, който имахме в sn_api контейнера, беше да направим характеристиката на типа “Грешка” да приложи “std::error::Error”. Това е нещо, което завършихме и обединихме през изминалата седмица с помощта на thiserror контейнер. Променихме и CLI кодовата база, за да използваме anyhow, така че всички функции сега връщат anyhow::Result и обработката на грешки е много по-лесна, без загуба на информация или контекст за основната причина за всяка от разпространените грешки.

В CLI-то е внедрена нова подкоманда $ safe networks set, която ще позволи на потребителите да се свързват по-лесно с мрежи, като просто използват IP адрес за зареждане:порт за начален адрес. Съответният PR включва актуализация на Ръководството за потребителя, така че за всеки, който се интересува от ранните отзиви за тази команда, моля, погледнете описанието тук.

Приносът от общността продължаваше да идва и през изминалата седмица. Има усилие в процес на работа от @bzee, за да направи пакета nodejs съвместим с последната версия на sn_api, както и поправка в CLI за премахване на име на флаг, което причинява конфликт между две различни команди ([поправка: премахване на кратка опция, използвана за тест от b-zee · Заявка за изтегляне # 708 · maidsafe / sn_api · GitHub] (https://github.com/maidsafe/sn_api/pull/708)). PR също беше издигнат и обединен, за да се премахне реализацията на събирането на логове от sn_client, тъй като това трябва да бъде оставено на приложенията или изпълнимите файлове, които използват библиотеката, уверявайки се, че приложенията не получават неочакван изход на stdout или stderr.

Тъй като по-голямата част от зависимостите на нашите хранилища използват tiny-keccak v2.0.2, @mav изпрати PR, за да актуализира всички наши хранилища, за да зависят от същата версия. Много ценим усилията на всеки, който се включи по какъвто и да е начин :clap:

BRB: Византийско надеждно излъчване

Извършихме допълнителна работа върху brb_node_qp2p, за да работи с двупосочни потоци и новия (излизащ скоро) qp2p API. Това позволява на всеки възел да изпраща и получава от един и същи порт, вместо да отваря нови връзки през отделен произволен порт за изходящи пакети. В процеса допринесохме няколко малки PR за qp2p. Един по-конкретно улеснява споделянето на „qp2p“ крайна точка между нишките, което би трябвало да е плюс за всеки, който изгражда p2p прогряма с библиотеката.

sn_data_types

Подготвихме дизайн за опростяване на логиката на политиката / разрешенията, регулиращи достъпа до мрежови данни, който в момента преминава през вътрешен преглед. Имаме и PoC за нов Chain CRDT, който може да се окаже по-добър CRDT за нашия Sequence тип данни , това дойде от проблемът, който @mav повдигнат относно Sequence типа данни .

Маршрутизиране

План на проекта

Тази седмица изследвахме обещаващ подход за справяне с разделяния на мрежата. В обобщение: имаме нещо, наречено „верижна секция“, която представлява списък с ключове на секции, свързани заедно с подписи. Може да се използва, за да се докаже, че част от данните са подписани от група възли, които някога са били валидни членове на секция, дори след като тези възли отдавна са изчезнали. Понастоящем тази верига изисква разделът да се съгласи кой ключ да се добави към него по-нататък. Ако има разногласия по това, веригата може да се раздели на две (или повече) взаимно несъвместими вериги, които биха могли в момента да разделят секцията. Това може да се случи, например, по време на интензивен отлив от възли. Надявахме се, че ще можем да отложим справянето с този проблем за още малко, т.е. докато тестовата мрежа не излезе, но се оказва, че понякога виждаме разделяния дори в относително малки тестови мрежи.

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

Преводи:

:uk: Английски; :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/