Safe Network новини 🇧🇬 30.3.2023

Понякога, когато работите с най-съвременни технологии, всичко, което можете да направите, е да изчакате напредъка да се случи другаде. Това развитие може да отнеме разочароващо дълго време, но тази седмица сме щастливи да обявим значителен пробив на мрежовия фронт. Също така постигаме значителен напредък и по отношение на DBC, таксите за транзакции и начина, по който те се обработват от Старейшините. @oetyng обяснява повече.

Общ напредък

Има множество положителни неща, за които да говорим тази седмица. Първо, малко майсторска детективска работа от @qi_ma :male_detective: разкри основната причина за дългогодишен проблем, който изпитвахме със стартирането на мрежата, което причиняваше грешки в CI. С радост може да кажем, че това главоболие вече го няма.

Следва нещо, описано от @dirvine едновременно като „променящо играта“ а също и малко мистериозно, като нещо „много релаксиращо“. И така, какво е то? Тази седмица Protocol Labs, екипът зад IPFS и Filecoin, актуализира своята libp2p библиотека. Libp2p се оказа доста успешен при мултиплексиране и пробиване на дупки, но досега работеше само през TCP. Това вече се промени и библиотеката работи с UDP и QUIC, което Safe използва за управление на връзките между възлите. Libp2p се използва от Filecoin, Eth и Avalanche и има много отлични инженери, работещи върху него.

Още по-добре, получаваме безплатно пробиване на дупки, локално откриване на възли, DoS защити и много други. Изглежда, че libp2p вече е това, което беше замислено и което се опитвахме да създадем с qp2p: солидна библиотека, фокусирана върху p2p. С неотдавнашното включване на QUIC можем да видим, че екипът на libp2p осъзнава, че много от работата, която са извършили (мултиплексиране на потоци, шум за сигурност и т.н.), е покрита в QUIC.

Както и да е, страхотни новини отвсякъде. Това трябва да означава, че най-накрая имаме голяма стабилност в мрежовия слой за да работи както искаме. Така че шапки долу за хората от libp2p :clap: :tada: С малко ощипване и няколко PR би трябвало най-накрая да можем да заменим Quinn и qp2p в Safe. Ограниченията на тези библиотеки държаха Дейвид буден през нощта в продължение на много месеци. Най-накрая той може да се отпусне. :beach_umbrella:

@bzee вече успя да получи прототип на Kademlia мрежа, спецификиран с libp2p и с малко повече работа би трябвало да работи като тест. @Roland също се рови в документацията, за да види дали можем да използваме това.

@bochaco добави някои CLI команди към RPC възела, за да позволи неща като проверки на нивото на съхранение, заявки за възнаграждение и промени на портфейлите.

И @oetyng изпълнява задълженията си по плащанията. Повече за това по-долу.

Новини за мрежата за плащания

Покрихме доста стъпки към платежната мрежа.

На първо място, както някои вече установиха, когато работеха с локална мрежа, имахме Клиенти пускащи заявки към Старейшините срещу заплащане (твърдо кодирана стойност от 1 нано) и да разширят техния трансфер, за да съдържат и по един DBC за всеки Старейшина. Това означаваше, че когато изпращате монети, всеки въведен DBC, който изразходвате, ще струва 7 нано, платени на Старейшините.

Но плащането беше по същество изгаряне. Защото Старейшините нито можеха да видят, че има плащане към тях, нито да получат достъп до него.

Проверка на размера на таксата

И така, следващата стъпка беше да се въведе „заслепяване“ на сумата на таксата, така че Старейшината да може да провери, че A. има плащане за тях и B., че това е достатъчна сума . Защото не забравяйте, външен човек не може да види каква сума съдържа DBC, нито за кого е предназначен. Трябва да имаме начин да кажем на Старейшините тези неща.

И така, клиентите изпращат двойка шифри - криптирана информация - заедно със своята заявка за похарчване. Когато Старейшините получат това, те могат да го дешифрират и да получат следното:

Индекс на извличане

„Индексът за извличане“ се използва за извличане на публичния ключ (по същество уникалния идентификатор) на новия DBC, съдържащ плащането на таксата. Клиентът извлича този идентификатор от статичния публичен ключ, изпратен от Старейшина, заедно с текущо изискваната сума на таксата при заявка до Старейшина.

Старейшините използват същия този индекс за извличане, за да извлечат съответния таен ключ, с който те могат да отключат стойността в DBC, съдържаща сумата на таксата към тях.

Тъй като този индекс на извличане се изпраща криптиран до Старейшината, никой не може да каже, че има плащане към този Старейшина и няма начин да се види за каква сума е било.

Заслепяващ фактор + сума

Освен това, Клиентът изпраща криптирания „коефициент на заслепяване“ и сумата.

С „коефициента на заслепяване“, Старейшината може да скрие сумата и да я сравни със сумата в DBC транзакцията. Това е така, защото ако се използват един и същ „заслепяващ фактор“ и количество, се получава точно същото неразбираемо изкривяване. Ето защо „заслепяващият фактор“ също е криптиран. Само Клиентът и Старейшината ще знаят сумата.

За повече подробности относно горния поток, можете да прочетете раздела за коментари в горната част на този файл: https://github.com/maidsafe/safe_network/blob/main/sn_interface/src/types/fees/mod.rs

Най-накрая получава таксата

Когато голямо мнозинство от Старейшини са подписали разходите, всеки от тях изпраща „SpentProofShare“ на притежателите на данни в мрежата. При заявка за тези споделяния, SpentProof може да бъде агрегиран от тези подписи и могат да бъдат създадени DBC, съответстващи на всеки от изходите в транзакцията. По този начин Старейшина може да направи запитване към мрежата за тях и след това да изгради DBC, който съдържа плащането на таксата.

От твърдо зададена до динамична такса

1 нано за такса няма да помогне много, затова изровихме изчислението на необходимите токени, за да съхраним данни, които вече имахме в нашите архиви.

Реализацията изчислява необходимите токени за операции за запис като брой токени, които трябва да бъдат платени за определен брой байтове, като се има предвид префиксът на текущита секция, броят на възлите в секцията и процентът на запълване. Това може да се използва и за изчисляване на таксата за превод, тъй като ние просто го захранваме с фиксиран брой байтове.

Предвид входните параметри и дизайна на кривата има ефект върху цената въз основа на търсенето и предлагането, макар и с известна инерция. Изчислената стойност е по-висока, когато има по-малко възли в секцията, когато има по-малко налично пространство и е рания живот на мрежата. Може да попитате какво значи ранен живот на мрежата. Да, предполага се, че по-голямата мрежа означава, че токенът има по-голяма стойност, тъй като повече хора споделят фиксиран брой токени. Следователно, необходимият брой монети за операция също е по-малък с разрастването на мрежата. С други думи, цената отразява дефлационния характер на SNT.

Друго свойство на кривата е, че тя е много плоска на ниско ниво, докато остане около 1/3 пространство, при което започва бързо да се изостря. Причината е таксата да остане възможно най-ниска възможно най-дълго.

Но това не е заместител на истинския пазар. Въпреки че имаме известен контрол върху търсенето/предлагането, той е доста бавен и следователно размерът на таксата въз основа на това е доста твърд. Следователно за мрежата е трудно да отразява действителните промени във фиатната стойност на токена и това може да доведе до големи дисбаланси - което никога не е добро нещо. Такива дисбаланси могат да бъдат твърде много заявки или твърде малко, тъй като действителната стойност не е в синхрон със стойността, изчислена от мрежовите параметри.

Това ни води до възможността клиентът да приоритизира разходите си и какво отваря това за нас.

Разход при приоритетна опашка

„Приоритетът“, прикрепен към разходите, е голям скок напред към истински пазар, където характеристиките на предлагане/търсене на системата са пъргави и отзивчиви.

Това се прави от Старейшините, които поддържат приоритетна опашка, подредена по стойността на таксата, платена им за подписване на разходите.

Ползите от прилагането на приоритетна опашка са следните:

  • Клиентите могат да получат по-ниска цена за тяхното съхранение, ако търсенето е ниско.
  • Старейшините могат да получат по-висока награда за услугите си, ако търсенето е високо.
  • Стимулите за операторите на възли да пуснат допълнителни възли се увеличават, когато търсенето се увеличи.
  • Мрежата става по-отзивчива и може да расте по-бързо (привлича повече работещи възли), когато търсенето се увеличи.
  • Непрекъснатата работа на възлите е по-защитена от претоварване при увеличени клиентските разходи.
  • Натоварването на мрежата се разпределя във времето, тъй като хората отлагат разходите по време на високо натоварване и ги преместват към времена на по-ниско натоварване.
  • Има потенциал за Старейшините да получат по-бърз достъп до наградите си, тъй като могат да ги събират и преиздават в по-голям DBC, когато таксите са ниски.
  • …и още…

Първият пример използва няколко отделни „приоритетни“ стъпки за клиент, които да използвате от потребителския интерфейс на портфейла, когато извършвате плащане. Това премахва необходимостта от ръчно определяне на суми на таксите.

Приоритетът се превръща в такса въз основа на текущите такси в опашката. Високият приоритет би означавал, че плащате подобна стойност на тези, които са по-високо в опашката, и обратното за нисък приоритет. Можете също така да го зададете на над най-високата стойност или под най-ниската и оттам може да започне натискът върху цената въз основа на търсенето и предлагането и нуждите на клиентите и операторите на възли за намиране на равновесие.

Чрез избора на приоритет, Клиентът по същество решава колко бързо иска да бъде обработен. Те могат да го обработят повече или по-малко мигновено или да определят таксата на по-ниско ниво, за да го обработят във време, когато търсенето и таксите са по-ниски.

Имайте предвид, че все още има ограничение за това колко ниска таксата може да бъде зададена от Клиента. Под нея заявката ще бъде премахната и на клиента ще бъде върната грешка.

Трябва също така да е възможно клиентът да актуализира предстоящи разходи, така че да не увиснат транзакциите му, ако таксите и търсенето останат на по-високо ниво.

Резюме

И така, за да обобщим, основната идея е, че изразходването на DBC може да доведе до много изходни DBC. Когато изпращаме заявка до Старейшините за изразходване на DBC, ние също прикачваме тези изходни DBC.

След това Старейшините проверяват сумата и продължават с обработката на разходите.

Наблюдателният читател би забелязал, че таксата, плащана на Старейшина, е в DBC и когато Старейшината иска да похарчи този DBC, тогава ще е необходима такса, за да го изразходва, и ако двете са еднакви… тогава имате… Нищо?
Това е точно така. И така, ако си спомним, че ценовият алгоритъм връща по-ниски стойности, колкото по-голяма е мрежата, можем да видим, че има нещо като ефект на блокиране + ефект от ранно участие в мрежата. Тъй като номиналната стойност на таксата намалява, предишните платени такси ще стават все по-достъпни.

Това също е мястото, където приоритетната опашка помага. Таксите, получени по време на големи натоварвания, могат да бъдат събрани и преиздадени, когато таксите са по-ниски. Друг фактор, който работи за изравняване на натоварването.

Надяваме се, че това ще ви даде добра представа за това, което се готви.


Преводи:

:uk: English :ru: Russian; :de: German; :es: Spanish; :fr: French

  • Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
  • Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
  • Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България