Safe Network новини 🇧🇬 29.7.2021

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

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

Общ прогрес

@danda и Дейвид Русу ръководят дизайна на поверителните транзакции и адаптират DBC за прилагането на еднократни ключове. @danda обяснява всичко това по-подробно в тази публикация.

От страна на клиента, @yogesh претърсва кода, за да даде възможност на клиентите да общуват директно със секции, където се намират парчетата данни, което е много по-ефективно от маршрутизирането на всичко през една секция.

Маршрутизация: @lionel.faber е в контакт с екипа на quinn, които предложиха някои идеи за това, което причинява някои от проблемите с изчакване / нулиране, които потребителите на тестовата мрежа имаха. Също така преместваме аспекти на функционалността за маршрутизиране към qp2p, за да намалим сложността.

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

Един от по-новите MaidSafer програмисти, който се стреми към реформата на съобщенията, е @Chris.Connelly. Ето кратко представяне от Крис:

Аз съм живеещ в Единбург софтуерен инженер с опит в разработването на уеб услуги и автоматизация на облачната инфраструктура, но сега се стремя да разширя хоризонтите си в разпределени и децентрализирани системи. Вярвам страстно в цялостното инженерство (като се има предвид цялата система и избягването на специализираните роли) и пиша надежден софтуер, използвайки Rust (а понякога и Elm за нещо странично), и съм въодушевен от работата си в MaidSafe!

Pedersen заявки и доказателства за обхват

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

Така че, ако имам 30 токена, плащам ви 20 и някой друг плаща 10, тази транзакция може да бъде проверена от трети страни (равни ли се входните и изходните стойности, „истина“ или „не истина“?), без те да знаят съответните стойности.

За да се харчат DBC, те трябва да бъдат разрешени от издател. Pedersen заявките дават възможност на издател да провери дали входните и изходните стойности на DBC са равни (т.е. валидни) и да подпише транзакцията, без да знае точните суми, които се изпращат.

Една слабост на Pedersen заявките, когато се използват за валидиране на транзакции, е, че те могат да бъдат измамени с отрицателни числа. Транзакция с вход 20 и изход 30 и -10 би била валидна, но тъй като „отрицателни пари“ не могат да съществуват като монета, на практика платецът е превърнал 20 монети в 30 монети. Магия! (Но не и за икономиката.)

Доказателствата за обхват правят криптографски невъзможно изходната стойност да бъде извън определен диапазон, да речем 0 - 2^32. Ние налагаме това, като обявяваме транзакцията за валидна само ако всеки изход съдържа и доказателство за диапазон.

Така че, ако имам DBC за 30 монети и искам да платя на Алис 20 и на Боб 10, процесът протича така:

Изпращам моя DBC към издател заедно с Pedersen заявка с (криптиран) вход като “30” и (шифрованите) изходи като “20 + доказателство за обхват” и “10 + доказателство за обхват”. Издателя проверява добавянето на входните и изходните стойности и дали всеки изход има валидно доказателство за обхвата, подписва транзакцията и преиздава DBC на публичните ключове на Алис и Боб (разбъркани).

Преводи:

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


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