Pedersen Commitments, czyli jak transakcje są ze sobą łączone

[garlonicon]

Na stronie Monero https://www.getmonero.org/resources/mon ... ingCT.html możemy przeczytać coś takiego: "rct=xG+aH(G)". Oprócz krótkiego filmu mamy także link do https://eprint.iacr.org/2015/1098.pdf, gdzie jest techniczny opis. Idąc po kolei: "rct" jest tym, co obliczamy, to jest właśnie tytułowe "Pedersen Commitment", właśnie to możemy łączyć i właśnie taka wartość jest używana przy składaniu podpisów pod transakcjami. Dzięki temu gdy mamy "rct_1" jednej transakcji oraz "rct_2" drugiej, to wykonujemy sumę tworząc "rct_n=rct_1+rct_2". Tak można składać transakcje bez naruszania sygnatur.

Idźmy dalej: "x" jest kwotą, którą chcemy przesłać. Jak wiadomo, klucze publiczne można sumować bez znajomości kluczy prywatnych. Dlatego każdy górnik po wykonaniu "rct_1+rct_2" uzyskuje "x_1*G+a_1*H(G)+x_2*G+a_2*H(G)". Po uproszczeniu tego wyrażenia widać, że wynikiem jest "rct_n=(x_1+x_2)*G+(a_1+a_2)*H(G)". Łatwo zauważyć, że taki podpis "rct_n" może z powodzeniem zastąpić podpisy pod "rct_1" oraz "rct_2", gdzie przesyłana kwota będzie wynosiła "x_1+x_2", czyli będzie zwykłą sumą wartości z obu transakcji.

Patrząc po kolei mamy literę "G", oznacza to po prostu punkt bazowy krzywej eliptycznej, analogicznie do punktu bazowego w secp256k1 w Bitcoinie, różnica jest taka, że w Monero obowiązuje ed25519, więc ten punkt jest inny, ale matematyka stojąca za krzywymi eliptycznymi wygląda identycznie.

Kolejnym symbolem jest "a", czyli wartość, która umożliwia zasłonięcie przesyłanej kwoty. Gdybyśmy mieli samo "rct=xG", to wtedy moglibyśmy założyć, że na przykład ilość przesyłanych monet jest wartością 64-bitową i spróbować ją odgadnąć. Co więcej, moglibyśmy zrobić tablicę tęczową, która natychmiast by nam zamieniła taki klucz publiczny na kwotę kryjącą się pod nim. Zakładając, że ludzie przesyłają równe kwoty lub że taka kwota jest równa w dolarach, euro, złotówkach, bądź innej lokalnej walucie, bylibyśmy w stanie odgadywać przesyłane kwoty. Dlatego tak ważna jest unikalność "a", podobnie jak ważna jest unikalność "k" w przypadku sygnatur w Bitcoinie, znajomość tej wartości umożliwia tutaj ustalenie przesyłanej kwoty, co więcej, o ile znajomość "aH(G)" pozwala jedynie na podgląd (to jest część tak zwanego "view key"), o tyle znajomość samego "a" pozwala na zmianę przesyłanej kwoty!

Dalsza część, czyli "H(G)" oznacza hash punktu bazowego zamieniony na klucz publiczny. O co chodzi: mamy punkt bazowy i jesteśmy w stanie obliczyć jego hash. Następnie taką wartość zamieniamy na klucz publiczny, do którego klucz prywatny jest nieznany. Istnieje możliwość tworzenia takich kluczy publicznych, do których nikt nie zna pasującego klucza prywatnego, na przykład w Bitcoinie może to być 020000000000000000000000000000000000000000000000000000000000000001. Zamiast ciągu zer i jedynki na końcu, po prostu wstawiamy tutaj ten hash, dzięki czemu nikt nie jest w stanie obliczyć takiego "h", gdzie "h*G" byłoby równe "H(G)". Dlaczego to jest takie ważne? Otóż dlatego, że gdybyśmy mieli "rct=xG+aG", czyli gdybyśmy używali punktu bazowego bezpośrednio, to wtedy dałoby się zmieniać przesyłaną kwotę bez naruszania sygnatury i mógłby to zrobić każdy obserwator mempoola, wystarczyłoby dodać lub odjąć taki punkt, o ile chcielibyśmy tą kwotę zmienić. Na szczęście jednak nikt nie zna klucza prywatnego do "H(G)" i zakładając, że użyta funkcja skrótu jest bezpieczna, to powinno wystarczyć do przekonania innych co do bezpieczeństwa systemu.

Oprócz tego warto wiedzieć, że wyżej opisany schemat obowiązuje nie tylko w Monero, ale także w monetach opartych na protokole MimbleWimble, takich jak Grin. Poza tym, w najbliższym czasie LTC planuje wprowadzenie takich udoskonaleń.