{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Liczby losowe i sieci zdecentralizowane: implementacje","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Wprowadzenie<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">function getAbsolutelyRandomNumer() {\n        return 4; \/\/ returns absolutely random number!\n}<\/code><\/pre>\n<p><\/p>\n<p>Podobnie jak w przypadku koncepcji absolutnie odpornych szyfr\u00f3w w kryptografii, rzeczywiste protoko\u0142y \u201ePublicly Verifiable Random Beacon\u201d (dalej PVRB) jedynie staraj\u0105 si\u0119 jak najlepiej przybli\u017cy\u0107 do idealnego schematu, poniewa\u017c w rzeczywistych sieciach nie jest on w czystej postaci zastosowalny: nale\u017cy si\u0119 um\u00f3wi\u0107 wy\u0142\u0105cznie na jeden bit, rund musi by\u0107 wiele, a wszystkie wiadomo\u015bci powinny by\u0107 ca\u0142kowicie szybkie i zawsze dostarczane. Oczywi\u015bcie, w rzeczywistych sieciach tak nie jest. Dlatego przy projektowaniu PVRB pod konkretne zadania w nowoczesnych blockchainach, opr\u00f3cz niemo\u017cno\u015bci kontroli uzyskanego losowego wyniku i odporno\u015bci kryptograficznej, pojawia si\u0119 jeszcze wiele czysto architektonicznych i technicznych problem\u00f3w.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Sam blockchain jest dla PVRB zasadniczo \u015brodowiskiem komunikacyjnym, w kt\u00f3rym wiadomo\u015bci=transakcje. Pozwala to cz\u0119\u015bciowo abstrahowa\u0107 od problem\u00f3w sieciowych, niedostarczenia wiadomo\u015bci, problem\u00f3w z oprogramowaniem po\u015brednicz\u0105cym \u2014 wszystkie te ryzyka bierze na siebie zdecentralizowana sie\u0107, a jej g\u0142\u00f3wn\u0105 warto\u015bci\u0105 dla PVRB jest niemo\u017cno\u015b\u0107 odwo\u0142ania lub zepsucia ju\u017c wys\u0142anej transakcji \u2014 to nie pozwala uczestnikom wycofa\u0107 si\u0119 z udzia\u0142u w protokole, chyba \u017ce przeprowadzili udany atak na konsensus. Taki poziom bezpiecze\u0144stwa jest akceptowalny, dlatego PVRB musi by\u0107 odporny na zmowy uczestnik\u00f3w dok\u0142adnie w takim samym stopniu, jak g\u0142\u00f3wny \u0142a\u0144cuch blockchaina. To tak\u017ce sugeruje, \u017ce PVRB powinien by\u0107 cz\u0119\u015bci\u0105 konsensusu, je\u015bli sie\u0107 um\u00f3wi\u0142a si\u0119 co do g\u0142\u00f3wnego \u0142a\u0144cucha blok\u00f3w, niech jednocze\u015bnie um\u00f3wi si\u0119 r\u00f3wnie\u017c na jedyny uczciwy wynik losowy. Alternatywnie, PVRB mo\u017ce by\u0107 po prostu protoko\u0142em niezale\u017cnym, realizowanym przez smart kontrakt, dzia\u0142aj\u0105cym asynchronicznie w stosunku do blockchaina i blok\u00f3w. Oba sposoby maj\u0105 swoje zalety i wady, a wyb\u00f3r pomi\u0119dzy nimi jest niezwykle z\u0142o\u017cony. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">Dwa sposoby implementacji PVRB<\/h2>\n<p><\/p>\n<p>Opiszmy dok\u0142adniej dwa warianty implementacji PVRB \u2014 wersj\u0119 niezale\u017cn\u0105, dzia\u0142aj\u0105c\u0105 z wykorzystaniem smart kontraktu, niezwi\u0105zanego z blockchainem, oraz wersj\u0119 zintegrowan\u0105 z konsensusem \u2014 wbudowan\u0105 w protok\u00f3\u0142, zgodnie z kt\u00f3rym sie\u0107 umawia si\u0119 co do \u0142a\u0144cucha blok\u00f3w i w\u0142\u0105czanych transakcji. We wszystkich przypadkach b\u0119d\u0119 mie\u0107 na my\u015bli popularne silniki blockchainowe: Ethereum, EOS i wszystkie inne, podobne do nich pod wzgl\u0119dem umieszczania i przetwarzania smart kontrakt\u00f3w. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Umowa samodzielna<\/h3>\n<p><\/p>\n<p>W tym wariancie PVRB jest inteligentnym kontraktem, kt\u00f3ry przyjmuje transakcje random-producer-\u00f3w (dalej RP), przetwarza je, \u0142\u0105czy wyniki i, w rezultacie, dochodzi do pewnej warto\u015bci, kt\u00f3r\u0105 mo\u017ce uzyska\u0107 ka\u017cdy u\u017cytkownik z tego kontraktu. Ta warto\u015b\u0107 nie musi by\u0107 przechowywana bezpo\u015brednio w kontrakcie, ale mo\u017ce by\u0107 reprezentowana jedynie przez dane, z kt\u00f3rych mo\u017cna deterministycznie uzyska\u0107 jedn\u0105 i tylko jedn\u0105 warto\u015b\u0107 rezultatu losowego. W tej schemacie RP to u\u017cytkownicy blockchaina, a w procesie generacji mo\u017cna pozwoli\u0107 uczestniczy\u0107 ka\u017cdemu.<\/p>\n<p><\/p>\n<p>Wariant z umow\u0105 samodzieln\u0105 jest dobry:<\/p>\n<p><\/p>\n<ul>\n<li>przeno\u015bno\u015bci\u0105 (kontrakty mo\u017cna przenosi\u0107 z blockchaina do blockchaina)<\/li>\n<li>\u0142atwo\u015bci\u0105 w realizacji i testowaniu (kontrakty \u0142atwo pisa\u0107 i testowa\u0107)<\/li>\n<li>wygod\u0105 w realizacji schemat\u00f3w ekonomicznych (\u0142atwo stworzy\u0107 sw\u00f3j token, kt\u00f3rego logika s\u0142u\u017cy celom PVRB)<\/li>\n<li>mo\u017cliwo\u015bci\u0105 uruchomienia w ju\u017c dzia\u0142aj\u0105cych blockchainach<\/li>\n<\/ul>\n<p><\/p>\n<p>Ma r\u00f3wnie\u017c wady:<\/p>\n<p><\/p>\n<ul>\n<li>silne ograniczenia zasob\u00f3w podczas oblicze\u0144, obj\u0119to\u015bci transakcji i storage (pro\u015bciej m\u00f3wi\u0105c cpu\/mem\/io)<\/li>\n<li>ograniczenia operacji wewn\u0105trz kontraktu (nie wszystkie instrukcje s\u0105 dost\u0119pne, trudno pod\u0142\u0105cza\u0107 zewn\u0119trzne biblioteki)<\/li>\n<li>niemo\u017cliwo\u015b\u0107 zorganizowania wymiany wiadomo\u015bci szybciej, ni\u017c transakcje s\u0105 w\u0142\u0105czane do blockchaina<\/li>\n<\/ul>\n<p><\/p>\n<p>Ten wariant nadaje si\u0119 do realizacji PVRB, kt\u00f3ry musi by\u0107 uruchomiony w ju\u017c istniej\u0105cej sieci, nie zawieraj\u0105cej skomplikowanej kryptografii i nie wymagaj\u0105cej du\u017cej liczby interakcji.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Zintegrowane z konsensusem<\/h3>\n<p><\/p>\n<p>W tej wersji PVRB zosta\u0142 zaimplementowany w kodzie w\u0119z\u0142a blockchain, wbudowany lub dzia\u0142aj\u0105cy r\u00f3wnolegle z wymian\u0105 wiadomo\u015bci mi\u0119dzy w\u0119z\u0142ami blockchain. Wyniki protoko\u0142u s\u0105 zapisywane bezpo\u015brednio w tworzonych blokach, a wiadomo\u015bci protoko\u0142u s\u0105 wysy\u0142ane w sieci p2p mi\u0119dzy w\u0119z\u0142ami. Poniewa\u017c protok\u00f3\u0142 generuje liczby, kt\u00f3re musz\u0105 by\u0107 zapisane w blokach, sie\u0107 musi osi\u0105gn\u0105\u0107 konsensus w tej sprawie. Oznacza to, \u017ce wiadomo\u015bci PVRB, podobnie jak transakcje, musz\u0105 by\u0107 walidowane przez w\u0119z\u0142y i w\u0142\u0105czane do blok\u00f3w, aby ka\u017cdy uczestnik sieci m\u00f3g\u0142 zweryfikowa\u0107 przestrzeganie protoko\u0142u PVRB. Automatycznie prowadzi to do oczywistego rozwi\u0105zania \u2014 je\u015bli sie\u0107 dochodzi do konsensusu w sprawie bloku i transakcji w nim, PVRB musi by\u0107 cz\u0119\u015bci\u0105 konsensusu, a nie oddzielnym protoko\u0142em. W przeciwnym razie mo\u017ce wyst\u0105pi\u0107 sytuacja, w kt\u00f3rej blok jest wa\u017cny z punktu widzenia konsensusu, ale protok\u00f3\u0142 PVRB nie jest przestrzegany, a z punktu widzenia PVRB blok nie mo\u017ce by\u0107 zaakceptowany. Tak wi\u0119c, je\u015bli wybrana zostanie opcja \u201eintegracja z konsensusem\u201d, PVRB staje si\u0119 wa\u017cn\u0105 cz\u0119\u015bci\u0105 konsensusu.<\/p>\n<p><\/p>\n<p>Opisuj\u0105c implementacje PVRB na poziomie konsensusu w sieci, w \u017cadnym wypadku nie mo\u017cna pomin\u0105\u0107 kwestii finalno\u015bci. Finalno\u015b\u0107 to mechanizm stosowany w deterministycznych konsensusach, kt\u00f3ry utrwala blok (i \u0142a\u0144cuch prowadz\u0105cy do niego) jako finalny, kt\u00f3ry nigdy nie zostanie odrzucony, nawet je\u015bli pojawi si\u0119 r\u00f3wnoleg\u0142y fork. Na przyk\u0142ad w Bitcoinie nie ma takiego mechanizmu \u2014 je\u015bli opublikowana zostanie \u0142a\u0144cuch o wi\u0119kszej z\u0142o\u017cono\u015bci, zast\u0105pi ona wszelkie mniej z\u0142o\u017cone, niezale\u017cnie od d\u0142ugo\u015bci \u0142a\u0144cuch\u00f3w. A w EOS na przyk\u0142ad finalnymi s\u0105 tak zwane Ostatnie Nieodwracalne Bloki, kt\u00f3re pojawiaj\u0105 si\u0119 \u015brednio co 432 bloki (12*21 + 12*15, pre-vote + pre-commit). Proces ten polega na oczekiwaniu na podpisy 2\/3 producent\u00f3w blok\u00f3w (dalej BP). Gdy pojawi\u0105 si\u0119 forki, kt\u00f3re s\u0105 starsze ni\u017c ostatni LIB, po prostu zostan\u0105 odrzucone. Ten mechanizm pozwala gwarantowa\u0107, \u017ce transakcja jest w\u0142\u0105czona do blockchaina i nigdy nie zostanie wycofana, niezale\u017cnie od zasob\u00f3w atakuj\u0105cego. Ponadto, finalnymi blokami s\u0105 bloki podpisane przez 2\/3 BP w Hyperledger, Tendermint i innych konsensusach opartych na pBFT. Ponadto, sensowne jest, aby protok\u00f3\u0142 zapewniaj\u0105cy finalno\u015b\u0107 dzia\u0142a\u0142 jako nadbudowa nad konsensusem, poniewa\u017c mo\u017ce pracowa\u0107 asynchronicznie z produkcj\u0105 i publikacj\u0105 blok\u00f3w. <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">artyku\u0142<\/a><\/noindex> o finalno\u015bci w Ethereum.<\/p>\n<p><\/p>\n<p>Finalno\u015b\u0107 jest niezwykle wa\u017cna dla u\u017cytkownik\u00f3w, kt\u00f3rzy bez niej mog\u0105 sta\u0107 si\u0119 ofiar\u0105 ataku \u201edouble spend\u201d, w kt\u00f3rym BP \u201ewstrzymuje\u201d bloki i publikuje je po tym, jak sie\u0107 \u201ezobaczy\u201d dobr\u0105 transakcj\u0119. Je\u015bli nie ma finalno\u015bci, opublikowany fork zast\u0119puje blok z \u201edobr\u0105\u201d transakcj\u0105 innym, z \u201ez\u0142ego\u201d forka, w kt\u00f3rym te same \u015brodki s\u0105 przekazywane na adres atakuj\u0105cego. W przypadku PVRB wymagania dotycz\u0105ce finalno\u015bci staj\u0105 si\u0119 jeszcze surowsze, poniewa\u017c budowanie fork\u00f3w dla PVRB oznacza mo\u017cliwo\u015b\u0107, \u017ce atakuj\u0105cy mo\u017ce przygotowa\u0107 kilka wariant\u00f3w losowo\u015bci, maj\u0105c na celu opublikowanie najkorzystniejszego dla siebie, i ograniczenie czasu mo\u017cliwego ataku \u2014 to dobre rozwi\u0105zanie.<\/p>\n<p><\/p>\n<p>Dlatego najlepszym rozwi\u0105zaniem jest po\u0142\u0105czenie PVRB i finalno\u015bci w jeden protok\u00f3\u0142 \u2014 wtedy zfinalizowany blok = zfinalizowana losowo\u015b\u0107, a to jest dok\u0142adnie to, co trzeba by\u0142o uzyska\u0107. Teraz gracze otrzymaj\u0105 gwarantowan\u0105 losowo\u015b\u0107 w ci\u0105gu N sekund i mog\u0105 by\u0107 pewni, \u017ce nie mo\u017cna jej cofn\u0105\u0107 ani odtworzy\u0107.<\/p>\n<p><\/p>\n<p>Opcja z integrowanym konsensusem jest dobra:<\/p>\n<p><\/p>\n<ul>\n<li>mo\u017cliwo\u015bci\u0105 asynchronicznej realizacji w odniesieniu do produkcji blok\u00f3w \u2014 bloki s\u0105 produkowane jak zwykle, ale r\u00f3wnolegle mo\u017ce dzia\u0142a\u0107 protok\u00f3\u0142 PVRB, kt\u00f3ry produkuje losowo\u015bci nie w ka\u017cdym bloku<\/li>\n<li>mo\u017cliwo\u015bci\u0105 implementacji nawet ci\u0119\u017ckiej kryptografii, bez ogranicze\u0144 nak\u0142adanych na inteligentne kontrakty<\/li>\n<li>mo\u017cliwo\u015bci\u0105 szybszego organizowania wymiany wiadomo\u015bci ni\u017c transakcje s\u0105 w\u0142\u0105czane do blockchaina, na przyk\u0142ad cz\u0119\u015b\u0107 protoko\u0142u mo\u017ce dzia\u0142a\u0107 mi\u0119dzy w\u0119z\u0142ami bez rozprzestrzeniania wiadomo\u015bci w sieci<\/li>\n<\/ul>\n<p><\/p>\n<p>Ma r\u00f3wnie\u017c wady:<\/p>\n<p><\/p>\n<ul>\n<li>trudno\u015bci przy testowaniu i rozwijaniu \u2014 trzeba b\u0119dzie emulowa\u0107 b\u0142\u0119dy sieciowe, znikaj\u0105ce w\u0119z\u0142y, hard forki sieci<\/li>\n<li>b\u0142\u0119dy w implementacji wymagaj\u0105 hard forka sieci<\/li>\n<\/ul>\n<p><\/p>\n<p>Oba sposoby implementacji PVRB maj\u0105 prawo do \u017cycia, ale implementacja na inteligentnych kontraktach w nowoczesnych blockchainach jest wci\u0105\u017c mocno ograniczona w zasobach obliczeniowych, a wszelkie przej\u015bcia do powa\u017cnej kryptografii cz\u0119sto s\u0105 po prostu niemo\u017cliwe. A powa\u017cna kryptografia b\u0119dzie nam potrzebna, co zostanie zaprezentowane dalej. Chocia\u017c problem ten ma wyra\u017anie tymczasowy charakter, powa\u017cna kryptografia w kontraktach jest potrzebna do rozwi\u0105zania wielu zada\u0144 i stopniowo si\u0119 pojawia (na przyk\u0142ad systemowe kontrakty dla zkSNARKs w Ethereum).<\/p>\n<p><\/p>\n<p>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. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB and block variables.<\/h2>\n<p><\/p>\n<p>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?<\/p>\n<p><\/p>\n<p>The favorite way to derive randomness in the blockchain is to take some 'unpredictable' information from the block and use it to create randomness\u2014simply by hashing one or more values. A good article on the problems with such schemes. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">tutaj<\/a><\/noindex>You 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 :)).<\/p>\n<p><\/p>\n<p>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:<\/p>\n<p><\/p>\n<ol>\n<li>Wynik musi mie\u0107 w spos\u00f3b udowodniony r\u00f3wnomierny rozk\u0142ad, tzn. oparty na udowodnionej odpornej kryptografii.<\/li>\n<li>Nie ma mo\u017cliwo\u015bci kontrolowania \u017cadnego z bit\u00f3w wyniku. W konsekwencji wynik nie mo\u017ce by\u0107 wcze\u015bniej przewidziany.<\/li>\n<li>Nie mo\u017cna sabotowa\u0107 protoko\u0142u generacji przez nieuczestniczenie w protokole ani przez przeci\u0105\u017cenie sieci atakuj\u0105cymi wiadomo\u015bciami.<\/li>\n<li>Wszystko, co wcze\u015bniej wymieniono, musi by\u0107 odporne na zmowy dozwolonej liczby nieuczciwych uczestnik\u00f3w protoko\u0142u (na przyk\u0142ad 1\/3 uczestnik\u00f3w).<\/li>\n<\/ol>\n<p><\/p>\n<p>W tym przypadku spe\u0142niony jest tylko warunek 1, a warunek 2 nie jest realizowany. Hashuj\u0105c nieprzewidywalne warto\u015bci z bloku, uzyskujemy r\u00f3wnomierne roz\u0142o\u017cenie i dobre losowania. Jednak BP ma przynajmniej mo\u017cliwo\u015b\u0107 \u201eopublikowania bloku lub nie\u201d. W ten spos\u00f3b BP mo\u017ce przynajmniej wybiera\u0107 spo\u015br\u00f3d DW\u00d3CH opcji losowania: \u201eswojej\u201d oraz tej, kt\u00f3ra wyniknie, je\u015bli blok stworzy kto\u015b inny. BP mo\u017ce wcze\u015bniej \u201ezajrze\u0107\u201d, co si\u0119 stanie, je\u015bli opublikuje blok, i po prostu podj\u0105\u0107 decyzj\u0119 o jego publikacji lub nie. W ten spos\u00f3b, graj\u0105c na przyk\u0142ad w \u201eparzyste-nieparzyste\u201d lub \u201eczerwone\/czarne\u201d w ruletce, mo\u017ce publikowa\u0107 blok tylko wtedy, gdy widzi mo\u017cliwo\u015b\u0107 wygranej. To sprawia r\u00f3wnie\u017c, \u017ce strategia wykorzystania, na przyk\u0142ad, hasha bloku \u201ez przesz\u0142o\u015bci\u201d staje si\u0119 nieefektywna. W takim przypadku m\u00f3wi si\u0119, \u017ce \u201ezastosowany b\u0119dzie los, kt\u00f3ry wynika z hashowania bie\u017c\u0105cych danych i hasha przysz\u0142ego bloku o wysoko\u015bci, na przyk\u0142ad, N + 42, gdzie N to obecna wysoko\u015b\u0107 bloku. To troch\u0119 wzmacnia schemat, ale wci\u0105\u017c pozwala BP, nawet w przysz\u0142o\u015bci, wybiera\u0107, czy zatrzyma\u0107 blok, czy go opublikowa\u0107.<\/p>\n<p><\/p>\n<p>Oprogramowanie BP w tym przypadku jest nieco bardziej skomplikowane, ale nie znacznie. Po prostu przy walidacji i w\u0142\u0105czaniu transakcji do bloku zachodzi szybkie sprawdzenie, czy b\u0119dzie wygrana, oraz mo\u017cliwe dobranie jednego parametru transakcji, aby uzyska\u0107 wysokie prawdopodobie\u0144stwo wygranej. Przy tym, z\u0142apanie sprytnego BP przy takich manipulacjach jest praktycznie niemo\u017cliwe, za ka\u017cdym razem mo\u017cna u\u017cywa\u0107 nowych adres\u00f3w i wygrywa\u0107 ma\u0142ymi krokami, nie wzbudzaj\u0105c podejrze\u0144.<\/p>\n<p><\/p>\n<p>Dlatego sposoby z wykorzystaniem informacji z bloku nie nadaj\u0105 si\u0119 do uniwersalnej implementacji PVRB. W ograniczonej wersji, z ograniczeniami wielko\u015bci stawek, ograniczeniami liczby graj\u0105cych i\/lub rejestracj\u0105 KYC (aby uniemo\u017cliwi\u0107 jednemu graczowi u\u017cywanie kilku adres\u00f3w), te schematy mog\u0105 dzia\u0142a\u0107 w przypadku ma\u0142ych gier, ale nie bardziej.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB oraz commit-reveal.<\/h2>\n<p><\/p>\n<p>Dobrze, dzi\u0119kuj\u0119 za hashowanie i przynajmniej wzgl\u0119dn\u0105 nieprzewidywalno\u015b\u0107 hasha bloku oraz innych zmiennych. Je\u015bli rozwi\u0105\u017cemy problem front-runningu g\u00f3rnik\u00f3w, powinno powsta\u0107 co\u015b bardziej sensownego. Dodajmy do tego schematu u\u017cytkownik\u00f3w \u2014 niech r\u00f3wnie\u017c maj\u0105 wp\u0142yw na losowo\u015b\u0107: ka\u017cdy pracownik wsparcia technicznego powie ci, \u017ce najbardziej losowym elementem w systemach IT s\u0105 dzia\u0142ania u\u017cytkownik\u00f3w \ud83d\ude42<\/p>\n<p><\/p>\n<p>Naivna schemat, w kt\u00f3rym u\u017cytkownicy po prostu wysy\u0142aj\u0105 losowe liczby, a wynik jest obliczany jako na przyk\u0142ad hash ich sumy, nie jest wystarczaj\u0105cy. W takim przypadku ostatni graj\u0105cy mo\u017ce kontrolowa\u0107 wynik, wybieraj\u0105c w\u0142asny los. Dlatego stosuje si\u0119 powszechnie u\u017cywany wzorzec commit-reveal. Uczestnicy najpierw wysy\u0142aj\u0105 hashe swoich los\u00f3w (commity), a nast\u0119pnie ujawniaj\u0105 same losy (reveale). Faza \u201ereveal\u201d zaczyna si\u0119 dopiero po zebraniu wymaganych commit\u00f3w, wi\u0119c uczestnicy mog\u0105 wys\u0142a\u0107 dok\u0142adnie ten los, kt\u00f3rego hash wys\u0142ali wcze\u015bniej. Teraz po\u0142\u0105czmy to z parametrami bloku, najlepiej wzi\u0119tymi z przysz\u0142o\u015bci (los mo\u017cna pozna\u0107 tylko w jednym z przysz\u0142ych blok\u00f3w), i voil\u00e0 \u2014 los gotowy! Teraz ka\u017cdy gracz wp\u0142ywa na wynikowy los i mo\u017ce \u201epokona\u0107\u201d z\u0142o\u015bliwego BP, zast\u0119puj\u0105c jego los swoim, nieznanym wcze\u015bniej, losem... Mo\u017cna r\u00f3wnie\u017c doda\u0107 ochron\u0119 przed sabota\u017cem protoko\u0142u poprzez uniemo\u017cliwienie ujawnienia na etapie reveal \u2014 po prostu wymagaj\u0105c przy commitach do\u0142\u0105czenia do transakcji pewnej kwoty \u2014 depozytu gwarancyjnego, kt\u00f3ry wr\u00f3ci tylko w trakcie procedury reveal. W takim przypadku dokonanie commitu i nieujawnienie b\u0119dzie nieop\u0142acalne.<\/p>\n<p><\/p>\n<p>To by\u0142a dobra pr\u00f3ba, i takie schematy te\u017c wyst\u0119puj\u0105 w DApp-ach gier, ale niestety, to wci\u0105\u017c za ma\u0142o. Teraz na wynik mo\u017ce wp\u0142ywa\u0107 nie tylko g\u00f3rnik, ale i ka\u017cdy uczestnik protoko\u0142u. Kontrolowa\u0107 samo warto\u015bci wci\u0105\u017c mo\u017cna, z mniejszym stopniem zmienno\u015bci i za pieni\u0105dze, ale, jak w przypadku g\u00f3rnika, je\u015bli wyniki losowania s\u0105 cenniejsze ni\u017c op\u0142ata za udzia\u0142 w protokole PVRB, to random-producer (RP) mo\u017ce decydowa\u0107, czy zrobi\u0107 reveal i nadal ma mo\u017cliwo\u015b\u0107 wyboru z przynajmniej dw\u00f3ch opcji los\u00f3w.<br \/>\nZa to pojawi\u0142a si\u0119 mo\u017cliwo\u015b\u0107 karania tych, kt\u00f3rzy dokonuj\u0105 commit i nie robi\u0105 reveal, co jeszcze bardziej przyda si\u0119. Jej prostota jest powa\u017cn\u0105 zalet\u0105 \u2014 bardziej zaawansowane protoko\u0142y wymagaj\u0105 znacznie pot\u0119\u017cniejszych oblicze\u0144.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">PVRB i deterministyczne podpisy.<\/h2>\n<p><\/p>\n<p>Jest jeszcze jeden spos\u00f3b, aby zmusi\u0107 RP do dostarczenia pseudolosowej liczby, na kt\u00f3r\u0105 nie b\u0119dzie mia\u0142 wp\u0142ywu, je\u015bli zostanie mu dostarczony \u201eprototyp\u201d \u2014 jest to podpis deterministyczny. Takim podpisem jest na przyk\u0142ad RSA, a nie ECS. Je\u015bli RP ma par\u0119 kluczy: RSA i ECC, i podpisuje swoim kluczem prywatnym pewn\u0105 warto\u015b\u0107, to w przypadku RSA uzyskuje JEDEN I TYLKO JEDEN podpis, a w przypadku ECS \u2014 mo\u017ce wygenerowa\u0107 dowoln\u0105 liczb\u0119 r\u00f3\u017cnych wa\u017cnych podpis\u00f3w. Dzieje si\u0119 tak, poniewa\u017c przy tworzeniu podpisu ECS u\u017cywane jest losowe liczby, wybierane przez podpisuj\u0105cego, i mog\u0105 by\u0107 one wybierane dowolnie, daj\u0105c podpisuj\u0105cemu mo\u017cliwo\u015b\u0107 wyboru jednego z kilku podpis\u00f3w. W przypadku RSA: \u201ejedna warto\u015b\u0107 wej\u015bciowa\u201d + \u201ejedna para kluczy\u201d = \u201ejeden podpis\u201d. Nie da si\u0119 przewidzie\u0107, jaki podpis uzyska inny RP, dlatego PVRB z podpisami deterministycznymi mo\u017ce by\u0107 zorganizowany poprzez kombinowanie podpis\u00f3w RSA kilku uczestnik\u00f3w, kt\u00f3rzy podpisali t\u0119 sam\u0105 warto\u015b\u0107. Na przyk\u0142ad \u2014 poprzedni\u0105 losow\u0105 liczb\u0119. W takim schemacie oszcz\u0119dza si\u0119 sporo zasob\u00f3w, poniewa\u017c podpisy s\u0105 jednocze\u015bnie potwierdzeniem poprawno\u015bci dzia\u0142ania zgodnie z protoko\u0142em i \u017ar\u00f3d\u0142em losowo\u015bci.<\/p>\n<p><\/p>\n<p>Mimo to, nawet z podpisami deterministycznymi, schemat wci\u0105\u017c jest podatny na problem \u201eostatniego aktora\u201d. Ostatni uczestnik wci\u0105\u017c mo\u017ce decydowa\u0107, czy opublikowa\u0107 sw\u00f3j podpis, kontroluj\u0105c tym samym rezultat. Mo\u017cna udoskonali\u0107 schemat, dodaj\u0105c do niego hashe blok\u00f3w, przeprowadzaj\u0105c rundy, aby wynik nie m\u00f3g\u0142 by\u0107 przewidywany z g\u00f3ry, ale wszystkie te zabiegi, nawet bior\u0105c pod uwag\u0119 wiele poprawek, wci\u0105\u017c pozostawiaj\u0105 nierozwi\u0105zan\u0105 problem wp\u0142ywu jednego uczestnika na zbiorowy wynik w nieufnym \u015brodowisku i mog\u0105 dzia\u0142a\u0107 tylko w warunkach ogranicze\u0144 ekonomicznych i czasowych. Ponadto rozmiar kluczy RSA (1024 i 2048 bit\u00f3w) jest do\u015b\u0107 du\u017cy, a rozmiar transakcji blockchainowych jest niezwykle wa\u017cnym parametrem. Wygl\u0105da na to, \u017ce proste rozwi\u0105zanie problemu nie b\u0119dzie mo\u017cliwe, idziemy dalej.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">Schematy PVRB i secret sharing<\/h2>\n<p><\/p>\n<p>W kryptografii istniej\u0105 schematy, kt\u00f3re umo\u017cliwiaj\u0105 sieci uzgodnienie jednego i tylko jednego wyniku PVRB, a takie schematy s\u0105 odporne na wszelkie z\u0142o\u015bliwe dzia\u0142ania niekt\u00f3rych uczestnik\u00f3w. Jednym z przydatnych protoko\u0142\u00f3w, kt\u00f3re warto pozna\u0107, jest schemat dzielenia tajemnicy Shamira. S\u0142u\u017cy on do podzia\u0142u tajemnicy (na przyk\u0142ad klucza tajnego) na kilka cz\u0119\u015bci, kt\u00f3re s\u0105 rozdzielane mi\u0119dzy N uczestnik\u00f3w. Tajemnica jest dzielona w taki spos\u00f3b, \u017ce do jej odbudowy wystarczy M cz\u0119\u015bci z N, przy czym mog\u0105 to by\u0107 dowolne M cz\u0119\u015bci. M\u00f3wi\u0105c w skr\u00f3cie, maj\u0105c wykres nieznanej funkcji, uczestnicy wymieniaj\u0105 si\u0119 punktami na wykresie, a po otrzymaniu M punkt\u00f3w, ca\u0142a funkcja mo\u017ce by\u0107 odbudowana.<br \/>\nDobre wyja\u015bnienie znajduje si\u0119 w <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> i aby poeksperymentowa\u0107 z nim praktycznie, przydatne jest z <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">demo<\/a><\/noindex> strony.<\/p>\n<p><\/p>\n<p>Gdyby schemat FSSS (Fiat-Shamir Secret Sharing) by\u0142 stosowany w czystej formie \u2014 by\u0142by to niezawodny PVRB. W najprostszej wersji protoko\u0142 mo\u017ce wygl\u0105da\u0107 nast\u0119puj\u0105co:<\/p>\n<p><\/p>\n<ul>\n<li>Ka\u017cdy uczestnik generuje w\u0142asny losowy sk\u0142adnik i rozdziela udzia\u0142y od niego pozosta\u0142ym uczestnikom.<\/li>\n<li>Ka\u017cdy uczestnik ujawnia swoje cz\u0119\u015bci tajemnic innych uczestnik\u00f3w.<\/li>\n<li>Je\u015bli dla uczestnika zebra\u0142o si\u0119 wi\u0119cej M udzia\u0142\u00f3w, to jego liczba mo\u017ce zosta\u0107 obliczona, i b\u0119dzie ona jedyna, bez wzgl\u0119du na zestaw ujawnionych uczestnik\u00f3w.<\/li>\n<li>Kombinacja ujawnionych sk\u0142adnik\u00f3w losowych to poszukiwany PVRB.<\/li>\n<\/ul>\n<p><\/p>\n<p>W tym miejscu pojedynczy uczestnik nie ma ju\u017c wp\u0142ywu na wyniki protoko\u0142u, z wyj\u0105tkiem przypadk\u00f3w, gdy tylko od niego zale\u017cy osi\u0105gni\u0119cie progu ujawnienia losowego. Dlatego ten protok\u00f3\u0142, przy odpowiednim udziale dzia\u0142aj\u0105cych zgodnie z protoko\u0142em i dost\u0119pnych RP, dzia\u0142a zgodnie z wymaganiami dotycz\u0105cymi odporno\u015bci kryptograficznej i jest odporny na problem 'ostatniego aktora'.<\/p>\n<p><\/p>\n<p>To m\u00f3g\u0142by by\u0107 idealny wariant; ten schemat PVRB oparty na dzieleniu tajemnic Fiat-Shamira jest opisany, na przyk\u0142ad, w <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">tego<\/a><\/noindex> artyku\u0142ach. Jednak, jak wspomniano wcze\u015bniej, je\u015bli spr\u00f3bowa\u0107 zastosowa\u0107 go bezpo\u015brednio w blockchainie, pojawiaj\u0105 si\u0119 ju\u017c ograniczenia techniczne. Oto przyk\u0142ad testowej realizacji protoko\u0142u w inteligentnym kontrakcie EOS oraz najwa\u017cniejsza jego cz\u0119\u015b\u0107 \u2014 weryfikacja opublikowanego udzia\u0142u uczestnika: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">kod<\/a><\/noindex>Z kodu wynika, \u017ce walidacja dowodu wymaga kilku mno\u017ce\u0144 skalarnych, a liczby s\u0105 bardzo du\u017ce. Nale\u017cy jednak zrozumie\u0107, \u017ce w blockchainach weryfikacja nast\u0119puje w momencie, gdy producent bloku przetwarza transakcj\u0119, a ka\u017cdy uczestnik powinien mie\u0107 \u0142atwy dost\u0119p do weryfikacji poprawno\u015bci protoko\u0142u, dlatego wymagania dotycz\u0105ce szybko\u015bci funkcji weryfikacji s\u0105 bardzo powa\u017cne. W tej wersji okaza\u0142a si\u0119 ona nieefektywna, poniewa\u017c weryfikacja nie mie\u015bci\u0142a si\u0119 w limicie na transakcj\u0119 (0,5 s).<\/p>\n<p><\/p>\n<p>Efektywno\u015b\u0107 weryfikacji to jedno z najwa\u017cniejszych wymaga\u0144 dotycz\u0105cych stosowania wszelkich zaawansowanych schemat\u00f3w kryptograficznych w blockchainie. Tworzenie dowod\u00f3w, przygotowanie wiadomo\u015bci \u2014 te procedury mo\u017cna zrealizowa\u0107 poza \u0142a\u0144cuchem i przeprowadza\u0107 na wysoko wydajnych komputerach, ale weryfikacji nie da si\u0119 pomin\u0105\u0107 \u2014 to kolejne wa\u017cne wymaganie dotycz\u0105ce PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB i podpisy progu<\/h2>\n<p><\/p>\n<p>Zapoznaj\u0105c si\u0119 z schematem dzielenia sekretu, odkryli\u015bmy ca\u0142y zbi\u00f3r protoko\u0142\u00f3w, kt\u00f3re \u0142\u0105czy kluczowe s\u0142owo \"threshold\". Gdy ujawnienie pewnych informacji wymaga udzia\u0142u M uczciwych uczestnik\u00f3w z N, a zbi\u00f3r uczciwych uczestnik\u00f3w mo\u017ce by\u0107 dowolnym podzbiorem N, m\u00f3wimy o schematach \"threshold\". To one pozwalaj\u0105 rozwi\u0105za\u0107 problem \"ostatniego aktora\", teraz je\u015bli atakuj\u0105cy nie ujawnia swojej cz\u0119\u015bci sekretu, uczciwy uczestnik zrobi to za niego. Te schematy pozwalaj\u0105 na ustalenie jednej, jedynej warto\u015bci, nawet w przypadku sabota\u017cu protoko\u0142u przez cz\u0119\u015b\u0107 uczestnik\u00f3w. <\/p>\n<p><\/p>\n<p>Po\u0142\u0105czenie deterministycznych podpis\u00f3w i schemat\u00f3w progu umo\u017cliwi\u0142o opracowanie bardzo wygodnego i obiecuj\u0105cego schematu realizacji PVRB \u2014 to deterministyczne podpisy progu. Oto <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">artyku\u0142<\/a><\/noindex> o r\u00f3\u017cnych zastosowaniach podpis\u00f3w progu, a oto jeszcze jeden dobry <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">longread<\/a><\/noindex> od Dash. <\/p>\n<p><\/p>\n<p>W ostatnim artykule opisano podpisy BLS (BLS rozwija si\u0119 jako Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">oto<\/a><\/noindex> artyku\u0142 ), kt\u00f3re maj\u0105 bardzo wa\u017cn\u0105 i niezwykle wygodn\u0105 dla programist\u00f3w cech\u0119 \u2014 klucze publiczne, sekretne i podpisy BLS mog\u0105 si\u0119 ze sob\u0105 \u0142\u0105czy\u0107 za pomoc\u0105 prostych operacji matematycznych, przy czym ich kombinacje pozostaj\u0105 wa\u017cnymi kluczami i podpisami, co pozwala \u0142atwo agregowa\u0107 wiele podpis\u00f3w w jeden oraz wiele kluczy publicznych w jeden. Maj\u0105 r\u00f3wnie\u017c deterministyczno\u015b\u0107, co oznacza, \u017ce na tych samych danych wej\u015bciowych daj\u0105 ten sam wynik. Dzi\u0119ki tej w\u0142a\u015bciwo\u015bci kombinacje podpis\u00f3w BLS same s\u0105 wa\u017cnymi kluczami, co umo\u017cliwia realizacj\u0119 wariantu, w kt\u00f3rym M z N uczestnik\u00f3w produkuje jeden i tylko jeden podpis, kt\u00f3ry jest deterministyczny, publicznie weryfikowalny i nieprzewidywalny do momentu, gdy nie zostanie ujawniony przez M-tego uczestnika.<\/p>\n<p><\/p>\n<p>W schemacie z threshold BLS signatures ka\u017cdy uczestnik podpisuje za pomoc\u0105 BLS co\u015b (na przyk\u0142ad poprzedni losowy wynik), a og\u00f3lny podpis threshold to poszukiwany losowy wynik. W\u0142a\u015bciwo\u015bci kryptograficzne podpis\u00f3w BLS spe\u0142niaj\u0105 wymagania dotycz\u0105ce jako\u015bci losowo\u015bci, cz\u0119\u015b\u0107 threshold chroni przed \u201eostatnim aktorem\u201d, a unikalna \u0142\u0105czno\u015b\u0107 kluczy pozwala na wdra\u017canie wielu interesuj\u0105cych algorytm\u00f3w, kt\u00f3re pozwalaj\u0105 na przyk\u0142ad na efektywne agregowanie wiadomo\u015bci protoko\u0142u.<\/p>\n<p><\/p>\n<p>Tak wi\u0119c, je\u015bli budujesz PVRB w swoim blockchainie, z du\u017cym prawdopodobie\u0144stwem przejdziesz do schematu BLS threshold signatures, kt\u00f3ry jest ju\u017c u\u017cywany w kilku projektach. Na przyk\u0142ad DFinity (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">tutaj<\/a><\/noindex> benchmark, kt\u00f3ry wdra\u017ca ten schemat, a <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">tutaj<\/a><\/noindex> przyk\u0142ad implementacji weryfikowalnego tajnego dzielenia), lub Keep.network (oto ich random beacon <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, a oto <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">przyk\u0142ad<\/a><\/noindex> smart kontraktu, kt\u00f3ry obs\u0142uguje protok\u00f3\u0142).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">Implementacja PVRB<\/h2>\n<p><\/p>\n<p>Niestety, wci\u0105\u017c nie widzimy gotowego, wdro\u017conego w blockchainach PVRB protoko\u0142u, kt\u00f3ry wykaza\u0142by swoje bezpiecze\u0144stwo i odporno\u015b\u0107. Mimo \u017ce same protoko\u0142y s\u0105 gotowe, technicznie ich zastosowanie w istniej\u0105cych rozwi\u0105zaniach jest trudne. Dla system\u00f3w scentralizowanych PVRB nie ma sensu, a zdecentralizowane s\u0105 \u015bci\u015ble ograniczone we wszystkich zasobach obliczeniowych: CPU, pami\u0119ci, przechowywaniu, I\/O. Projektowanie PVRB to \u0142\u0105czenie r\u00f3\u017cnych protoko\u0142\u00f3w, aby stworzy\u0107 co\u015b, co spe\u0142ni wszystkie wymagania, przynajmniej dla jakiegokolwiek dzia\u0142aj\u0105cego blockchaina. Jeden protok\u00f3\u0142 skuteczniej oblicza, ale wymaga wi\u0119cej wiadomo\u015bci mi\u0119dzy RP, a inny wymaga bardzo ma\u0142o wiadomo\u015bci, ale stworzenie proof-a mo\u017ce by\u0107 zadaniem trwaj\u0105cym dziesi\u0105tki minut, a nawet godzin.<\/p>\n<p><\/p>\n<p>Wymieni\u0119 czynniki, kt\u00f3re musisz wzi\u0105\u0107 pod uwag\u0119 przy wyborze wysokiej jako\u015bci PVRB:<\/p>\n<p><\/p>\n<ul>\n<li><em>Odporno\u015b\u0107 kryptograficzna<\/em>. Tw\u00f3j PVRB musi by\u0107 absolutnie unbiasable, bez mo\u017cliwo\u015bci kontrolowania pojedynczego bitu. W niekt\u00f3rych schematach jest inaczej, dlatego zapro\u015b kryptografa.<\/li>\n<li><em>Problem \u201eostatniego aktora\u201d<\/em>. Tw\u00f3j PVRB musi by\u0107 odporny na ataki, w kt\u00f3rych atakuj\u0105cy, kontroluj\u0105cy jednego lub kilku RP, mo\u017ce wybiera\u0107 jedn\u0105 z dw\u00f3ch mo\u017cliwo\u015bci wyniku.<\/li>\n<li><em>Problem sabota\u017cu protoko\u0142u<\/em>. Tw\u00f3j PVRB musi by\u0107 odporny na ataki, w kt\u00f3rych atakuj\u0105cy, kontroluj\u0105cy jednego lub kilku RP, decyduje, czy rutynowe wyniki maj\u0105 miejsce, i mo\u017ce gwarantowa\u0107, lub z okre\u015blon\u0105 prawdopodobie\u0144stwem wp\u0142ywa\u0107 na to.<\/li>\n<li><em>Problem liczby wiadomo\u015bci<\/em>. Twoje RP powinny wysy\u0142a\u0107 do blockchaina minimum wiadomo\u015bci i maksymalnie unika\u0107 synchronizowanych dzia\u0142a\u0144 typu \u201ewys\u0142a\u0142em pewne informacje, czekam na odpowied\u017a od konkretnego uczestnika\u201d. W sieciach p2p, szczeg\u00f3lnie geograficznie rozproszonych, nie nale\u017cy liczy\u0107 na szybki odzew.<\/li>\n<li><em>Problem z\u0142o\u017cono\u015bci obliczeniowej<\/em>. Weryfikacja jakiegokolwiek etapu PVRB on-chain musi by\u0107 niezwykle \u0142atwa, poniewa\u017c wykonuj\u0105 j\u0105 wszystkie pe\u0142ne w\u0119z\u0142y sieci. Je\u015bli realizacja odbywa si\u0119 za pomoc\u0105 smart kontraktu, wymagania dotycz\u0105ce szybko\u015bci s\u0105 bardzo rygorystyczne.<\/li>\n<li><em>Problem dost\u0119pno\u015bci i aktywno\u015bci<\/em>. Tw\u00f3j PVRB powinien d\u0105\u017cy\u0107 do odporno\u015bci na sytuacje, w kt\u00f3rych cz\u0119\u015b\u0107 sieci sta\u0142a si\u0119 niedost\u0119pna na pewien czas, a cz\u0119\u015b\u0107 RP po prostu przesta\u0142a dzia\u0142a\u0107.<\/li>\n<li><em>Problem zaufanego ustawienia i pocz\u0105tkowego rozdzia\u0142u kluczy.<\/em>. Je\u015bli Tw\u00f3j PVRB u\u017cywa podstawowego ustawienia protoko\u0142u, to jest to odr\u0119bna du\u017ca i powa\u017cna sprawa. Oto <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">przyk\u0142ad<\/a><\/noindex>. Je\u015bli uczestnicy musz\u0105 przed rozpocz\u0119ciem protoko\u0142u wymieni\u0107 si\u0119 swoimi kluczami \u2014 to r\u00f3wnie\u017c jest problem, je\u015bli sk\u0142ad uczestnik\u00f3w si\u0119 zmienia<\/li>\n<li><em>Problemy z rozwojem<\/em>. Obecno\u015b\u0107 bibliotek w potrzebnych j\u0119zykach, ich bezpiecze\u0144stwo i wydajno\u015b\u0107, publiczno\u015b\u0107, z\u0142o\u017cone testy itd.<\/li>\n<\/ul>\n<p><\/p>\n<p>Na przyk\u0142ad pr\u00f3g podpis\u00f3w BLS ma istotny problem \u2014 zanim zacznie si\u0119 prac\u0119, uczestnicy musz\u0105 obowi\u0105zkowo wymieni\u0107 si\u0119 kluczami, organizuj\u0105c grup\u0119, w ramach kt\u00f3rej b\u0119dzie dzia\u0142a\u0142 pr\u00f3g. Oznacza to, \u017ce przynajmniej jedna runda wymiany w zdecentralizowanej sieci musi by\u0107 wyczekiwana, a bior\u0105c pod uwag\u0119, \u017ce generowany losowo\u015b\u0107, na przyk\u0142ad, jest niezb\u0119dna w grach, praktycznie w czasie rzeczywistym, oznacza to, \u017ce sabotowanie protoko\u0142u jest mo\u017cliwe na tym etapie, a zalety schematu progowego s\u0105 tracone. Ten problem jest ju\u017c prostszy ni\u017c poprzedni, ale nadal wymaga opracowania osobnej procedury formowania grup progowych, kt\u00f3re b\u0119d\u0105 musia\u0142y by\u0107 ekonomicznie zabezpieczone, poprzez depozyty i odebranie \u015brodk\u00f3w (slashing) uczestnikom, kt\u00f3rzy nie przestrzegaj\u0105 protoko\u0142u. Ponadto, weryfikacja BLS z akceptowalnym poziomem bezpiecze\u0144stwa po prostu nie mie\u015bci si\u0119, na przyk\u0142ad, w standardowej transakcji EOS lub Ethereum \u2014 po prostu brakuje czasu na weryfikacj\u0119. Kod kontrakt\u00f3w to WebAssembly lub EVM, wykonywany przez maszyn\u0119 wirtualn\u0105. Funkcje kryptograficzne nie s\u0105 realizowane natywnie (jak dot\u0105d) i dzia\u0142aj\u0105 dziesi\u0105tki razy wolniej ni\u017c standardowe biblioteki kryptograficzne. Wiele protoko\u0142\u00f3w nie spe\u0142nia wymaga\u0144 po prostu ze wzgl\u0119du na wielko\u015b\u0107 kluczy, na przyk\u0142ad 1024 i 2048 bit dla RSA, 4-8 razy wi\u0119cej ni\u017c standardowy podpis transakcji w Bitcoinie i Ethereum.<\/p>\n<p><\/p>\n<p>Rola odgrywa r\u00f3wnie\u017c obecno\u015b\u0107 wdro\u017ce\u0144 w r\u00f3\u017cnych j\u0119zykach programowania \u2014 kt\u00f3rych jest niewiele, szczeg\u00f3lnie dla nowych protoko\u0142\u00f3w. Opcja z integracj\u0105 w konsensus wymaga pisania protoko\u0142u w j\u0119zyku platformy, dlatego trzeba b\u0119dzie szuka\u0107 kodu w Go dla geth, w Rust dla Parity, w C++ dla EOS. Kod w JavaScript trzeba b\u0119dzie szuka\u0107 dla wszystkich, a poniewa\u017c JavaScript i kryptografia nie s\u0105 sobie szczeg\u00f3lnie bliskie, pomo\u017ce WebAssembly, kt\u00f3re ju\u017c na pewno pretenduje do roli nast\u0119pnego wa\u017cnego standardu internetowego.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Podsumowanie<\/h2>\n<p><\/p>\n<p>Mam nadziej\u0119, \u017ce w poprzedniej <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">artyku\u0142<\/a><\/noindex> Uda\u0142o mi si\u0119 przekona\u0107 Was, \u017ce generowanie liczb losowych w blockchainie jest krytyczne dla wielu aspekt\u00f3w \u017cycia zdecentralizowanych sieci, a w tym artykule pokaza\u0142em, \u017ce zadanie to jest niezwykle ambitne i trudne, ale dobre rozwi\u0105zania ju\u017c istniej\u0105. Tak naprawd\u0119 ostateczny projekt protoko\u0142u b\u0119dzie mo\u017cliwy dopiero po przeprowadzeniu masowych test\u00f3w, kt\u00f3re uwzgl\u0119dni\u0105 wszystkie aspekty, od ustawienia po symulacj\u0119 awarii, wi\u0119c raczej nie znajdziecie gotowych przepis\u00f3w w whitepaperach zespo\u0142\u00f3w ani w artyku\u0142ach, a my w najbli\u017cszym roku lub dw\u00f3ch na pewno nie odwa\u017cymy si\u0119 pisa\u0107 \u201ezr\u00f3bcie tak, tak na pewno jest w\u0142a\u015bciwie\u201d. <\/p>\n<p><\/p>\n<p>Na razie, dla naszego PVRB w rozwijanym blockchainie <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, zatrzymali\u015bmy si\u0119 na zastosowaniu podpis\u00f3w BLS z progowym zaufaniem, planujemy implementowa\u0107 PVRB na poziomie konsensusu, poniewa\u017c weryfikacja w smart kontraktach z akceptowalnym poziomem bezpiecze\u0144stwa jest na razie niemo\u017cliwa. Mo\u017cliwe, \u017ce u\u017cyjemy od razu dw\u00f3ch schemat\u00f3w: najpierw kosztownego dzielenia tajemnicy do stworzenia d\u0142ugoterminowego random_seed, a nast\u0119pnie u\u017cyjemy go jako bazy do wysokocz\u0119stotliwo\u015bciowego generowania losowo\u015bci za pomoc\u0105 deterministycznych podpis\u00f3w BLS z progiem, by\u0107 mo\u017ce ograniczymy si\u0119 tylko do jednego z tych schemat\u00f3w. Niestety, trudno jest z g\u00f3ry powiedzie\u0107, jak b\u0119dzie wygl\u0105da\u0142 protok\u00f3\u0142, cieszy tylko to, \u017ce podobnie jak w nauce, w zadaniach in\u017cynieryjnych negatywny wynik to r\u00f3wnie\u017c wynik, a ka\u017cda nowa pr\u00f3ba rozwi\u0105zania problemu jest kolejnym krokiem w poszukiwaniach wszystkich zajmuj\u0105cych si\u0119 tym zagadnieniem. Aby spe\u0142ni\u0107 wymagania ze strony biznesu, rozwi\u0105zujemy konkretny praktyczny problem \u2014 zapewnienie aplikacjom gier niezawodnego \u017ar\u00f3d\u0142a entropii, dlatego musimy tak\u017ce zwraca\u0107 uwag\u0119 na sam blockchain, w szczeg\u00f3lno\u015bci na pytania dotycz\u0105ce finalno\u015bci \u0142a\u0144cucha i zarz\u0105dzania sieci\u0105. <\/p>\n<p><\/p>\n<p>I chocia\u017c na razie nie widzimy w blockchainach udowodnionego i odpornego PVRB, kt\u00f3ry by\u0142by u\u017cywany wystarczaj\u0105co d\u0142ugo, aby przej\u015b\u0107 pr\u00f3by w rzeczywistych aplikacjach, wieloma audytami, obci\u0105\u017ceniami i oczywi\u015bcie prawdziwymi atakami, liczba mo\u017cliwych dr\u00f3g potwierdza, \u017ce rozwi\u0105zanie istnieje i jeden z tych algorytm\u00f3w w ko\u0144cu rozwi\u0105\u017ce problem. Z przyjemno\u015bci\u0105 b\u0119dziemy dzieli\u0107 si\u0119 wynikami i dzi\u0119kujemy innym zespo\u0142om, kt\u00f3re r\u00f3wnie\u017c zajmuj\u0105 si\u0119 tym zagadnieniem, za artyku\u0142y i kody, kt\u00f3re pozwalaj\u0105 in\u017cynierom nie pope\u0142nia\u0107 tych samych b\u0142\u0119d\u00f3w drugi raz. <\/p>\n<p><\/p>\n<p>Kiedy spotykasz programist\u0119 projektuj\u0105cego zdecentralizowany generator losowy, b\u0105d\u017a ostro\u017cny i troskliwy, w razie potrzeby udziel mu wsparcia psychologicznego \ud83d\ude42<\/p>\n<p>\u0179r\u00f3d\u0142o: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/452340\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number! } \u041a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0441 \u043a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u0435\u0439 \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0448\u0438\u0444\u0440\u0430 \u0438\u0437 \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0438, \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u201cPublicly Verifiable Random Beacon\u201d (\u0434\u0430\u043b\u0435\u0435 PVRB) \u043b\u0438\u0448\u044c \u043f\u044b\u0442\u0430\u044e\u0442\u0441\u044f \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u043f\u0440\u0438\u0431\u043b\u0438\u0437\u0438\u0442\u044c\u0441\u044f \u043a \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u0435, \u0442.\u043a. \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u0441\u0435\u0442\u044f\u0445 \u0432 \u0447\u0438\u0441\u0442\u043e\u043c \u0432\u0438\u0434\u0435 \u043e\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u0430: \u0434\u043e\u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u043d\u0430\u0434\u043e \u0441\u0442\u0440\u043e\u0433\u043e \u043e\u0431 \u043e\u0434\u043d\u043e\u043c \u0431\u0438\u0442\u0435, \u0440\u0430\u0443\u043d\u0434\u043e\u0432 \u0434\u043e\u043b\u0436\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33888","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.1.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"pl_PL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Liczby losowe i sieci zdecentralizowane: implementacje | ProHoster","description":"Wprowadzenie function getAbsolutelyRandomNumer() { return 4; \/\/ zwraca ca\u0142kowicie losow\u0105 liczb\u0119!","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:55:15+00:00","article:modified_time":"2019-10-31T18:55:15+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33888","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 17:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:31:23","updated":"2026-01-21 17:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/33888","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}