Български (Bulgarian) 🇧🇬 Добре дошли в Safe Forum

Safe Network новини - 26.11.2020

Накратко

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

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

След като миналата седмица добавихме Sequence CRDT операции за подписване, тази седмица интегрирахме това в купчината, с някои промени в sn_node тук и sn_client тук и тук, за да получите всички операции, подписани преди да бъдат предадени в мрежата. Това извади наяве някои други проблеми по отношение на локалното кеширане на последователности (кога да се използва локален кеш и кога да се използва мрежата и т.н.). Засега сме решили да премахнем този кеш чрез този PR за простота. Това помогна за укрепване на тестовия пакет, като ни позволи да видим по-ясно някои потоци от тип CRDT в действие, например, изпращането на промени не се изтегля веднага от мрежата, така че трябва да изчакаме очаквани промени там.

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

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

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

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

Също така започнахме да подготвяме authd и CLI за адаптиране към новата UI / UX терминология, например преминахме от “Акаунти” към “Сейфове”, както и да правим необходимите промени, за да може authd да съхранява ‘ключовите двойки’ на програмите в мрежата, използвайки Map като тип данни за съхранение за “Сейфа”. Ще продължим с тази задача, за да приведем всички CLI команди и функции за удостоверяване в съответствие с тези нови терминологии, както и с новия API на sn_client.

След като приключим с горните актуализации, поправки и всякакви грешки, които изкочат, ще бъдем готови да запалим нашите вътрешни тестови мрежи отново с пълна газ, да подредим различните модули, да проверим отново стабилността им, да завържем свободните краища и да се надяваме да доставим ранен коледен подарък на всички вас! :wink:

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

Тази седмица нашият консултант усъвършенства идеята за Часовник за генериране, спомената миналата седмица, и представи алгоритъм за псевдокод на екипа за коментар. Този хибриден подход налага пълен ред за редки операции за присъединяване и напускане, но само частичен ред за много по-чести операции с данни. На обикновен език това означава, че присъединяването/напускането трябва да бъде ограничено (т.е. не можем да позволим да съществуват неотговарящи възли) и да се използва форма на пълен ред, но можем да обработваме много листа наведнъж и т.н., докато могат да се появят редовни операции с данни с високи нива на съвпадение, стига всяко да е от различен източник (Актьор на CRDT език). Засега предложението изглежда солидно и следващата стъпка е да го внедрим в код и да напишем някои тестове. Повече за това следващата седмица.

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

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

Както беше обсъдено предишните седмици, работата за подобряване на откриването на загубени възли беше одобрена и обединена тази седмица. Това се възползва от функцията за обединяване на връзки в qp2p. Тази промяна означава, че основата на кода за маршрутизация е опростена и сега позволява да се добавят по-сложни интеграционни тестове, за да се проверят характеристиките на готовия код.

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

По време на тестването забелязахме проблем, при който по време на първоначалното стартиране, когато съобщението NodeApproval е последвано незабавно от друго съобщение, например Relocate, стартирането завършва след обработката на NodeApproval. Това оставя всяко следващо съобщение, като Преместване, в буфера на междинния канал и никога няма да бъде извадено и обработено, т.е. загубвахме това съобщение. Обединихме поправящ го PR Отстраняване на загубени съобщения по време на първоначално стартиране, за да разрешим този проблем. Той премахва междинния канал, заменяйки го с обикновена обвивка около приемника ConnectionEvent. По този начин моделът “push/ pull” се променя в обикновен модел “pull”. По този начин съобщението никога не се извлича от канала, ако не е готово да се обработи.

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

Safe Network програма и UX

Проследяване на функции / Екрани и потоци / Включен прототип

Благодарим за всички ваши отзиви за предложените промени в лексикона на Safe. Започнахме да добавяме тези промени в UX потоците и прототипите на Safe Network програмата и ще ги видите да се появяват в различните файлове на Figma, докато работим върху тях.

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

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

Изглеждаше така:

Но можем ли да направим процеса по-гладък? Можем ли да го направим по-малко плашещ и да помогнем на потребителя бързо да стартира своя Safe, без никаква външна помощ, и след това да го накараме да следва печеленето на Safe Network Tokens за стартиране.

Ето малък прототип на новия подход - само с една опция напред - колкото да ви даде представа за процеса:

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

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

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

Преводи:

:uk: Английски; :ru: Руски; :de: Немски; :es: Испански; :fr: Френски;


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

Safe Network новини - 3.12.2020

Накратко

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

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

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

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

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

Друга особеност, по която работихме тази седмица, е регулирането на съхранението в секция и в крайна сметка в мрежата чрез PR # 1153. От този PR възлите за съхранение на данни следят тяхното съхранение при всяко записване, което извършват, като предупреждават старейшините в секциите, ако достигнат максималния си капацитет. След това старейшините поддържат регистър на тези запълнени възли и когато достигнат определен праг на запълване в същата секция, ще гласуват за приемане на нови възли, които да се присъединят към тяхната секция, спирайки достъпа, след като е изпълнено търсенето / предлагането, като по този начин се поддържа баланс в мрежата. През следващите дни ще извършим различни оптимизации на показателите.

Повдигнат е PR за Rust-CRDT, за да се приведе LSeq в съответствие с други типове CRDT, които се нуждаят от apply, за да бъдат извикани преди модифициране на самия тип данни. Използваме това в Sequence типа данни, за да гарантираме, че всички операции са подписани.

Продължихме с промените в sn_api и CLI през изминалата седмица, като ги адаптирахме към новите sn_client API-та, и както беше споменато миналата седмица, също се опитваме да ги мигрираме към новите UX термини. В момента повечето от тестовете sn_api преминават, използвайки локална секция, и сега се опитваме да финализираме тези промени, както и да разрешим неуспешните тестове, което би трябвало да означава, че CLI командите и E2E тестовете ще стартират отново.

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

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

Продължава работата по Generation Clock подхода към динамичното членство. Работещ прототип на кода се очаква до края на седмицата.

Като паралелна задача bft-crdts контейнера се разделя на отделни контейнери в усилие за модулиране. Идеята е да се дефинират 3 линии: една за внедряване на BRB, една за типовете данни, които трябва да бъдат предадени и защитени, и една за мрежовия слой.

По този начин изпълненията и на трите линии могат да бъдат смесени и съчетани. Например, можем да използваме използваната памет в мрежата за тестови случаи, qp2p impl за маршрутизиране в Safe Network и трета страна може да използва внедряване на TCP / IP сокети за нещо друго. От страна на данните вече имаме внедряване на AT2 банка и внедряване на CRDT orswot.

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

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

Както бе споменато по-горе, sn_node беше публикуван и пуснат за първи път в сегашния си вид тази седмица. За да не изостане маршрутизиращият екип вече също пусна и публикува sn_routing, първото издание от почти 2,5 години насам! Вижте списъка с промените за да придобиете представа за направените промени. Както при sn_node, тези издания не означават, че разработката на sn_routing е приключила, а просто сметнахме, че е достатъчно стабилна, за да обединим вече създадения преди това механизъм за непрекъсната доставка PR. Разработката продължава с добро темпо и сега всеки обединен PR ще доведе до допълнително автоматично генерирано ново издание.

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

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

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

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

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

Преводи:

:uk: Английски; :ru: Руски; :de: Немски; :es: Испански; :fr: Френски;


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

Safe Network новини - 10.12.2020

Накратко

  • sn_client v0.44.0 получи първото си обновление от юли месец насам.
  • Завършихме въвеждането на дублирането на Blob парчетата, когато Възрастен напусне мрежата - нова версия sn_node v0.25.9.
  • Консултантът ни представи завършен, тестван и работещ алгоритъм за динамично членство.

Обобщение

Накратко за напредъкът ни към предстоящата тестова мрежа.

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

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

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

Тази седмица се появи първата версия и обновление на sn_client от юли месец насам. Това хранилище преди това се състоеше от различни контейнери под името Safe Клиентски библиотеки, но тъй като редовните читатели тук несъмнено знаят, извършихме доста голямо преструктуриране, което доведе до премахването на хиляди редове код, който според нас беше неефективен, пълен с грешки или ненужен. Вече има един единствен контейнер sn_client, пуснат под това име за първи път. Той се присъединява към новите значими версии на sn_node и sn_routing пуснати през последните 2 седмици, което се надяваме да покажем напредъка, който постигаме, когато основните парчета на мрежата започват да застават по мястата си. Тази версия не означава, че сме приключили със sn_client, а просто означава, че го считаме за достатъчно стабилен за да въведем конвейер за непрекъсната доставка. Разработката продължава с добро темпо и сега всеки обединен PR ще доведе до допълнително автоматично генерирано ново издание.

Тази седмица се опитваме да проследим източника на проблем с препълване на стека, който се появи в sn_node. Първоначално изглеждаше, че няма конкретен източник и използването на стека просто нараства с времето. Първоначално това се случваше само в Windows, където открихме, че размерът на стека по подразбиране е 1 мегабайт, което е ниско в сравнение с Ubuntu, който има 8 MB. Намаляването на размера на стека в Ubuntu ни позволи да повторим това, което е добре. Така че продължаваме да разследваме това и да търсим начини да го предотвратим.

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

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

Добри новини! Нашият консултант създаде работещ алгоритъм за динамично членство. Това е оригинална разработка, която използва Generation Clock с една операция за присъединяване или напускане, разрешена за един актьор, за едно завъртане на часовника. Този алгоритъм вече е написан в код заедно с тестов пакет и всички тестове преминават.

Следващата стъпка ще бъде интегрирането му със съществуващата реализация на DSB. Така че в крайна сметка ще имаме протокол за договаряне на динамично членство, който е различен, но допълва DSB протокола за BFT предаване на редовни операции / данни.

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

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

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

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

Преводи:

:uk: Английски; :ru: Руски; :de: Немски; :es: Испански; :fr: Френски;


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

Safe Network новини - 17.12.2020

Тестова мрежа

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

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

Как да стартирате локална тестова мрежа на своята машина?

Ще можете да създадете Safe в тази мрежа, да влезете, да качите данни, да създадете ключове и портфейли и всички други команди, описани в Ръководство за потребителя на CLI. Това ръководство ще ви преведе през стартиране на локална секция, но разбира се може да се приложи за стартиране / свързване към която и да е споделена секция, споделена от всеки, с няколко промени според гореспоменатото ръководство за потребителя.

Първо, изтеглете най-новия инсталационен файл за CLI чрез нашия скрипт за инсталиране.

След това трябва да актуализирате своя Удостоверяващ демон и Възел до най-новите днешни версии. Можете да направите следното:

$ safe auth install
$ safe node install

Вече можем да стартираме мрежа, използвайки:

$ safe node run-baby-fleming

Това ще стартира 8 възли на вашия компютър: 5 възрастни и 3 старейшини.

Можем също да добавим допълнителни възли към мрежата, това се постига с помощта на safe node join, както следва.

Имайте предвид, че може да се наложи да зададете променливата на RUST_LOG средата, преди да стартирате вашия възел, за да предотвратите записването на твърде много информация в логовете.

## за Linux и Mac OS
$ export RUST_LOG=safe=trace
## Windows (команден ред)
$ set RUST_LOG=trace
## Windows (powershell)
$ $env:RUST_LOG="safe=trace"

И след това стартирайте възела с:

$ safe node join
Storing nodes' generated data at /Users/maidsafe/.safe/node/local-node
Starting a node to join a Safe network...
Launching with node executable from: /Users/maidsafe/.safe/node/sn_node
Node started with hardcoded contact(s): ["127.0.0.1:12000"]
Launching node...
Node logs are being stored at: /Users/maidsafe/.safe/node/local-node/sn_node.log

Сега вашият възел ще се стартира и ще се опита да се свърже с вашата локална мрежа. Можете да следите напредъка му в логовете, които можете да намерите в
~/.safe/node/local-node/sn_node.log.

Преди да преминете през останалите CLI команди не забравяйте да удостоверите и създадете своя Safe.

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

Известен проблем

В тази версия има известен проблем, по който все още работим, за да го отстраним. Първият път, когато упълномощавате приложението CLI с authd, като използвате командата $ safe auth unlock --self-auth (моля вижте този раздел от Ръководството за потребителя за повече информация за тази команда), може да получите грешка при опит за качване на файл или запис на данни в мрежата, например тази грешка може да бъде върната:

[2020-12-17T20:21:06Z ERROR safe] sn_cli error: [Error] NetDataError - Failed to store Public Sequence data: Data error -> Unexpected error: Could not get history for key PublicKey::Ed25519(d802d5..) - ClientError::DataError -> Unexpected("Could not get history for key PublicKey::Ed25519(d802d5..)")

В такъв сценарий, моля, продължете напред и изпълнете отново същата команда, за да отключите ‘Safe’-а отново, и след това опитайте отново с запис на данни в мрежата.

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

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

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

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

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

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

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

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

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

Работата тази седмица се фокусира върху интегрирането на новия динамичен код за членство със съществуващото детерминирано изпълнение на защитено излъчване. Тази интеграция вече работи. По-нататъшна работа се извършва, за да се направи кода готов за използване, например малко преструктуриране, за да се премахнат всички заявки за unwrap() и panic().

Преводи:

:uk: Английски; :ru: Руски; :de: Немски; :es: Испански; :fr: Френски;


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

Safe Network новини - 7.1.2021

Накратко

  • Честита Нова Година! :fireworks:
  • Радваме се да съобщим, че работата по динамичното членство е завършена и днес публикувахме няколко контейнера на Византийско надеждно излъчване (BRB) в GitHub :tada:. Всички са свързани от централния brb контейнер.
  • Работихме усилено, дори през празниците, за да подобрим слоя за грешки и съобщения, включително създавайки нов контейнер „sn_messaging“.
  • Ние сме в процес на подготовка на някои незначителни корекции за нова CLI версия.
  • Също така сме близо до създаването на CLI и authd с musl, което означава съвместимост с по-голям набор от платформи.
  • Имаме нов инструмент за стрес тестване за маршрутизирането с PR в процес на проверка. Този нов инструмент е създаден, за да открие ограниченията на маршрутизацията по отношение на начина, по който се справя с промените в членството (разделяне) и вече ни показа някои проблеми.

Относно тестовата мрежа

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

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

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

Работим за подобряване на историята ни за грешки в библиотеки ни и преминахме към използването на thiserror в node / data_types / client / transfer за осигуряване на по-добра верига за грешки и по-голяма капсулация на функционалността. По-рано използвахме много смесени грешки, изтегляйки много от sn_data_types в други библиотеки. Сега имаме специфични грешки във всяка библиотека, за тази библиотека, и разпространяваме грешки само от долните библиотеки като друга версия на грешките на текущата библиотека.

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

Като част от тези усилия изследваме различни типове сериализация, като крайната цел е да има такъв, който е агностик на езика за програмиране. В момента се фокусираме върху проста JSON сериализация (за разлика от използвания в момента bincode), но също така си играем с Msgpack.

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

В тандем премахнахме „предизвикателствата“ на клиента от първоначалното свързване на възела / клиента. По-рано те се използваха за проверка, че клиентът държи ключове, за да се предотвратят атаки за повторно възпроизвеждане на съобщения. Но с idempotency, идващ от типовете данни AT2 и CRDT, това ще бъде обработено там. Това води до още по-голямо опростяване както за клиента, така и за възела и допълнително изяснява мрежовите операции само като подписани съобщения.

Преди време, за да предотвратим атаки за продажба на ключове в мрежата, премахнахме всички API-та за показвване на SecretKey от sn_routing и ги съхранявахме само в техния контейнер. Установихме обаче, че има многобройни усложнения в дървото на зависимостите, причинени от това премахване, и затова решихме да върнем тези API-та, за да ни позволят да продължим бързо с тестовата мрежа по време на празниците. Решихме да се справим с този проблем веднага и започнахме да преструкторираме контейнерите „sn_transfers“ и „sn_node“, където държим и използваме тези SecretKeys извън „sn_routing“.

Обобщената работа по събиране на подписите, извършвана от sn_node по време на обмен на съобщения между KeySection и DataSection, вероятно се дублира с работата по натрупване на консенсус при маршрутизацията, тъй като и двете всъщност се извършват от по-старите възли. Проучваме и извършваме известна работа по преструктуриране, опитвайки се да премахнем тази част от контейнера sn_node и да се доверим на консенсусните съобщения от sn_routing.

И в последно работим за премахване на stream от потока от възлите. Това беше въведено за поддържане на комуникации с клиенти, но с последните промени на „qp2p“ можем да разчитаме на обединяване на връзките там, което ще ни свърши работа, и така премахваме много сложност от клиентската обработка на възела. Също така сме в процес на преструктуриране на qp2p примерите в отделни части, за да демонстрираме echo_service и системите за съобщения ясно и отчетливо. Правим пробни пускове с тези примери с ръчно пренасочване на портове към потенциално поддържани рутери, несъвместими с IGD в следващи тестови мрежи.

API и CLI

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

Също така се опитваме да изградим следващото издание на CLI и authd с musl, което, както знаем, ще ни позволи да стартираме тези приложения на много повече платформи, използвайки същите версии на CLI-то. Вече успяхме да ги изградим ръчно (благодарим много на @mav и @tfa за техните забележки и принос към това), така че сега се стремим да ги включим в нашия CI през следващите дни.

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

Радваме се да съобщим, че работата по динамичното членство е завършена и днес публикувахме няколко контейнера на Византийско надеждно излъчване (BRB) в GitHub :tada:. Всички са свързани с централния brb контейнер.

BRB системата се състои от:

  1. Основният BRB протокол за излъчване за членове на кворум за копиране на данни по BFT начин.
  2. Протоколът за динамично членство за възли за динамично присъединяване и излизане от активен кворум.
  3. Опаковки от тип данни, които капсулират съвместими типове данни (напр. CRDT) за прехвърляне чрез BRB.
  4. Изчерпателни тестове за проверка на коректността.
  5. brb_node_qp2p: примерно CLI приложение / възел за ръчно извикване на BRB функционалност.

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

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

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

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

Предприета е и промяна на API-то за подаване на информация от секция за конкретно име на участник. Това главно се използва в “sn_node” за бъдеща работа по преструктуриране.

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

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


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

Safe Network новини - 14.1.2021

Накратко

  • Продължаваме да преместваме всички дефиниции на клиентските съобщения и логиката на сериализацията към новия контейнер sn_messaging.
  • Работата по премахването на управлението на „потока“ във възлите, както беше споменато в актуализацията от миналата седмица, е завършена и обединена
  • Продължихме да решаваме проблемите, подчертани от новия ни инструмент за стрес тестване на маршрутизацията.
  • Голямо благодаря към двама членове на общността за PR-ите тази седмица - @mav и @tfa се включиха с множество PR-и в различни хранилища, за да помогнат и подобрят нашата работа. Винаги е вдъхновяващо да получим помощ :heartbeat:
  • Все още работим по тестването и финалното отстраняване на грешки, което се надяваме да означава, че ще можем да пуснем следващата версия на тестовата мрежа скоро.

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

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

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

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

Работата продължи с разпределените преходи на актьори при смяна на старейшина, т.е. прехвърляне на парите в секцията към нов старейшима. Малка грешка, възпрепятстваща прехода (поради неуспешна проверка на подписите) отне известно време, за да се изкорени, но току-що беше намерена. Остават да бъдат тествани следващите стъпки в прехода.

И накрая, напредваме с актуализирането на клиента / възела, за да премахнем клиентските предизвикателства и да активираме отново правилното включване на клиенти, след като работата по премахване на управлението на потока от възлите, както беше споменато в актуализацията от миналата седмица, беше завършена и обединена. Това от своя страна разкри някои потенциални проблеми при получаването или разбора на клиентски съобщения, така че се работим по тях.

API и CLI

Тази седмица успяхме да генерираме успешно „musl“ компилации за CLI и authd в нашия CI и затова всичко е настроено и готово за следващото ни издание. Това означава, че както CLI, така и authd приложенията трябва да са съвместими с която и да е Linux платформа без допълнителни настройки, ще ни е необходима помощ от общността, която да ни помогне да проверим дали това всъщност е така, като го изпробвате на толкова много различни Linux платформи колкото е възможно. Ще пуснем новите версии своевременно.

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

Работата продължи и тази седмица за допълнително полиране на BRB контейнерите. Приложният програмен интерфейс (API) на DataType е променен, така че подробностите за грешка при проверка могат да бъдат върнати на повикващия. В тази връзка и rust-crdt контейнера беше подобрен, така че всеки тип CRDT, който използваме сега, има validate () метод, който може да бъде извикан преди прилагане на операция. За всеки BRB контейнер са направени заявки за изтегляне за CI / CD (Непрекъсната интеграция и Непрекъснато внедряване и доставка). Имаме още няколко промени, които трябва да завършим тази седмица, след което планираме да пуснем първото издание към crates.io.

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

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

Миналата седмица споменахме как инструментът за стрес тест разкри някои скрити проблеми при маршрутизирането. Тази седмица се заехме да ги издирим и поправим. Един от проблемите беше, че членове на дадена секция, които не са Старейшини не разбират, че се е случило разделение на секцията поради грешка в начина на създаване на „Sync“ съобщенията. Това беше поправено и обединено. В момента работим по още един PR, който решава още няколко от тези проблеми. Останалите проблеми след това вероятно са свързани с начина, по който се справяме с промените в членството в секциите. Надяваме се да ги разрешим чрез интегриране на новия BRB алгоритъм за членство, който също беше споменат миналата седмица. Тази работа ще започне възможно най-скоро следващата седмица, ако всичко върви добре.

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

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French

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

Safe Network новини - 21.1.2021

Накратко

  • Намерихме и обединихме заобиколно решение за проблем с „изоставането“, който се опитваше да остане нерешен.
  • Публикувахме PR проект за разпределяне на наградите, който е близо до завършване.
  • Някои неработещи тестове на клиентската мрежа, които ни пречиха да напреднем с тестването на корекцията за проблема със съобщенията „KeySection“ и „DataSection“ (последният проблем, блокиращ публична мрежа за тестове), вече са разрешени и тестването ще бъде възобновено.
  • Обединихме PR-те на CI / CD във всеки от BRB контейнерите ни, което доведе до автоматизирано покритие на тестовете, създаването на версии и първите ни издания на BRB контейнери в crates.io.
  • @JimCollinson предоставя поредната завладяваща актуализация за напредъка на Safe Network програмата и потребителското изживяване.

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

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

Решаване на проблеми със закъснението

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

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

Изглежда, че една проста промяна на времето за изчакване на възела (намалявайки го от 30 сек. на ~ 5 сек … в момента експериментираме, за да намерим оптимални числа) ще доведе до достатъчно деблокиране на възлите, за да можем отново да стартираме тестове на клиентите. Така че, докато проверяваме, за да видим дали има проблем в пула за свързване на qp2p и преструктурираме sn_node до известна степен, сега можем да продължим напред, като тестваме всичко още веднъж.

Разпределяне на наградите

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

Преходът от първия (генезис) възел, както и тестовете за това са завършени и потвърдени, сега работим върху следващите преходи.

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

KeySection и DataSection проблем със съобщенията

В новините от миналата седмица споменахме, че проучваме премахването на възможната дублирана работа извършвана по съвкупното събиране на подписи от “sn_node” по време на обмен на съобщения между “KeySection” и “DataSection”. За тази цел има подготвен WIP PR за натрупване за премахване на подписи. Този PR преминава тестовете на sn_node и продължаваме със sn_client мрежови тестове, за да извършим допълнителна проверка. Въпреки това, поради друга работа по преструктуриране в sn_node и sn_client, извършвана паралелно, sn_client мрежовите тестове са нарушени по други причини, така че работата по проверката трябва да бъде задържана за кратко.

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

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

API и CLI

След въвеждането на sn_messaging контейнера, където вече са дефинирани всички типове клиентски съобщения, работихме върху извършването на необходимите промени в sn_api и CLI, за да бъде всичко съвместимо отново с sn_node и sn_routing съобщенията. Това вече е завършено и всички промени са обединени в основните клонове на всички тези контейнери. Също така постигнахме известен напредък в опитите да преместим дефинициите на sn_routing съобщението в sn_messaging контейнера, въпреки че това все още е текуща задача с по-нисък приоритет от повечето други неща, по които работим.

Също така обединихме някои API подобрения, направени от @Scorch, в контейнера qjsonrpc, което прави параметрите на пътя общи. Затова бихме искали да му благодарим за приноса. :raised_hands:

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

Вторник отбеляза още един важен момент, когато обединихме PR-те за CI / CD, което доведе до автоматизирано покритие на тестовете, създаване на версии и първите ни публикации на brb контейнери в crates.io.

Основно подобрение, което влезе в тази версия, е поддръжката за обикновенни типове актьори чрез rust черти. Това означава, че кодът вече е достатъчно гъвкав, за да поддържа повечето / всеки криптографски алгоритъм или библиотека с публичен ключ, без допълнителни промени в основните библиотеки. Поддръжката за ed25519 вече е включена, но ще разгледаме и добавянето на BLS поддръжка. Дори хардуерни устройства за подписване ще могат да бъдат добавени в бъдеще.

Допълнителните подобрения включват:

  • CLI-то на brb_node_qp2p има някои корекции при екранно извеждане и нова команда за повторен опит в случай на изпуснати пакети.
  • съхраняване на логове. Всички println повиквания са променени към подходящи функции за съхранение на логове.

Работа в процес на осъществяване:

  • тестовите случаи се подобряват, за да показват резултати и да се премахнат всички заявки, които връщат panic() грешки
  • добавят се коментари в документацията, за да се направи кодът по-използваем от други разработчици

И накрая, още няколко страхотни новини! Нашият CRDT специалист и големите мозъци зад brb контейнерите се съгласиха да удължат договора си с още 3 месеца, за да съдействат за по-нататъшната работа по интеграция. :tada:

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

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

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

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

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

Safe Network програма и потребителско изживяване

Проследяване на функции / Екрани и потоци

Ако си спомните в новините за потребителското изживяване от ноември миналата година ви проведохме чрез предложените промени на лексикона на Safe Network, въвеждайки нова метафора за Safe заменяща Акаунт, токени заменящи Safecoin, и отхвърляне използването на термина Трезор (Vault).

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

Ако влезете във Figma файла показващ Safe Network програмата, ще ги видите в действие, заедно с някои други подобрения.

Това е доста голям файл със стотици различни екрани и потоци, така че не винаги е лесно да се разбере всичко, което се случва. Ето няколко акцента:

Отключване на Safe Ви

Тук виждаме въвеждането на Safe метафората за данните на потребителя - заключването и отключването му - с някои визуални сигнали, които се надяваме да го подсилят.

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

Работа с токените

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

Печелене на токени

С отпадането на термина Трезор, тук може да видите на практика как можем да използваме глагол като Печелене за да стартирате предлагането на ресурси на мрежата в замяна на Safe Network токени.

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

Няколко стъпки за конфигуриране на нещата и започваме.

Менюто за действия

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

Вече е достъпно горе вляво на приложението и тук можете да го видите както в заключено, така и в отключено състояние.

Едно малко напомняне за това как командите също могат да се търсят и стартират. Удобно.

Чувствайте се поканени да разгледате Figma файла, за да видите всички подробности, с множество отделни потоци, проучени и документирани.

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French

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

Safe Network новини - 27.1.2021

Накратко

  • Днес е Денят за поверителност на данните (известен също като Денят за защита на данните в някои части на света). Ние насърчаваме всички в общността ни, както и всички, свързани с други проекти с подобни цели, да се стремят по-силно от всякога да постигнат това. Всеки ден всички се приближаваме с една крачка по-близо. :raise_hands:
  • PR за наградите сега преминава през допълнителна проверка и тестване - добива на нови монети е много близо!
  • Най-накрая открихме и поправихме проблема с увисващите връзки, който ни се опъваше от няколко седмици.
  • Търсенето на проблема с висящите връзки подчерта някои възможни области за подобрение и опростявабе на процеса, ако нещо подобно се покачи отново и затова работим по актуализиране на qp2p и опростяване на неговото API.
  • С този PR вече обединен, CLI-тп вече е в състояние да проверява баланса на собствения си SafeKey.
  • Публикувахме нови версии на sn_authd (v0.0.15), CLI (v0.17.2) и sn_node (v0.25.39), като CLI и authd вече са изградени с помощта на MUSL за Linux.

Без публичен тест за момента…

Днес бяхме на ръба, докато сериозно обмисляхме дали да продължим да поправяме съобщенията, наградите и някои подобрения в qp2p (всички описани по-подробно по-долу) или да публикуваме публична тестова мрежа с всичко, което имаме досега. Решихме, че правилното решение е да продължим с поправянето и подобренията, при които така или иначе сме по средата, и затова задържаме публичната тестова мрежа за както смятаме още само няколко дни. Преценихме, че ще има твърде много отвличане на вниманието на екипа при настройването и поддържането на тестовата мрежа, плюс кода „може“ да е по-малко стабилен и по-труден при отстраняването на грешки, отколкото бихме искали, ако липсват корекциите и подобренията за съобщенията и qp2p. Забавяне също ни дава шанс да завършим и да включим подробно описания по-долу добив на нови монети монети :wink: във всяка публична тестова мрежа.

Работим за поправяне/подобряване на всичко и това работи добре за целеустремеността на екипа, така че забавянето на публичния тест засега с още няколко дни за подреждане на някои части ни изглежда правилно. Има някои страхотни подобрения на кода с участие на общността и всичко помага, чувства се определено движение в правилната посока.

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

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

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

Награди

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

С това на място вече стигнахме до въвеждането на изплащанията на наградите. PR черновата е преобразувана в завършен PR и се тества от P.O.V. клиент преди да обединим тази работа в главния клон след като тестовете преминат.
След това ще продължим с завършването на изплащането на наградите, като в този момент функцията за фермерство е горе-долу готова за включване в тестовата мрежа.

PR-и от общността

Тази седмица обединихме няколко PR-а, @mav изпрати един PR, който добавя някои липсващи функционалности към клиента, и още едно подобряване на ефективността на извикване на sequence.in_range.

Увисване на връзката

Продължихме да отстраняваме грешки във връзките и през изминалата седмица и най-накрая намерихме основната причина за проблема. Qp2p погрешно изпускаше връзки, които връщаха грешка. В този случай грешката беше валидна и не изискваше прекъсване на връзката. С обединяването на тази корекция вече не виждаме дълги изчаквания поради изгубени връзки, което е страхотно усещане :relieved:. Носи се слух, че @joshuef е имал коса преди да възникне тази грешка!

Главният възел / клиент е много по-стабилен сега. Търсим някои появяващи се от време на време грешки, възникващи като част от съхраняването на пакети, където изглежда не успяваме да съхраним пакет и / или метаданни, свързани с него.

Опростено qp2p API

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

API и CLI

Sn_api хранилището е видя много активност от членовете на общността тази седмица, което е отлична новина, особено защото тези приложения се използват от всички потребители и следователно колкото повече принос получаваме от реални крайни потребители, толкова повече можем да ги подобрим, дори по-добре, ако подобренията са действителен код!

@anon57419684 работи по нова функция за въвеждане на команда reset в CLI, която може да ни позволи да изчистим всички данни и конфигурационни файлове, които приложенията CLI, sn_authd и sn_node съхраняват локално, запазвайки действителните програмни файлове недокоснати. Всеки, който се интересува от това да ни помогне, моля да се присъедини към дискусиите и прегледа на кода тук: WIP: feat(cli): implements 'safe reset' subcommand - #6 by bochaco - Core Libraries - Safe Dev Forum.

Някои подобрения, подадени от @mav в нашето API също са обединени, имаше някои грешки в съобщенията за грешки, които са коригирани, като е добавена и проверка при NRS имената за отхвърляне на наклонени знаци.

Някои примерни qjsonrpc приложения се разработват от @scorch (https://github.com/maidsafe/sn_api/pull/690), което ще помогне на потребителите да разберат как може да се използва qjsonrpc API-то и как приложения, нуждаещи се от JSON-RPC над QUIC протокола могат да бъде създадени. Информация за контекста на това е много добре описана в тази публикация за всеки, който се интересува да разбере повече за това.

С този PR, вече обединен, CLI-то е в състояние да проверява и баланса на собствения си SafeKey, т.е. с authd, което CLI използва за плащане на разходите за цялата операция, извършена от / с него. По този начин, чрез извикване на “$ safe ключове баланс”, без да предоставя своя таен ключ, сега по подразбиране проверява текущия баланс на CLI ключа / SafeKey.

Публикувани са нови версии на sn_authd (v0.0.15), CLI (v0.17.2) и sn_node (v0.25.39) за тези, които ги използват локално. Тъй като CLI и authd инсталационните файлове вече са изградени с помощта на MUSL за Linux платформи, ако сте на Linux моля, уверете се, че сте ги инсталирали, вместо да се опитвате да ги актуализирате с помощта на CLI, можете да намерите пълни инструкции за инсталирането им в CLI ръководството за потребителя.

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

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

Имаше доста дискусии за дизайна около интегрирането на BLS Distributed Key Generation (DKG) в BRB. Надеждата беше, че DKG ще може да се върне обратно към динамичните операции за членство (присъединяване / напускане) на BRB. В крайна сметка обаче установихме, че това не работи, тъй като DKG изисква 100% участие и трябва да се проведе като отделен процес след създаването на групата за гласуване на BRB.

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

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

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

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

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

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


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

Safe Network новини - 4.2.2021

Накратко

  • Днешното така очаквано пускане на тестова мрежа трябва да бъде отложено, тъй като не успяхме да въведем получаването на награди навреме, а да го деактивираме от наличния код не помогна.
  • Възможността да видим разделянето на секции в мрежата през последните дни, с въвеждането на последните подобрения, ни позволи да намерим и смачкаме някои неизвестни досега многосекционни проблеми.
  • Работата за опростяване на qp2p API-то за вътрешно управление на връзките и потоците, и отнемането на част от натиска от потребителското API вече преминава през допълнителна проверка.
  • Повдигнат е BRB PR за отстраняване на случайни загуби на пакети, които пречат на BRB операциите, тестван е и се очаква да бъде обединен скоро.
  • Специални благодарности на членовете на общността @bzee, @mav и @scorch за усилията им през последната седмица и за обединяването на множество техни PR-и.

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

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

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

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

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

По-голямата част от времето ни тази седмица беше фокусирано върху тестовата мрежа, но ето обобщение на някои от другите неща, върху които работихме…

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

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

За начало тази седмица беше обединен PR от @bzee, който позволява програмно конфигуриране на възли. Добра работа! :raised_hands:

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

Освен това, отстраняваме грешки и различни проблеми с разделянето на секции сега, след като тази функционалност вече работи (макар и ограничено поради гореспоменатите проблеми), а уеб приложението на @mav node-logger се оказа чудесен инструмент за бързо разглеждане на потоците от съобщения предавани между различните възли и фокусиране на изходните данни от многосекционната мрежа в нещо малко по-четливо от човек.

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

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

API и CLI

През изминалата седмица получихме още няколко PR-а от общността, които бяха обединени и вече са част от нова CLI версия, публикувана днес (v0.18.0).

Благодарение на този PR, изпратен от @mav, валидирането на NRS вече изключва по-голям набор от знаци, които никога не биха имали някаква разумна цел за включване в кой да е URL адрес. Наличието на ограничение на общата дължина на URL адреса на NRS от 255 байта, при което всеки поддомейн не може да бъде по-голям от 63 байта, сега се налага с този PR .

Safe auth CLI командите сега дават приоритет на аргумента --config пред използването на променливи, това също вече е налице в новата версия благодарение на PR #700, също изпратено от @mav.

От страна на qjsonrpc PR #698, подаден от @Scorch се реализира основен клиент/сървър пример чрез използването на API-то на qjsonrpc. Клиентът на qjsonrpc изпраща съобщение ping до qjsonrpc сървър и той отговаря със съобщение ack. Този пример за програма просто и прецизно показва как qjsonrpc може да се използва за изграждане на всяка програма, използвайки JSON-RPC над QUIC. Има много повече дейности и проучвания, направени от @Scorch с още идеи около qjsonrpc - за тези, които се интересуват от повече подробности и / или искат да участват в това усилие, погледнете неговата тема във форума за разработчици. :clap:

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

Повдигнахме PR в brb_node_qp2p, за да коригираме случайна загуба на пакети, която пречеше на BRB операциите. Това прави възела стабилен, в случай че някой член на общността би искал да тества BRB в CLI среда. Основните инструкции за използване са тук (Имайте предвид, че трябва да изградите кода сами, поне засега).

Дискусиите за интегриране на BRB с BLS Генериране на разпределен ключ (Distributed Key Generation - DKG) продължиха с няколко възможни опции. Изглежда, че консенсуса се фокусира върху една от опциите. Подробности за тези планове трябва да бъдат публикувани в идните седмица след като започнем работата.

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

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

Направихме първата стъпка към преместването на всички дефиниции на съобщения от sn_routing в sn_messaging контейнера, където ще се намират не само дефинициите на съобщенията, но и всякаква логика, свързана със сериализацията им. Първоначалната версия на това, заедно с унифициран тип съобщения за клиенти и възли, свързващи се към секция, вече е налице в най-новите версии на sn_routing и sn_client. Следващата ни стъпка в това отношение е най-накрая да преместим всички дефиниции на типовете съобщения върху sn_messaging контейнера, което ще ни позволи да отделим действителната sn_routing логика от това, което би станало API-то на мрежата.

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


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

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 общност: SAFEnetwork България | Facebook
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България
2 Likes

Safe Network новини - 18.2.2021

Накратко

  • Добавен е нов набор от инфраструктурни съобщения, които sn_routing може да използва за по-добра обработка и връщане на грешки по време на разделянето на секциите.
  • Работата по обработката на невалидни SignatureShares от лоши актьори при трансфери започна, като сега изготвяме санкциите за тези лоши актьори.
  • Работата по обмена на съобщения е към своя завършек, което означава значително по-малко код и сложност за анализ на входящите съобщения в sn_node и разчистване на пътя за интегриране на възнагражденията.
  • Пуснати са нови версии на CLI-то (v0.19.0) и authd (v0.1.1), което ги прави съвместими с най-новия sn_node (v0.26.16), както и няколко други подобрения.
  • Първата примерна програма вече е налична в sn_api хранилището, демонстрираща как да качите файл в мрежата и след това да го достъпите, използвайки нейния XOR-URL адрес.
  • Направихме стъпки към интегриране на sn_fs и BRB, за да създадем P2P византийско-толерантен прототип на разпределена файлова система.
  • Модификациите на секционните вериги в sn_routing за справяне с форкове вече са на място, като тестовете ни показват голямо подобрение на стабилността на мрежата, особено при разделянията.
  • Още фантастични приноси на общността към кодовата база :heartbeat:

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

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

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

Благодарим ви за търпението!

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

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

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

За да се справим по-добре с проблемите при разделянето на секции, както и по време на отпадането на възли, добавихме нов набор от съобщения за инфраструктурата, които sn_routing може да използва за връщане на грешки като DKGINprocess, когато се опитваме да изпращаме съобщения на старейшини в такива ситуации. За да направят това, клиентите / възлите ще предоставят текущия PublicKey за секцията, доколкото той им е известно, и ще можем да предприемем действия, ако това е, например, неактуално. Тези промени са добавени в sn_messaging, sn_client и sn_routing и разглеждаме някои малки преструктурирания, за да опростим нещата с възлите.

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

Наказване на лоши актьори

Работата с невалидни споделяния на подписи от лоши участници в трансферите също е в процес на разработка. Досега ние одобрявахме прехвърляне, когато дяла от валидни гласове достигне „праг + 1“ успешно, игнорирайки всички невалидни гласове, които не са необходими за това обобщаване. Сега ще въведем наказателни механизми в мрежата, за да накажем съответно възлите след проверка. Започваме преструктурирането с sn_transfers, тъй като там се случват натрупванията за преводи на плащания и ще продължим с работа нагоре през слоевете.

Поток на съобщенията

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

Тъй като първоначалното свързване на клиентите сега се извършва в слоя sn_routing, тези примитиви на местоположението трябваше да бъдат разширени с клиентски вариант. В sn_routing беше внедрен регистър на свързани клиенти, заедно с предоставяне на публичен ключ и подпис върху адрес на сокет при първоначалното свързване на клиента. Сега има значително по-малко код и сложност за анализ на входящите съобщения в sn_node. Досега са премахнати общо около 1000 реда.

API и CLI

Новите версии на CLI (v0.19.0) и authd (v0.1.1) бяха пуснати тази седмица, което включва всички корекции, подобрения и нови функции, внедрени от предишната версия. Както обикновено, те могат да бъдат надстроени съответно с $ safe update и $ safe auth update. Тези приложения са съвместими с най-новата версия sn_node v0.26.16, така че за тези, които надграждат, също така не забравяйте да надстроите и sn_node програмата ($ safe node install или $ safe node update).

@scorch забеляза, че най-новата версия на clippy оплаква под Windows за CLI и authd codebase, и представи поправка за него. Това ни накара да подобрим clippy проверките в нашите CI скриптове, за да се изпълняват не само под Linux, но и под Windows, което трябва да предотврати повторното му подхлъзване.

С добавянето (от @mav) на ново API в CRDT Sequence типовете данни за извличане на запис, посочващ единичен индекс, а не диапазон, @mav сега промени нашия sn_api, за да се използва това ново API за извличане на определена версия на Sequence.

Няколко подобрения бяха направени и в този нов CLI (v0.19.0), който позволява на потребителя да настрои информацията за първоначално зареждане на мрежата чрез IP (v4 или v6) и номер на порт, за повече подробности за тази нова команда, моля, вижте в съответния раздел в Ръководството за потребителя на CLI.

За тези, които са любопитни да видят как се развива Rust API-то и как ще се изграждат приложения с него, вижте първата примерна програма вече налична в sn_api хранилището, което демонстрира как да качите файл в мрежата и след това да го изтеглите, използвайки неговия XOR-URL адрес. Надяваме се, че това ще вдъхнови други да създадат прости примерни програми за нашето Rust Safe API, да открият възможности за подобрения, когато започнем да ги използваме, както и да бъде добър ресурс за нови разработчици, желаещи да пишат Safe програми.

CRDT

Дейвид Русу, автор на rust-crdt, както и на нашата реализация на „BRB“, преглежда „LSeq“ кода, след като @mav съобщи за проблеми с него когато се изпълняват много въвеждания. Той замени внедряването на ID, базирано на оригиналната LSeq разработка, с рационално число от num хранилището. Това прави LSeq кода много по-опростен и също така води до по-добро (по-равномерно) разпределение, разрешавайки проблема и позволявайки вмъкване на произволен брой елементи. „LSeq“ също е преименуван на List. Искане за изтегляне.

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

Помните ли sn_fs, нашият прототип на файлова система, използваща дървесния CRDT? Е, тази седмица правихме стъпки към интегриране на sn_fs и BRB, за да създадем прототип на P2P разпределена файлова система, устойчива на византийски атаки, .

Първо отделихме brb_node_qp2p и създадохме brb_node_tree, което демонстрира изпращане на операции crdt_tree чрез brb. След това модифицирахме контейнера sn_fs и го превърнахме в библиотека. Съвсем наскоро създадохме brb_node_snfs контейнер, в който обединяваме всичко. Към днешна дата успяхме да свържем два (или повече) възела и да извършваме операции с директории като mkdir,rmdir. Операциите се отразяват в монтираната файлова система на всеки партньор. Операциите с файлове все още не работят, но трябва да са готови скоро.

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

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

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

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

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

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

[ДОПЪЛНЕНИЕ от 22 февруари] - Safe браузър

Нещо, което първоначално забравихме да добавим към тези новини :man_facepalming:

@bzee създаде PR, за да ускори sn_nodejs с най-новите промени в API-то, който е необходим за обновяване на Safe браузъра, за да бъде съвместим с останалата част от Safe мрежата отново. Той също така разглежда ограниченията на текущата библиотека и вижда възможности за подобряване на нещата!.

Благодарим ти @bzee! :tada: и извинения за това, че първоначално пропуснахме твоя принос.

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


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

Safe Network новини - 25.2.2021

Накратко

  • В петък, 26 февруари (утре) от 21:00 GMT, ще има виртуална среща на Safe общността. Пълни подробности тук.
  • Идентифицирането на грешки и премахването им продължава, заедно с няколко подобрения на ефективността, докато продължаваме и тази седмица със значителен напредък по пътя към публична тестова мрежа.
  • През седмицата бяха обединени някои значителни PR-а в sn_routing, по-специално PR # 2323, PR # 2328 и PR # 2336. Пълни подробности по-надолу.
  • Два допълнителни значими PR в sn_routing, # 2335 и # 2336, критични за стабилна тестова мрежа, вече са повдигнати и трябва да бъдат прегледани и обединени през следващите дни.
  • @scorch е подаде PR, за да (най-накрая!) разреши „този проблем“, където версиите на самия CLI и външните изпълними файлове като sn_node или sn_authd се объркват.
  • Вижте отличния анализ на @bzee тук, с който той се стреми да подобри и актуализира обвързванията към Node.js.

Виртуална среща на Safe общността: петък, 26 февруари от 21:00 GMT

Задвижваните от общността маркетингови усилия продължават благодарение на работата на @sotros25, @m3data, @piluso и други. Впечатляващи неуморни усилия от тяхна страна!

Имаше дискусии и стратегии във форума, както и малки zoom срещи през последните няколко седмици, включително тази, в която обсъждаме някои от пазарните проучвания на @sotros25 за свързани проекти.

Радваме се, че този петък ще имаме още една виртуална среща с отворена покана за участие на всички членове на общността.

Първите 45 минути от разговора ще бъдат за маркетинговата стратегия на общността. След това ще преминем към по-широка дискусия относно Safe мрежата. Целта е да се помогне за дефинирането на маркетинговата стратегия и също така да се използва съдържанието от тези дискусии като видео за изграждане на информираност и ангажираност.

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

Пълните подробности и връзката за присъединяване ще бъдат достъпни тук.

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

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

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

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

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

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

Като задача с по-нисък приоритет и успоредно с горното, започнахме да се подготвяме за надстройка до нова версия на Quinn, която ни позволява най-накрая да надстроим до стабилен Tokio v1. Току-що го опитахме и подготвяме PR за тази миграция, която да се случи веднага след публикуването на Quinn версия 0.7.0.

Друго подобрение, което направихме през тази седмица, се отнася до изтриването на лични данни. Преди ново обединените промени в self_encryption и sn_client, изтриването на лични данни означаваше изтриване само на картата с данни към действителните данни, които са самокриптирани и съхранени в мрежата. Последното ни попълнение в екипа, @kanav, внедри подход на рекурсивно изтриване, който изтрива отделните парчета, заедно с парчетата, които съхраняват картата с данни, постигайки изтриване в истински смисъл.

API и CLI

@scorch изпрати PR за премахване на опцията -V от подкомандите на CLI, за да се избегне объркване между версията на самия CLI и версията на външни изпълними файлове като sn_node или sn_authd. Тази промяна включва също добавянето на подкомандата bin-version към подкомандите $ safe node и $ safe auth за извличане на версията на външните изпълними файлове, така че семантиката да е ясна, заедно с разграничението между CLI версия и sn_node или sn_authd версии.

В момента qjsonrpc библиотека е внедрена, за да поддържа стандарта JSON-RPC 2.0. Въпреки това, има определени кодове за грешки, които са дефинирани в спецификацията, които не са били изложени от контейнера. Това означава, че потребителите трябва сами да предефинират едни и същи константи, което не е необходимо, тъй като те в известен смисъл са част от изпълнението. Поради тази причина @scorch също изпрати PR, за да изложи тези кодове за грешки като константи от qjsonrpc.

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

CRDT

Правихме повторения на процесите в CRDT, който е в основата на типа Sequence в sn_data_types. Преди това Sequence беше реализиран с LSeq. Изпробвахме по-опростен Списък, за да разрешим някои проблеми с дълбоки вмъквания, след което преминахме към GList за да поддържаме само растеж. При анализ, всички тези CRDT не правят моделиране на версии, както бихме искали. Те се опитват да линеаризират реда на документите, когато в действителност историята на документите формира DAG. Имаме дизайн на CRDT за регистрация на Merkle-DAG, който ще ни позволи да моделираме вярно историята на документите и да четем най-актуалните версии.

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

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

Опитът ни да интегрираме прототипа на файловата система sn_fs с BRB разкри няколко проблеми. Причината е, че sn_fs получава операции от ядрото на операционната система по-бързо, отколкото те могат да бъдат приложени от BRB. За тази цел сме измислили няколко свързани решения: 1) заобикаляне на мрежовия слой при изпращане на операция към себе си и 2) проследяване кога другите участници са получили ProofOfAgreement, за да можем да избегнем изпращането на следващата операция докато 2/3 от останалите участници не са приложили настоящата операция. Това е необходимо, за да се изпълни изискването за подреждане на източника при BRB. Подреждането на източника означава, че операциите, идващи от един и същ източник (актьор), трябва да бъдат последователно подредени, но операции от много различни участници могат да бъдат обработвани едновременно.

Също като част от интеграцията на sn_fs, модифицирахме контейнера brb_dt_tree, за да поддържа изпращането на множество дървовидни операции в рамките на една BRB операция. Това ефективно ни дава свойствата за атомна транзакция за прилагане на логически свързани CRDT операции по „всичко или нищо“ начин. Възнамеряваме да използваме същия модел в други BRB типове данни.

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

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

Тази седмица обединихме PR промяна на начина, по който се обработват клиентските съобщения, така че сега те могат да бъдат пренасочени през мрежата по същия начин като съобщенията на възела. Това означава, че клиентът може да изпрати заявка извън своята секция и да получи отговор обратно, дори когато клиентът не може да бъде свързан директно от получателя(ите) на заявката поради ограничен NAT или подобни проблеми.

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

И накрая, PR за справяне с форкове вече е в процес на преглед. По време на работата по този PR открихме няколко допълнителни грешки, които не са свързани със справяне с форкове. През цялата седмица бяхме заети с отстраняването на грешки и към днешна дата изглежда, че ги отстранихме всичките. Резултатите от вътрешното стрес тестване изглеждат много обещаващи, плюс това успяхме да стартираме локална хост мрежа с 111(!) възли на една машина и всичко мина гладко. PR с тези корекции в момента е в процес на писане и скоро трябва да бъде готов за преглед.

Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


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

Safe Network новини - 4.3.2021

Накратко

  • Миналия петък отвореното към всички събиране на общността Safe Chat постигна голям успех! Благодарим много на всички участващи и по-специално @sotros25 и @m3data за отличните им презентации. :clap:
  • @jimcollinson ще отговаря на всякакви въпроси в Reddit - моля, включете се!
  • Съсредоточихме се в отстраняването на грешки в многосекционните мрежи тази седмица, като въведохме няколко нови метода за обработка на грешки, докато отстраняваме проблемите, които могат да доведат до провал на мрежите.
  • Нови версии на sn_api (v0.20.0), sn_authd (v0.2.0) и CLI (v0.20.0) току-що бяха публикувани, което го прави съвместими с най-новия sn_node.
  • Завършихме разработката на MerkleReg, спомената миналата седмица, и започна работата по интегрирането му в sn_data_types.
  • Тази седмица станахме свидетели на прехвърлянето на първите файлове от един SNFS възел на друг чрез BRB. :tada:
  • В маршрутизирането най-накрая обединихме PR за справянето с форкове.
  • Също така при маршрутизирането обединихме три отделни PR-а (# 2349, # 2351 и # 2336) за прилагане на корекции за различни проблеми, възникнали по време на стрес тестването. Сега се счита, че маршрутизацията е готова за стабилна тестова мрежа.

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

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

Все по-близо и по-близо…

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

Още корекции

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

Справяне с основния проблем

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

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

Safe браузър

Също така отделихме и малко време на Safe Browser, за да изтупаме праха от хранилището му (мина известно време откакто сме го пипали!), актуализирахме зависимости, така че няма да имаме куп проблеми със сигурността, когато сме готови да продължим работата върху него. (Изглежда, че @bzee напредва добре с napi преобразуването на sn_nodejs, което е страхотно!). Това не е вълнуваща новина, но е едно нещо по-малко, с което да се справим, когато сме доволни от стабилността на тестовата мрежа.

API и CLI

Нови версии на sn_api (v0.20.0), sn_authd (v0.2.0) и CLI (v0.20.0) току-що бяха пуснати с някои подобрения в начина, по който файловете и NRS контейнерите се съхраняват в мрежата, както и с новите подкоманди bin-version за идентификация и възлите за заявка към тяхната версия. Както обикновено, можете да използвате CLI-то за обновяване ($ safe update и $ safe auth update) или да инсталирате най-новото CLI, както е описано в Ръководство за потребителя. Тези нови версии са съвместими с най-новите sn_node v0.28.1.

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

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

CRDT - Реплицирани типове данни без конфликти (Conflict-free Replicated Data Types)

Завършихме разработката на MerkleReg, споменат миналата седмица: rust-crdt # 111 и започнахме работа по интегрирането му в sn_data_types. Като напомняне, MerkleReg ще бъде новия подкрепящ CRDT към Sequence типа. Той поддържа разклонена история, която може да бъде обходена (подобно на историята на git разклонение).

Също през тази седмица беше установено, че CRDT на GList / List има проблем с вмъкването между индексите, използващи един и същ идентификатор, оправихме го бързо с rust-crdt # 112.

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

Интеграцията на Safe Network файловата система (SNFS) с BRB се оказа много ползотворна при откриването на някои липсващи функции в BRB:

  1. Клиентът не е бил уведомен, когато е приложена операция. Клиентите се нуждаят от тази информация, за да изпратят отново потенциално изпуснати пакети. Това е решено с въвеждането на пакети тип Доставено: brb # 27.
  2. Когато операция се изпълнява от BRB върху клиент, той разчита на мрежовия стек, за да изпраща пакети до себе си. Това би довело до състезателни условия при изключително конкурентни клиенти, когато операции се изпълняват в бърза последователност. Сега прескачаме това като обединяваме тези пакети към самите себе си и ги обработваме, преди да се върнат на клиента: brb # 29.
  3. За да се справим с изпуснати пакети, добавихме API за повторно изпращане на пакети, за които все още не сме получили отговор: brb # 29.

SNFS - Safe Network файлова система

Добри новини! Тази седмица видяхме първите файлове, прехвърлени от един SNFS възел на друг чрез BRB. :tada:

Първоначално изпълнихме BRB предаването синхронно с FUSE операцият, но това се оказа твърде бавно. Беше направено подобрение на операциите да се подреждат в опашка и незабавно да се връщат към FUSE. След това отделна нишка системно изпраща операции на връстници в реда на източника и гарантира, че всяка от тях е приложена. Това е необходима стъпка към файлова система, която може да се използва офлайн и след това да се синхронизира с мрежата, когато връзката бъде възстановена. С тази промяна на място, файловата система се усеща (от гледна точка на скоростта) като използването на обикновена файлова система на операционна система, като например ext4 под Linux със SSD. Може би все още не е толкова бързо, но е близо.

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

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

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

Тази седмица най-накрая обединихме PR за справянето с форкове. Същността на този PR е нова реализация на структурата от данни SectionChain, която сега е пълен CRDT. Това означава, че гарантира (в последствие) последователност, независимо в какъв ред се прилагат операциите, как са групирани или дори дублирани. Дори ако в него са вмъкнати множество отделни ключове, в крайна сметка всеки ще се съгласи кой е най-новият и по този начин кои са настоящите старейшини (тъй като всеки ключ на секция е уникално свързан с една група старейшини). И всичко това се постига, без да се използва сложен консенсусен механизъм. Точно това искахме, когато премахнахме Parsec и сега най-накрая го постигнахме.

След това последваха три отделни PR-а (# 2349, # 2351 и # 2336) прилагащи корекции за различни проблеми, възникнали по време на стрес тестовете ни. Ето някои от най-забележителните:

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

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

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

Safe разговори

Първият от нашите Safe разговори с отворени врати към общността беше в петък и беше удоволствие! Докато дневният ред беше съсредоточен върху темата за приноса на общността към маркетинга на мрежата, с няколко отлични презентации от @sotros25 и @m3data, дискусиите бяха по-обширни, както можете да си представите.

Не само беше страхотно да видим лицата си - въпреки че камерите не бяха задължителни! - изглежда събитието се оформя като важна среда за сътрудничество и изграждане на големи планове!

Ако още не сте го направили можете да видите разговора тук:

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

Аз съм UX дизайнер, който помага за изграждането на новия Интернет: Питай ме всичко!

@jimcollinson подхвана Питай ме всичко в Reddit, както и във всички останали Safe социални канали всъщност.

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

Моля, присъединете се!

Safe Network програма - потребителско изживяване

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

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

fb56043ffdae530fb9c94ebb2558f658a99defdc

Работата за опростяване на този поток също ни накара да разгледаме процеса на покана като цяло и да го оформим донякъде.

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

Накратко, онова, това беше предназначено да улесни живота, докато всичко работи както е предвидено, но може да усложни нещата при проблеми.

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

Но вече не! Можем да направим компенсацията за инфлация по-разбираема и стабилна, но изискваща намеса от потребителя, ако просто продължим напред и представим ръчни допълвания на средства.

Така че получаваме две неща наведнъж. Ще имаме по-разбираемо управление на поканите и ще можете да добавяте толкова токени, колкото искате към поканите.

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


Преводи:

:uk: Английски; :ru: Russian ; :de: German ; :es: Spanish ; :fr: French


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

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 общност: SAFEnetwork България | Facebook
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България
2 Likes

Safe Network новини - 18.3.2021

Накратко

  • Радваме се да обявим създаването на фонд BambooGarden, който ще бъде използван за инициативи в помощ на разпространението и приемането на мрежата! Пълни подробности може да намерите в отделна публикация във форума тук
  • Мързеливите съобщения се приближават към интеграция в sn_node, с обещаващи резултати до момента, плюс опростяване на кода.
  • Убедени сме, че най-накрая се справихме с разделянето на портфейла на секцията, след като днес успяхме да го накараме да работи безотказно. Това ни позволява да активираме преместванията и по този начин да изплащаме наградите, насочваме се към решаването на потенциално възникнали проблеми.
  • За феновете на @jimcollinson - вижте новият му клип демонстриращ как проектираме нещата с цел да направим печеленето на токени лесно, дори за тези, които не са на ти с компютрите.
  • @dimitar беше гост на българския крипто подкаст “Cyber people”, който излезе тази седмица. Ако говорите български език, можете да гледате пълния епизод тук, в противен случай трябва да видите неговото „великденско яйце“ на 58-ма минута тук :joy: :clap:
  • Следете редовно темата Харесайте този туит за някои отлични насоки за това как да спомогнете за популяризирането на Safe мрежата с едно щракване на мишката! :bird:

Представяме ви фонд BambooGarden :mega:

Радваме се да съобщим за създаването на фонд, който да се използва за инициативи, които или директно ще помогнат за пускането на Safe Network, или ще привлекат потребители към Safe Network, когато мрежата стартира.

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

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

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

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

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

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

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

Разделяне на портфейла на секция

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

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

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

Изплащане на награди

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

Брои старейшини

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

Документация

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

API и CLI

Подобно на това, което наскоро направихме с абстракцията на FilesContainer в sn_api, т.е. цялото съдържание се съхранява в Blobs и запазва само Safe връзка в FilesContainer, сега започваме да правим същия тип промени в изпълнението на NRS контейнера ни. Това няма да повлияе на начина, по който потребителите взаимодействат, създават и/или имат достъп до NRS имената и подимената, а само как данните се съхраняват в мрежата. Всяка нова версия на съпоставянията, създадена за NRS име, сега ще бъде сериализирана и съхранена в публична неизменяема Blob, като се запази само връзка от NRS контейнера към всяка от тези Blobs. По този начин NRS контейнерът все още ще следи историята на промените, като същевременно ограничава количеството съдържание, съхранявано на изменяемото парче съдържание, да бъде просто Safe връзки.

Както е обяснено в раздела по-долу, също се придвижваме от Sequence типа данни към новия Register тип данни, който е по-опростен и по-надежден CRDT за поддържане на едновременни операции от различни клиенти, като по този начин NRS контейнерите ще се съхраняват в регистрите, вместо в Карти, както е в момента. С това на място ще имаме всички реализации за абстракция на данни, базирани на CRDT.

CRDT

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

MerkleReg: Спряхме се на обходен API за MerkleReg, като това ни дава възможност да прегледаме историята на разклоняването на регистъра, както и да правим заявки за каквито и да е по-нови данни, записани в регистъра. rust-crdt # 116

С това, което вече е на място, започнахме да мигрираме от Sequence типа данни към новия Register тип данни. Промените за sn_data_types контейнера са готови (PR # 352) и сега работим за адаптиране на sn_client копието плюс sn_messaging съответно (PR # 65).

Safe Network програма и потребителско изживяване на фермерството

Представяме ви седмичната доза потребителско изживяване с това бързо видео от @jimcollinson, демонстриращо как проектираме нещата с цел да направим лесно печеленето на Safe токени, дори за тези, които не са супер уверени с компютрите.

Джим показва стила на предаване на информация, който разработваме за ключови области на Safe програмата при първо използване, като целта е да поведем хората през някои от по-нюансираните потоци, без да е прекалено подробно.

Преводи:

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


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

Safe Network новини - 25.3.2021

Накратко

  • Приключихме с набирането на членове за доброволческия комитет към BambooGarden фонда! Събраха се 8 уважавани и опитни членове от общността.
  • След като комисията за BambooGarden фонда вече е потвърдена, ще преминем към създаването на комуникационни канали, за да можем да поканим първите заявления за финансиране.
  • Направихме множество сравнително малки промени в клиентския код през последната седмица, което доведе до успешното преминаване на повечето клиентски тестове в многосекционна мрежа.
  • След като стабилизирахме клиента, успяхме да активираме отново изплащанията за награди и сега работим по проблеми и оптимизации.
  • Внедряването на мързеливите съобщения продължава навсякъде.
  • Още въпроси се събраха в AMA, и още един отговор е наличен в това видео от @jimcollinson тук
  • Публикувахме резюме на функциите за предстоящата тестова мрежа по-рано през седмицата.
  • Следете редовно темата Харесайте този туит за някои отлични насоки за това как да спомогнете за популяризирането на Safe мрежата с едно щракване на мишката! :bird:

Новини за BambooGarden фонда

Изказваме големи благодарности към всеки от доброволците съставили комитета на BambooGarden фонда. Имаме 8 доброволци, които ще отделят от своето време и затова смятаме, че това е добра точка за момента да спрем с приемането на още членове в комисията, за да я поддържаме в управляем размер.

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

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

Всичко това беше съобщено на доброволците на комисията през последните няколко дни, заедно с някои други важни решения. Например, членовете на комисията ще се събират в отделен форум, където ще можем да обсъждаме и гласуваме заявления. MaidSafe също така предложи някои непосредствени области, които определихме като неотложни при предприемането на стъпки за постигане на цел номер 1 на този фонд, а именно: „да се ускори темпът на разгръщане на Safe мрежата“. Тези области са:

  • Официална документация - ние вярваме, че проектът ще има огромна полза от официалното документиране на нашите алгоритми. Може би човек, който има опит в писането на официални алгоритми и документи, би могъл да предложи стойност тук. Наличието на тези официални документи помага на програмистите, които се включват, като същевременно помага на външни одитори, които в даден момент бихме искали да проверят нашия код за грешки в сигурността, бъгове и т.н.
  • Допълнителни експертни познания за CRDT, които ще ни помогнат да преминем на следващото ниво
  • Допълнителен консенсус опит.
  • Допълнителна експертиза за мрежовата свързаност.

Ако имате идеи за заявления за финансиране в тези области, моля изчакайте с изпращането им, но можете да започнете да ги обмисляте докато подготвяме отварянето на процеса за кандидатстване.

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

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

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

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

Подобрения на клиентския код

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

Възнаграждения

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

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

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

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

Маршрутизиране на съседи

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

Така че сега възлите поддържат информация за всички секции в мрежата, което означава, че няма нужда да се препредава нищо, тъй като те винаги познават крайните получатели. Това опростява дизайна и подобрява производителността. Човек може да се притеснява дали това няма да изисква огромно количество памет, но се оказва, че не го прави. Изчислихме, че можем да поддържаме няколко стотици хиляди секции, преди паметта да се превърне в проблем. Ще се справим с този проблем, когато стигнем там. Като част от тази промяна, също реконструирахме мързеливата логика за съобщения и я извлякохме в отделен модул, което ни позволи да добавим още модулни тестове към нея, увеличавайки доверието в кода.

API и CLI

След финализиране на промените, необходими за новия тип данни Register CRDT в „sn_node“ и „sn_client“ контейнерите, започнахме да адаптираме „sn_api“ кодовата база и нейното API, за да я поддържаме.

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

Също така започнахме с адаптирането на всички наши абстракции (NRS, FilesContainers и портфейли), за да използваме този тип данни. Тук виждаме по-голямо предизвикателство по отношение на UX, като се има предвид, че четенето на FilesContainer може да доведе до виждането на повече от едно състояние, както е обяснено по-горе. По този начин сега търсим най-добрия начин да изложим това в нашето API, така че потребителят и / или разработчикът на програми да може да реши какво да прави в тези ситуации. Например крайният потребител може да бъде подканен да реши не само кой клон да прочете, но и може би как да ги обедини отново в един клон. Както вече можете да видите, може да има няколко начина, по които потребителят или разработчикът биха искали да се справят с появата на клонове в данните и това е основният двигател зад новия дизайн на тези API-та.

Що се отнася до Safe CLI-то, ще трябва да вземем някои решения относно това какви опции да предложим на крайния потребител за справяне с клонове с данни. Пример тук е при извличане на FilesContainer с две неразрешени състояния, CLI-то вероятно може да представи подробна информация за тях и да позволи на потребителя да реши кое да прегледа.

CRDT

Продължаваме с работата по проучването на Bounded Counter и тази седмица работим, за да го направим устойчив на византийски атаки и да приложим PoC. Надяваме се през следващата седмица или по следващата да имаме нещо конкретно за споделяне на този фронт.

Освен това разработихме дизайна на нов CRM на MultiMap, базиран на MerkleReg. Това вероятно ще бъде основата за типовете данни на NRS поддомейн, както и гъвкава структура за други програми, които се нуждаят от карта като тип данни.

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

Още въпроси се събраха в AMA темата и е наличен нов видео отговор. Този път @jimcollinson отговаря на въпрос от @dimitar: Прекалено късно ли е за поверителност онлайн? Не са ли получили вече цялата ни информация?

Преводи:

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


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

Safe Network новини - 15.7.2021

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

Всяка седмица ще се опитаме да обясним и определена област от мрежата - тази седмица това е DBC.

Радваме се да приветстваме обратно DevOps специалистта Крис О’Нийл (@Chriso), който беше част от QA MaidSafe екипа ни до 2019 г. Назначаването на Крис подсилва екипа, към който наскоро се присъединиха инженерите Анселме Гръмбах @Anselme и Крис Конъли @Chris.Connelly, които вече работят с пълни сили.

Ето малко предистория от устата на самия Крис О’Нийл:

В момента се намирам в южната част на Глазгоу и съм в софтуерната индустрия от 14 години. Започнах кариерата си като програмист и работих върху разработването на продукти около 7/8 години. След това се преместих повече в DevOps пространството и там се фокусирах основно през последните 5 или 6 години. Радвам се да се присъединя отново към MaidSafe и да бъда част от проекта отново. Въпреки че ще се радвам да помогна с всякакви DevOps изисквания, този път имам амбицията и аз да бъда част от разработката на мрежата.

Напредък

ARM компилациите на @Chriso за sn_cli и sn_node вече са обединени, въпреки че може да са необходими повече тестове и корекции на грешки, преди да са готови за публично представяне. (“aarch64” компилации ще следват скоро, @chriso работи по внедряването им в момента :+1: )

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

Регистрацията и свързването (автоматично маркиране на синтаксични грешки) се преглеждат, за да се улесни и направи по-лесно откриването на грешки и несъответствия.

Съобщения: за оптимална производителност, комуникациите между възлите трябва да бъдат сведени до абсолютно необходимия минимум. Броят на съобщенията вече е значително намален в резултат на анализите от тестовата мрежа, но тук има още какво да се направи, особено за да се позволи поддръжка за офлайн подписване. За тази цел току-що обединихме основна поправка на съобщенията, която има за цел да опрости протокола за съобщения.
DBC: Седмата тестова мрежа ще включва основно внедряване на “Сертификати за цифрови носители” (DBC). Дизайнът на внедряването продължава добре и проучваме най-добрия начин да гарантираме абсолютна поверителност.

Още за DBC

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

Важното за нас е, че DBC осигуряват бърз, безопасен, гъвкав начин за извършване на плащания, който е съвместим с криптография с множество подписи/праг на подпис и може да се използва онлайн и офлайн. Те опростяват много аспекти на икономиката на Safe мрежата.
DBC всъщност датират от 1997 г., но досега не са спечелили голяма популярност, до голяма степен поради трудността да се защити централизиран издател, който е единична точка на опасност.

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

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

Преводи:

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


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

Safe Network новини - 22.7.2021

В новините за тази седмица се задълбочаваме в най-малко любимата тема на всички - бъговете. Грешките не са лесна тема за определяне, защото в сложна, многостранна, авангардна система като Safe може да е трудно да се разбере откъде започва една грешка, а другата свършва. Дали тази грешка е в нашия код или в библиотека на трета страна или може би в това как те си пасват? Това наистина ли е корекция на грешка или просто оптимизация чакаща да се случи?

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

Общ напредък

@Chriso продължава работата по ARM компилации за aarch64, но за съжаление новата му Raspberry Pi пристигна с дефектна microSD карта. Замяна пристигна във вторник, така че не остава още много чакане. Благодарим на @folaht, @stout77 и други за изпробването на съществуващите компилации.

DBCs

Постигнахме напредък по анонимните транзакции, използвайки Pedersen заявки и заслепени стойности, за да скрием паричните суми. Повече за тях друг ден!

Потребителско изживяване

@JimCollinson преосмисля потоците на потребителско изживяване въз основа на развитието на мрежата, за да включва DBC, предплатени качвания, транзакции с множество сигнали и възможности за онлайн/офлайн CRDT транзакции.

NRS новини

@Anselme and @bochaco have been updating the client API and Name Resolution System, tidying up the code and removing the old Map data type.

Speaking of no-longer-the-new-boy Anselme, here’s a bit from him:

@Anselme и @bochaco актуализират клиентския API и системата за разрешаване на имена, подреждат кода и премахват стария карта тип данни.

Ето и малко информация за “не-толкова-новия” член на екипа Анселме:

Идвайки от специализация по системно програмиране (UNIX), прескачах от поле на поле, преминавайки от блокчейн към бек-енд програмиране, инженеринг на данни и машинно обучение. Запален съм по компютърните вируси, системното програмиране, софтуерната сигурност, децентрализацията, машинното обучение и езиците за програмиране.
Обичам да мисля за кода като поезия, въпреки това, искам да разработвам за по-голяма цел, за по важни неща. Ето защо съм тук в MaidSafe.

Премахване на загубите на данни

От само себе си се разбира, че загубата на данни е абсолютно не-не за Safe (изчезването на данните от вечната мрежа би било особено лошо). Парчетата от данни, съхранявани на Safe възли по целия свят, трябва да могат да преживеят събития при отпадане, локални прекъсвания и византийски участници. Тези от вас, които помогнаха с тестването (:thankyou:), знаят, че все още не сме се справили с премахването на загубата на данни.

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

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

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

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

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

Малко по малко ще се справим, но няма да имаме шанс да ги проследим без всички вас, които ни помагате с тестването. Дори когато те са краткотрайни, информацията, която тестовите мрежи предоставят на екипа, е безценна, така че благодарим още веднъж на всички за отстраняването на грешките досега!

Преводи:

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


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

Safe Network новини - 29.7.2021

Тази седмица ще разгледаме по-задълбочено DBC, които имат потенциала да революционизират онлайн плащанията и да опростят много аспекти от икономиката на Safe мрежата. Те наистина са толкова голяма работа, но в стандартната си форма имат няколко недостатъка, когато става въпрос за частни транзакции.

Един от проблемите е, че издател може да вижда транзакциите, преминаващи през него, и в случай на недоброжелателство може да публикува тези транзакции. Тази седмица ще разгледаме начин да скрием транзакциите от издател - Pedersen заявки - и също така начин да спрем Pedersen заявките да се преодолеят от лоши актьори - чрез доказателства за обхват.

Общ прогрес

@danda и Дейвид Русу ръководят дизайна на поверителните транзакции и адаптират DBC за прилагането на еднократни ключове. @danda обяснява всичко това по-подробно в тази публикация.

От страна на клиента, @yogesh претърсва кода, за да даде възможност на клиентите да общуват директно със секции, където се намират парчетата данни, което е много по-ефективно от маршрутизирането на всичко през една секция.

Маршрутизация: @lionel.faber е в контакт с екипа на quinn, които предложиха някои идеи за това, което причинява някои от проблемите с изчакване / нулиране, които потребителите на тестовата мрежа имаха. Също така преместваме аспекти на функционалността за маршрутизиране към qp2p, за да намалим сложността.

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

Един от по-новите MaidSafer програмисти, който се стреми към реформата на съобщенията, е @Chris.Connelly. Ето кратко представяне от Крис:

Аз съм живеещ в Единбург софтуерен инженер с опит в разработването на уеб услуги и автоматизация на облачната инфраструктура, но сега се стремя да разширя хоризонтите си в разпределени и децентрализирани системи. Вярвам страстно в цялостното инженерство (като се има предвид цялата система и избягването на специализираните роли) и пиша надежден софтуер, използвайки Rust (а понякога и Elm за нещо странично), и съм въодушевен от работата си в MaidSafe!

Pedersen заявки и доказателства за обхват

Pedersen заявките са форма на доказателство с нулеви знания, предназначени да скрият сумите в транзакциите. Те позволяват на получателя да провери дали сумата от всички числа, въведени в заявката, е равна на сумата от всички числа, изведени от транзакцията, без да разкриват самите числа.

Така че, ако имам 30 токена, плащам ви 20 и някой друг плаща 10, тази транзакция може да бъде проверена от трети страни (равни ли се входните и изходните стойности, „истина“ или „не истина“?), без те да знаят съответните стойности.

За да се харчат DBC, те трябва да бъдат разрешени от издател. Pedersen заявките дават възможност на издател да провери дали входните и изходните стойности на DBC са равни (т.е. валидни) и да подпише транзакцията, без да знае точните суми, които се изпращат.

Една слабост на Pedersen заявките, когато се използват за валидиране на транзакции, е, че те могат да бъдат измамени с отрицателни числа. Транзакция с вход 20 и изход 30 и -10 би била валидна, но тъй като „отрицателни пари“ не могат да съществуват като монета, на практика платецът е превърнал 20 монети в 30 монети. Магия! (Но не и за икономиката.)

Доказателствата за обхват правят криптографски невъзможно изходната стойност да бъде извън определен диапазон, да речем 0 - 2^32. Ние налагаме това, като обявяваме транзакцията за валидна само ако всеки изход съдържа и доказателство за диапазон.

Така че, ако имам DBC за 30 монети и искам да платя на Алис 20 и на Боб 10, процесът протича така:

Изпращам моя DBC към издател заедно с Pedersen заявка с (криптиран) вход като “30” и (шифрованите) изходи като “20 + доказателство за обхват” и “10 + доказателство за обхват”. Издателя проверява добавянето на входните и изходните стойности и дали всеки изход има валидно доказателство за обхвата, подписва транзакцията и преиздава DBC на публичните ключове на Алис и Боб (разбъркани).

Преводи:

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


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

Safe Network новини - 5.8.2021

Тази седмица разглеждаме промените в типовете данни в резултат на въвеждането на безконфликтни типове данни (CRDT).

За тези, които се нуждаят от бързо опресняване, CRDT са структури от данни с някои специални математически свойства. Когато съществуват множество версии на данни, като например копия на документ, който се редактира офлайн на различни компютри, в крайна сметка, когато компютрите се свържат отново, те винаги ще се обединят в една „истинска“ версия.

За Safe мрежата CRDT са един от ключовите начини за осигуряване на консенсус, без да се изисква тежкот, общосистемно подреждане на събитията, както при блокчейн технологията. Това е красиво елегантна концепция, въпреки че очевидната простота крие факта, че под капака се случват доста интересни неща. Дори Google не можа да се справи с проблемът с едновременното писане при създаването на Google Документи - трябваше да прибягнат до грозна бъркотия. Да изпреварим Google в играта за едновременност е възможност, която е твърде добра, за да пропуснем!

За да се възползваме от магьосничеството на CRDT, преконфигурираме нашите променливи типове данни - повече за това по долу.

Общ прогрес

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

@chriso работи на заден режим, добавяйки поддръжка за AArch64 или ARM64, ако предпочитате. В последните версии на sn_cli и safe_network ще видите, че са приложени изпълними файлове за ARM, ARMv7 и AArch64. Крис е тествал изпълнимите файлове за AArch64 и е успял да потвърди, че те работят, има тестов скрипт, който използвахме, за да проверим това тук за всеки, който се интересува. Не сме тествали основните изпълними файлове за ARM и ARMv7, нямаме хардуер, който да използваме за начало, така че използвайте ги на свой собствен риск! Имайте предвид също, че нашите контейнери в момента са в интензивно развитие, докато се придвижваме към следващата тестова мрежа, така че най-новите изпълними файлове са по-често несъвместими помежду си във всички архитектури. Бихме посъветвали всеки, който желае да тества, да се въздържи, докато не обявим съвместими версии навсякъде, т.е. при следващата тестова мрежа.

@qi_ma и @chriso се справиха с някои грешки в процеса на непрекъсната интеграция (CI). Гладко работещият CI е от съществено значение за бързото обединяване на заявки за изтегляне, което само по себе си е от жизненоважно значение за бърза итерация и тестване.

Отбелязваме голям напредък с актуализирането на qp2p библиотеката, където елементи като XorName се преместват от оптимизирания sn_routing към qp2p. Продължаваме с проучване за прекъснати връзки, запазване на връзките, повторни опити и стартиране. Твърде много неща са, за да навлизаме в подробности сега, но ако имате въпроси, ще направим всичко възможно да им отговорим в тази тема. Безопасно е да се каже, че това държи екипа доста зает!

@oetyng също е дълбоко в групирането на потоци от парчета и плащания. Груповото пакетиране позволява да се извършва едно плащане за произволен брой операции. В рамките на това е и възможността за разделяне на части и криптиране офлайн и предплащане.

Така че, след локално криптиране и постоянство, потребителят може:

  1. По всяко време може се свържете, за да получите вечно валидна „оферта“ за партидата.
  2. С тази оферта - отново, по всяко време - може да платите и извлечете „разписка“.
  3. И накрая (познахте, по всяко време) може да качите произволен брой от тези парчета/операции.

Всичко това е свързано с текущата работа за прехвърляне на повече работа върху Клиента. В края на краищата, ако Клиентът прави искането, то е справедливо, той също така да свърши работата; този подход има и предимства срещу спам.

Последователният тип данни вече е напълно премахнат от sn_api
благодарение на @anselme и ще бъде заменен с CRDT-съвместими типове данни. Повече за това по-долу.

Типове данни

Преди имахме тип данни Карта, който беше ключ за редактиране: хранилище за стойности, използвано за съхраняване на информация като подробности за акаунта; тип данни само за Последователно добавяне, подходящ за уеб страници и файлови контейнери, с възможност за връщане към предишни версии; и Blob - неизменни данни.

Всички нови и обновени типове данни се основават на - както може да предположите - CRDT, което носи някои ясни предимства.

Регистърът е общ тип CRDT данни, който съдържа стойност. За Safe искахме регистър, който също да ни позволи да се върнем назад във времето и да разгледаме предишните стойности, така че Дейвид Русу създаде нов тип регистър, базиран на Merkle DAG, наречен MerkleReg - регистър с история. Това беше внедрено преди известно време заедно със свой публичен API от страната на клиента.

Този нов Регистър прави типа данни Sequence ненужни, тъй като може да прави всичко, което Sequence би могъл да направи по отношение на съхраняването на предишни версии с добавения бонус, че може да обработва и паралелност. Ако клиент паралелни пише в регистъра, това води до разклонение, което след това може да бъде разрешено от клиента (това беше невъзможно при Sequence). В Safe използваме регистъра за съхраняване на указатели към текущата и предишните версии на данните, като текстов файл или уеб страница, които се съхраняват като пакет данни.

Толкова за Sequence :wave :, но какво да кажем за Map?

Е, картите бяха подобрени, за да се превърнат в мултикарти, като „мулти-“, се отнася до факта, че всеки ключ вече може да има множество стойности. И тук това позволява паралелност. Множество клиенти (напр. Приложения) могат да редактират мултикарта едновременно и резултатът ще бъде разклонения. Как ще се разрешат тези разклонения, в крайна сметка ще зависи от приложението, но след време те ще се сближат по същия начин, по който правят клоновете на Git. Мрежовата файлова система NFS и системата за разрешаване на имена NRS от тази седмица са напълно внедрени като Мултикарти, което ще бъде много важно след време за работата ни.

А пакетите данни? Те остават неизменими. В свят на постоянна промяна някои неща трябва да останат същите.

Преводи:

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


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