Safe Network новини 🇧🇬 25.3.2021

Dimitar · April 1, 2021, 9:36am

Накратко

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

Новини за 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: Прекалено късно ли е за поверителност онлайн? Не са ли получили вече цялата ни информация?

Преводи:

English Russian ; German ; Spanish ; French

Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum

Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...

Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България