Конфиденциални транзакции в Monero, или как да преведем неизвестно как неизвестно къде

Продължаваме нашия цикъл за устройството на блокчейна Monero, а днешната статия е посветена на протокола RingCT (Ring Confidential Transactions), който представя конфиденциални транзакции и нови пръстенови подписи. За съжаление, в интернет има малко информация за това как работи и ние се опитахме да попълним този пропуск.

Ще говорим за това как с помощта на този протокол мрежата скрива сумите на преводите, защо се отказа от класическите пръстенови подписи на cryptonote и как тази технология ще се развива впред бъдеще.

Тъй като този протокол е една от най-сложните технологии в Monero, на читателя ще са необходими основни знания за устройството на този блокчейн и повърхностни познания в криптографията на елиптични криви (за да освежите тези знания, можете да прочетете първите глави на нашата предишна статия за мултиподписите).

Протоколът RingCT

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

Струва си да се отбележи, че идеята за скриване на сумите не е нова. Един от първите, който я описа, е разработчикът на Bitcoin Core Грег Максвелл в своята статия Confidential Transactions. Текущата реализация на RingCT представлява нейна модификация с възможността за използване на пръстенови подписи (както и без тях), и така получи името си — Ring Confidential Transactions.

Сред другото протоколът помага да се отървем от проблемите със смесването на прахообразните изходи — изходи с малка сума (обикновено получени под формата на реституция от транзакции), които създаваха повече проблеми, отколкото струваха самите те.

През януари 2017 г. се проведе хардфорк на мрежата Monero, позволяващ опционално използване на конфиденциални транзакции. А вече през септември на същата година с хардфорка на версия 6 такива транзакции станаха единствено разрешените в мрежата.

RingCT използва множество механизми: многослойни свързани спонтанни анонимни групови подписи (Multilayered Linkable Spontaneous Anonymous Group Signature, нататък — MLSAG), схема за ангажименти (Pedersen Commitments) и доказателства за диапазон (на български няма утвърден превод на този термин).

Протоколът RingCT въвежда два типа анонимни транзакции: simple и full. Първият тип се генерира от портфейла, когато транзакцията използва повече от един вход, а вторият — при обратната ситуация. Те се различават по валидирането на сумите на транзакциите и данните, подписани с MLSAG-подпис (повече по този въпрос ще говорим по-долу). Освен това, транзакции от тип full могат да се генерират с произволен брой входове, без принципна разлика. «Zero to Monero» в случая посочва, че решението да се ограничи тип full транзакции до един вход е взето на бързо и в бъдеще може да се промени.

MLSAG-подпис

Нека си припомним какво представляват подписваните входове на транзакцията. Всяка транзакция харчи определени средства и генерира. Генерирането на средства става чрез създаване на изходи на транзакцията (директен аналог — банкноти), а изходът, който транзакцията харчи (в действителност харчим именно банкноти), става вход (внимавайте, тук е много лесно да се объркате).

Входът се отнася до няколко изхода, но харчи само един, създавайки по този начин 'димна завеса', за да затрудни анализа на историята на преводите. Ако транзакцията има повече от един вход, такава структура може да се представи под формата на матрица, където редовете са входове, а колоните — ангажирани изходи. За да докажат на мрежата, че транзакцията харчи именно своите изходи (знае техните секретни ключове), входовете подписват с пръстенен подпис. Такъв подпис дава гаранция, че подписващият е знаел секретните ключове на всички елементи на някои от колоните.

Конфиденциалните транзакции вече не използват класическите за cryptonote пръстенни подписи, а на тяхно място дойдоха MLSAG — адаптирана за няколко входа версия на аналогичните еднослойни пръстенни подписи, LSAG.

Наричат се многослойни, защото подписват едновременно няколко входа, всеки от които е ангажиран с няколко други, т.е. подписва се матрица, а не един ред. Както ще видим по-късно, това помага за спестяване на размера на подписа.

Нека разгледаме как се формира ринговият подпис, на примера на транзакция, която харчи 2 реални изхода и използва за размесване m — 1 случайни от блокчейна. Нека обозначим публичните ключове на изходите, които харчим, като
, а key images за тях съответно: По този начин получаваме матрица с размер 2 х m. Първо трябва да изчислим т.н. challenges за всяка двойка изходи:

Започваме изчисленията с изходите, които харчим, използвайки техните публични ключове:и случайни числаВ крайна сметка получаваме стойности:
, които използваме за изчисление на challenge
на следващата двойка изходи (за да е по-лесно да разберем какво накъде поставяме, сме отбелязали тези стойности с различни цветове). Всички следващи стойности се изчисляват по цикъл по формулите, посочени на първата илюстрация. Последно се изчислява challenge за двойката реални изходи.

Както виждаме, във всички колони, освен в колоната с реални изходи, се използват случайно генерирани числа. За π-та колона също ще ни е нужна. Преобразувамев s:
Самият подпис представлява тоз кортеж от всички тези стойности:

След това тези данни се записват в транзакцията.

Както виждаме, MLSAG съдържа само един challenge c0, което позволява да се спести в размера на подписа (който и без това изисква много място). След това всеки проверяващ, използвайки данните, възстановява стойностите c1,…, cm и проверява, че. По този начин нашето кольцо е затворено и подписът преминава проверка.

За RingCT транзакции от тип full се добавя още един ред към матрицата с размесените изходи, но за това ще разкажем по-късно.

Pedersen Commitments

Схеми на задълженията (по-често се използва английският термин — commitments) се използват, за да може една страна да докаже, че знае някаква тайна (число), всъщност не я разкривайки. Например, хвърляте на зара някакво число, изчислявате commitment и предавате на проверяващата страна. По този начин, в момента на разкритие на секретното число, проверяващият самостоятелно изчислява commitment, уверявайки се, че не сте го излъгали.

В Monero commitments се използват за скриване на сумите на трансакциите и прилагат най-разпространения вариант — Pedersen commitments. Между другото, интересен факт — първоначално разработчиците предлагали да се скриват сумите чрез обикновено замесване, т.е. да се добавят изходи на произволни суми, за да се въведе несигурност, но след това преминаха на commitments (при което не е сигурно, че спестиха на размера на транзакцията, както ще видим по-долу).
В общия случай commitment изглежда по следния начин:
Къде C — стойността на самия commitment, a — скриваната сума, H — фиксирана точка на елиптичната крива (допълнителен генератор), а x — някаква произволна маска, скриващ фактор, генерираща се на случаен принцип. Маската тук е необходима, за да не може трета страна да подбере стойността на commitment чрез просто подреждане.

При генериране на нов изход портфейлът изчислява commitment за него, а при разходване взима или изчисленото при генериране значение, или го преизчислява отново — в зависимост от типа на транзакцията.

RingCT simple

В случая на simple RingCT транзакции за да се гарантира, че транзакцията е създала изходи на сума равна на сумата на входовете (не е създала пари от въздуха) трябва сумата на commitments на първите и вторите да бъде еднаква, т.е.:

Коммитмента на таксата се изчислява малко по-различно — без маска:
, където a — сумата на таксата, тя е публично достъпна.

Този подход позволява да се докаже на проверяващата страна, че използваме еднакви суми, без да ги разкриваме.

За да стане всичко по-ясно, нека разгледаме пример. Да предположим, че транзакцията харчи два изхода (тоест те стават входове) на 10 и 5 XMR и генерира три изхода на сума 12 XMR: 3, 4 и 5 XMR. При това плаща такса 3 XMR. Така сумата на похарчените средства плюс сумата на генерираните и таксата са равни на 15 XMR. Нека опитаме да изчислим commitments и да видим разликата между техните суми (да си спомним математиката):

Тук виждаме, че за да се съгласува уравнението — сумите на маските на входовете и изходите ни трябват да бъдат еднакви. За това портфейлът генерира на случаен принцип x1, y1, y2 и y3, а оставащия x2 изчислява така:

Използвайки тези маски, можем да докажем на всеки проверяващ, че не генерираме средства повече, отколкото харчим, без да разкриваме сумите. Оригинално, нали?

RingCT full

В транзакциите full RingCT проверката на сумите на преводите е малко по-сложна. В тези транзакции портфейлът не пресмята commitments за входовете, а използва такива, изчислени при тяхното генериране. При това трябва да приемем, че разликата на сумите вече няма да бъде равна на нула, а вместо това:

Тук z — разликата между маските на входовете и изходите. Ако разгледаме zG като публичен ключ (какъвто той де-факто е), то z — това е частният ключ. По този начин знаем публичните и съответстващите им частни ключове. Имаме тези данни и можем да ги използваме в пръстеновидния подпис MLSAG наред с публичните ключове на замесените изходи:

По този начин валидният пръстеновиден подпис ще гарантира, че знаем всички частни ключове на един от стълбовете, а частният ключ на последния ред можем да знаем само ако транзакцията не генерира средства повече, отколкото изразходва. Между другото, тук е и отговорът на въпроса «защо разликата на сумите commitments не води до нула» — ако zG = 0, то ще разкрием стълба с реалните изходи.

А как получателят на средствата ще разбере колко пари е получил? Тук всичко е просто — изпращачът на транзакцията и получателят обменят ключове по протокола на Диффи-Хелмана, използвайки ключа на транзакцията и view-ключа на получателя и изчисляват обща тайна. Изпращачът записва в специални полета на транзакцията данните за сумите на изходите, шифровани с този общ ключ.

Доказателства за диапазон

А какво ще стане, ако за сумата в commitments използваме отрицателно число? Това може да доведе до генерирането на допълнителни монети! Такъв изход е недопустим, затова е необходима гаранция, че използваните от нас суми не са отрицателни (без разкриване на тези суми, разбира се, иначе всичките усилия ще са напразни). С други думи, трябва да докажем, че сумата попада в интервала [0, 2n — 1].

За целта сумата на всеки изход се разделя на двоични разряди и се изчислява commitment за всеки разряд поотделно. Как става това, е най-добре да разгледаме на примера.

Да предположим, че сумите са малки и се помещават в 4 бита (на практика това е 64 бита), а ние създаваме изход на сума 5 XMR. Изчисляваме commitments за всеки разряд и общ commitment за цялата сума:
След това всеки commitment се замесва с сурогатен (Ci-2iH) и попарно подписва се с кольцевата подпись на Борромео (още една кольцова подпись), предложена от Грег Максвелл през 2015 г. (повече за нея можете да прочетете тук.):
Всичко това се нарича range proof и позволява да се гарантира, че в commitments се използват суми в интервал. [0, 2n — 1].

Какво следва?

В текущата реализация range proofs заемат много място — 6176 байта за един изход. Това води до големи транзакции и, съответно, по-високи такси. За да се намали размерът на транзакцията, разработчиците на Monero въвеждат вместо подписите на Борромео bulletproofs — механизъм за range proof без битови commitments. Според някои оценки, те могат да намалят размера на range proof до 94%. Между другото, в средата на юли технологията премина одит от компанията Kudelski Security, която не установи съществени недостатъци нито в самата технология, нито в нейното приложение. Технологията вече се използва в тестова мрежа, а с новия хардфорк вероятно може да премине и в основната мрежа.

Задавайте своите въпроси, предлагайте теми за нови статии за технологии в областта на криптовалутите и се абонирайте за нашата група в Facebook, за да бъдете в крак с нашите събития и публикации.

Източник: habr.com