Safe Network новини 🇧🇬 26.5.2022

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

Общ напредък

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

@Chriso се задълбочава в внедряването на DBC и вече е завършил всички промени в CLI-то за предаване на DBC на нов собственик. Сега той насочва вниманието си към sn_api за присвояване на промяната на DBC собственика.

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

И @davidrusu разпространява добрата дума за мрежата, като присъства на друга среща на CompSci в Торонто, за да говори за Tree CRDT. „Страхотна дискусия навсякъде“, съобщи той, и чудесно място за набиране на заинтересовани страни към Safe Labs.

В по-широкия Safe свят, текущият проект на общността за подкрепа на MaidSafeCoin wyrhu ERC20 протокола продължава с неотслабваща сила и с удоволствие съобщаваме, че тези усилия продължават да дават плодове! Така че в допълнение към Uniswap eMAID вече е отворен и за търговия в P2PB2B!

Можете да благодарите на членове на общността - @Sotros25 и @Mightyfoolза напредъка :clap:

Оптимизиране на трансфера на данни

Когато някой направи GET заявка, това стартира редица процеси. Първо, заявката се предава на Старейшините в чиято Секция се съхранява парчето данни. След това Старейшините изчисляват кои четирима възрастни съхраняват парчето – четирите XOR възрастни най-близки до адреса на парчето – и всеки от тези Възрастни предава своето копие на парчето обратно на старейшините, които след това го връщат на клиента.

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

Ако клиентът се свърже с всичките седем Старейшини на секцията, като поиска 1MB парче „A“ и всеки старейшина на свой ред поиска парче A от четиримата възрастни, които го държат, и ги върне на клиента, тогава потенциално това са 28MB (4x7), преминаващи през мрежата за една GET заявка от 1MB.

Понастоящем използваме половинчата система, при която клиентът се свързва с трима Старейшини на случаен принцип и тези Старейшини се свързват с четиримата възрастни, държащи парче A - така че потенциално имаме 12MB (3x4) данни, протичащи през мрежата за заявка от 1MB - по-добре, но все още не е страхотно. И намаляването на връзката до трима Старейшини също идва с цена: ако имаме само трима Старейшини, които взаимодействат с Възрастните, вече нямаме свръхмнозинство, което да решава дали един от Възрастните не функционира, което прави проследяването на дисфункцията по-сложно.

Решение, което разглеждаме сега, са алгоритмите за разпръскване на информация (IDA, известен също като erasure кодиране). Това може да ни помогне значително да намалим обема на прехвърляне на данни за GET, като накараме Възрастните да предадат част от данните на Старейшините, вместо цялото парче данни. След това Старейшините предават тези споделени данни обратно на клиента, който ги сглобява отново и, voila, част А се пресъздава. Потенциално това може да намали потоците на GET до само 1,4MB за 1MB парче.

И така, как работи? Първо, ние не предлагаме замяна на репликацията с IDA. Някои проекти правят това (например Solana), но за нас има твърде много компромиси. Така че, както сега, ако възрастен излезе офлайн, неговите данни се репликират изцяло на друг възрастен. Промяната е, че възрастните ще могат да разделят част А на седем части с помощта на IDA и да предават само една част обратно на старейшините при поискване, а не цялата част, което означава, че се обменят много по-малко данни.

След като събере пет от седемте парчета, клиентът може да сглоби отново парче А.

Тази цифра пет от седем несъмнено ви изглежда познато :bulb:, защото това е същият праг, който използваме за BLS консенсус, но IDA е различен звяр от праговата криптография, предназначена по-скоро за оптимизиране на съхранението и трансфера на данни отколкото тайно споделяне. В случай, че се чудите откъде идват допълнителните 0,4 (прехвърлянето на 1MB парче чрез IDA изисква 1,4MB потоци от данни), това е неизбежно излишно натоварване от начина на работа на алгоритъма.

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

По-нататъшни оптимизации също трябва да бъдат възможни с тази архитектура. Поради скорошни промени в Членството, сега знаем кой Възрастен от трите държащи част А всъщност е най-близък. Така че вместо да иска парче A, клиентът може да поиска директно първото парче A[0] и Старейшините ще отидат направо при най-близкия Възрастен; за второто парче A[1], Старейшините ще попитат следващия най-близък възрастен и т.н. Всички неуспехи просто се опитват отново при друг Възрастен. Това е по-ефективно и означава, че потенциално можем да увеличим броя на репликите - Възрастни, държащи парче А - без значително допълнително натоварване на мрежата, с очевидни ползи от излишък от данни.


Преводи:

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

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