Тази седмица ще навлезем малко по-подробно в разпределените/разпокъсани монетни дворове, как те се вписват в DBC, поверителността и какво означават както за мрежата, така и за потребителското изживяване.
Общ напредък
Дейвид Русу и @danda експериментираха с добавянето на принудителни еднократни ключове към работата си по заслепените подписи и също така накараха клиента да пише в разходната книга. Работата все още е в ход, но засега изглежда добре.
Поправихме много грешки тази седмица. Преборихме се с пореден проблем с паметта на възлите около запазването на файлове. Тези скокове на паметта са причинени от проблем с усилването на съобщението, причинен от потоците AE на клиента, както и от Възрастни комуникиращи към клиенти. Поправките за тях вече са обединени и използването на паметта е намалено значително.
След това започнахме да търсим повече обобщения относно съобщенията в мрежата, като възлите са настроени да отпечатват тези статистически данни заедно с използването на ресурсите им в логовете. След като приключим с това, ще започнем да разглеждаме използването на цялата тази информация в нашите системи за тестване, за да гарантираме, че повече усилващи грешки не могат да се промъкнат.
Във връзка с това @chris.connelly се рови в qp2p, премахвайки част от функционалността за обединяване на връзки, която вече не е необходима.
@oetyng реализира обработката на обратното налягане (съпротивление или сила, противопоставяща се на желания поток от данни чрез софтуер). Идеята е възела да проверява натоварването на процесора си, когато приема заявки. Ако е над определено ниво, той ще върне съобщение, съдържащо натоварването на процесора. Получаващият възел може след това да регулира своите комуникации въз основа на тази информация. След известно време се връща към настройките по подразбиране.
Не е необходимо да се синхронизира тази информация или да се постига споразумение. Работата с обратното налягане е като регулирането на движението по улиците. Когато повечето шофьори спазват указанията за трафика, трафикът протича по-гладко, дори ако има някои откачени шофьори 
Това означава, че въпреки че лош възел може да избере да не следва указанията, тъй като повечето възли в мрежата ще работят правилно и ще следват указанията, трафикът ще бъде подобрен в сравнение с липсата на тези насоки.
Поне това е идеята и ще продължим да го тестваме още известно време. Това е ново измерение на мрежовата комуникация, нещо като AE, което ще изисква време, за да се наложи.
@Anselme насочи усилията си в процесът на самокриптиране, който изпраща някои объркващи грешки, които объркват някои единични тестове. Сега той обмисля преструктуриране на NRS, за да го опрости.
Междувременно @Lionel.faber подобри начина, по който GitHub Actions работи за автоматизиране на внедряването на тестовите ни мрежи в Digital Ocean, което се отрази много добре на екипа, а @Qi_Ma установи някои аномални поведения с AE. С всяка смачкана грешка се приближаваме малко повече до нов публичен тест.
О, и сме много щастливи да получим PR от @davidpbrown. Страхотно е членове на общността да се включват към усилията ни. Ако някой иска да се включи, първо трябва да копира хранилищата - повече тук.
DBC монетни дворове
DBC монетните дворове съществуват от 90-те години на миналия век, но не станаха много популярни.
Един сериозен проблем, възпрепятстващ популяризирането им, е, че те обикновено са централизирани и по този начин изискват потребителите на системата (притежателите на монети) да се доверяват напълно на оператора на монетния двор. Злонамерен оператор на монетен двор може да надуе паричното предлагане, без никой друг да знае, като по този начин открадне стойността от всички потребители. Също така операторът на монетен двор може просто да изчезне и всички монети да изгубят стойността си буквално за една нощ. Така че човек трябва да се доверява на оператора на монетен двор не само днес, но и утре, както и да вярва че никоя трета страна, хакер, вътрешна информация или правителство не могат да повлияят на тяхната работа.
Децентрализацията чрез секции (sharding) е централна характеристика на дизайна на Safe мрежата. Дизайнът на SN DBC използва и надгражда върху това, за да създаде монетен двор, който е едновременно децентрализиран и мащабируем. Към днешна дата нито една работеща криптовалута [1] не е включила децентрализирани монетни токени DBC, доколкото ни е известно, така че това е наше нововъведение. Целта ни е да се наложи до световно използване с незабавни (и частни) транзакции.
Функционалността на децентрализацията може да бъде разделена на няколко основни области:
- MintNode партньори в рамките на Секция.
- Sharding: Всеки раздел е отговорен за подмножество от DBC.
- Агрегиране на клиенти
- Разпределена разходна книга, написана от Клиента
Нека разгледаме всеки от тях.
MintNode партньори в Секция.
В рамките на секция всеки Старейшина изпълнява и ролята на MintNode. По този начин има 7 възли, като други са готови и чакат да заменят всеки възел, който изгуби връзка. Когато секцията се формира или членството се промени, възлите създават кръг за генериране на разпределен ключ (DKG), за да създадат споделен BLS ключ. Това е ключ с множество подписи, така че 5 от 7 (супер мнозинство) възли трябва да подпишат парче данни, за да се счита за валидно. В случая на DBC, подписаните данни се наричат ReissueShare. Тези ReissueShares трябва да бъдат събрани от супер мнозинство от възли в секция, за да завърши преиздаването на DBC-тата, управлявани от тази секция.
Да кажем, че един от възлите е злонамерен. Може би потребител е сключил сделка с възел, за да похарчи двойно един от своите DBC. Злонамерения възел може да отговори с фалшив ReissueShare за повторно похарчване, но този ReissueShare сам по себе си е безполезен, клиентът трябва да убеди свръх-мнозинството възли, преди да може да събере достатъчно ReissueShares, за да сертифицира повторно издаване за второ похарчване на същата сума.
Получаването на статус на възел издател на монети е трудно по отношение на времето и необходимите ресурсите (Старейшина в Секцията) на първо място. Safe мрежата има концепция за Възраст на възлите, чрез която Възрастните възли трябва да се докажат като надеждни и честни във времето. Само най-стария възрастен се избира за Старейшина, когато съществуващ Старейшина изчезне. Освен всичко това възел не може да избере в кой раздел да бъде. Всички тези стратегии затрудняват нападателя да постави множество злонамерени възли в секция, свързана с тяхната DBC дейност.
Sharding: Всяка секция е отговорна за подмножество от DBC.
Sharding е общ термин, който означава разбиване на данни, така че различните секции да обработват подмножества от данни.
Нашият подход за разбиване всъщност е доста прост. Ключът за харчене на DBC (универсален уникален еднократен ключ) определя коя секция отговаря за обработката му. Клиентският софтуер е отговорен за изпращането на идентичен ReissueRequest до всички възли на монетния двор във всички секции, съответстващи на DBC входовете в ReissueRequest.
В следния пример имаме 3 входа, всеки от които се обработва от различни секции, всяка секция отговаря със свръх мнозинство (5 от 7) преиздадени разрешения.
Тъй като MintNode преминава през входните DBC, за всеки един той проверява дали носи отговорност или не. Ако MintNode е отговорен за DBC, се проверява в Разходната книга дали този DBC вече е изразходван. Така че MintNode ReissueShare предоставя само SignatureShare само за DBC, за които определена секция има правомощия.
Агрегиране на клиенти
Когато потребителят иска да преиздаде DBC, клиентският софтуер на потребителя се свързва с всеки от 7-те MintNodes на секцията(-ите), отговорна за входните DBC-ти и изпраща ReissueRequest. Всеки възел потвърждава заявката и ако всичко е правилно, той отговаря с ReissueShare, който съдържа BLS SignatureShare.
Клиентският софтуер събира отговорите ReissueShare от всички MintNodes, с които се е свързал, и ги проверява. Ако поне 5 възли в даден раздел са отговорили правилно, тогава клиентът може да комбинира своя SignatureShare, за да формира окончателен Mint Signature за всеки изходен DBC. С подпис в ръка клиентът след това конструира действителните DBC-ри, които по-късно могат да бъдат изпратени като вход към друго преиздаване.
Разпределена разходна книга, написана от Клиент
Това е функция, която е в процес на разработка. Основната идея е, че Клиентът се ангажира с дадена ReissueTransaction и публикува този ангажимент, идентифициран от разходния ключ на DBC (или хеш на ключа), в Safe мрежата, преди да направи ReissueRequest. След това всеки MintNode трябва само да прочете записа на Spentbook за всеки DBC и да потвърди, че записът е правилно подписан от собственика на DBC. Това опростява операциите за MintNode, който вече не трябва да записва никакви данни, и запазва идемпотентността на API-то за преиздаване на MintNode. С други думи, клиентът може да извика преиздаване много пъти с един и същ ReissueRequest и винаги да получава един и същ отговор.
Планираме да разгледаме по-подробно за Разходната книга, в някои от следващите седмични новини.
[1] През 2019 г. беше публикувана бяла книга, описваща децентрализирана система DBC Mint, наречена Scrit. Дизайнът на Скрит е значително различен от нашия и изглежда не е бил публично приложен към настоящия момент.
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България