Беше фантастично и приятно да видим как най-новата тестова мрежа на общността се представи толкова добре 
. Огромни благодарности към всички, които участваха 
. Сега, когато мрежата става все по-стабилна, е време да преминем към финните настройки за съхранение и извличане на данни, и настоящите ни планове са описани по-долу. Както винаги, ние се опитваме да измислим основни механизми, които са леки и гъвкави и които могат лесно да бъдат разширени, за да поддържат други функции като плащания и фермерство. Най-важното е, че те не включват никакви зависимост от мрежова синхронизация.
Общ напредък
@yogesh успя да реши логически проблем при избирането на нови старейшини, намаляване на броя на рундовете на AE и последователния обмен на съобщения от 150 на 15. Това е впечатляваща 10X оптимизация, но той е сигурен, че тук може да се оптимизира допълнително на по-късен етап. Той и @anselme сега разглеждат процесите за обработка на данни, описани в основния раздел по-долу, като @qi_ma отстранява грешки в процеса на потвърждение и обработка на грешки при клиента.
@Joshuef представи Bors, система за автоматизация, която интегрира множество PR наведнъж, така че спестява реално време, когато работи – което горе долу вече е така след малко борба, за щастие. Той и @oetyng също работят върху преместването на регистрите при Възрастните, опростяване на качването на регистрите и облекчаване на настоящото изискване за изпращане на заявки до всичките седем старейшини (вижте по-долу).
@bochaco обмисля консенсуса за членство в потока на маршрутизацията и обработката на възлите, които са излезли офлайн, и как това ще бъде интегрирано с работата на DKG, която @davidrusu и @danda проправят.
@chriso актуализира и подрежда CLI документацията, а @lionel.faber поправи някои тестове от край до край, които не преминаха, като актуализира инструмента за тестване на мрежата в процеса на работа.
Работа с данни
Сърцето на Safe мрежата е способността й да съхранява данни сигурно, надеждно и за постоянно. Ето и преглед на нашето текущо мислене относно обработката на данни. То засяга и други проблеми, като например потребителския интерфейс/UX и проверките на функционалността на възрастните, за да видим дали правят каквото трябва, както и механизъмът, чрез който клиентите плащат за съхранение.
Валидни данни
Данните, съхранявани в мрежата, трябва да са валидни от гледна точка на мрежата. След като част от данните са валидирани, те потенциално могат да бъдат съхранени от всеки.
Всеки елемент от данни се състои от име, съдържание, подпис и ключ на секция.
Името трябва да бъде подписано с всеки валиден (стар или текущ) ключ на секция, а ключът на секцията ще бъде от секцията, където се съхранява.
Напомняме, че една секция се състои от седем вземащи решения Старейшини и много повече (60 до 100) Възрастни, които съхраняват данни и ги предоставят на клиенти, когато са инструктирани от Старейшините.
Данните се съхраняват от четиримата възрастни, които са най-близо (по отношение на XOR) до името им.
Капацитет за съхранение
Поглеждайки от по-далеч, всеки Възрастен всъщност е нечий компютър. Може да е облачна виртуална машина, домашен компютър или Raspberry Pi - или дори смартфон, при условие че има достатъчно място за съхранение. Но колко място за съхранение е достатъчно? Това е малко сложно, защото изискванията вероятно ще нараснат с времето.
Ако при Възрастен свърши мястото за съхранение, той ще спре да реагира правилно и ще бъде наказан (загуба на възраст на възела). Ако машината се използва и за други неща, като работа, музика, съхраняване на снимки и т.н., запълването със Safe парчета от данни също ще им повлияе, така че и по двете причини е важно собственикът й да получи достатъчно предупреждение, когато капацитетът бива изчерпван - както и самата мрежа да бъде наясно с това.
Тук има няколко възможности. Първо, ние не задаваме ограничение за Safe съхранението, просто измерваме оставащото място на диска и предупреждаваме, когато е почти пълен. Това има предимството на простотата, но тъй като съхранението е фонов процес, пълният капацитет може да бъде достигнат и потребителя да получи неприятна изненада.
Друг вариант би бил потребителят да избере фиксирана стойност за обема за съхранение, с предложени ограничения въз основа на наличното пространство в момента на стартиране на възела, като подтикне хората да предоставят полезно за мрежата пространство, може би чрез подчертаване на средната стойност.
Това дава на потребителите повече контрол, но недостатъкът е, че нито ние, нито те, всъщност знаем каква е идеалната стойност и как може тя да се промени с течение на времето.
Възможно е да се създаде специален разширяем дял само за данни от Safe мрежата, но това може да бъде сложно за изпълнение, като се има предвид разнообразието от платформи и операционни системи.
Така че, това все още е в процес на обсъждане.
Проверка на поведението на Възрастните
Когато клиентът иска да получи някои данни, той отправя заявка към Старейшините в секцията, която е най-близо до името на данните. След това всеки Старейшина изчислява кои четирима възрастни трябва да държат парчето данни. Старейшината съхранява запис на идентификационния номер на операцията, която Възрастните трябва да изпълнят. Когато Старейшините получат отговор от Възрастен с блок от данни, те разделят идентификатора на операцията от името на този Възрастен, тъй като вече е изпълнил задачата.
На този етап Старейшините ще проверяват за неотзовали се Възрастни. Възрастен се приема за неотзовал се ако се представя значително по-лошо от своите съседи (точният толеранс ще се установи експериментално). Възрастта на възрастните, които не реагират, ще бъде намалена наполовина и може да бъдат преместени.
Кеширане при Старейшините
От известно време мислим за най-добрия начин за внедряване на кеширане. За много операции смятаме, че кеширането върху възли Старейшини ще помогне за производителността и управлението на данни, когато възлите излизат офлайн, като мярка за безопасност срещу загуба на данни и начин за ускоряване на преразпределението на парчета данни.
В тази схема Старейшините ще съхраняват всички данни, поставени или извлечени от секцията в LRU (най-малко използван) кеш. Капацитетът на кеша ще бъде ограничен, като Старейшините ще премахват от него най-старите използвани данни, ако е необходимо.
Какво се случва, когато повишаваме възел?
Когато повишаваме Възрастен до Старейшина, Възрастният първо публикува своите данни към други Възрастни и Старейшините записват парчетата в своя LRU кеш, като премахват произволно всички над ограничението им за размер, ако е необходимо.
Какво се случва при рестартиране?
Когато Възрастен рестартира или се премести, той изпраща своите парчета до тримата най-близки Старейшини до името на парчето и те съхраняват колкото е възможно повече в своя кеш. Старейшините от своя страна изпращат всяко парче до четирима възрастни.
Старейшините могат да изхвърлят данни от кеша си, но Възрастните не могат да премахват данни. Възрастните непрекъснато отчитат нивото си до Старейшините и след като са пълни на 90% повече данни не се изпращат към тях.
Съхранение на данни от клиент
Когато клиент съхранява данни, той ги изпраща на трима старейшини за подпис. Защо трима? Защото е гарантирано, че сред тях ще има един честен възел, тъй като предполагаме, че има не повече от двама злонамерени Старейшини в секция от седем. С един честен Старейшина, стига данните да са валидни, клиентът в крайна сметка ще получи свръхмнозинство от подписите (5) от честните Старейшини на секцията, което означава, че те могат да бъдат съхранени. Веднага щом един възел върне потвърждение с мрежов подпис, тази част може да се счита за съхранена.
Получаване на данни като клиент
Тъй като парчетата са подписани и самопроверяващи се, в случай на неизменни данни клиентът се нуждае само от едно парче данни. Не го интересува дали е подписано в мрежа или не, защото е неизменно.
Променливите (CRDT) данни са малко по-сложни. В този случай контейнерът е подписан от секция, но съдържанието се подписва само от клиента (собственикът на данните). По този начин данните се самопроверяват и трудно се повреждат, но злонамерен или дефектен възел може да откаже да достави съдържанието или да даде на клиента старо съдържание.
Така клиентът иска да се увери, че получава възможно най-много от данните, което означава, че трябва да поиска данните поне от свръхмалцинство Старейшини (трима). Колкото повече копия има, толкова по-бързо може да обедини тези копия, за да пресъздаде най-новата версия на данните.
Плащане за съхранение
Този модел се вписва добре в използването на DBC за заплащане на съхранение предварително. Когато клиент поиска да се съхрани 100 парчета, Старейшините се връщат с цена за подписване на имената на тези парчета.
Офертите на старейшините трябва да са едни и същи. Всяка по-стара оферта, която е изключително различна, би предполагала дефектен Старейшина и клиентът би могъл да обяви този факт обратно в секцията, за да може да бъде разгледан.
След това клиентът плаща посочената сума, преди да съхрани данните си.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България