Още един testnet е в ход, следим дали последните ни подобрения увеличават стабилността. Включете се, ако имате време. Възлите все още трябва да се изпълняват от облака, докато libp2p има по-добра QUIC поддръжка, но клиентите могат да работят отвсякъде.
Надяваме се да видим подобрена стабилност на възлите, но все още виждаме някои проблеми с паметта. Разглеждайки лог файлове от мъртвите възли, сме склонни да виждаме вълна от съобщения точно преди те да се преобърнат, което е нещо, което проучваме сега.
Някои от вас са забелязали суматоха DBC хранилището в GitHub. Наистина, както споменахме миналата седмица, сега това е във фокуса на нашето внимание и нещата се развиват добре.
Кранчето за монети работи, така че DBC разпределението в тестовата мрежа ще бъде на самообслужване и можем да гарантираме, че хората трябва да плащат за качване на парчета, като плащането за регистрите също е почти готово. След това трябва да се изчисли колко струва съхранението във възлите и как да се използват повторно мрежовите DBC, но сме на добър път да внедрим основна версия на плащане за данни. След това идват на ред механизми за откриване на цените, за които също имаме няколко опции, които да опитаме.
Общ напредък
На DBC фронта @bochaco въведе промяна, за да направи плащането за качвания задължително feat: make Chunks storage payment required by bochaco · Pull Request #533 · maidsafe/safe_network · GitHub. Той разглежда варианти за намаляване на доказателствата за изхарчване по-малки. Rust касите са малко прости тук, така че може да се наложи да изчакаме или да навием наши собствени.
И DBC вече ще се съхраняват в kad record_store - последният от нашите типове данни, който въвеждаме 
@roland също помага тук.
@Qi_ma разглежда специфичен за Windows проблем, при който съхраняването на DBC в хранилището на записи причинява забиване на CI. Той също така обмисля да направи кутията за самошифроване конфигурируема, така че чрез тестване да можем да оптимизираме размера на парчето.
@anselme публикува крана в локалния двоичен файл на тестовата мрежа, за да можем да го проверим задълбочено, преди да го преместим в правилния инструмент за тестова мрежа.
@aed900 разглежда времето за изчакване на връзките и как можем да уведомим потребителите, когато това се случи. Той също се задълбочи в ситуацията с поддръжката на QUIC с libp2b.
@bzee разглежда още подобрения на libp2p и оценява корекцията на връзките, за която говорихме при последното търсене. Текущата тестова мрежа трябва да му бъде от помощ.
@chris търси да преработи инструмента testnet (програмата, която използваме за стартиране на тестови мрежи в Digital Ocean и AWS), за да премахне някои натрупани усложнения.
И накрая, @joshuef проучва текущите проблеми с паметта и обработката, опитвайки се да идентифицира всички потенциални тесни места, които може да причиняват натрупване на съобщения.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България