Тази седмица разглеждаме малко по-задълбочено емитирането на SNT токени. Ето как, след първоначалното разпределение на токени при създаването на мрежата, останалите 70% от общото количество ще бъде създадено и сигурно разпределено в резултат на това, че хората качват данни в дългосрочен план. Мислихме малко по-задълбочено как това трябва да работи, така че да е възможно най-просто и сигурно, и премахнахме няколко стъпки от нашия оригинален дизайн.
Благодарности към @southside за тестването на най-новите версии и предоставяне на логовете 
. Сега разглеждаме тези пикове и повреди при възлите.
Общ напредък
@Davidrusu рационализира логовете, така че всеки от тях да е на един ред, за да ги направи по-лесни за анализиране и премахване на допълнителната информация. За съжаление в този процес счупихме Vdash на @happybeing - но се надяваме, че не по начин, който е твърде труден за оправяне.
Голяма част от останалата работа е тестване, тестване, тестване. Следвайки предложение от @Chriso, правим някои промени в начина, по който тестовете влияят на нощното изграждане, като въвеждаме етапен клон и даваме приоритет на коригирането на неуспешни тестове, които предотвратяват пускане там, така че кодът винаги да е готов за пускане или близо до пускане.
И @anselme поправи проблем в стъпката за излъчване на ефимерен BLS ключ в DKG. Както предаването на BLS ключовете, така и гласуването при DKG работят правилно сега и всички членове получават всички гласове, което е важна стъпка.
SNT емисии
Когато потребителите качват данни в мрежата, те плащат. Ние не искаме всяко плащане да води до създаване на нови SNT, а само част от тях и искаме тази част да варира в съответствие с нуждите на мрежата. Ако мрежата изисква повече място за съхранение, делът на качванията, водещи до генериране на нови SNT, се увеличава, за да привлече повече възли за съхранение, когато има достатъчно място, той намалява. Точният механизъм за това все още се обсъжда, но се надяваме скоро да ви предоставим повече подробности.
Плащане, което води до създаването на нов („Genesis“) DBC, се нарича (засега) „Genesis събитие“. Събитието „Genesis“ изисква „GenesisProof“, което е файл, който кодира информация за стойността на DBC и неговите получатели.
Стойността на „Genesis DBC“ се определя лесно – това е фиксирана част от стойността на транзакцията за съхранение (напр. 90% от първоначалното плащане може да бъде възнаградено).
Частта с получателите е мястото, където нещата са малко по-сложни. „Genesis“ събитието от транзакция се случва само в една секция и всички Старейшини и възли за съхранение получават заплащане пропорционално на възрастта на техния възел. Но членството в дадена секция непрекъснато се променя, така че как да разберем на кои възли да плащаме?
Информацията за Старейшините на секциите се съхранява в Section Authority Provider (SAP), но това може да не е напълно актуално и докато се актуализира чрез AE, членството може да се промени отново.
Така че по-добър начин би бил да използваме получателите от „Genesis event“ плащането. В заявката за съхранение (оферта) на клиента се казва на кого да се плати, включително SAP (старейшините) и възлите за съхранение. Възрастта на възлите към момента на заявката може да се изчисли от техния ID. По този начин всеки от получателите може да преиздаде DBC на себе си и на другите получатели по всяко време и плащането ще бъде гарантирано, че ще стигне до тях, дори ако вече не са в секцията, процесът е детерминистичен.
Първото ни място за преиздаване обаче винаги ще бъде клиентът (платецът), тъй като това отнема известно напрежение от мрежата. Обсъждаме дали един от получателите на DBC наградата може да бъде самият клиент, създавайки стимул за клиента да извърши повторното издаване, но ако това не успее, всеки от мрежовите възли, споменати в GenesisProof, може да го направи вместо клиента.
Плащането само към съхраняващи данни Възрастни, а не към всички Възрастни в секция (друг възможен сценарий), работи добре, тъй като означава по-малко DBC и по-малко съобщения. С течение на времето плащанията се извършват на случаен принцип в секцията/мрежата, тъй като възлите за съхранение се определят от XOR адреса на частите от данни.
Така че върху това работим сега. Все още трябва да разберем как да зададем цената за съхранение, как да направим копаенето на SNT неикономично за измамни секции и къде да съхраняваме „GenesisProofs“.
Също така искаме да премахнем псевдонима „Genesis“ за новите DBC, тъй като е объркващ. Едно предложение е RootDBC - какво мислиш, о, наша общност?
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България