По целия свят хиляди възли все още си тананикат, внимателно и безспорно съхранявайки и възпроизвеждайки снимките на общността и необозримите музикални избори завинаги, и винаги, и винаги. Не се притеснявайте, ние ще премахнем тази тестова мрежа своевременно. Все още не сме там, но с течение на времето мрежата става забележимо по-стабилна, предвидима и мащабируема - което е изключително радващо. Моля, продължете с качването и споделянето и публикувайте вашите регистрационни файлове, ако видите нещо неблагоприятно.
Под капака
Някои заключителни резултати от тестовете ни убедиха да превключим модела на репликация на данни от push към pull. Съгласно модела на изтласкване, който използвахме досега, когато има разделяне (възел излиза офлайн), възлите с копия на данните, съхранявани от мъртвия възел, ги изтласкват към следващия най-близък възел. Някои от тези възли ще успеят да прокарат своите парчета, други не, но трябва да има достатъчно толерантност в системата (както се контролира от избора на k-стойност), за да сме сигурни, че няма да се загубят данни.
Методът на изтегляне е подобен, с изключение на това, че новият възел, осъзнавайки, че е наследник на мъртвия възел, изисква парчета от своята близка група. Отново, някои заявки може да са успешни, други няма да бъдат, но в крайна сметка всички парчета трябва да бъдат получени.
И така, каква е разликата? Това е в броя на съобщенията, които се изпращат, и в броя на допълнителните копия, които са необходими, за да работи моделът на натискане. @Qi_ma проведе тестове при екстремни условия на разделяне и откри, че разделянето е по-добро по всеки показател - съобщения, процесор, памет и процент на успех. Следователно смяната беше наложителна. Към момента използваме модела на изтегляне.
Много по-добре е, но все още виждаме случайни изпуснати съобщения, поради което успехът все още не е 100%-ов.
Навсякъде другаде DBC сега се копират, полагайки основата за плащане за данни, което ще бъде тема на бъдеща тестова мрежа. @bochaco създаде илюстрация на Merkle DAG и как те изграждат дърво за парчета, което ни позволява да използваме корена на дървото като доказателство за плащане за съхранение, което ще възпроизведем тук.
Доказателствата за плащане за съхранение се генерират с помощта на двоично дърво на Merkle:
Дърво на Merkle, известно още като хеш дърво, е структура от данни, използвана за проверка на данни и синхронизация. Това е дървовидна структура от данни, където всеки нелистов възел е хеш на неговите дъщерни възли. Всички листни възли са на една и съща дълбочина и са толкова вляво, колкото е възможно. Той поддържа целостта на данните и използва хеш функции за тази цел.
В Safe, за да се плати на мрежата за съхранение на данни, всички файлове първо се самокриптират за да се получат всички парчета, за които потребителят трябва да плати, преди да ги качи. Двоично Merkle дървото се създава с помощта на всички тези адреси на парчета/Xornames, всяко листо в Merkle дървото съдържа стойността, получена от хеширане на всяко Xorname/адрес на парчето.
Следното дърво изобразява как ще бъдат използвани два файла A и B, с по две парчета всяко
за изграждане на Merkle дървото:[ Root ] hash(Node0 + Node1) ^ | *-------------------------------------------* | | [ Node0 ] [ Node1 ] hash(Leaf0 + Leaf1) hash(Leaf2 + Leaf3) ^ ^ | | *----------------------* *----------------------* | | | | [ Leaf0 ] [ Leaf1 ] [ Leaf2 ] [ Leaf3 ] hash(ChunkA_0.addr) hash(ChunkA_1.addr) hash(ChunkB_0.addr) hash(ChunkB_1.addr) ^ ^ ^ ^ ^ ^ ^ ^ | | | | [ ChunkA_0 ] [ ChunkA_1 ] [ ChunkB_0 ] [ ChunkB_1 ] ^ ^ ^ ^ | | | | *----------------------* *----------------------* | | self-encryption self-encryption | | [ FileA ] [ FileB ]Потребителят свързва извършеното плащане с възлите за съхранение, като зададе стойността на корена на Merkle дървото като стойността „Dbc::reason_hash“. Благодарение на свойствата на дървото Merkle, след това потребителят може да осигури изходния DBC и одитна пътека за всяко от парчетата, които се плащат със същото DBC и дърво към възлите за съхранение при качване на парчетата за съхраняването им в мрежата.
@Anselme работи с някои грешки в кранчето и портфейла, които в момента не маркират DBC като изразходвани в мрежата. Той също така разреши някои проблеми с регистрирането.
@Roland повдигна PR за събиране на системни, мрежови и процесни показатели. Това е зад функционална врата, което означава, че може да се включва и изключва според нашите нужди. Би трябвало да е полезно по време на тестови мрежи да се събират показатели от общността. По-късно ще активираме показателите на OpenSearch, но засега това е просто решение.
@ChrisO пусна автоматизиран процес на освобождаване на тестова мрежа, който работи експериментално. Трябва да е готов за действие на живо много скоро. Той и @aed900 също работят върху други аспекти на тестовите мрежи, включително управление на тайни в Digital Ocean. Ангъс също разглежда проблем, при който частните възли (зад NAT) се записват в таблицата за маршрутизиране, което не е това, което искаме.
За щастие @bzee, който се рови в libp2p, вярва, че една предстояща версия трябва да реши този проблем за нас.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България