Od pomysłu do realizacji: modyfikujemy istniejący schemat podpisu cyfrowego o krzywej eliptycznej tak, aby był deterministyczny i na jego podstawie udostępniamy funkcje uzyskiwania liczb pseudolosowych weryfikowalnych w ramach blockchain.
Pomysł
Jesienią 2018 roku dołączono blockchain Waves od razu pojawiło się pytanie o możliwość uzyskania możesz zaufać.
Zastanawiając się nad tym pytaniem, w końcu doszedłem do wniosku: każdy blockchain jest komórką, w systemie zamkniętym nie da się pozyskać zaufanego źródła entropii.
Ale nadal podobał mi się jeden pomysł: jeśli podpisze dane użytkownika algorytmem deterministycznym, wówczas użytkownik zawsze będzie mógł zweryfikować taki podpis za pomocą klucza publicznego i będzie miał pewność, że otrzymana wartość jest unikalna. Wyrocznia, choćby bardzo chciała, nie jest w stanie niczego zmienić, algorytm daje jednoznaczny wynik. Zasadniczo użytkownik rejestruje wynik, ale nie zna go, dopóki wyrocznia go nie opublikuje. Okazuje się, że nie można w ogóle ufać wyroczni, ale sprawdzić wynik jej pracy. Wówczas w przypadku pomyślnej weryfikacji taki podpis można uznać za źródło entropii dla liczby pseudolosowej.
Platforma blockchain Waves wykorzystuje schemat podpisu вариант . W tym schemacie podpis składa się z wartości R i S, gdzie R zależy od wartości losowej, a S jest obliczane na podstawie podpisywanej wiadomości, klucza prywatnego i tej samej liczby losowej co R. Okazuje się, że nie ma unikalnej zależności dla tego samego. Wiadomość użytkownika ma wiele ważnych podpisów.
Oczywiście w czystej postaci taki podpis nie może być używany jako źródło liczb pseudolosowych, ponieważ jest niedeterministyczny i dlatego wyrocznia może łatwo nim manipulować.
Ale, jak się okazało, faktycznie możliwe jest uczynienie go deterministycznym.
Pokładałem w nim wielkie nadzieje , ale po przestudiowaniu sprzętu musiałem porzucić tę opcję. Chociaż VRF oferuje deterministyczną wersję podpisu i jego dowód, w algorytmie jest dziwne miejsce, które otwiera czarną dziurę do manipulacji wyrocznią. Mianowicie przy obliczaniu wartości k () używany jest klucz prywatny, który pozostaje nieznany użytkownikowi, co oznacza, że użytkownik nie może zweryfikować poprawności obliczenia k, co oznacza, że wyrocznia może wykorzystać dowolną wartość k, jaką potrzebuje, utrzymując jednocześnie bazę korespondencji k i podpisanymi danymi, aby zawsze móc przeliczyć poprawny wynik z punktu widzenia VRF. Jeśli widzisz rysunek oparty na VRF bez ujawniania klucza prywatnego, możesz wykazać się sprytem: wskaż potrzebę ujawnienia klucza lub wyklucz go z obliczenia k, wtedy klucz prywatny ujawni się automatycznie po pojawieniu się pierwszego podpisu . Ogólnie rzecz biorąc, jak już wspomniano, dziwny schemat losowej wyroczni.
Po krótkim namyśle i pozyskaniu wsparcia lokalnych analityków narodził się schemat pracy VECRO.
VECRO to skrót od Verible Elliptic Curve Random Oracle, co w języku rosyjskim oznacza sprawdzalną losową wyrocznię na krzywych eliptycznych.
Wszystko okazało się dość proste, aby osiągnąć determinizm, należy ustalić wartość R, zanim pojawi się komunikat do podpisu. Jeśli R jest zatwierdzona i stanowi część podpisywanej wiadomości, co dodatkowo gwarantuje, że R zostanie zatwierdzona w podpisywanej wiadomości, wartość S jest jednoznacznie określana przez wiadomość użytkownika i dlatego może być używana jako źródło liczb pseudolosowych.
W takim schemacie nie ma znaczenia, w jaki sposób R jest ustalone; pozostaje to w gestii wyroczni. Ważne jest, aby S było jednoznacznie określone przez użytkownika, ale jego wartość nie jest znana, dopóki wyrocznia jej nie opublikuje. Wszystko, czego chcieliśmy!
Mówiąc o stałym R, zauważ to podczas podpisywania różnych wiadomości jednoznacznie ujawnia klucz prywatny w schemacie EdDSA. Dla właściciela Oracle niezwykle ważne staje się wyeliminowanie możliwości ponownego użycia języka R do podpisywania różnych wiadomości użytkownika. Oznacza to, że w przypadku jakiejkolwiek manipulacji lub zmowy wyrocznia zawsze będzie narażona na ryzyko utraty swojego klucza prywatnego.
W sumie wyrocznia musi zapewnić użytkownikom dwie funkcje: inicjalizację, która ustala wartość R i podpis, który zwraca wartość S. W tym przypadku para R, S to zwykły weryfikowalny podpis wiadomości użytkownika zawierającej ustaloną wartość wartość R i dowolne dane użytkownika.
Można argumentować, że ten schemat dla blockchainu jest niczym więcej niż zwyczajnym . W zasadzie tak, to ona. Ale jest kilka niuansów. Po pierwsze, wyrocznia zawsze działa z tym samym kluczem we wszystkich operacjach, na przykład jest to wygodne w użyciu w umowach. Po drugie istnieje ryzyko, że wyrocznia straci klucz prywatny jeśli zachowa się nieprawidłowo, np. wyrocznia pozwala na zrobienie próbek wyniku, wtedy wystarczą tylko dwa testy, aby poznać klucz prywatny i zyskać pełną dostęp do portfela. Po trzecie, podpis, który jest natywnie weryfikowalny na blockchainie i jest źródłem losowości, jest piękny.
Przez pół roku w mojej głowie kipiał pomysł realizacji, aż w końcu w formie pojawiła się motywacja . Z dużym grantem wiąże się wielka odpowiedzialność, więc projekt będzie!
realizacja
Tak w tym projekcie na blockchainie Waves w trybie żądanie-odpowiedź z wykorzystaniem transakcji transferu pomiędzy użytkownikiem a wyrocznią. Jednocześnie na koncie Oracle instalowany jest skrypt, który kontroluje pracę ściśle według opisanej powyżej logiki. Transakcje Oracle są weryfikowane i przywracany jest cały łańcuch interakcji użytkownika. Wszystkie cztery transakcje biorą udział w weryfikacji ostatecznej wartości, inteligentny kontrakt łączy je ze sobą ścisłym wątkiem weryfikacyjnym, sprawdzając krok po kroku wszystkie wartości i nie pozostawiając miejsca na jakąkolwiek manipulację.
Jeszcze raz odłóżmy to na bok i wyjaśnijmy. Wyrocznia nie działa tylko według proponowanego schematu. Jego praca jest całkowicie kontrolowana na poziomie blockchain przez uznaną firmę . Krok w lewo, a transakcja po prostu nie dojdzie do skutku. Jeśli więc transakcja jest zawarta w blockchainie, użytkownik nie musi nawet niczego sprawdzać, setki węzłów sieci sprawdziło już wszystko za niego.
Obecnie w głównej sieci Waves działa jedno VECRO (możesz uruchomić swój własny, nie jest to trudne, wystarczy ). Obecny kod działa w PHP (on , o których ).
Aby móc korzystać z usługi Oracle należy:
- Napraw R;
- Wyślij co najmniej 0.005 fal na adres Oracle alias init@vecr;
- Otrzymaj kod R w polu załącznika przy przekazywaniu 1 tokena R-vecr od Oracle do użytkownika;
- Zdobądź podpis;
- Wyślij co najmniej 0.005 Waves na adres Oracle alias random@vecr, a także MUSISZ wskazać wcześniej otrzymany kod R i dodatkowe dane użytkownika w polu załącznika;
- Otrzymaj kod S w polu załącznika przy przekazywaniu 1 tokena S-vecr od Oracle do użytkownika;
- Użyj kodu S jako źródła liczby pseudolosowej.
Niuanse obecnej implementacji:
- Fale wysyłane do Oracle służą jako prowizja za transakcję zwrotną dla użytkownika, maksymalnie do 1 Fal;
- Kod R jest połączeniem bajtu znaku „R” i 32-bajtowej wartości R zakodowanej w formacie Base58;
- Kod R w załączniku powinien być pierwszy, dane użytkownika znajdują się po kodzie R;
- Kod S jest połączeniem bajtu znaku „S” i 32-bajtowej wartości S zakodowanej w formacie Base58;
- S jest wynikiem dzielenia modulo, więc nie można użyć S jako pełnej 256-bitowej liczby pseudolosowej (tę liczbę można uznać za maksymalnie 252-bitową liczbę pseudolosową);
- Najprostszą opcją jest użycie skrótu kodu S jako liczby pseudolosowej.
Przykład otrzymania kodu S:
- Inicjalizacja:
- Uzyskiwanie kodu R:
- Zapytanie o wynik podpisania kodu R i dane użytkownika „losowe”:
- Odbieranie kodu S:
Z technicznego punktu widzenia wyrocznia jest całkowicie gotowa do pracy, można z niej bezpiecznie korzystać. Z punktu widzenia użytkowania przez przeciętnego użytkownika brakuje wygodnego interfejsu graficznego, to będzie musiało poczekać.
Chętnie odpowiem na pytania i przyjmę uwagi, dziękuję.
Źródło: www.habr.com