Обявяваме NatNet за категоричен успех! Доколкото можем да кажем, всички домашни възли, работещи зад NAT, бяха успешно открити и затворени, смекчавайки проблемите, които изпитвахме по-рано, когато мрежата се опитваше да комуникира с недостъпни възли. Сега сме уверени в откриването на възли зад NAT, следващата стъпка на този фронт ще бъде да им позволим да се присъединят чрез пробиване на дупки и UDP/Quic. NatNet беше само TCP.
Наред с това обаче (преминаването на NAT все още се нуждае от малко работа, както споменахме преди, то е доста основно в libp2p, така че това може да отнеме известно време), има много други неща в ход.
Правим първоначален преглед на възлите на доставчика, които могат да изпълняват задачи като архивиране. Ако си спомняте, с libp2p можем да третираме определени възли като доставчици на услуги за изпълнение на специални функции като архивиране.
Другата област, към която се върнахме, е въпросът за оразмеряването на възела (и опитите за сравнение на потоците на репликация). Колко малко е малко? По-добри ли са 1000 малки възли от един голям със същия капацитет? Каква е разликата, когато имаме масово оттегляне? Какви са компромисите? Сега провеждаме някои предварителни тестове.
Общ напредък
@anselme адаптира книгата за разходи, за да съдържа и двата записа за двойни разходи вместо само един. Тогава с тях може да се работи по-лесно. Това е в допълнение към неотдавнашното сливане на работата по получаване на DBC в RecordStore, което означава, че те ще бъдат автоматично репликирани заедно с парчета (само регистрите, останаха за сортиране там).
@bochaco работи върху сериализирането и изпращането на доказателства за плащане до възли, опитвайки различни методи, за да поддържа нещата леки.
@joshuef разглежда предимствата и ограниченията на наличието на множество възли на машина и опциите там. Досега, без оптимизации, 10 възела на машина в Digital Ocean работят сравнително добре (макар и без отлив), въпреки че удвояването на този брой забавя всичко. Това обаче трябва да ни позволи да имаме много, много повече възли в предстоящите тестови мрежи!
Благодарение на информацията от DiskNet и последвалото вътрешно тестване, @roland внедрява RecordHeader и валидира записите, преди да ги съхраним. Това също така ни позволява да разделим адресното пространство между нашите базови типове данни (парчета/DBC/регистър) и да имаме някаква персонализирана обработка там (обединяване на регистър CRDT операции, например).
@qi_ma проучва проблем със затварянето на връзката по време на предаването на данни. Това може да е свързано с използването на RPC адрес за предаване на данни, когато не трябва да бъде. Ако е така, това може да е основната причина за някои от грешките във връзката, които виждаме, както и свързаните с тях проблеми, при които връзките също могат да бъдат затворени, тъй като при търсенето на партньор той се опитва да се свърже с повече от един от своите адреси. @bzee рови там.
Междувременно @Chriso и @aed900 продължават да работят върху инструментите за стартиране на тестови мрежи.
Далеч от кода @jimcollinson отново е силно ангажиран в проучване на пазара и планиране на стартирането. Той и @andrew.james внимателно проучват методи за осигуряване на плавен икономически преход по време на началните етапи на Мрежата, със специален фокус върху ликвидността. Сега, когато фондацията работи успешно в Швейцария, този процес е много по-прост. Андрю също поддържа връзка с швейцарски одитори, за да обсъдят подходящи счетоводни структури.
Така че все още няма нова тестова мрежа. Но все пак е натоварено време!
Преводи:
English 
Russian; 
German; 
Spanish; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България