Wprowadzenie

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

Podobnie jak w przypadku koncepcji absolutnie silnego szyfru z kryptografii, prawdziwe protokoły „Publicly Verible Random Beacon” (zwane dalej PVRB) starają się jedynie zbliżyć jak najbliżej idealnego schematu, ponieważ w rzeczywistych sieciach nie ma to zastosowania w czystej postaci: trzeba ściśle uzgodnić jeden bit, rund musi być wiele, a wszystkie wiadomości muszą być idealnie szybkie i zawsze dostarczane. Oczywiście nie ma to miejsca w prawdziwych sieciach. Dlatego przy projektowaniu PVRB do konkretnych zadań we współczesnych blockchainach, oprócz braku możliwości kontrolowania powstałej losowości i siły kryptograficznej, pojawia się wiele innych problemów czysto architektonicznych i technicznych.

Dla PVRB sam łańcuch bloków jest zasadniczo środkiem komunikacji, w którym wiadomości = transakcje. Pozwala to częściowo abstrahować od problemów z siecią, 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 uszkodzenia już wysłanej transakcji – to nie nie pozwalać uczestnikom na odmowę udziału w protokole, chyba że przeprowadzili skuteczny atak na konsensus. Taki poziom bezpieczeństwa jest akceptowalny, zatem PVRB powinien być odporny na zmowy uczestników dokładnie w takim samym stopniu, jak główny łańcuch blockchain. Wskazuje to również, że PVRB musi być częścią konsensusu, jeśli sieć zgadza się na główny łańcuch bloków, nawet jeśli zgadza się również na jedyny sprawiedliwy wynik losowy. Lub PVRB to po prostu samodzielny protokół wdrażany przez inteligentny kontrakt, który działa asynchronicznie w odniesieniu do łańcucha bloków i bloków. Obie metody mają swoje zalety i wady, a wybór pomiędzy nimi jest niezwykle nietrywialny.

Dwa sposoby wdrożenia PVRB

Opiszmy bardziej szczegółowo dwie opcje wdrożenia PVRB – wersję samodzielną, która działa w oparciu o inteligentny kontrakt niezależny od blockchaina oraz wersję zintegrowaną z konsensusem, wbudowaną w protokół, zgodnie z którą sieć uzgadnia blockchain i transakcje, które należy uwzględnić. We wszystkich przypadkach mam na myśli popularne silniki blockchain: Ethereum, EOS i wszystkie podobne do nich w sposobie hostowania i przetwarzania inteligentnych kontraktów.

Samodzielna umowa

W tej wersji PVRB jest inteligentnym kontraktem, który akceptuje transakcje losowych producentów (zwanych dalej RP), przetwarza je, łączy wyniki i w efekcie uzyskuje określoną wartość, którą każdy użytkownik może otrzymać z tego kontraktu. Wartość ta nie może być przechowywana bezpośrednio w kontrakcie, ale raczej być reprezentowana jedynie przez dane, z których można deterministycznie uzyskać jedną i tylko jedną wartość wynikowego losu. W tym schemacie RP są użytkownikami blockchainu i każdy może wziąć udział w procesie generowania.

Opcja z umową samodzielną jest dobra:

• przenośność (umowy można przeciągać z blockchain na blockchain)
• łatwość wdrożenia i testowania (umowy można łatwo napisać i przetestować)
• wygoda we wdrażaniu schematów ekonomicznych (łatwo stworzyć własny token, którego logika służy celom PVRB)
• możliwość uruchomienia na już działających blockchainach

Ma również wady:

• silne ograniczenia zasobów obliczeniowych, wolumenu transakcji i pamięci (innymi słowy, procesor/mem/io)
• ograniczenia operacji w ramach kontraktu (nie wszystkie instrukcje są dostępne, trudno jest podłączyć biblioteki zewnętrzne)
• niemożność organizowania wiadomości szybciej niż transakcje są zawarte w blockchainie

Ta opcja jest odpowiednia do wdrożenia PVRB, który musi działać w istniejącej sieci, nie zawiera skomplikowanej kryptografii i nie wymaga dużej liczby interakcji.

Zintegrowane w oparciu o konsensus

W tej wersji PVRB jest zaimplementowany w kodzie węzła blockchain, wbudowany lub działający równolegle z wymianą komunikatów pomiędzy węzłami blockchain. Wyniki protokołu zapisywane są bezpośrednio w utworzonych blokach, a komunikaty protokołu przesyłane są siecią p2p pomiędzy węzłami. Ponieważ protokół skutkuje liczbami, które mają być zapisane w blokach, sieć musi osiągnąć konsensus w ich sprawie. Oznacza to, że komunikaty PVRB, podobnie jak transakcje, muszą zostać zweryfikowane przez węzły i zawarte w blokach, aby każdy uczestnik sieci mógł sprawdzić zgodność z protokołem PVRB. To automatycznie prowadzi nas do oczywistego rozwiązania – jeśli sieć zgodzi się na konsensus co do bloku i transakcji w nim zawartych, to PVRB powinien być częścią konsensusu, a nie samodzielnym protokołem. W przeciwnym razie możliwe jest, że blokada jest ważna z punktu widzenia konsensusu, ale protokół PVRB nie jest przestrzegany i z punktu widzenia PVRB blokada nie może zostać zaakceptowana. Jeśli więc zostanie wybrana opcja „zintegrowana z konsensusem”, PVRB stanie się ważną częścią konsensusu.

Opisując wdrożenia PVRB na poziomie konsensusu sieciowego, w żadnym wypadku nie można uniknąć kwestii ostateczności. Finalność to mechanizm stosowany w deterministycznych konsensusach, który blokuje blok (i prowadzący do niego łańcuch), który jest ostateczny i nigdy nie zostanie wyrzucony, nawet jeśli nastąpi równoległe rozwidlenie. Przykładowo w Bitcoinie nie ma takiego mechanizmu – jeśli opublikujesz łańcuch o większej złożoności, zastąpi on każdy mniej skomplikowany, niezależnie od długości łańcuchów. A w EOS na przykład te ostatnie to tzw. ostatnie nieodwracalne bloki, które pojawiają się średnio co 432 bloki (12*21 + 12*15, pre-vote + pre-commit). Proces ten zasadniczo polega na oczekiwaniu na podpisy 2/3 producentów blokowych (zwanych dalej BP). Kiedy pojawiają się forki starsze niż ostatni LIB, są one po prostu odrzucane. Mechanizm ten pozwala zagwarantować, że transakcja zostanie uwzględniona w blockchainie i nigdy nie zostanie wycofana, niezależnie od zasobów atakującego. Ponadto ostatnie bloki to bloki podpisane przez 2/3 BP w Hyperledger, Tendermint i innych konsensusach opartych na pBFT. Ponadto sensowne jest uczynienie protokołu zapewniającego ostateczność dodatkiem do konsensusu, ponieważ może on działać asynchronicznie z produkcją i publikacją bloków. Oto dobry artykuł o ostateczności w Ethereum.

Finalność jest niezwykle ważna dla użytkowników, którzy bez niej mogą stać się ofiarami ataku „podwójnego wydatku”, w ramach którego BP „przetrzymuje” bloki i publikuje je, gdy sieć „zobaczy” dobrą transakcję. Jeśli nie ma ostateczności, opublikowany fork zastępuje blok „dobrą” transakcją inną, ze „złego” forku, w którym te same środki są przesyłane na adres atakującego. W przypadku PVRB wymagania dotyczące ostateczności są jeszcze bardziej rygorystyczne, ponieważ budowanie forków dla PVRB oznacza dla atakującego możliwość przygotowania kilku losowych opcji w celu opublikowania najbardziej opłacalnej, a ograniczenie czasu ewentualnego ataku jest dobre rozwiązanie.

Dlatego najlepszą opcją jest połączenie PVRB i finalności w jeden protokół - wtedy sfinalizowany blok = sfinalizowany losowo i właśnie to musieliśmy uzyskać. Teraz gracze otrzymają gwarantowaną losowość w N sekund i mogą być pewni, że nie będzie można jej cofnąć ani odtworzyć ponownie.

Opcja zintegrowana z konsensusem jest dobra:

• możliwość realizacji asynchronicznej w stosunku do produkcji bloków - bloki produkowane są w zwykły sposób, ale równolegle do tego może pracować protokół PVRB, który nie daje losowości dla każdego bloku
• możliwość wdrożenia nawet ciężkiej kryptografii, bez ograniczeń nałożonych na inteligentne kontrakty
• możliwość organizowania wymiany komunikatów szybciej niż transakcje zawarte są w blockchainie, np. część protokołu może pracować pomiędzy węzłami bez dystrybucji komunikatów w sieci

Ma również wady:

• Trudności w testowaniu i rozwoju - będziesz musiał emulować błędy sieciowe, brakujące węzły, hard forki sieciowe
• Błędy implementacyjne wymagają hardforku sieci

Obydwa sposoby wdrożenia PVRB mają prawo do życia, jednak wdrożenie na inteligentnych kontraktach we współczesnych blockchainach jest w dalszym ciągu dość ograniczone zasobami obliczeniowymi, a jakiekolwiek przejście na poważną kryptografię często jest po prostu niemożliwe. Będziemy potrzebować poważnej kryptografii, co zostanie pokazane poniżej. Choć problem ten ma wyraźnie charakter tymczasowy, do rozwiązania wielu problemów potrzebna jest poważna kryptografia w kontraktach i pojawia się ona stopniowo (np. kontrakty systemowe dla zkSNARK w Ethereum)

Blockchain, który zapewnia przejrzysty i niezawodny kanał przesyłania komunikatów protokołów, nie robi tego za darmo. Każdy zdecentralizowany protokół musi uwzględniać możliwość ataku Sybil, każda akcja może być wykonana wspólnymi siłami wielu kont, dlatego przy projektowaniu należy wziąć pod uwagę zdolność atakujących do stworzenia dowolnej liczby protokołów uczestników działających w zmowie.

PVRB i zmienne blokowe.

Nie skłamałem mówiąc, że nikt jeszcze nie zaimplementował w blockchainach dobrego PVRB, przetestowanego przez wiele aplikacji hazardowych. Skąd zatem bierze się tak wiele aplikacji hazardowych na Ethereum i EOS? Zaskakuje mnie to tak samo, jak zaskakuje ciebie. Skąd wzięli tak wiele „trwałych” losów w całkowicie deterministycznym środowisku?

Ulubionym sposobem uzyskania losowości w łańcuchu bloków jest pobranie z bloku jakiejś „nieprzewidywalnej” informacji i utworzenie na jej podstawie losowej informacji – po prostu poprzez hashowanie jednej lub więcej wartości. Dobry artykuł o problemach takich schematów tutaj. Możesz przyjąć w bloku dowolne „nieprzewidywalne” wartości, na przykład hash bloku, liczbę transakcji, złożoność sieci i inne wartości nieznane z góry. Następnie zahaszuj je, jeden lub więcej, i teoretycznie powinieneś otrzymać naprawdę losowy wynik. Możesz nawet dodać do białej gazety, że Twój schemat jest „zabezpieczony post-kwantowo” (ponieważ istnieją kwantowo odporne funkcje skrótu :)).

Ale nawet post-kwantowe bezpieczne skróty nie wystarczą. Sekret tkwi w wymaganiach dla PVRB, przypomnę je z poprzedniego artykułu:

1. Wynik musi mieć możliwy do udowodnienia równomierny rozkład, tj. być oparty na możliwej do udowodnienia silnej kryptografii.
2. Nie ma możliwości kontrolowania żadnego bitu wyniku. W rezultacie nie można z góry przewidzieć wyniku.
3. Nie można sabotować protokołu generowania poprzez nieuczestniczenie w protokole lub przeciążanie sieci komunikatami ataku
4. Wszystko to musi być odporne na zmowę dopuszczalnej liczby nieuczciwych uczestników protokołu (np. 1/3 uczestników).

W tym przypadku spełniony jest tylko wymóg 1, a nie spełniony jest wymóg 2. Mieszając nieprzewidywalne wartości z bloku, otrzymamy równomierny rozkład i dobre losy. Ale BP ma przynajmniej opcję „opublikowania bloku lub nie”. Zatem BP może wybrać przynajmniej DWIE losowe opcje: „własną” i tę, która okaże się, jeśli ktoś inny wykona blok. BP może z wyprzedzeniem „podsłuchać”, co się stanie, jeśli opublikuje blok, i po prostu decyduje się to zrobić lub nie. Zatem grając na przykład w ruletkę „parzysto-nieparzysty” lub „czerwony/czarny”, może opublikować blok tylko wtedy, gdy zobaczy wygraną. To również sprawia, że ​​strategia wykorzystania na przykład skrótu blokowego „z przyszłości” jest niewykonalna. W tym przypadku mówią, że „zostanie użyty losowy, który uzyskuje się poprzez hashowanie bieżących danych i hash przyszłego bloku o wysokości np. N + 42, gdzie N to bieżąca wysokość bloku. Wzmacnia to nieco schemat, ale nadal pozwala BP, choć w przyszłości, na wybór, czy wstrzymać blokadę, czy opublikować.

Oprogramowanie BP w tym przypadku staje się bardziej skomplikowane, ale niewiele. Po prostu, podczas walidacji i włączania transakcji do bloku, następuje szybkie sprawdzenie, czy dojdzie do wygranej i ewentualnie wybór jednego z parametrów transakcji, aby uzyskać wysokie prawdopodobieństwo wygranej. Jednocześnie prawie niemożliwe jest złapanie sprytnego BP na takie manipulacje, za każdym razem możesz używać nowych adresów i stopniowo wygrywać, nie wzbudzając podejrzeń.

Zatem metody wykorzystujące informacje z bloku nie nadają się jako uniwersalna implementacja PVRB. W wersji ograniczonej, z ograniczeniami dotyczącymi wielkości zakładów, ograniczeniami dotyczącymi liczby graczy i/lub rejestracji KYC (aby uniemożliwić jednemu graczowi korzystanie z wielu adresów), schematy te mogą działać w przypadku małych gier, ale nic więcej.

PVRB i zatwierdzenie-ujawnienie.

OK, dzięki mieszaniu i przynajmniej względnej nieprzewidywalności skrótu bloku i innych zmiennych. Jeśli rozwiążesz problem czołowych górników, powinieneś dostać coś bardziej odpowiedniego. Dodajmy do tego schematu użytkowników - niech oni także mają wpływ na losowość: każdy pracownik wsparcia technicznego powie Ci, że najbardziej losową rzeczą w systemach IT są działania użytkowników :)

Naiwny schemat, w którym użytkownicy po prostu wysyłają losowe liczby, a wynik jest obliczany na przykład jako skrót ich sumy, nie jest odpowiedni. W takim przypadku ostatni gracz może, wybierając własną losowość, kontrolować wynik. Dlatego właśnie używany jest bardzo szeroko stosowany wzorzec zatwierdzania i ujawniania. Uczestnicy najpierw wysyłają skróty ze swoich losów (zatwierdzenia), a następnie sami je otwierają (ujawniają). Faza „ujawniania” rozpoczyna się dopiero po zebraniu niezbędnych zatwierdzeń, dzięki czemu uczestnicy mogą wysłać dokładnie taki losowy skrót, z którego wysłali wcześniej. Teraz połączmy to wszystko z parametrami bloku, lepszego niż ten wzięty z przyszłości (losowość można znaleźć tylko w jednym z przyszłych bloków) i voila – losowość gotowa! Teraz każdy gracz ma wpływ na powstałą losowość i może „pokonać” złośliwego BP, zastępując go własną, z góry nieznaną losowością... Możesz także dodać ochronę przed sabotażem protokołu, nie otwierając go na etapie ujawniania - po prostu poprzez wymaganie dołączenia do transakcji określonej kwoty przy jej zawarciu — kaucji, która zostanie zwrócona dopiero w trakcie procedury ujawniania. W takim przypadku popełnienie i nieujawnienie będzie nieopłacalne.

To była dobra próba, takie schematy istnieją również w grach DApps, ale niestety to znowu nie wystarczy. Teraz nie tylko górnik, ale także każdy uczestnik protokołu może mieć wpływ na wynik. Nadal możliwe jest kontrolowanie samej wartości, z mniejszą zmiennością i kosztem, ale podobnie jak w przypadku górnika, jeśli wyniki losowania są cenniejsze niż opłata za udział w protokole PVRB, wówczas losowy -producer(RP) może zdecydować, czy ujawnić i nadal może wybierać spośród co najmniej dwóch losowych opcji.
Ale stało się możliwe karanie tych, którzy popełniają i nie ujawniają, a ten schemat się przyda. Jego prostota jest poważną zaletą - poważniejsze protokoły wymagają znacznie potężniejszych obliczeń.

PVRB i sygnatury deterministyczne.

Istnieje inny sposób, aby zmusić RP do podania liczby pseudolosowej, na którą nie ma wpływu, jeśli zostanie mu dostarczony „obraz wstępny” - jest to podpis deterministyczny. Taki podpis to np. RSA, a nie ECS. Jeśli RP ma parę kluczy: RSA i ECC i swoim kluczem prywatnym podpisuje określoną wartość, to w przypadku RSA otrzyma JEDNYM I TYLKO JEDEN podpis, a w przypadku ECS może wygenerować dowolną liczbę różne ważne podpisy. Dzieje się tak dlatego, że podczas tworzenia podpisu ECS wykorzystywana jest losowa liczba, wybrana przez podpisującego, i można ją wybrać w dowolny sposób, 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 otrzyma inny RP, dlatego PVRB z deterministycznymi podpisami można zorganizować, łącząc podpisy RSA kilku uczestników, którzy podpisali tę samą wartość. Na przykład poprzedni losowy. Ten schemat pozwala zaoszczędzić wiele zasobów, ponieważ podpisy są zarówno potwierdzeniem prawidłowego zachowania zgodnie z protokołem, jak i źródłem losowości.

Jednak nawet w przypadku podpisów deterministycznych schemat jest nadal podatny na problem „ostatniego aktora”. Ostatni uczestnik może jeszcze zdecydować, czy opublikować podpis, czy nie, kontrolując w ten sposób wynik. Możesz modyfikować schemat, dodawać do niego skróty blokowe, robić zaokrąglenia, aby wyniku nie można było przewidzieć z góry, ale wszystkie te techniki, nawet biorąc pod uwagę wiele modyfikacji, nadal pozostawiają nierozwiązany problem wpływu jednego uczestnika na kolektyw skutkuje powstaniem niezaufanego środowiska i może działać jedynie pod ograniczeniami ekonomicznymi i czasowymi. Poza tym rozmiar kluczy RSA (1024 i 2048 bitów) jest dość duży, a rozmiar dla transakcji typu blockchain jest niezwykle istotnym parametrem. Najwyraźniej nie ma prostego sposobu na rozwiązanie problemu, przejdźmy dalej.

PVRB i programy tajnego udostępniania

W kryptografii istnieją schematy, które pozwalają sieci na uzgodnienie jednej i tylko jednej wartości PVRB, przy czym schematy takie są odporne na jakiekolwiek złośliwe działania niektórych uczestników. Jednym z przydatnych protokołów, z którym warto się zapoznać, jest schemat tajnego udostępniania Shamira. Służy do podzielenia sekretu (na przykład tajnego klucza) na kilka części i przekazania tych części N uczestnikom. Sekret jest rozdzielany w taki sposób, że do jego odzyskania wystarczy M części z N i mogą to być dowolne M części. Jeśli na palcach, to mając wykres nieznanej funkcji, uczestnicy wymieniają się punktami na wykresie, a po otrzymaniu M punktów można przywrócić całą funkcję.
Dobre wyjaśnienie podano w wiki ale zabawa z nim praktycznie w celu odtworzenia protokołu w głowie jest przydatna próbny strona.

Gdyby schemat FSSS (Fiat-Shamir Secret Sharing) miał zastosowanie w czystej postaci, byłby to niezniszczalny PVRB. W najprostszej formie protokół może wyglądać następująco:

• Każdy uczestnik generuje swój własny los i rozdziela z niego udziały innym uczestnikom
• Każdy uczestnik odkrywa swoją część tajemnic pozostałych uczestników
• Jeśli uczestnik ma więcej niż M akcji, wówczas można obliczyć liczbę tego uczestnika i będzie ona unikalna, niezależnie od zbioru ujawnionych uczestników
• Kombinacja ujawnionych losów jest pożądanym PVRB

Tutaj indywidualny uczestnik nie ma już wpływu na wyniki protokołu, z wyjątkiem przypadków, w których osiągnięcie progu ujawnienia losowości zależy wyłącznie od niego. Zatem ten protokół, jeśli jest wymagana proporcja RP pracujących nad protokołem i dostępnych, działa, realizując wymagania dotyczące siły kryptograficznej i będąc odpornym na problem „ostatniego aktora”.

Może to być idealna opcja, ten schemat PVRB oparty na udostępnianiu tajnych informacji Fiat-Shamir opisano na przykład w to artykuł. Ale, jak wspomniano powyżej, jeśli spróbujesz zastosować to bezpośrednio w blockchainie, pojawią się ograniczenia techniczne. Oto przykład testowej implementacji protokołu w inteligentnej umowie EOS i jej najważniejsza część - sprawdzenie opublikowanego uczestnika udziału: kod. Z kodu widać, że weryfikacja dowodu wymaga kilku mnożeń przez skalar, a użyte liczby są bardzo duże. Należy rozumieć, że w blockchainach weryfikacja następuje w momencie, gdy producent bloku przetwarza transakcję i w ogóle każdy uczestnik musi łatwo zweryfikować poprawność protokołu, więc wymagania dotyczące szybkości funkcji weryfikacji są bardzo poważne . W tym wariancie opcja okazała się nieskuteczna, gdyż weryfikacja nie zmieściła się w limicie transakcji (0.5 sekundy).

Skuteczność weryfikacji jest jednym z najważniejszych wymogów stosowania w ogóle wszelkich zaawansowanych schematów kryptograficznych w blockchainie. Tworzenie proofów, przygotowywanie komunikatów – procedury te można zdjąć z łańcucha i wykonać na komputerach o dużej wydajności, ale weryfikacji nie da się ominąć – to kolejny ważny wymóg dla PVRB.

PVRB i sygnatury progowe

Zapoznawszy się ze schematem tajnego udostępniania, odkryliśmy całą klasę protokołów, które łączy słowo kluczowe „próg”. Kiedy ujawnienie jakiejś informacji wymaga udziału M uczciwych uczestników z N, a zbiór uczciwych uczestników może stanowić dowolny podzbiór N, mówimy o schematach „progowych”. To właśnie one pozwalają uporać się z problemem „ostatniego aktora”, teraz jeśli atakujący nie zdradzi swojej części tajemnicy, zrobi to za niego inny, uczciwy uczestnik. Schematy te pozwalają na porozumienie co do jednego i tylko jednego znaczenia, nawet jeśli protokół zostanie sabotowany przez część uczestników.

Połączenie deterministycznych sygnatur i schematów progowych umożliwiło opracowanie bardzo wygodnego i obiecującego schematu wdrażania PVRB - są to deterministyczne sygnatury progowe. Tutaj artykuł o różnych zastosowaniach podpisów progowych, a oto kolejny dobry dawno przeczytane z Dasha.

Ostatni artykuł opisuje podpisy BLS (BLS to skrót od Boneh-Lynn-Shacham, tutaj artykuł), które mają bardzo ważną i niezwykle wygodną dla programistów cechę - klucze publiczne, tajne, publiczne i podpisy BLS można ze sobą łączyć za pomocą prostych operacji matematycznych, przy czym ich kombinacje pozostają ważnymi kluczami i podpisami, co pozwala na łatwe agregowanie wielu podpisów w jeden i wielu kluczy publicznych w jeden. Są one również deterministyczne i dają ten sam wynik dla tych samych danych wejściowych. Dzięki tej jakości kombinacje podpisów BLS same w sobie są ważnymi kluczami, co pozwala na wdrożenie opcji, w której M z N uczestników tworzy jeden i tylko jeden podpis, który jest deterministyczny, publicznie weryfikowalny i nieprzewidywalny do czasu jego otwarcia przez Mth uczestnik .

W schemacie z progowymi podpisami BLS każdy uczestnik podpisuje coś za pomocą BLS (na przykład poprzedni losowy), a wspólny podpis progowy jest pożądanym losowym. Właściwości kryptograficzne podpisów BLS spełniają wymagania jakości losowej, część progowa chroni przed „ostatnim aktorem”, a unikalna możliwość łączenia kluczy umożliwia implementację wielu innych ciekawych algorytmów, które pozwalają np. na wydajną agregację komunikatów protokołu .

Tak więc, jeśli budujesz PVRB na swoim blockchainie, najprawdopodobniej skończysz ze schematem podpisów progowych BLS, kilka projektów już z niego korzysta. Na przykład DFinity (tutaj benchmark, który implementuje obwód, oraz tutaj przykładowa implementacja weryfikowalnego udostępniania sekretów) lub Keep.network (tutaj jest ich losowy sygnał nawigacyjny żółty papier, Ale przykład inteligentny kontrakt obsługujący protokół).

Wdrożenie PVRB

Niestety, nadal nie widzimy gotowego protokołu zaimplementowanego w blockchainach PVRB, który udowodniłby swoje bezpieczeństwo i stabilność. Mimo że same protokoły są gotowe, technicznie zastosowanie ich do istniejących rozwiązań nie jest łatwe. W przypadku systemów scentralizowanych PVRB nie ma sensu, a zdecentralizowane są ściśle ograniczone we wszystkich zasobach obliczeniowych: procesorze, pamięci, pamięci masowej, wejściach/wyjściach. Projektowanie PVRB to połączenie różnych protokołów w celu stworzenia czegoś, co spełnia wszystkie wymagania przynajmniej części realnego blockchainu. Jeden protokół wykonuje obliczenia wydajniej, ale wymaga większej liczby komunikatów między RP, podczas gdy drugi wymaga bardzo niewielu komunikatów, ale utworzenie dowodu może zająć dziesiątki minut, a nawet godzin.

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

• Siła kryptograficzna. Twój PVRB musi być całkowicie bezstronny i nie mieć możliwości kontrolowania ani jednego bitu. W niektórych schematach tak nie jest, dlatego zadzwoń do kryptologa
• Problem „ostatniego aktora”.. Twój PVRB musi być odporny na ataki, w których atakujący kontrolujący jeden lub więcej RP może wybrać jeden z dwóch wyników.
• Problem sabotażu protokołu. Twój PVRB musi być odporny na ataki, w których atakujący kontrolujący jeden lub więcej RP decyduje, czy ma to być losowy, czy nie, i może mieć gwarancję lub z określonym prawdopodobieństwem wywarcia na to wpływu
• Problem z liczbą wiadomości. Twoi RP powinni wysyłać minimum komunikatów do blockchainu i w miarę możliwości unikać działań synchronicznych, takich jak sytuacje typu „Wysłałem pewne informacje, czekam na odpowiedź od konkretnego uczestnika”. W sieciach p2p, szczególnie rozproszonych geograficznie, nie należy liczyć na szybką reakcję
• Problem złożoności obliczeniowej. Weryfikacja dowolnego etapu łańcucha PVRB powinna być niezwykle łatwa, ponieważ wykonują ją wszyscy pełnoprawni klienci sieci. Jeśli wdrożenie odbywa się za pomocą inteligentnego kontraktu, wówczas wymagania dotyczące prędkości są bardzo rygorystyczne
• Problem dostępności i żywotności. Twój PVRB powinien starać się być odporny na sytuacje, w których część sieci staje się niedostępna przez pewien czas, a część RP po prostu przestaje działać
• Problem zaufanej konfiguracji i początkowej dystrybucji klucza. Jeśli Twój PVRB korzysta z podstawowej konfiguracji protokołu, jest to osobna, duża i poważna historia. Tutaj przykład. Jeżeli uczestnicy muszą przekazać sobie nawzajem swoje klucze przed rozpoczęciem protokołu, stanowi to również problem w przypadku zmiany składu uczestników
• Problemy rozwojowe. Dostępność bibliotek w wymaganych językach, ich bezpieczeństwo i wydajność, promocja, złożone testy itp.

Przykładowo progowe podpisy BLS mają poważny problem – przed przystąpieniem do pracy uczestnicy muszą rozdać sobie klucze, organizując grupę, w ramach której próg będzie działał. Oznacza to, że przynajmniej jedna runda wymiany w zdecentralizowanej sieci będzie musiała poczekać, a biorąc pod uwagę, że wygenerowany rand jest niezbędny np. w grach, niemal w czasie rzeczywistym, oznacza to, że na tym etapie możliwy jest sabotaż protokołu , a zalety systemu progowego zostaną utracone . Problem ten jest już prostszy niż poprzednie, ale nadal wymaga opracowania odrębnej procedury tworzenia grup progowych, które trzeba będzie chronić ekonomicznie poprzez wpłaty i wypłaty środków (tzw. obniżki) od uczestników, którzy nie przestrzegają protokół. Poza tym weryfikacja BLS przy akceptowalnym poziomie bezpieczeństwa po prostu nie mieści się np. w standardową transakcję EOS czy Ethereum – na weryfikację po prostu nie starcza czasu. Kod kontraktu to WebAssembly lub EVM, wykonywany przez maszynę wirtualną. Funkcje kryptograficzne nie są (jeszcze) zaimplementowane natywnie i działają kilkadziesiąt razy wolniej niż konwencjonalne biblioteki kryptograficzne. Wiele protokołów nie spełnia wymagań opartych wyłącznie na wolumenie klucza, na przykład 1024 i 2048 bitów dla RSA, 4-8 razy więcej niż standardowy podpis transakcji w Bitcoin i Ethereum.

Istotną rolę odgrywa także obecność implementacji w różnych językach programowania – których jest niewiele, szczególnie w przypadku nowych protokołów. Opcja z integracją do konsensusu wymaga napisania protokołu w języku platformy, więc kodu będziesz musiał szukać w Go dla geth, w Rust dla Parity, w C++ dla EOS. Kodu JavaScript będzie musiał szukać każdy, a że JavaScript i kryptografia nie są zbyt bliskimi przyjaciółmi, z pomocą przyjdzie WebAssembly, który teraz zdecydowanie pretenduje do miana kolejnego ważnego standardu internetowego.

wniosek

Mam nadzieję, że w poprzednim Artykuł Udało mi się Cię przekonać, że generowanie liczb losowych na blockchainie jest krytyczne dla wielu aspektów życia zdecentralizowanych sieci i tym artykułem pokazałem, że to zadanie jest niezwykle ambitne i trudne, ale dobre rozwiązania już istnieją. Ogólnie rzecz biorąc, ostateczny projekt protokołu jest możliwy dopiero po przeprowadzeniu masowych testów, które uwzględniają wszystkie aspekty, od konfiguracji po emulację błędów, więc jest mało prawdopodobne, aby znaleźć gotowe przepisy w oficjalnych dokumentach i artykułach zespołu, a my na pewno tego nie zrobimy zdecyduj za rok lub dwa, napisz „zrób to w ten sposób, dokładnie tak”.

Cześć, dla naszego PVRB w opracowywanym blockchainie Haya, zdecydowaliśmy się na stosowanie progowych podpisów BLS, planujemy wdrożenie PVRB na poziomie konsensusu, ponieważ weryfikacja w inteligentnych kontraktach przy akceptowalnym poziomie bezpieczeństwa nie jest jeszcze możliwa. Możliwe, że zastosujemy dwa schematy na raz: najpierw drogie udostępnianie sekretu w celu stworzenia długoterminowego random_seed, a następnie wykorzystamy to jako podstawę do generowania losowego o wysokiej częstotliwości przy użyciu deterministycznych progowych sygnatur BLS, być może ograniczymy się tylko do jeden ze schematów. Niestety nie da się z góry powiedzieć jaki będzie protokół, jedyne co dobre to to, że tak jak w nauce, w problemach inżynierskich wynik negatywny też jest skutkiem, a każda nowa próba rozwiązania problemu to kolejny krok do przodu badania wszystkich osób zaangażowanych w problem. Aby sprostać wymaganiom biznesowym, rozwiązujemy konkretny problem praktyczny – zapewnienie aplikacjom gamingowym niezawodnego źródła entropii, zatem musimy zwrócić uwagę także na sam blockchain, w szczególności na kwestie finalności łańcucha i zarządzania siecią.

I choć nie widzimy jeszcze w blockchainach sprawdzonego, odpornego PVRB, który byłby używany przez wystarczająco dużo czasu, aby został przetestowany przez rzeczywiste aplikacje, wielokrotne audyty, obciążenia i oczywiście prawdziwe ataki, to liczba możliwych ścieżek to potwierdza istnieje rozwiązanie i który z tych algorytmów ostatecznie rozwiąże problem. Chętnie podzielimy się wynikami i podziękujemy innym zespołom, które również pracują nad tym problemem, za artykuły i kod, który pozwala inżynierom nie wchodzić dwa razy na tę samą prowizję.

Tak więc, gdy spotkasz programistę projektującego zdecentralizowany los, bądź uważny i opiekuńczy, a jeśli to konieczne, zapewnij pomoc psychologiczną :)

Źródło: www.habr.com