През последните няколко години често симпатизирахме на Сизиф от гръцката легенда. Сизиф трябвало да бута камък нагоре по хълм цяла вечност, само за да се търколи обратно надолу веднага щом наближи върха.
Не искаме да изкушаваме прословутите отмъстителни гръцки богове, но сме все по-сигурни, че този път най-накрая стигнахме върха и седим спокойно на платото. Защо тази увереност ще попитате, о, вие, които сте с нас през всичко, о, вие, които може би изпитвате слабо чувство на дежа вю?
Ами защото бъговете стават по-малки и ги поправяме по-бързо. Защото целият екип поправя грешки заедно, вместо всеки да има специализация. Тъй като тестовите мрежи продължават по-дълго и дават резултати, които можем да разберем и да се справим с тях. Защото можем да повтаряме в движение с осезаеми подобрения. Защото си сътрудничим с хора с подобно мислене. И защото общността се занимава със собствени корекции. Преминахме от теоретичното към практическото и това е чудесно усещане.
Цяла купчина PR-и влязоха тази седмица, от екипа, до екипа и до някои други проекти. В обобщение:
- Корекция за връщане на повечето възли, а не на всички.
- PR за плащане само на един възел, а не на всички тях, докато все още се репликира към близката група.
- Друг за репликация, относно използване на
tokio::Intervalза принудителна репликация вместо Instant, за справяне с пикове в трафика, които причиняват блокажи. - Промяна в клиента за проверка само на части, които достигат мнозинство за репликация.
- Корекция за peer проблем с дублиране при задействане на репликация.
- И друг, който експериментира с разширяване на обхвата на репликация.
- След това има един, който премахва бавното регистриране на content_hash за големи записи - вероятно изтичане на памет.
- Отново относно регистрирането, има едно, което добавя регистриране на SwarmCmd за профилиране на производителността, друго, което добавя регистриране на KBucketKey на възел и друг, който коригира логове за тайминга.
- Освен това има PR на @bzee към
libp2pза справяне с непрекъснато нарастващ адресен вектор за съхранение - друг кандидат за изтичане на памет. - След това има корекция за неуспешни тестове за възнаграждение чрез излъчване на NetworkEvent на GossipSub публикации.
- Освен това има още няколко чакащи да кацнат от отделните клонове на екипа.
Благодарим на @southside за неговия полезен PR за просто подобрение на изхода и на shuoer86 за някои корекции на печатни грешки. Всички останали, не се срамувайте. Ако забележите нещо, което може да бъде променено или подобрено, пуснете PR или ни уведомете във форума.
Общ напредък
@joshuef разглежда вариациите в цената за съхранение и как клиентите се завъртат ненужно върху увеличаването на цените и плащат за данни, които вече са съхранени. (PRs 887/888). Затягаме системата за плащания, като проверяваме кой има частта и им изплащаме, ако е необходимо, а не изплащаме на всички. На свой ред това намалява стреса върху процеса на проверка, което означава по-малко безсмислена дейност и подобрена производителност.
Свързаните подобрения включват елиминиране на излишно хеширане на съдържание и проверяване само на части в по-голямата част от близката група, а не на всички, за да се избегне ненужна работа.
@bochaco работи върху промени в документацията за нови команди cli/rpc-client и тества testnet-deploy, за да провери дали CashNotes може да бъде изтеглен и депозиран в локален портфейл. Той също така финализира процеса за плащане на възлите на Фондацията и подготви най-новата тестова мрежа, за да я изпълни.
@bzee преглежда плащане към един възел за съхранение на данни. Както беше обсъдено миналата седмица, това може да бъде хубава евтина и мръсна опция за съхранение без излишък, стига да се окаже достатъчно надеждна. Освен това се надяваме, че е поправил друго изтичане на данни около непрекъснато нарастващо съхранение в „libp2p“, който съдържа идентичности на известни възли. Екипът на libp2p се занимава с това сега.
Междувременно @anselme обнови плащанията за съхранение с CashNotes и Transfers.
@roland насочва вниманието си към репликацията, като я забавя от моментален до проверява на всеки 10 секунди, за да избегне нежелани блокажи другаде. Освен това Roland оптимизира начина, по който възлите записват и съхраняват своите близки партньори, за да избегне дублиране.
Репликирането на регистри е друг проблем, който ни задържа. Ако даден регистър се промени по време на процеса на репликация, различни възли могат в крайна сметка да държат различни версии, като възникват проблеми поради това, че конвергенцията на CRDT не се случва навреме. @Qi_ma представи корекция и за това.
И @chriso продължава да подобрява процеса на автоматизация на тестовата мрежа, включително команда за инсталиране на мениджъра на възли.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България