Както сигурно сте забелязали, нова тестова мрежа е налична. Време е да се включите, ако още не сте го направили! Изтеглете Safe и качете няколко файлове и вижте как плащането за всяко качване автоматично се изважда от вашия портфейл. Разбира се всички пари са тестови засега, но е страхотно да ги видите в действие. Уведомете ни за грешки, които може да видите в тази тема.
Плащането за данни е голяма крачка напред, благодарение на факта, че мрежата вече се държи доста добре и е стабилна (да чукнем на дърво). Използваната памет от възлите се движи в диапазона 50 - 60 MB, докато преди беше в стотици MB. Но все още има неща за изглаждане. Благодарим за отзивите досега и продължавайте да ги давате. Следващият етап ще бъде изпробване на основния поток на плащане към възлите и някакъв прост механизъм за ценообразуване.
Все още няма солидно преминаване на NAT, за съжаление, но ако имате облъчен възел или ако искате да пренасочите портове, може да пуснете възел или два. Уведомете ни как върви.
Сега, когато сме на стабилно място, също ще започнем да обясняваме работата на мрежата. Тази седмица @roland ще обясни какво се случва по време на репликация на данни.
Общ напредък
@Chriso работи върху централизирано регистриране, за да улесни анализирането на грешките с агрегирането им след тестовите мрежи. В крайна сметка се надяваме да дадем възможност на членовете на общността да правят това в реално време, но засега искаме да е възможно най-опростено.
Томас Айзингер и Макс Индън от екипа на rust-libp2p обединиха корекция от @bzee, която виждаше, че нови възли продължават да набират (изпращат съобщения към) други възли дори след като са свързани към мрежата. @bzee е в редовен контакт с този екип, който казва, че AutoNAT и пробиването на дупки трябва да работят „скоро“. Един от поддържащите има предварително решение, което би решило проблема с повторното използване на портове - AutoNAT не трябва да използва повторно портове на изходящи проби. Стискаме палци за някакъв ранен напредък по въпроса.
@aed900 работи върху подобряване на UX около несвързани възли обработване на изчаквания.
@bochaco усъвършенства функция за едновременно извличане на всички разходи за доказателство за плащане, за да ускори процеса на потвърждение на DBC, както и подход за извършване на регистрации с адресиране на съдържание.
@qi_ma поправи лек бъг с DBC. Когато клиент иска да изразходва DBC за качване на данни, възлите проверяват дали има съществуващо доказателство за разходите на съответния адрес (за да спрат двойното харчене). Възелът, който държи този адрес, също ще отговаря активно на GET заявки, което може да забави отговора му на запитващите възли, карайки ги да мислят, че там няма изразходвано доказателство. Това е изключително рядко събитие, но сме го виждали в дивата природа и би позволило двойно харчене. Поправяме го, като изискваме 5 възела да видят GET, преди да бъдат предприети действия.
И @joshuef разглежда динамични плащания и ценообразуване, включително клиентът пита възли близо до мястото на плащане каква е тяхната цена за съхранение, и с това актуализира плащането за качвания. А също и основно изчисление на цената за съхранение въз основа на капацитета за съхранение.
Репликация на данни
Репликацията на данни е механизъм, който позволява на възлите да разпространяват данни към нови партньори, докато се присъединяват и прехвърлят данни от „мъртъв партньор“ към другите възли. Това гарантира, че данните остават налични в мрежата, дори когато възлите се присъединяват или напускат. Въпреки това подходът, използван от Libp2p, разчита на възел, който периодично наводнява мрежата с всичките си данни. Това дойде с някои недостатъци, включително тежък мрежов трафик и високо използване на паметта между възлите. Освен това новите възли не са получили данните, за които са отговорни, а данните, съхранявани от мъртвите възли, не са били репликирани навреме. За да се справим с тези проблеми, внедрихме персонализиран процес на репликация, който се задейства всеки път, когато има промяна в близката група на възел.
Преди да се задълбочим в процеса на репликация, нека обсъдим накратко как се съхраняват данните в мрежата. Мрежата работи като разпределена хеш таблица (DHT), позволяваща извличане на данни с помощта на уникални ключове. Когато някой иска да съхрани файл в мрежата, той първо ще използва своя DBC, за да плати за файла и след това ще качи файла в мрежата. Тези данни (DBC, Chunk или Register) се трансформират в поредица от 0 и 1 и се поставят в нещо, наречено „запис“. Въпреки че записите могат да бъдат безкрайно големи, възлите са ограничени да обработват записи с размер 1mb. Всеки „Запис“ има свой собствен „Ключ“, който е „XorName“ на данните, които съхранява.
За да съхрани „Записа“, съдържащ както данните, така и ключа в мрежата, клиентът изчислява Xor разстоянието между „Ключа на записа“ и неговите възли в своята RT (Таблица за маршрутизиране), като сортира партньорите по тяхната близост до „Ключа“. Впоследствие клиентът моли тези възли да „изчислят и споделят партньорите, които смятат, че са най-близо до „Ключа“. След това клиентът сортира отговорите и идентифицира възли, които са дори по-близо до „Ключа“. Този процес продължава, докато не бъдат открити осемте отговорни възела за записа и записът се съхрани с тях. Libp2p абстрахира този сложен процес, позволявайки ни да изградим нашата мрежа върху него.
След като „запис“ бъде съхранен сред най-близките партньори в мрежата, ние искаме да поддържаме поне осем копия на записа, дори ако възлите, които ги държат, са офлайн. Текущият ни процес на репликация работи по следния начин: Всеки възел следи партньорите, близки до него, т.е. неговата близка група. Всеки път, когато партньор се добавя или премахва от RT, ние проверяваме дали това засяга нашата близка група. Ако има промяна, ние изпращаме „Ключовете за запис“ на колегите от нашата близка група, за които смятаме, че трябва да държат този запис. При получаване на списъка с ключове, ако даден партньор няма съответния запис, той го изисква от възела, който първоначално е изпратил „Ключа“. В случай, че не може да получи записа от възела, който първоначално е изпратил ключа, той пита мрежата за данните.
Въпреки че са възможни допълнителни оптимизации, настоящият подход за репликация е значително по-малко ресурсоемък от този в Libp2p и ефективно предотвратява загубата на данни.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България