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

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 страницата на Safe Network България: https://www.facebook.com/SafeNetworkBulgaria/
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 страницата на Safe Network България: Safe Network България - Home | Facebook
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 страницата на Safe Network България: Safe Network България - Home | Facebook
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 общност: SAFEnetwork България
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България - Home | Facebook
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 общност: SAFEnetwork България
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България - Home | Facebook
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 България: Redirecting...
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 България: Redirecting...
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 общност: SAFEnetwork България
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Redirecting...

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