Напоследък се задълбочихме в работата на цифровите сертификати носители (DBC), като проучихме как работят и защо са толкова подходящи за Safe мрежата, но какво всъщност се случва, когато плащате за качване на данни или прехвърляте малко SNT на друго лице? DBC транзакциите са темата на новините тази седмица.
Общ напредък
Предаването вече е завършено, полирано и интегрирано в sn_network, благодарение на солидна работа на екипа, особено @anselme, който се занимаваше с това през последните няколко седмици. Като напомняне, Предаването управлява процеси като разделяне и отпадане на възли, където трябва да сме сигурни, че данните се копират на правилните места с достатъчно копия за излишък.
@Chriso завърши първата версия на автоматизацията за проверка на лиценза. След като наскоро рационализирахме лицензирането на кода ни, искаме да сме сигурни, че той ще остане такъв и да гарантираме, че ще се използва само по предназначение. Лицензът GPL3 е „copyleft“, което предотвратява „подлицензиране“, т.е. хората, които извличат нещо ново от оригиналния код, нямат право да променят типа на лиценза на своето копие; това гарантира, че всеки Safe код ще остане с отворен код. За генеричните библиотеки сме по-малко ограничителни.
Защо BSD-3-клауза? Както при MIT и Apache, това е доста либерално, но с допълнителната трета клауза, която предотвратява одобрението от оригиналните автори с всякакви производни продукти, и е полезно за защита на репутацията на MaidSafe. Преди имахме двойни лицензи за много хранилища, но изглежда няма голяма полза от това и е по-лесно за автоматизиран процес да наложи използването на един лиценз.
Що се отнася до системния мониторинг и визуализация, @yogesh се занимава със стека на ELK и той трябва да бъде готов за изпробване от общността много скоро. Следете 
И @JimColinson въвежда в писмен вид стратегическите цели на MaidSafe и Safe Network, като разглежда ключовите мерки, които трябва да предприемем, за да постигнем целите си, както и идентифицира всички потенциални препятствия, което ни дава време да начертаем курс около тях.
Също така сърдечни благодарности на @stout77 за предоставянето на корицата на новините тази седмица! 
DBC в действие
Какво се случва, когато харчите DBC в Safe мрежата? Какви са елементите на една DBC транзакция? Преди да задълбаем малко по-дълбоко, ето едно много кратко обобщение…
DBC е цифров файл, който кодира редица фактори, включително неговия родител, сумата и идентификацията, като подпис или ключ, за да покаже, че е валиден. За да изхарчите DBC, първо трябва да го преиздадете чрез Старейшините.
Транзакцията също е цифров файл. В този случай той кодира входните DBC и изходните DBC.
Опростена версия на транзакция в Safe мрежата протича както следва:
Клиент (човек или приложение) създава желаната транзакция, например „вземете тези 100 SNT DBC от портфейла ми и създайте два нови DBC, 90 като плащане към магазина и 10 като ресто за мен“. Клиентът подписва транзакцията и я изпраща до съответната секция според XOR адреса на файла на транзакцията.
Старейшините на секцията потвърждават транзакцията, като гарантират, че всички входове са валидни DBC, които никога не са били изразходвани, и след това я записват в разходната книга.
Всеки Старейшина проверява, че транзакцията е в разходната книга и дали сумата на входните и изходните DBC е нула (така че пари не се създават или губят, просто се прехвърлят към нови DBC) и връща транзакцията на клиента с неговия дял от подписа.
След като клиентът събере свръхмнозинство от подписаните дялове (5 от 7 Старейшини), той отново предава транзакцията с попълнен подпис на Старейшините, за да бъде преиздадена. Двойните разходи се предотвратяват от факта, че транзакцията с нейните резултати вече е записана в разходната книга. Всеки изходен DBC може да бъде само преиздаден (изхарчен), така че няма значение колко пъти е изпратен повторно.
Проверка и прикриване
Всичко по-горе изброено е добре. То предотвратява двойното харчене и премахва необходимостта Секциите да синхронизират разходните книги помежду си. Въпреки това има какво още да се подобри.
Първо, ние използваме библиотеката Rust bulletproofs, за да проверим дали диапазонът на DBC сумата е положителен - отрицателните суми биха позволили парите да се създават от нищо - очевидно това е нещо, което не искаме.
Втората важна мярка е прикриването. Използваме поверителни транзакции (RingCT), за да скрием ключовете на собственика и получателя. Въпреки че ключът на собственика е скрит, старейшините все още могат да кажат дали транзакцията, записана в разходната книга, е валидна. По подобен начин бронирането (bulletproofs) крие количеството, но все пак могат да проверят дали входните суми балансират изходните суми.
Стъпките на прикриване се случват преди транзакцията да бъде записана в разходната книга, което ефективно прекъсва връзката между родителския DBC и неговите изходи. Ако не правихме това, щеше да бъде лесно да се проследят всички транзакции, тъй като всички DBC се свързват обратно към генезис DBC-то и нямаше да има поверителност.
DBC Генезисът
Връщаме се в началото, тъй като точните подробности за това как разпространяваме DBC към фермерите и притежателите на токена (MAID) все още се разработват. Текущото ни мислене е, че всички SNT ще бъдат зададени в един DBC генезис - такъв без входове.
Така че всички SNT, които някога ще бъдат създадени, ще бъдат в тази една форма, като Вселената преди Големия взрив. След като мрежата стартира реално, DBC ще бъде преиздадена, разделена и разпространена по целия небосклон. Най-добрият механизъм, по който това разпространение да се осъществи е това, което разглеждаме в момента.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България