Wprowadzenie

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Podobnie jak w przypadku koncepcji absolutnie odpornych szyfrów w kryptografii, rzeczywiste protokoły „Publicly Verifiable Random Beacon” (dalej PVRB) jedynie starają się jak najlepiej przybliżyć do idealnego schematu, ponieważ w rzeczywistych sieciach nie jest on w czystej postaci zastosowalny: należy się umówić wyłącznie na jeden bit, rund musi być wiele, a wszystkie wiadomości powinny być całkowicie szybkie i zawsze dostarczane. Oczywiście, w rzeczywistych sieciach tak nie jest. Dlatego przy projektowaniu PVRB pod konkretne zadania w nowoczesnych blockchainach, oprócz niemożności kontroli uzyskanego losowego wyniku i odporności kryptograficznej, pojawia się jeszcze wiele czysto architektonicznych i technicznych problemów.

Sam blockchain jest dla PVRB zasadniczo środowiskiem komunikacyjnym, w którym wiadomości=transakcje. Pozwala to częściowo abstrahować od problemów sieciowych, niedostarczenia wiadomości, problemów z oprogramowaniem pośredniczącym — wszystkie te ryzyka bierze na siebie zdecentralizowana sieć, a jej główną wartością dla PVRB jest niemożność odwołania lub zepsucia już wysłanej transakcji — to nie pozwala uczestnikom wycofać się z udziału w protokole, chyba że przeprowadzili udany atak na konsensus. Taki poziom bezpieczeństwa jest akceptowalny, dlatego PVRB musi być odporny na zmowy uczestników dokładnie w takim samym stopniu, jak główny łańcuch blockchaina. To także sugeruje, że PVRB powinien być częścią konsensusu, jeśli sieć umówiła się co do głównego łańcucha bloków, niech jednocześnie umówi się również na jedyny uczciwy wynik losowy. Alternatywnie, PVRB może być po prostu protokołem niezależnym, realizowanym przez smart kontrakt, działającym asynchronicznie w stosunku do blockchaina i bloków. Oba sposoby mają swoje zalety i wady, a wybór pomiędzy nimi jest niezwykle złożony.

Dwa sposoby implementacji PVRB

Opiszmy dokładniej dwa warianty implementacji PVRB — wersję niezależną, działającą z wykorzystaniem smart kontraktu, niezwiązanego z blockchainem, oraz wersję zintegrowaną z konsensusem — wbudowaną w protokół, zgodnie z którym sieć umawia się co do łańcucha bloków i włączanych transakcji. We wszystkich przypadkach będę mieć na myśli popularne silniki blockchainowe: Ethereum, EOS i wszystkie inne, podobne do nich pod względem umieszczania i przetwarzania smart kontraktów.

Umowa samodzielna

W tym wariancie PVRB jest inteligentnym kontraktem, który przyjmuje transakcje random-producer-ów (dalej RP), przetwarza je, łączy wyniki i, w rezultacie, dochodzi do pewnej wartości, którą może uzyskać każdy użytkownik z tego kontraktu. Ta wartość nie musi być przechowywana bezpośrednio w kontrakcie, ale może być reprezentowana jedynie przez dane, z których można deterministycznie uzyskać jedną i tylko jedną wartość rezultatu losowego. W tej schemacie RP to użytkownicy blockchaina, a w procesie generacji można pozwolić uczestniczyć każdemu.

Wariant z umową samodzielną jest dobry:

przenośnością (kontrakty można przenosić z blockchaina do blockchaina)
łatwością w realizacji i testowaniu (kontrakty łatwo pisać i testować)
wygodą w realizacji schematów ekonomicznych (łatwo stworzyć swój token, którego logika służy celom PVRB)
możliwością uruchomienia w już działających blockchainach

Ma również wady:

silne ograniczenia zasobów podczas obliczeń, objętości transakcji i storage (prościej mówiąc cpu/mem/io)
ograniczenia operacji wewnątrz kontraktu (nie wszystkie instrukcje są dostępne, trudno podłączać zewnętrzne biblioteki)
niemożliwość zorganizowania wymiany wiadomości szybciej, niż transakcje są włączane do blockchaina

Ten wariant nadaje się do realizacji PVRB, który musi być uruchomiony w już istniejącej sieci, nie zawierającej skomplikowanej kryptografii i nie wymagającej dużej liczby interakcji.

Zintegrowane z konsensusem

W tej wersji PVRB został zaimplementowany w kodzie węzła blockchain, wbudowany lub działający równolegle z wymianą wiadomości między węzłami blockchain. Wyniki protokołu są zapisywane bezpośrednio w tworzonych blokach, a wiadomości protokołu są wysyłane w sieci p2p między węzłami. Ponieważ protokół generuje liczby, które muszą być zapisane w blokach, sieć musi osiągnąć konsensus w tej sprawie. Oznacza to, że wiadomości PVRB, podobnie jak transakcje, muszą być walidowane przez węzły i włączane do bloków, aby każdy uczestnik sieci mógł zweryfikować przestrzeganie protokołu PVRB. Automatycznie prowadzi to do oczywistego rozwiązania — jeśli sieć dochodzi do konsensusu w sprawie bloku i transakcji w nim, PVRB musi być częścią konsensusu, a nie oddzielnym protokołem. W przeciwnym razie może wystąpić sytuacja, w której blok jest ważny z punktu widzenia konsensusu, ale protokół PVRB nie jest przestrzegany, a z punktu widzenia PVRB blok nie może być zaakceptowany. Tak więc, jeśli wybrana zostanie opcja „integracja z konsensusem”, PVRB staje się ważną częścią konsensusu.

Opisując implementacje PVRB na poziomie konsensusu w sieci, w żadnym wypadku nie można pominąć kwestii finalności. Finalność to mechanizm stosowany w deterministycznych konsensusach, który utrwala blok (i łańcuch prowadzący do niego) jako finalny, który nigdy nie zostanie odrzucony, nawet jeśli pojawi się równoległy fork. Na przykład w Bitcoinie nie ma takiego mechanizmu — jeśli opublikowana zostanie łańcuch o większej złożoności, zastąpi ona wszelkie mniej złożone, niezależnie od długości łańcuchów. A w EOS na przykład finalnymi są tak zwane Ostatnie Nieodwracalne Bloki, które pojawiają się średnio co 432 bloki (12*21 + 12*15, pre-vote + pre-commit). Proces ten polega na oczekiwaniu na podpisy 2/3 producentów bloków (dalej BP). Gdy pojawią się forki, które są starsze niż ostatni LIB, po prostu zostaną odrzucone. Ten mechanizm pozwala gwarantować, że transakcja jest włączona do blockchaina i nigdy nie zostanie wycofana, niezależnie od zasobów atakującego. Ponadto, finalnymi blokami są bloki podpisane przez 2/3 BP w Hyperledger, Tendermint i innych konsensusach opartych na pBFT. Ponadto, sensowne jest, aby protokół zapewniający finalność działał jako nadbudowa nad konsensusem, ponieważ może pracować asynchronicznie z produkcją i publikacją bloków. artykuł o finalności w Ethereum.

Finalność jest niezwykle ważna dla użytkowników, którzy bez niej mogą stać się ofiarą ataku „double spend”, w którym BP „wstrzymuje” bloki i publikuje je po tym, jak sieć „zobaczy” dobrą transakcję. Jeśli nie ma finalności, opublikowany fork zastępuje blok z „dobrą” transakcją innym, z „złego” forka, w którym te same środki są przekazywane na adres atakującego. W przypadku PVRB wymagania dotyczące finalności stają się jeszcze surowsze, ponieważ budowanie forków dla PVRB oznacza możliwość, że atakujący może przygotować kilka wariantów losowości, mając na celu opublikowanie najkorzystniejszego dla siebie, i ograniczenie czasu możliwego ataku — to dobre rozwiązanie.

Dlatego najlepszym rozwiązaniem jest połączenie PVRB i finalności w jeden protokół — wtedy zfinalizowany blok = zfinalizowana losowość, a to jest dokładnie to, co trzeba było uzyskać. Teraz gracze otrzymają gwarantowaną losowość w ciągu N sekund i mogą być pewni, że nie można jej cofnąć ani odtworzyć.

Opcja z integrowanym konsensusem jest dobra:

możliwością asynchronicznej realizacji w odniesieniu do produkcji bloków — bloki są produkowane jak zwykle, ale równolegle może działać protokół PVRB, który produkuje losowości nie w każdym bloku
możliwością implementacji nawet ciężkiej kryptografii, bez ograniczeń nakładanych na inteligentne kontrakty
możliwością szybszego organizowania wymiany wiadomości niż transakcje są włączane do blockchaina, na przykład część protokołu może działać między węzłami bez rozprzestrzeniania wiadomości w sieci

Ma również wady:

trudności przy testowaniu i rozwijaniu — trzeba będzie emulować błędy sieciowe, znikające węzły, hard forki sieci
błędy w implementacji wymagają hard forka sieci

Oba sposoby implementacji PVRB mają prawo do życia, ale implementacja na inteligentnych kontraktach w nowoczesnych blockchainach jest wciąż mocno ograniczona w zasobach obliczeniowych, a wszelkie przejścia do poważnej kryptografii często są po prostu niemożliwe. A poważna kryptografia będzie nam potrzebna, co zostanie zaprezentowane dalej. Chociaż problem ten ma wyraźnie tymczasowy charakter, poważna kryptografia w kontraktach jest potrzebna do rozwiązania wielu zadań i stopniowo się pojawia (na przykład systemowe kontrakty dla zkSNARKs w Ethereum).

Blockchain, which provides a transparent and reliable messaging channel for the protocol, does not come for free. Any decentralized protocol must consider the possibility of Sybil attacks; any action can be coordinated by a multitude of accounts, so it is necessary to account for the attackers' capabilities to create an arbitrary number of protocol participants acting in collusion.

PVRB and block variables.

I wasn't lying when I said that a good PVRB, validated by numerous gambling applications, has not yet been implemented in blockchains. So where does such a number of gambling applications in Ethereum and EOS come from? This surprises me just as much as it surprises you; where did so many 'resilient' randoms come from in a completely deterministic environment?

The favorite way to derive randomness in the blockchain is to take some 'unpredictable' information from the block and use it to create randomness—simply by hashing one or more values. A good article on the problems with such schemes. tutajYou can take any of the 'unpredictable' values in the block, such as the block hash, the number of transactions, network difficulty, and other unknown values. Then hash them, one or more, and ideally, you should get true randomness. You can even add to the whitepaper that your scheme is 'post-quantum secure' (since there are quantum-proof hash functions :)).

But even post-quantum secure hashes are unfortunately not enough. The secret lies in the requirements for PVRB; let me remind you of them from the previous article:

Wynik musi mieć w sposób udowodniony równomierny rozkład, tzn. oparty na udowodnionej odpornej kryptografii.
Nie ma możliwości kontrolowania żadnego z bitów wyniku. W konsekwencji wynik nie może być wcześniej przewidziany.
Nie można sabotować protokołu generacji przez nieuczestniczenie w protokole ani przez przeciążenie sieci atakującymi wiadomościami.
Wszystko, co wcześniej wymieniono, musi być odporne na zmowy dozwolonej liczby nieuczciwych uczestników protokołu (na przykład 1/3 uczestników).

W tym przypadku spełniony jest tylko warunek 1, a warunek 2 nie jest realizowany. Hashując nieprzewidywalne wartości z bloku, uzyskujemy równomierne rozłożenie i dobre losowania. Jednak BP ma przynajmniej możliwość „opublikowania bloku lub nie”. W ten sposób BP może przynajmniej wybierać spośród DWÓCH opcji losowania: „swojej” oraz tej, która wyniknie, jeśli blok stworzy ktoś inny. BP może wcześniej „zajrzeć”, co się stanie, jeśli opublikuje blok, i po prostu podjąć decyzję o jego publikacji lub nie. W ten sposób, grając na przykład w „parzyste-nieparzyste” lub „czerwone/czarne” w ruletce, może publikować blok tylko wtedy, gdy widzi możliwość wygranej. To sprawia również, że strategia wykorzystania, na przykład, hasha bloku „z przeszłości” staje się nieefektywna. W takim przypadku mówi się, że „zastosowany będzie los, który wynika z hashowania bieżących danych i hasha przyszłego bloku o wysokości, na przykład, N + 42, gdzie N to obecna wysokość bloku. To trochę wzmacnia schemat, ale wciąż pozwala BP, nawet w przyszłości, wybierać, czy zatrzymać blok, czy go opublikować.

Oprogramowanie BP w tym przypadku jest nieco bardziej skomplikowane, ale nie znacznie. Po prostu przy walidacji i włączaniu transakcji do bloku zachodzi szybkie sprawdzenie, czy będzie wygrana, oraz możliwe dobranie jednego parametru transakcji, aby uzyskać wysokie prawdopodobieństwo wygranej. Przy tym, złapanie sprytnego BP przy takich manipulacjach jest praktycznie niemożliwe, za każdym razem można używać nowych adresów i wygrywać małymi krokami, nie wzbudzając podejrzeń.

Dlatego sposoby z wykorzystaniem informacji z bloku nie nadają się do uniwersalnej implementacji PVRB. W ograniczonej wersji, z ograniczeniami wielkości stawek, ograniczeniami liczby grających i/lub rejestracją KYC (aby uniemożliwić jednemu graczowi używanie kilku adresów), te schematy mogą działać w przypadku małych gier, ale nie bardziej.

PVRB oraz commit-reveal.

Dobrze, dziękuję za hashowanie i przynajmniej względną nieprzewidywalność hasha bloku oraz innych zmiennych. Jeśli rozwiążemy problem front-runningu górników, powinno powstać coś bardziej sensownego. Dodajmy do tego schematu użytkowników — niech również mają wpływ na losowość: każdy pracownik wsparcia technicznego powie ci, że najbardziej losowym elementem w systemach IT są działania użytkowników 🙂

Naivna schemat, w którym użytkownicy po prostu wysyłają losowe liczby, a wynik jest obliczany jako na przykład hash ich sumy, nie jest wystarczający. W takim przypadku ostatni grający może kontrolować wynik, wybierając własny los. Dlatego stosuje się powszechnie używany wzorzec commit-reveal. Uczestnicy najpierw wysyłają hashe swoich losów (commity), a następnie ujawniają same losy (reveale). Faza „reveal” zaczyna się dopiero po zebraniu wymaganych commitów, więc uczestnicy mogą wysłać dokładnie ten los, którego hash wysłali wcześniej. Teraz połączmy to z parametrami bloku, najlepiej wziętymi z przyszłości (los można poznać tylko w jednym z przyszłych bloków), i voilà — los gotowy! Teraz każdy gracz wpływa na wynikowy los i może „pokonać” złośliwego BP, zastępując jego los swoim, nieznanym wcześniej, losem... Można również dodać ochronę przed sabotażem protokołu poprzez uniemożliwienie ujawnienia na etapie reveal — po prostu wymagając przy commitach dołączenia do transakcji pewnej kwoty — depozytu gwarancyjnego, który wróci tylko w trakcie procedury reveal. W takim przypadku dokonanie commitu i nieujawnienie będzie nieopłacalne.

To była dobra próba, i takie schematy też występują w DApp-ach gier, ale niestety, to wciąż za mało. Teraz na wynik może wpływać nie tylko górnik, ale i każdy uczestnik protokołu. Kontrolować samo wartości wciąż można, z mniejszym stopniem zmienności i za pieniądze, ale, jak w przypadku górnika, jeśli wyniki losowania są cenniejsze niż opłata za udział w protokole PVRB, to random-producer (RP) może decydować, czy zrobić reveal i nadal ma możliwość wyboru z przynajmniej dwóch opcji losów.
Za to pojawiła się możliwość karania tych, którzy dokonują commit i nie robią reveal, co jeszcze bardziej przyda się. Jej prostota jest poważną zaletą — bardziej zaawansowane protokoły wymagają znacznie potężniejszych obliczeń.

PVRB i deterministyczne podpisy.

Jest jeszcze jeden sposób, aby zmusić RP do dostarczenia pseudolosowej liczby, na którą nie będzie miał wpływu, jeśli zostanie mu dostarczony „prototyp” — jest to podpis deterministyczny. Takim podpisem jest na przykład RSA, a nie ECS. Jeśli RP ma parę kluczy: RSA i ECC, i podpisuje swoim kluczem prywatnym pewną wartość, to w przypadku RSA uzyskuje JEDEN I TYLKO JEDEN podpis, a w przypadku ECS — może wygenerować dowolną liczbę różnych ważnych podpisów. Dzieje się tak, ponieważ przy tworzeniu podpisu ECS używane jest losowe liczby, wybierane przez podpisującego, i mogą być one wybierane dowolnie, dając podpisującemu możliwość wyboru jednego z kilku podpisów. W przypadku RSA: „jedna wartość wejściowa” + „jedna para kluczy” = „jeden podpis”. Nie da się przewidzieć, jaki podpis uzyska inny RP, dlatego PVRB z podpisami deterministycznymi może być zorganizowany poprzez kombinowanie podpisów RSA kilku uczestników, którzy podpisali tę samą wartość. Na przykład — poprzednią losową liczbę. W takim schemacie oszczędza się sporo zasobów, ponieważ podpisy są jednocześnie potwierdzeniem poprawności działania zgodnie z protokołem i źródłem losowości.

Mimo to, nawet z podpisami deterministycznymi, schemat wciąż jest podatny na problem „ostatniego aktora”. Ostatni uczestnik wciąż może decydować, czy opublikować swój podpis, kontrolując tym samym rezultat. Można udoskonalić schemat, dodając do niego hashe bloków, przeprowadzając rundy, aby wynik nie mógł być przewidywany z góry, ale wszystkie te zabiegi, nawet biorąc pod uwagę wiele poprawek, wciąż pozostawiają nierozwiązaną problem wpływu jednego uczestnika na zbiorowy wynik w nieufnym środowisku i mogą działać tylko w warunkach ograniczeń ekonomicznych i czasowych. Ponadto rozmiar kluczy RSA (1024 i 2048 bitów) jest dość duży, a rozmiar transakcji blockchainowych jest niezwykle ważnym parametrem. Wygląda na to, że proste rozwiązanie problemu nie będzie możliwe, idziemy dalej.

W kryptografii istnieją schematy, które umożliwiają sieci uzgodnienie jednego i tylko jednego wyniku PVRB, a takie schematy są odporne na wszelkie złośliwe działania niektórych uczestników. Jednym z przydatnych protokołów, które warto poznać, jest schemat dzielenia tajemnicy Shamira. Służy on do podziału tajemnicy (na przykład klucza tajnego) na kilka części, które są rozdzielane między N uczestników. Tajemnica jest dzielona w taki sposób, że do jej odbudowy wystarczy M części z N, przy czym mogą to być dowolne M części. Mówiąc w skrócie, mając wykres nieznanej funkcji, uczestnicy wymieniają się punktami na wykresie, a po otrzymaniu M punktów, cała funkcja może być odbudowana.
Dobre wyjaśnienie znajduje się w wiki i aby poeksperymentować z nim praktycznie, przydatne jest z demo strony.

Gdyby schemat FSSS (Fiat-Shamir Secret Sharing) był stosowany w czystej formie — byłby to niezawodny PVRB. W najprostszej wersji protokoł może wyglądać następująco:

Każdy uczestnik generuje własny losowy składnik i rozdziela udziały od niego pozostałym uczestnikom.
Każdy uczestnik ujawnia swoje części tajemnic innych uczestników.
Jeśli dla uczestnika zebrało się więcej M udziałów, to jego liczba może zostać obliczona, i będzie ona jedyna, bez względu na zestaw ujawnionych uczestników.
Kombinacja ujawnionych składników losowych to poszukiwany PVRB.

W tym miejscu pojedynczy uczestnik nie ma już wpływu na wyniki protokołu, z wyjątkiem przypadków, gdy tylko od niego zależy osiągnięcie progu ujawnienia losowego. Dlatego ten protokół, przy odpowiednim udziale działających zgodnie z protokołem i dostępnych RP, działa zgodnie z wymaganiami dotyczącymi odporności kryptograficznej i jest odporny na problem 'ostatniego aktora'.

To mógłby być idealny wariant; ten schemat PVRB oparty na dzieleniu tajemnic Fiat-Shamira jest opisany, na przykład, w tego artykułach. Jednak, jak wspomniano wcześniej, jeśli spróbować zastosować go bezpośrednio w blockchainie, pojawiają się już ograniczenia techniczne. Oto przykład testowej realizacji protokołu w inteligentnym kontrakcie EOS oraz najważniejsza jego część — weryfikacja opublikowanego udziału uczestnika: kodZ kodu wynika, że walidacja dowodu wymaga kilku mnożeń skalarnych, a liczby są bardzo duże. Należy jednak zrozumieć, że w blockchainach weryfikacja następuje w momencie, gdy producent bloku przetwarza transakcję, a każdy uczestnik powinien mieć łatwy dostęp do weryfikacji poprawności protokołu, dlatego wymagania dotyczące szybkości funkcji weryfikacji są bardzo poważne. W tej wersji okazała się ona nieefektywna, ponieważ weryfikacja nie mieściła się w limicie na transakcję (0,5 s).

Efektywność weryfikacji to jedno z najważniejszych wymagań dotyczących stosowania wszelkich zaawansowanych schematów kryptograficznych w blockchainie. Tworzenie dowodów, przygotowanie wiadomości — te procedury można zrealizować poza łańcuchem i przeprowadzać na wysoko wydajnych komputerach, ale weryfikacji nie da się pominąć — to kolejne ważne wymaganie dotyczące PVRB.

PVRB i podpisy progu

Zapoznając się z schematem dzielenia sekretu, odkryliśmy cały zbiór protokołów, które łączy kluczowe słowo "threshold". Gdy ujawnienie pewnych informacji wymaga udziału M uczciwych uczestników z N, a zbiór uczciwych uczestników może być dowolnym podzbiorem N, mówimy o schematach "threshold". To one pozwalają rozwiązać problem "ostatniego aktora", teraz jeśli atakujący nie ujawnia swojej części sekretu, uczciwy uczestnik zrobi to za niego. Te schematy pozwalają na ustalenie jednej, jedynej wartości, nawet w przypadku sabotażu protokołu przez część uczestników.

Połączenie deterministycznych podpisów i schematów progu umożliwiło opracowanie bardzo wygodnego i obiecującego schematu realizacji PVRB — to deterministyczne podpisy progu. Oto artykuł o różnych zastosowaniach podpisów progu, a oto jeszcze jeden dobry longread od Dash.

W ostatnim artykule opisano podpisy BLS (BLS rozwija się jako Boneh-Lynn-Shacham, oto artykuł ), które mają bardzo ważną i niezwykle wygodną dla programistów cechę — klucze publiczne, sekretne i podpisy BLS mogą się ze sobą łączyć za pomocą prostych operacji matematycznych, przy czym ich kombinacje pozostają ważnymi kluczami i podpisami, co pozwala łatwo agregować wiele podpisów w jeden oraz wiele kluczy publicznych w jeden. Mają również deterministyczność, co oznacza, że na tych samych danych wejściowych dają ten sam wynik. Dzięki tej właściwości kombinacje podpisów BLS same są ważnymi kluczami, co umożliwia realizację wariantu, w którym M z N uczestników produkuje jeden i tylko jeden podpis, który jest deterministyczny, publicznie weryfikowalny i nieprzewidywalny do momentu, gdy nie zostanie ujawniony przez M-tego uczestnika.

W schemacie z threshold BLS signatures każdy uczestnik podpisuje za pomocą BLS coś (na przykład poprzedni losowy wynik), a ogólny podpis threshold to poszukiwany losowy wynik. Właściwości kryptograficzne podpisów BLS spełniają wymagania dotyczące jakości losowości, część threshold chroni przed „ostatnim aktorem”, a unikalna łączność kluczy pozwala na wdrażanie wielu interesujących algorytmów, które pozwalają na przykład na efektywne agregowanie wiadomości protokołu.

Tak więc, jeśli budujesz PVRB w swoim blockchainie, z dużym prawdopodobieństwem przejdziesz do schematu BLS threshold signatures, który jest już używany w kilku projektach. Na przykład DFinity (tutaj benchmark, który wdraża ten schemat, a tutaj przykład implementacji weryfikowalnego tajnego dzielenia), lub Keep.network (oto ich random beacon yellowpaper, a oto przykład smart kontraktu, który obsługuje protokół).

Implementacja PVRB

Niestety, wciąż nie widzimy gotowego, wdrożonego w blockchainach PVRB protokołu, który wykazałby swoje bezpieczeństwo i odporność. Mimo że same protokoły są gotowe, technicznie ich zastosowanie w istniejących rozwiązaniach jest trudne. Dla systemów scentralizowanych PVRB nie ma sensu, a zdecentralizowane są ściśle ograniczone we wszystkich zasobach obliczeniowych: CPU, pamięci, przechowywaniu, I/O. Projektowanie PVRB to łączenie różnych protokołów, aby stworzyć coś, co spełni wszystkie wymagania, przynajmniej dla jakiegokolwiek działającego blockchaina. Jeden protokół skuteczniej oblicza, ale wymaga więcej wiadomości między RP, a inny wymaga bardzo mało wiadomości, ale stworzenie proof-a może być zadaniem trwającym dziesiątki minut, a nawet godzin.

Wymienię czynniki, które musisz wziąć pod uwagę przy wyborze wysokiej jakości PVRB:

Odporność kryptograficzna. Twój PVRB musi być absolutnie unbiasable, bez możliwości kontrolowania pojedynczego bitu. W niektórych schematach jest inaczej, dlatego zaproś kryptografa.
Problem „ostatniego aktora”. Twój PVRB musi być odporny na ataki, w których atakujący, kontrolujący jednego lub kilku RP, może wybierać jedną z dwóch możliwości wyniku.
Problem sabotażu protokołu. Twój PVRB musi być odporny na ataki, w których atakujący, kontrolujący jednego lub kilku RP, decyduje, czy rutynowe wyniki mają miejsce, i może gwarantować, lub z określoną prawdopodobieństwem wpływać na to.
Problem liczby wiadomości. Twoje RP powinny wysyłać do blockchaina minimum wiadomości i maksymalnie unikać synchronizowanych działań typu „wysłałem pewne informacje, czekam na odpowiedź od konkretnego uczestnika”. W sieciach p2p, szczególnie geograficznie rozproszonych, nie należy liczyć na szybki odzew.
Problem złożoności obliczeniowej. Weryfikacja jakiegokolwiek etapu PVRB on-chain musi być niezwykle łatwa, ponieważ wykonują ją wszystkie pełne węzły sieci. Jeśli realizacja odbywa się za pomocą smart kontraktu, wymagania dotyczące szybkości są bardzo rygorystyczne.
Problem dostępności i aktywności. Twój PVRB powinien dążyć do odporności na sytuacje, w których część sieci stała się niedostępna na pewien czas, a część RP po prostu przestała działać.
Problem zaufanego ustawienia i początkowego rozdziału kluczy.. Jeśli Twój PVRB używa podstawowego ustawienia protokołu, to jest to odrębna duża i poważna sprawa. Oto przykład. Jeśli uczestnicy muszą przed rozpoczęciem protokołu wymienić się swoimi kluczami — to również jest problem, jeśli skład uczestników się zmienia
Problemy z rozwojem. Obecność bibliotek w potrzebnych językach, ich bezpieczeństwo i wydajność, publiczność, złożone testy itd.

Na przykład próg podpisów BLS ma istotny problem — zanim zacznie się pracę, uczestnicy muszą obowiązkowo wymienić się kluczami, organizując grupę, w ramach której będzie działał próg. Oznacza to, że przynajmniej jedna runda wymiany w zdecentralizowanej sieci musi być wyczekiwana, a biorąc pod uwagę, że generowany losowość, na przykład, jest niezbędna w grach, praktycznie w czasie rzeczywistym, oznacza to, że sabotowanie protokołu jest możliwe na tym etapie, a zalety schematu progowego są tracone. Ten problem jest już prostszy niż poprzedni, ale nadal wymaga opracowania osobnej procedury formowania grup progowych, które będą musiały być ekonomicznie zabezpieczone, poprzez depozyty i odebranie środków (slashing) uczestnikom, którzy nie przestrzegają protokołu. Ponadto, weryfikacja BLS z akceptowalnym poziomem bezpieczeństwa po prostu nie mieści się, na przykład, w standardowej transakcji EOS lub Ethereum — po prostu brakuje czasu na weryfikację. Kod kontraktów to WebAssembly lub EVM, wykonywany przez maszynę wirtualną. Funkcje kryptograficzne nie są realizowane natywnie (jak dotąd) i działają dziesiątki razy wolniej niż standardowe biblioteki kryptograficzne. Wiele protokołów nie spełnia wymagań po prostu ze względu na wielkość kluczy, na przykład 1024 i 2048 bit dla RSA, 4-8 razy więcej niż standardowy podpis transakcji w Bitcoinie i Ethereum.

Rola odgrywa również obecność wdrożeń w różnych językach programowania — których jest niewiele, szczególnie dla nowych protokołów. Opcja z integracją w konsensus wymaga pisania protokołu w języku platformy, dlatego trzeba będzie szukać kodu w Go dla geth, w Rust dla Parity, w C++ dla EOS. Kod w JavaScript trzeba będzie szukać dla wszystkich, a ponieważ JavaScript i kryptografia nie są sobie szczególnie bliskie, pomoże WebAssembly, które już na pewno pretenduje do roli następnego ważnego standardu internetowego.

Podsumowanie

Mam nadzieję, że w poprzedniej artykuł Udało mi się przekonać Was, że generowanie liczb losowych w blockchainie jest krytyczne dla wielu aspektów życia zdecentralizowanych sieci, a w tym artykule pokazałem, że zadanie to jest niezwykle ambitne i trudne, ale dobre rozwiązania już istnieją. Tak naprawdę ostateczny projekt protokołu będzie możliwy dopiero po przeprowadzeniu masowych testów, które uwzględnią wszystkie aspekty, od ustawienia po symulację awarii, więc raczej nie znajdziecie gotowych przepisów w whitepaperach zespołów ani w artykułach, a my w najbliższym roku lub dwóch na pewno nie odważymy się pisać „zróbcie tak, tak na pewno jest właściwie”.

Na razie, dla naszego PVRB w rozwijanym blockchainie Haya, zatrzymaliśmy się na zastosowaniu podpisów BLS z progowym zaufaniem, planujemy implementować PVRB na poziomie konsensusu, ponieważ weryfikacja w smart kontraktach z akceptowalnym poziomem bezpieczeństwa jest na razie niemożliwa. Możliwe, że użyjemy od razu dwóch schematów: najpierw kosztownego dzielenia tajemnicy do stworzenia długoterminowego random_seed, a następnie użyjemy go jako bazy do wysokoczęstotliwościowego generowania losowości za pomocą deterministycznych podpisów BLS z progiem, być może ograniczymy się tylko do jednego z tych schematów. Niestety, trudno jest z góry powiedzieć, jak będzie wyglądał protokół, cieszy tylko to, że podobnie jak w nauce, w zadaniach inżynieryjnych negatywny wynik to również wynik, a każda nowa próba rozwiązania problemu jest kolejnym krokiem w poszukiwaniach wszystkich zajmujących się tym zagadnieniem. Aby spełnić wymagania ze strony biznesu, rozwiązujemy konkretny praktyczny problem — zapewnienie aplikacjom gier niezawodnego źródła entropii, dlatego musimy także zwracać uwagę na sam blockchain, w szczególności na pytania dotyczące finalności łańcucha i zarządzania siecią.

I chociaż na razie nie widzimy w blockchainach udowodnionego i odpornego PVRB, który byłby używany wystarczająco długo, aby przejść próby w rzeczywistych aplikacjach, wieloma audytami, obciążeniami i oczywiście prawdziwymi atakami, liczba możliwych dróg potwierdza, że rozwiązanie istnieje i jeden z tych algorytmów w końcu rozwiąże problem. Z przyjemnością będziemy dzielić się wynikami i dziękujemy innym zespołom, które również zajmują się tym zagadnieniem, za artykuły i kody, które pozwalają inżynierom nie popełniać tych samych błędów drugi raz.

Kiedy spotykasz programistę projektującego zdecentralizowany generator losowy, bądź ostrożny i troskliwy, w razie potrzeby udziel mu wsparcia psychologicznego 🙂

Źródło: habr.com