С риск да се повторим, но тази седмица отново можем да съобщим, че тестовата мрежа NodeDiscoveryNet все още работи. Малко груба по ръбовете и има нужда от усъвършенстване, разбира се, но основите й се чувстват много солидни. Тази стабилност вече не е изненада, но след много години на вълнение, докато се опитвахме да накараме това нещо да лети, честно казано, това е типът скука, с който можем да живеем.
Сред настройките, произтичащи от констатациите на тестовата мрежа, ние подобряваме съобщенията за грешка до потребителите, когато възел не успее да се свърже правилно. В момента, когато това се случи, няма очевидни признаци за потребителя, който трябва да рови в лог файловете - въпреки че липсата на съхраняване на парчета е показателна за проблема.
Повечето неуспешни връзки са резултат от опит за свързване с недостъпни нодове. Също така видяхме много повече връзки, отколкото може да очакваме към валидните адреси (като се има предвид, че libp2p предлага мултиплексиране). Повече от дузина на партньор не трябва да съществуват в даден момент, но сме виждали стотици! След известно ровене се оказа, че това е функция (не грешка…) на libp2p, просто не е оптимизирана за нашия случай на употреба. @bzee протегна ръка и Макс Индън от Protocol Labs любезно излезе с корекция, която доведе до намаляване на броя на връзките от десетки до само шест или седем. Благодаря Макс!
Открихме, че възлите извършват проверка „get_closest“ всеки път, когато се добави нов възел, докато те трябва да правят това само когато се присъединят за първи път, така че това е още малко излишни разходи, които намалихме. Ще има още.
В допълнение, разгледахме по-задълбочено сигурността на регистъра, обмисляйки какво би се случило, ако нападател вместо да се опита да промени данните в регистър (на практика невъзможно без правилното разрешение) просто замени целия регистър - не е невъзможно с настоящата ни настройка. Работим по най-добрите начини да поправим това.
Общ напредък
@joshuef направи някои промени в потока на репликация, включително една, която разбърква данните, чакащи да бъдат репликирани/извлечени, за да предотврати единия край на затворената група да бъде притиснат от подреждане в Xorspace. Заедно с прекомерните връзки и прекомерното изпращане на съобщения, това е друга вероятна причина за забиване на възли.
@Roland работи върху тест за проверка къде е определена част от данните в мрежата, а @Qi_ma вкарва регистри в теста за изтичане , така че можем да видим как те се справят, когато нещата станат диви. След това ще разгледаме усъвършенстването на тестовете ни за запазване на данни и ще насочим вниманието си към DBC.
Имайки предвид това, @bochaco преработи как клиентът разделя файловете по време на самокриптиране и плаща за тяхното съхранение. Преди това разделяхме файлове два пъти (първо, за да създадем дървото на Merkle за плащане и след това, когато ги качвахме). Сега генерираме части и ги съхраняваме в локална временна папка, когато плащаме, и четем от тази временна папка на партиди, когато качваме платените части. Това трябва да намали отпечатъка върху паметта на клиента, особено за големи файлове, тъй като вече не е необходимо да се съхраняват в паметта.
@Anselme надстрои крана за токени. Простият самостоятелен файл, който се намираше на локалната машина, сега е HTTP сървър, който изпраща токени до адресите в заявката. И така, това е самообслужване и вече не е необходимо да имаме един човек, който да изисква Genesis ключа, след което да раздава жетоните ръчно, когато хората изпратят своите ключове. Това ни поставя на добро място, когато сме готови да започнем да раздаваме токени, за да тестваме DBC в бъдещи тестови мрежи.
Това скоро ще бъде добавено към testnet инструмента, който @aed900 преработва заедно с @Chriso.
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България