Kontynuujemy naszą serię o blockchainie Monero, a dzisiejszy artykuł skupi się na protokole RingCT (Ring Confidential Transactions), który wprowadza poufne transakcje i nowe podpisy pierścieniowe. Niestety w Internecie niewiele jest informacji na temat jego działania, dlatego my staraliśmy się wypełnić tę lukę.
Porozmawiamy o tym, jak sieć ukrywa kwoty transferów za pomocą tego protokołu, dlaczego porzuciła klasyczne podpisy pierścieniowe w kryptonotach i jak ta technologia będzie się dalej rozwijać.
Ponieważ protokół ten jest jedną z najbardziej złożonych technologii w Monero, czytelnik będzie potrzebował podstawowej wiedzy na temat konstrukcji tego blockchainu oraz przelotnej wiedzy na temat kryptografii krzywych eliptycznych (aby odświeżyć tę wiedzę, możesz przeczytać pierwsze rozdziały naszego poprzedni artykuł o ).
Protokół RingCT
Jednym z możliwych ataków na kryptowaluty jest analiza blockchain oparta na wiedzy o kwocie i czasie wysłanej transakcji. To pozwala znacznie zawęzić obszar poszukiwań wyjść interesujących atakującego. Aby zabezpieczyć się przed taką analizą, Monero wdrożyło anonimowy protokół transakcji, który całkowicie ukrywa kwoty przelewów w sieci.
Warto zaznaczyć, że pomysł ukrywania kwot nie jest nowy. Twórca Bitcoin Core, Greg Maxwell, był jednym z pierwszych, który opisał to w swoim . Obecna implementacja RingCT to jego modyfikacja z możliwością stosowania podpisów pierścieniowych (czy to bez nich), i stąd wzięła się nazwa – Ring Confidential Transactions.
Protokół pozwala między innymi pozbyć się problemów z mieszaniem pyłów wyjściowych - produktów o niewielkiej ilości (zwykle otrzymywanych w formie reszty z transakcji), które stwarzały więcej problemów niż były warte.
W styczniu 2017 roku miał miejsce hard fork sieci Monero, umożliwiający opcjonalne korzystanie z transakcji poufnych. I już we wrześniu tego samego roku, wraz z hard forkiem w wersji 6, takie transakcje stały się jedynymi dozwolonymi w sieci.
RingCT wykorzystuje kilka mechanizmów jednocześnie: wielowarstwowe połączone spontaniczne anonimowe podpisy grupowe (Multilayered Linkable Spontaneous Anonymous Group Signature, zwane dalej MLSAG), schemat zobowiązań (Pedersen Commitments) i dowody zasięgu (termin ten nie ma ustalonego tłumaczenia na język rosyjski) .
Protokół RingCT wprowadza dwa rodzaje transakcji anonimowych: proste i pełne. Portfel generuje pierwsze, gdy transakcja korzysta z więcej niż jednego wejścia, drugie – w sytuacji odwrotnej. Różnią się one walidacją kwot transakcji oraz danymi podpisanymi podpisem MLSAG (więcej o tym porozmawiamy poniżej). Co więcej, transakcje typu full można generować z dowolną liczbą wejść, nie ma zasadniczej różnicy. W książce W związku z tym mówi się, że decyzja o ograniczeniu pełnych transakcji do jednego wejścia została podjęta w pośpiechu i może ulec zmianie w przyszłości.
Podpis MLSAG
Pamiętajmy, czym są podpisane dane wejściowe transakcji. Każda transakcja powoduje wydatki i generuje pewne środki. Generowanie środków następuje poprzez utworzenie wyników transakcji (bezpośrednią analogią są rachunki), a wyjście, które wydaje transakcja (w końcu w prawdziwym życiu wydajemy banknoty) staje się wejściem (uważaj, bardzo łatwo się pomylić Tutaj).
Dane wejściowe odwołują się do wielu wyników, ale zużywają tylko jeden, tworząc w ten sposób „zasłonę dymną” utrudniającą analizę historii tłumaczeń. Jeżeli transakcja ma więcej niż jedno wejście, wówczas taką strukturę można przedstawić w postaci macierzy, w której wiersze stanowią dane wejściowe, a kolumny mieszane wyjścia. Aby udowodnić sieci, że transakcja wykorzystuje dokładnie swoje dane wyjściowe (zna ich tajne klucze), dane wejściowe są podpisane sygnaturą pierścieniową. Taki podpis gwarantuje, że podpisujący znał tajne klucze do wszystkich elementów dowolnej kolumny.
W transakcjach poufnych nie wykorzystuje się już klasycznych transakcji sygnatury pierścieniowe zastąpiono je MLSAG – wersją podobnych jednowarstwowych sygnatur pierścieniowych przystosowaną do wielu wejść, .
Nazywa się je wielowarstwowymi, ponieważ podpisują kilka wejść jednocześnie, z których każde jest mieszane z kilkoma innymi, czyli podpisana jest macierz, a nie jeden wiersz. Jak zobaczymy później, pomaga to zaoszczędzić na rozmiarze podpisu.
Przyjrzyjmy się, jak powstaje podpis pierścieniowy, na przykładzie transakcji, która zużywa 2 rzeczywiste wyjścia i wykorzystuje do miksowania m - 1 losowych z łańcucha bloków. Oznaczmy klucze publiczne wyników, które wydajemy jako
i odpowiednio dla nich kluczowe obrazy: W ten sposób otrzymujemy macierz rozmiarów 2xm. Najpierw musimy obliczyć tzw. wyzwania dla każdej pary wyników:
Obliczenia rozpoczynamy od wyników, które wydajemy przy użyciu ich kluczy publicznych:i liczby losoweW rezultacie otrzymujemy następujące wartości:
, którego używamy do obliczenia wyzwania
kolejna para wyjść (aby łatwiej było zrozumieć, co gdzie podstawiamy, wyróżniliśmy te wartości różnymi kolorami). Wszystkie poniższe wartości są obliczane w okręgu przy użyciu wzorów podanych na pierwszej ilustracji. Ostatnią rzeczą do obliczenia jest wyzwanie dla pary rzeczywistych wyników.
Jak widać, wszystkie kolumny z wyjątkiem tej zawierającej wyniki rzeczywiste korzystają z liczb generowanych losowo. Dla π- kolumna, będziemy ich również potrzebować. Przekształćmy sięw s:
Sam podpis jest krotką wszystkich tych wartości:
Dane te są następnie zapisywane w transakcji.
Jak widzimy, MLSAG zawiera tylko jedno wyzwanie c0, co pozwala zaoszczędzić na rozmiarze podpisu (który i tak wymaga dużo miejsca). Ponadto każdy inspektor korzystający z danych, przywraca wartości c1,…, cm i sprawdza to. Tym samym nasz pierścień jest zamknięty, a podpis zweryfikowany.
W przypadku transakcji RingCT typu pełnego do macierzy dodawana jest jeszcze jedna linia z mieszanymi wynikami, ale o tym porozmawiamy poniżej.
Zobowiązania Pedersena
(częściej używany jest angielski termin „zobowiązania”) mają na celu umożliwienie jednej ze stron udowodnienia, że zna dany sekret (liczbę), bez konieczności jego ujawniania. Przykładowo rzucasz na kostkę określoną liczbę, rozważasz zaangażowanie i przekazujesz je osobie weryfikującej. Zatem w momencie ujawnienia tajnego numeru weryfikator samodzielnie wylicza zobowiązanie, upewniając się tym samym, że go nie oszukałeś.
Zobowiązania Monero służą do ukrywania kwot przelewów i korzystania z najpowszechniejszej opcji – zobowiązań Pedersen. Swoją drogą ciekawostka - początkowo twórcy proponowali ukrywanie kwot poprzez zwykłe mieszanie, czyli dodawanie wyjść dla dowolnych kwot, aby wprowadzić niepewność, ale potem przeszli na zobowiązania (nie jest faktem, że oszczędzali na wielkość transakcji, jak zobaczymy poniżej).
Ogólnie zaangażowanie wygląda tak:
Где C — sens samego zaangażowania, a - ukryta kwota, H jest stałym punktem na krzywej eliptycznej (dodatkowy generator), oraz x — rodzaj dowolnej maski, współczynnika ukrywania generowanego losowo. Tu potrzebna jest maska, żeby osoba trzecia nie mogła po prostu odgadnąć wartości zaangażowania.
Kiedy generowany jest nowy wynik, portfel oblicza dla niego zobowiązanie, a po wydaniu przyjmuje wartość obliczoną podczas generowania lub przelicza ją, w zależności od rodzaju transakcji.
RingCT jest prosty
W przypadku prostych transakcji RingCT, aby mieć pewność, że transakcja wytworzyła produkty w ilości równej ilości wejść (nie wygenerowała pieniędzy z powietrza), konieczne jest, aby suma zobowiązań pierwszej i drugiej będą takie same, to znaczy:
Prowizje od zaangażowania rozpatrują to trochę inaczej – bez maski:
Gdzie a — wysokość prowizji jest publicznie dostępna.
Takie podejście pozwala nam udowodnić stronie ufającej, że korzystamy z tych samych kwot, bez ich ujawniania.
Aby wszystko było jaśniejsze, spójrzmy na przykład. Załóżmy, że transakcja wymaga dwóch wyników (co oznacza, że stają się danymi wejściowymi) o wartości 10 i 5 XMR i generuje trzy wyniki o wartości 12 XMR: 3, 4 i 5 XMR. Jednocześnie płaci prowizję w wysokości 3 XMR. Zatem kwota wydanych pieniędzy plus kwota wygenerowana i prowizja wynosi 15 XMR. Spróbujmy policzyć zobowiązania i przyjrzeć się różnicy w ich wysokościach (pamiętajcie o matematyce):
Widzimy tutaj, że aby równanie było zbieżne, sumy masek wejściowych i wyjściowych muszą być takie same. W tym celu portfel generuje się losowo x1, y1, y2 i y3, i pozostałe x2 oblicza w ten sposób:
Za pomocą tych masek możemy udowodnić każdemu weryfikatorowi, że nie generujemy więcej środków niż wydajemy, nie ujawniając przy tym kwoty. Oryginalne, prawda?
RingCT pełny
W przypadku pełnych transakcji RingCT sprawdzenie kwot przelewu jest nieco bardziej skomplikowane. W przypadku tych transakcji portfel nie przelicza zobowiązań na dane wejściowe, lecz wykorzystuje te obliczone w momencie ich wygenerowania. W tym przypadku musimy założyć, że nie będziemy już otrzymywać różnicy w sumach równych zero, ale zamiast tego:
Tutaj z — różnica pomiędzy maską wejściową i wyjściową. Jeśli weźmiemy pod uwagę zG jako klucz publiczny (który de facto nim jest). z jest kluczem prywatnym. W ten sposób znamy klucze publiczne i odpowiadające im klucze prywatne. Mając te dane, możemy ich użyć w podpisie pierścieniowym MLSAG wraz z kluczami publicznymi miksowanych wyjść:
Zatem ważny podpis pierścieniowy zapewni, że znamy wszystkie klucze prywatne jednej z kolumn, a klucz prywatny w ostatnim wierszu będziemy mogli poznać tylko wtedy, gdy transakcja nie wygeneruje więcej środków, niż wydaje. Swoją drogą, oto odpowiedź na pytanie „dlaczego różnica w kwotach zobowiązań nie prowadzi do zera” – jeśli zG = 0, wówczas rozwiniemy kolumnę o rzeczywiste wyniki.
Skąd odbiorca środków wie, ile pieniędzy mu wysłano? Tutaj wszystko jest proste – nadawca transakcji i odbiorca wymieniają klucze za pomocą protokołu Diffiego-Hellmana, wykorzystując klucz transakcji i klucz widoku odbiorcy i obliczają wspólny sekret. Nadawca zapisuje dane o kwotach wyjściowych, zaszyfrowane tym wspólnym kluczem, w specjalnych polach transakcji.
Dowody zasięgu
Co się stanie, jeśli w zobowiązaniach użyjesz liczby ujemnej? Może to prowadzić do generowania dodatkowych monet! Wynik ten jest nie do przyjęcia, dlatego musimy zagwarantować, że kwoty, które wykorzystujemy, nie będą ujemne (oczywiście nie ujawniając tych kwot, bo w przeciwnym razie jest tyle pracy i wszystko na marne). Innymi słowy, musimy udowodnić, że suma należy do przedziału [0, 2n - 1].
W tym celu sumę każdego wyjścia dzieli się na cyfry binarne i zobowiązanie oblicza się dla każdej cyfry osobno. Lepiej zobaczyć, jak to się dzieje na przykładzie.
Załóżmy, że nasze kwoty są małe i mieszczą się w 4 bitach (w praktyce jest to 64 bity) i tworzymy wynik o wartości 5 XMR. Obliczamy zobowiązania dla każdej kategorii oraz zobowiązanie całkowite na całą kwotę:
Następnie każde zobowiązanie jest mieszane z surogatem (Ci-2iH) i jest sygnowany parami z sygnaturą pierścieniową Boromeusza (kolejną sygnaturą pierścieniową), zaproponowaną przez Grega Maxwella w 2015 roku (więcej na ten temat można przeczytać ):
Podsumowując, nazywa się to dowodem zakresu i pozwala upewnić się, że zobowiązania wykorzystują kwoty z zakresu [0, 2n - 1].
Co dalej?
W obecnej implementacji dowody zasięgu zajmują dużo miejsca - 6176 bajtów na wyjście. Prowadzi to do większych transakcji i tym samym wyższych opłat. Aby zmniejszyć rozmiar transakcji Monero, programiści zamiast podpisów Borromeo wprowadzają kuloodporne mechanizmy – mechanizm sprawdzający zakres bez zobowiązań bitowych. są w stanie zmniejszyć rozmiar dowodu zasięgu nawet o 94%. Nawiasem mówiąc, w połowie lipca technologia minęła z Kudelski Security, który nie ujawnił żadnych istotnych niedociągnięć ani w samej technologii, ani w jej wykonaniu. Technologia jest już wykorzystywana w sieci testowej, a dzięki nowemu hard forkowi prawdopodobnie uda się ją przenieść do sieci głównej.
Zadawaj pytania, proponuj tematy nowych artykułów o technologiach z zakresu kryptowalut, a także zapisz się do naszej grupy w aby być na bieżąco z naszymi wydarzeniami i publikacjami.
Źródło: www.habr.com