Честита Нова Година на всички! Отново сме на седлото 
и сме готови да препуснем напред.
Много благодарности към @josh за пускането на скорошната тестова мрежа за общността и на всички, които взеха участие в нея. Някои от аномалиите, за които ни съобщихте, вече сме виждали и в нашите собствени тестове, но имаше и няколко изненади, включително максималното натоварване на процесора, което разглеждаме сега. Наздраве момчета!
Малко бързи новини тази седмица, за да ви уведомим върху какво работим в момента. Щастливи сме да кажем, че вече завързахме няколко хлабави края и сме кажи-речи готови за потегляне.
Общ напредък
С течение на времето разгледахме множество различни начини за изчисляване на свободното пространство в мрежата. Напоследък обикаляхме няколко db директории и добавяхме размери им, за да изчислим използваното пространство. Водени от @anselme, сега опростихме съхранението на данни, като премахнахме усъвършенстваната база данни, за да я заменим с по-опростен процес със структура на директории с двоично дърво. Това наложи да заменим процеса на обхождане на директориите с такъв, който отчита всеки байт, докато се записва и следи общото използвано пространство, което е много по-бързо и по-мащабируемо сега, когато имаме дълбоко дърво от директории вместо една или два такива. Това също така значително ще опрости процеса на повторно присъединяване на възел с парчета данни към мрежата, защото не е необходимо да го измерваме всеки път, заедно с опростяване на разделянето на секции.
Анселме също разглежда как пространството за съхранение, освободено при изтриване на частни регистри (променяеми данни), може лесно да се изчисли.
Говорейки за променливи данни, обмисляхме какъв вид такси трябва да бъдат прикрепени към типа данни на регистъра. Плащането при промяна би било много тромаво, затова искаме да отделим редакциите от процеса на DBC. Понастоящем мислим да таксуваме кратно на цената на неизменна част (blob) PUT за регистър PUT и да позволим безкрайни редакции от собственика на данните (и страни, с които те решат да го споделят) след това.
@bochaco продължи да усъвършенства процеса на членство, т.е. как да поддържаме правилния брой Старейшини в секция и как да добавяме нови възли за Възрастни към секцията, когато е необходимо. Когато нов възел поиска да се присъедини към него, стартира процес, който включва AE съобщения и тест за доказване на ресурсите, и след като старейшините се съгласят да го приемат, съобщението се изпраща обратно до присъединяващия се възел. Този поток вече е интегриран в хранилището sn_membership – поне за Възрастни, които са повишени в Старейшини и Старейшини, които напускат. Въпреки това, този процес на „sn членство“ в момента предполага, че всички включени възли са членове с право на глас (т.е. Старейшини), така че изключва повишаването на възрастен до старейшина. @bochaco и @davidrusu работят по това в момента. Ще обясним повече в бъдещи новини.
Междувременно @lionel.faber търси ускоряване на процеса на CI/CD със самохоствани GitHub runners в AWS. Местни виртуални машини в GitHub Actions могат да бъдат доста бавни - особено под Windows - което се оказа пречка при тестването. Като хостваме услугата сами в AWS, можем да използваме по-мощни виртуални машини, за да завършим работните си процеси по-бързо. Lionel също документира процеса на генериране на разпределени ключове (DKG), който използваме за консенсус.
И като говорим за тестове, понякога те могат да бъдат твърде строги. Как така? Тестовете са предназначени да уловят всяка грешка, когато се случи, докато устойчива на грешки мрежа с CRDT може да е в състояние да заобиколи тези проблеми, достигайки в крайна сметка до гарантирано последователно състояние. Така че може да бъде разточително да се създават тестове, които ще уловят всичко - но това е сложен акт за балансиране!
Показателен случай е грешка при липсващи данни, като тази, която може да сте виждали в тестовата мрежа. Наистина ли липсват данните или просто още не са пристигнали? Може би ще се появят по-късно или може би са там, но има друга пречка.
В този сценарий съобщенията между актьорите също са нюансирани и това е друга тема за дискусия. Когато парче данни е било успешно качено, на клиента трябва (по избор) да се каже, че е съхранено и благодарение на CRDTs това трябва да е 100% сигурно, но ако очевидно е „провалено“, това не е 100% сигурно поради асинхронност и други фактори, така че клиентът се нуждае от опции как да продължи.
@Qi_ma разглежда регистрационните файлове, за да проследи грешката с липсващите данни, а @yogesh търси причината за наводненията от AE съобщения, които понякога затрупват комуникациите между възлите. Свързани ли са? Трябва да знаем скоро. Междувременно @joshuef проучва грешка, която може да причини проблеми във възлите, които са наводнени с заявки от клиенти, причинявайки скокове в паметта на възлите и понякога ги срива. В момента просто ограничаваме това с произволен лимит от едновременни клиентски съобщения, но ще гледаме да направим това динамично въз основа на натоварването на възела, с напредването ни.
Всяка стъпка е още една стъпка по-близо.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България