Днес ще разгледаме допълнително DBC и собствеността. Работата по основната мрежа и DBC/монетните дворове се движи паралелно напред, но вече се доближаваме до възможността да ги обединим 
. В момента се случват толкова много неща - голяма част от които за съжаление е невъзможно да се опишат в настоящите новини- но като обобщение беше добра седмица за преодоляване на някои дългогодишни и заплетени проблеми със стабилността, връзките и тестването.
Общ напредък
@oetyng проучва най-добрия начин за справяне с малки файлове, които няма да бъдат самокриптирани поради техния размер, наричаме ги Точки, за да ги различим от по-големите Петна (> 3072 байта), които преминават през самокриптиране. Точките ще включват много файлове с обикновени текстови данни, включително DataMaps, така че все още трябва да бъдат криптирани, освен ако не са публично публикувани данни.
@yogesh и @joshuef поправят грешка, която изпраща съобщение до всички Старейшини в секция, а не само до тези, които се изисква след съобщение за актуализация на AE. Това драстично увеличаваше съобщенията напред и назад в мрежата, причинявайки натрупване на съобщенията (повече съобщения до Старейшините означават повече съобщения за Възрастните и след това отново обратно). С поправянето, обединено в PR#473 ефективността и пропускателната способност на мрежата се увеличиха, което означава, че нашите E2E тестове преминават много по-последователно.
Въвеждането на някои временни съобщения за тестване на АЕ също е в процес на разработка. Той ще се използва от секции за периодично изследване на други секции в мрежата, търсене на актуализации чрез задействане на AE потоци и ще помогне на секциите да остават актуализирани, давайки повече стабилност на мрежата. (Това в крайна сметка трябва да бъде оттеглено, след като DBC трафикът се пренасочи в цялата мрежа).
@Yogesh също отстрани проблем с AE тестовете, където циклирането причиняваше натрупване на съобщенията.
@ChrisO работи по CLI-то и API-то, като ги актуализира, за да бъдат съвместими с най-новите версии на мрежата, а някои команди вече работят използвайки генезис ключа, въпреки че тази работа тепърва ще се прехвърли в основното хранилище, тя трябва да дойде „скоро“.
@Chris.Connelly и @lionel.faber експериментират с премахването на пула за връзки от qp2p. Пулът за връзки поддържа връзките отворени след първоначален контакт, но това е нефункционален инструмент и нещо като черна кутия. Искаме по-голям контрол, за да можем да оптимизираме използването на ресурси и затова се стремим да внедрим нещо по-добро в safe_network кодовата база.
Предишните проблеми с паметта вече бяха поправени (повечето от възлите на празен ход заемат ~ 80mb памет и достигат до около 250mb памет при натоварване), но има един краен случай, открит от @qi_ma, където регистрационният файл на ново преместен възел е с разрастващ се размер, вероятно защото съобщенията не се получават.
DBC собственост
Когато проектирате DBC система, едно от решенията, които трябва да вземете, е дали DBC ще имат собственици или не. С DBC без собственик всеки, който се добере до DBC, може да го похарчи, което доста добре приближава характеристиките на физическото злато, но това има свои собствени проблеми.
Тъй като всеки, който има копие от DBC, може да го похарчи, обичайна практика е веднага да го преиздадете, след като го получите, за да сте сигурни, че някой друг няма да го похарчи първи.
Това преиздаване включва изпращане на DBC-то в монетен двор, за да бъде преобразуван в нов DBC със същата стойност, това местене на DBC е разточително както за клиента, така и за мрежата, и по-лошото отслабва сигурността ни, тъй като изпращането на DBC до монетен двор може да доведе до открадването му от злонамерен възел в монетния двор (не забравяйте, че всеки, който има копие от DBC-то, може да го похарчи и монетните възли се нуждаят от копие, за да изпълнят преиздаване му).
DBC със собственици разрешават тези проблеми, като добавят публичния ключ на собствениците на DBC-то към него. Монетният двор ще изисква доказателство за собственост, преди да преиздаде притежаван DBC. Това доказателство обикновено включва собственика, който подписва транзакцията за преиздаване.
С добавянето на DBC собственици, можем да съхраняваме DBC публично, без да се страхуваме от кражба, тъй като само ние имаме тайните ключове за изразходване на нашите DBC.
ЗАБЕЛЕЖКА: Всъщност можем да създадем DBC без собственик със собствени DBC, като опаковаме секретния ключ в DBC при извършване на плащане.
Поверителност и притежавани DBC
За да илюстрираме този раздел, представете си, че Сам би искал да получава дарения в SafeCoin, Сам публикува публичния им ключ за дарение онлайн, за да могат всички да го видят, и иска от своите последователи дарения.
Всеки, който иска да дари на Сам, ще преиздаде част от своите DBC на Сам, като използва ключа за дарение на Сам като собственик на DBC и изпрати новоиздадените DBC на Сам.
Сега, за съжаление, всеки, който прегледа дневниците за преиздаването на монети, би могъл да намери транзакциите на Сам, като сканира за транзакции, включващи ключа за дарение на Сам. Това не е това, което искаме от паричната система, създадена с поверителност в сърцето си.
Дълго обсъждахме този сценарий, но със съществуващата криптография не можахме да намерим начин да комбинираме статичен ключ за дарение и DBC използващо еднократни ключове.
За щастие по същото време, когато проучвахме тези въпроси, @mav задълбаваше в математиката зад техниките за извличане на BLS ключове и измисли наистина умна техника, която ни позволява да правим странично извличане на ключове. Техниката позволява на всеки да извлече дъщерен ключ от добре известен публичен ключ.
Например, в горния случай на Сам, да предположим, че Джанет иска да дари $ 10 на Сам. Джанет първо ще извлече нов ключ на собственик, използвайки случаен индекс
owner_index = random_256bits()
owner_pk = sams_donation_pk.derive_child(owner_index)
Тогава Джанет ще преиздаде DBC от 10 долара със собственик, зададен на owner_pk. Тези DBC от 10 долара след това се изпращат на Сам заедно с owner_index. Когато Сам отива да харчи това дарение, той използва owner_index, за да извлече секретния ключ на собственика от секретния ключ на дарението:
owner_sk = sams_donation_sk.derive_child(owner_index)
И така, за да обобщим, ние скрихме публичния ключ на дарението, използвайки индекс на произволно извеждане. Този индекс се изпраща на Сам заедно с дарения DBC, за да може Сам да изведе ключа на собственика, когато иска да го похарчи. Тъй като индексът за извличане никога не се изпраща до Монетния двор, записите за одит няма да могат да намерят препратки към ключа за дарение на Сам.
Разходна книга и ключовете за изразходване
Преиздаването на DBC винаги включва запис в Разходната книга. Разходната книга е дневник на всички DBC, които са били изразходвани, и транзакцията за преиздаване, в която е бил изразходван DBC, може да се мисли за нея като за голяма разпределена таблица, която съпоставя DBC-то с транзакцията. Всеки път, когато се използва DBC, той се добавя към Разходната книга. Когато някой се опита отново да похарчи същия DBC, монетните дворове ще забележат, че той вече има запис в Разходната книга и ще откажат да подпишат преиздаването.
В по-ранните версии на Safe DBC системата карахме самите монетни дворове да добавят записите на Разходната книга за всяко преиздаване, но наскоро преминахме към нов модел, където се очаква клиентите да пишат в Разходната книга. Тази промяна значително намалява натоварването на нашите монетни възли, защото записването в Разходната книга и необходимите проверки на доказателствата за собственост са натоварващи потока на преиздаване части.
За да илюстрираме промяната, нека продължим горния пример, Сам получи DBC дарение от 10 долара и сега би искал да го похарчи.
Първо, Сам изгражда транзакцията, която би искал да изпълни, тук той разделя своите $ 10 на $ 8 DBC и $ 2 DBC.
let tx = ReissueTransaction {
inputs: { $10DBC }
outputs: { $8DBC, $2DBC }
}
Сега, когато Сам е посочил транзакцията, Сам трябва да добави $ 10 DBC за тази транзакция, като я регистрира в Разходната книга.
Писането в Разходната книга изисква доказателство, че всъщност сте собственик на DBC-то, начинът, по който правим това, е да задължим клиентите да извлекат DBC разписващ ключ и да докажат собствеността си чрез подписване на транзакцията.
Разписващ ключ
Ключът за разписване е начинът, по който DBC са посочени в Разходната книга. Извлича се от собственика на DBC-то, използвайки хеша на DBC-то.
let dbc = $10DBC;
let spend_key = dbc.owner.derive_child(sha3_256(dbc))
Може би се чудите защо не използваме директно собственика на DBC? Защо да извличаме друг ключ, когато собственикът трябва да бъде еднократен ключ? Е, монетния възел не вижда случайния индекс, използван за идентификация на собственика, така че нямаме гаранция, че всъщност е уникален ключ.
Разходната книга изисква от нас да имаме уникален ключ за всеки DBC, така че използваме хеша на DBC, за да извлечем ключ за разходи, който гарантирано е непредсказуем. Така че като цяло тук работим с три ключа, получени във верига:
well_known_key <-- published widely and associated with a real entity
owner_key <-- derived from the well_known_key using a random index
spend_key <-- derived from the owner_key using the DBC hash
Ангажиране за транзакция
Сега Сам има транзакция, към която би искал да се ангажира, и ключ за изразходване.
let input_dbc = $10DBC;
let tx = ReissueTransaction {
inputs: { input_dbc }
outputs: { $8DBC, $2DBC }
}
let spend_key = input_dbc.owner.derive_child(sha3_256(input_dbc))
Сам подписва транзакцията с този разписващ ключ и изпраща tx, разписващ_ключ и подпис в мрежата, за да бъде записан в Разходната книга.
След като се разпишете в Разходната книга, остава само да получите подпис от монетния двор, удостоверяващ, че транзакцията е валидна. За да направи това, Сам просто изпраща транзакцията tx към монетния двор, всеки възел на монетния двор ще запита Разходната книга и ще гарантира, че всеки вход за транзакция е ангажиран със същата транзакция. Ако това премине, проверяваме стандартните ограничения за преиздаване, а именно сумата от входовете трябва да се балансира към сумата от изходите и че всеки входен DBC е валиден.
След като всички проверки преминат, Монетният двор подписва преиздаването и връща подписа на Сам, който след това обобщава и формира крайните изходни DBC. Това е всичко.
Този нов поток на преиздаване води до монетни възли, които просто действат като валидатори с възможност само за четене от Разходната книга, това би трябвало да намали изискванията за ресурси от възлите Старейшини и да ни даде по-бърза мрежа.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България