Е, беше неизбежно да се случи. След поредица от успехи, RoyaltiesPaymentNet беше прокълнат от високо използване на паметта, което унищожи много възли, преди дори да могат да стартират, и остави останалите доста зомбирани. Призрачното е, че всичко работеше добре в нашите вътрешни тестови мрежи (макар и с леко повишени нива на памет). Възможно ли е бедният RoyaltiesPaymentNet да е бил поразен от тъмни сили извън нашето разбиране? 
Или може би има логично обяснение. Главният заподозрян е „GossipSub“, системата, чрез която възлите, извършващи транзакции, разпространяват факта до основните възли, които след това поемат своя дял. GossipSub се занимава с много повече съобщения от очакваното. Все още не е ясно дали това е зацикляне, или клиентски презареждания, изпращащи повторно роялти плащания, или нещо друго.
Един проблем е, че всички възли се опитват да декодират всички трансфери, причинявайки много ненужна дейност, друг е, че libp2p се разпределя доста щедро… Имаме някои PR, които да помогнат там и се надяваме, че това все пак ще проработи!
Има и някои други корекции, включително корекции на libp2p, криптирани трансфери и репликация при put промени, които трябва да намалят натоварването, когато стартираме друга тестова мрежа.
Благодарни сме, че екипът на libp2p е отзивчив и отворен да ни помогне. Тази седмица @dirvine се свърза с тях относно изграждане на Sybil защита въз основа на някои скорошни изследвания и те казаха, че са отворени към идеята.
Общ напредък
@roland проучва разделянето на парчета и процеса на плащане, а също така добави нова функция към CLI, която гарантира, че потребителят има достатъчно баланс преди да изпълни действие като качване.
@chriso работи върху управлението на възлите. Windows винаги е по-труден в това отношение и той се сблъска с някои проблеми, но сега в повечето случаи е работи.
@joshuef изследва високото използване на паметта и зациклящите съобщения в GossipSub, което може да е причинило повредата на тестовата мрежа, както и други малки поправки, и се стреми да внедри плащане към един нод, което трябва да ускори процеса на валидиране и да подобри производителността.
@bochaco създаде PR, за да преработи валидирането на трансфера, за да го направи по-ефективен, и също така беше основният двигател за внедряване на криптирани роялти трансфери. Тестовете вече работят.
Претърпяхме няколко неуспешни плащания при тестване, докато преминаваме към плащане само на един възел. @anselme се рови в тях и работи, за да направи проблема по-лесен за отстраняване на грешки.
@qi_ma поправя някои други вътрешни тестове, които се провалят.
И @bzee също работи върху плащане към един нод, като същевременно предлага някои подобрения на работните Kad API потоци.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България