{"id":95468,"date":"2020-09-29T19:42:29","date_gmt":"2020-09-29T17:42:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1"},"modified":"2020-09-29T19:42:29","modified_gmt":"2020-09-29T17:42:29","slug":"mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","title":{"rendered":"Czy mo\u017cna generowa\u0107 liczby losowe, je\u015bli sobie nie ufamy? Cz\u0119\u015b\u0107 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107, Habr!<\/p>\n

W tym artykule opowiem o generowaniu pseudo-losowych liczb przez uczestnik\u00f3w, kt\u00f3rzy nie ufaj\u0105 sobie nawzajem. Jak zobaczymy poni\u017cej, stworzenie \u201eprawie\u201d dobrego generatora jest do\u015b\u0107 proste, ale bardzo dobrego \u2014 ju\u017c nie.<\/p>\n

Dlaczego w og\u00f3le potrzebne jest generowanie liczb losowych dla uczestnik\u00f3w, kt\u00f3rzy sobie nie ufaj\u0105? Jednym z zastosowa\u0144 s\u0105 aplikacje zdecentralizowane. Na przyk\u0142ad aplikacja, kt\u00f3ra przyjmuje zak\u0142ad od uczestnika i z prawdopodobie\u0144stwem 49% podwaja kwot\u0119 lub z 51% j\u0105 zabiera, b\u0119dzie dzia\u0142a\u0107 tylko wtedy, gdy b\u0119dzie mog\u0142a bezstronnie uzyska\u0107 liczb\u0119 losow\u0105. Je\u015bli oszust mo\u017ce wp\u0142yn\u0105\u0107 na wynik dzia\u0142ania generatora liczb losowych i nawet nieznacznie zwi\u0119kszy\u0107 swoje szanse na wyp\u0142at\u0119 w aplikacji, \u0142atwo j\u0105 zrujnuje.<\/p>\n

Kiedy projektujemy rozproszony protok\u00f3\u0142 generowania losowych liczb, chcemy, aby mia\u0142 on trzy w\u0142a\u015bciwo\u015bci:<\/p>\n

    \n
  1. \n

    Musi by\u0107 obiektywny. Innymi s\u0142owy, \u017caden uczestnik nie powinien mie\u0107 wp\u0142ywu na wynik generatora losowych liczb.<\/p>\n<\/li>\n

  2. \n

    Musi by\u0107 nieprzewidywalny. Innymi s\u0142owy, \u017caden uczestnik nie powinien mie\u0107 mo\u017cliwo\u015bci przewidzenia, jaka liczba zostanie wygenerowana (ani wydobycia jakichkolwiek jej w\u0142a\u015bciwo\u015bci) zanim zostanie ona wygenerowana.<\/p>\n<\/li>\n

  3. \n

    Protok\u00f3\u0142 musi by\u0107 wykonalny, tzn. odporny na sytuacj\u0119, w kt\u00f3rej jaki\u015b procent uczestnik\u00f3w wy\u0142\u0105czy si\u0119 z sieci lub celowo spr\u00f3buje zatrzyma\u0107 protok\u00f3\u0142.<\/p>\n<\/li>\n<\/ol>\n

    W tym artykule om\u00f3wimy dwa podej\u015bcia: RANDAO + VDF oraz podej\u015bcie oparte na kodach wyg\u0142adzaj\u0105cych. W nast\u0119pnej cz\u0119\u015bci szczeg\u00f3\u0142owo om\u00f3wimy podej\u015bcie oparte na podpisach progowych.<\/p>\n

    Ale na pocz\u0105tek przyjrzyjmy si\u0119 prostemu i cz\u0119sto stosowanemu algorytmowi, kt\u00f3ry jest wykonalny, nieprzewidywalny, ale nieobiektywny.<\/p>\n

    RANDAO<\/h3>\n

    RANDAO to bardzo prosty i, w zwi\u0105zku z tym, do\u015b\u0107 cz\u0119sto stosowany spos\u00f3b na uzyskanie losowo\u015bci. Wszyscy uczestnicy sieci najpierw lokalnie wybieraj\u0105 liczb\u0119 pseudolosow\u0105, nast\u0119pnie ka\u017cdy uczestnik przesy\u0142a hash wybranej liczby. Nast\u0119pnie uczestnicy na przemian ujawniaj\u0105 swoje wybrane liczby, a nad ujawnionymi liczbami wykonuj\u0105 operacj\u0119 XOR, a wynik tej operacji staje si\u0119 wynikiem dzia\u0142ania protoko\u0142u.<\/p>\n

    Krok publikacji haszy przed odkryciem liczb jest niezb\u0119dny, aby przest\u0119pca nie m\u00f3g\u0142 wybra\u0107 swojej liczby po tym, jak zobaczy liczby pozosta\u0142ych uczestnik\u00f3w. Pozwoli\u0142oby to mu na samodzielne okre\u015blenie wyniku generatora liczb losowych.<\/p>\n

    W trakcie protoko\u0142u uczestnicy musz\u0105 dwukrotnie doj\u015b\u0107 do konsensusu: kiedy rozpocz\u0105\u0107 odkrywanie wybranych liczb, a tym samym zaprzesta\u0107 przyjmowania haszy, oraz kiedy zako\u0144czy\u0107 przyjmowanie wybranych liczb i obliczy\u0107 wynikow\u0105 liczb\u0119 losow\u0105. Podejmowanie takich decyzji mi\u0119dzy uczestnikami, kt\u00f3rzy sobie nawzajem nie ufaj\u0105, jest samo w sobie skomplikowanym zadaniem, do kt\u00f3rego powr\u00f3cimy w przysz\u0142ych artyku\u0142ach; w tym artykule zak\u0142adamy, \u017ce taki algorytm konsensusu jest nam dost\u0119pny.<\/p>\n

    Jakie w\u0142a\u015bciwo\u015bci, kt\u00f3re opisali\u015bmy powy\u017cej, ma RANDAO? Jest nieprzewidywalny, ma t\u0119 sam\u0105 \u017cywotno\u015b\u0107, co le\u017c\u0105cy u jego podstaw protok\u00f3\u0142 konsensusu, ale jest stronniczy. W szczeg\u00f3lno\u015bci przest\u0119pca mo\u017ce obserwowa\u0107 sie\u0107 i po tym, jak inni uczestnicy odkryj\u0105 swoje liczby, mo\u017ce obliczy\u0107 ich XOR i zdecydowa\u0107, czy odkrywa\u0107, czy nie odkrywa\u0107 swojej liczby, aby wp\u0142yn\u0105\u0107 na wynik. Chocia\u017c nie pozwala to przest\u0119pcy na samodzielne okre\u015blenie wyniku generatora liczb losowych, wci\u0105\u017c daje mu 1 bit wp\u0142ywu. A je\u015bli przest\u0119pcy kontroluj\u0105 kilku uczestnik\u00f3w, liczba kontrolowanych przez nich bit\u00f3w b\u0119dzie r\u00f3wna liczbie uczestnik\u00f3w znajduj\u0105cych si\u0119 pod ich kontrol\u0105.<\/p>\n

    \"Czy<\/p>\n

    Wp\u0142yw przest\u0119pc\u00f3w mo\u017cna znacznie zmniejszy\u0107, wymagaj\u0105c, aby uczestnicy odkrywali liczby w kolejno\u015bci. Wtedy przest\u0119pca b\u0119dzie m\u00f3g\u0142 wp\u0142yn\u0105\u0107 na wynik tylko wtedy, gdy odkrywa si\u0119 jako ostatni. Chocia\u017c wp\u0142yw jest znacznie mniejszy, algorytm wci\u0105\u017c pozostaje stronniczy.<\/p>\n

    RANDAO + VDF<\/h3>\n

    Jednym z pomys\u0142\u00f3w na uczynienie RANDAO nieodparty jest to, \u017ce po tym, jak wszystkie liczby zosta\u0142y odkryte i obliczono XOR, jego wynik jest podawany jako wej\u015bcie do funkcji, kt\u00f3ra jest bardzo wolna w obliczeniach, ale pozwala na szybkie weryfikowanie poprawno\u015bci oblicze\u0144.<\/p>\n

    (vdf_output, vdf_proof) = VDF_compute(input) \/\/ to jest bardzo wolne\ncorrect = VDF_verify(input, vdf_output, vdf_proof) \/\/ to jest bardzo szybkie<\/code><\/pre>\n
    Ta funkcja nazywa si\u0119 Verifiable Delay Function, czyli VDF. Je\u015bli obliczenie ostatecznego wyniku zajmuje wi\u0119cej czasu ni\u017c etap ujawnienia liczb, to sprawca nie b\u0119dzie w stanie przewidzie\u0107 efektu pokazu lub ukrywania swojej liczby, a tym samym straci mo\u017cliwo\u015b\u0107 wp\u0142ywania na wynik.<\/p>\n
    Opracowanie dobrych VDF jest niezwykle trudne. Ostatnio dokonano kilku prze\u0142om\u00f3w, na przyk\u0142ad ten<\/u><\/a><\/noindex> i tego,<\/u><\/a><\/noindex> kt\u00f3re sprawi\u0142y, \u017ce VDF sta\u0142y si\u0119 bardziej praktyczne, a Ethereum 2.0 w d\u0142u\u017cszej perspektywie planuje wykorzystanie RANDAO z VDF jako \u017ar\u00f3d\u0142a liczb losowych. Poza tym, \u017ce podej\u015bcie to jest nieprzewidywalne i obiektywne, ma dodatkow\u0105 zalet\u0119 polegaj\u0105c\u0105 na \u017cywotno\u015bci, je\u015bli przynajmniej dw\u00f3ch uczestnik\u00f3w jest dost\u0119pnych w sieci (pod warunkiem, \u017ce u\u017cywany protok\u00f3\u0142 konsensusu jest skuteczny przy tak niewielkiej liczbie uczestnik\u00f3w).<\/p>\n
    Najwi\u0119ksza trudno\u015b\u0107 tego podej\u015bcia polega na skonfigurowaniu VDF tak, aby nawet uczestnik z bardzo drogim specjalistycznym sprz\u0119tem nie by\u0142 w stanie obliczy\u0107 VDF przed zako\u0144czeniem fazy ujawniania. W idealnym przypadku algorytm powinien mie\u0107 nawet znaczny zapas, powiedzmy 10x. Na poni\u017cszym rysunku pokazano atak uczestnika posiadaj\u0105cego specjalistyczne ASIC, kt\u00f3ry pozwala mu uruchomi\u0107 VDF szybciej, ni\u017c czas przydzielony na ujawnienie potwierdzenia RANDAO. Taki uczestnik mo\u017ce nadal oblicza\u0107 ostateczny wynik, wykorzystuj\u0105c i nie wykorzystuj\u0105c swojej liczby, a nast\u0119pnie na podstawie oblicze\u0144 decydowa\u0107, czy j\u0105 pokaza\u0107, czy nie.<\/p>\n
    \"Czy<\/p>\n
    Dla wspomnianego powy\u017cej rodziny VDF wydajno\u015b\u0107 specjalistycznego ASIC mo\u017ce by\u0107 ponad 100 razy wy\u017csza ni\u017c w przypadku zwyk\u0142ego sprz\u0119tu. Zatem je\u015bli faza ujawnienia trwa 10 sekund, to VDF obliczane na takim ASIC powinno zajmowa\u0107 ponad 100 sekund, aby uzyska\u0107 10-krotny zapas bezpiecze\u0144stwa, a zatem to samo VDF obliczone na zwyk\u0142ym sprz\u0119cie powinno zaj\u0105\u0107 100 x 100 sekund = ~ 3 godziny.<\/p>\n
    Fundacja Ethereum planuje rozwi\u0105za\u0107 ten problem poprzez stworzenie w\u0142asnych publicznych, darmowych ASIC. Gdy to nast\u0105pi, inne protoko\u0142y r\u00f3wnie\u017c b\u0119d\u0105 mog\u0142y korzysta\u0107 z tej technologii, ale do tego czasu podej\u015bcie RANDAO + VDF nie b\u0119dzie tak samo wykonalne dla protoko\u0142\u00f3w, kt\u00f3re nie mog\u0105 zainwestowa\u0107 w opracowanie w\u0142asnych ASIC.<\/p>\n
    Wiele artyku\u0142\u00f3w, film\u00f3w i innych informacji na temat VDF zebrano na tej stronie<\/u><\/a><\/noindex>.<\/p>\n
    U\u017cywamy kod\u00f3w erasure<\/h3>\n
    W tej sekcji przyjrzymy si\u0119 protoko\u0142owi generowania liczb losowych, kt\u00f3ry wykorzystuje kody erasure<\/a><\/noindex>. Mo\u017ce on wytrzyma\u0107 do \u2153 z\u0142o\u015bliwych aktor\u00f3w, pozostaj\u0105c wykonalnym, i dopuszcza istnienie do \u2154 z\u0142o\u015bliwych aktor\u00f3w, zanim b\u0119d\u0105 mogli przewidzie\u0107 lub wp\u0142yn\u0105\u0107 na wynik.<\/p>\n
    G\u0142\u00f3wn\u0105 ide\u0105 protoko\u0142u jest nast\u0119puj\u0105ca. Dla uproszczenia za\u0142\u00f3\u017cmy, \u017ce w nim uczestniczy dok\u0142adnie 100 os\u00f3b. Za\u0142\u00f3\u017cmy r\u00f3wnie\u017c, \u017ce wszyscy uczestnicy lokalnie maj\u0105 jaki\u015b prywatny klucz, a publiczne klucze wszystkich uczestnik\u00f3w s\u0105 znane wszystkim uczestnikom:<\/p>\n
      \n
    1. \n
      Ka\u017cdy uczestnik lokalnie wymy\u015bla d\u0142ugi ci\u0105g, dzieli go na 67 cz\u0119\u015bci, tworzy kody erasure, aby uzyska\u0107 100 udzia\u0142\u00f3w, z kt\u00f3rych jakiekolwiek 67 wystarczy do odtworzenia ci\u0105gu, przypisuje ka\u017cdemu z 100 udzia\u0142\u00f3w jednemu z uczestnik\u00f3w i szyfruje je za pomoc\u0105 publicznego klucza tego samego uczestnika. Nast\u0119pnie wszystkie zakodowane udzia\u0142y s\u0105 publikowane.<\/p>\n<\/li>\n
    2. \n
      Uczestnicy u\u017cywaj\u0105 jakiego\u015b konsensusu, aby osi\u0105gn\u0105\u0107 zgodno\u015b\u0107 co do zakodowanych zestaw\u00f3w od konkretnych 67 uczestnik\u00f3w.<\/p>\n<\/li>\n
    3. \n
      Gdy konsensus zostanie osi\u0105gni\u0119ty, ka\u017cdy uczestnik bierze zakodowane udzia\u0142y w ka\u017cdym z 67 zestaw\u00f3w, zaszyfrowane ich publicznym kluczem, deszyfruje wszystkie takie udzia\u0142y i publikuje wszystkie takie odszyfrowane udzia\u0142y.<\/p>\n<\/li>\n
    4. \n
      Gdy 67 uczestnik\u00f3w wykona krok (3), wszystkie uzgodnione zestawy mog\u0105 by\u0107 ca\u0142kowicie dekodowane i odtwarzane dzi\u0119ki w\u0142a\u015bciwo\u015bciom kod\u00f3w erasure, a ostateczna liczba mo\u017ce by\u0107 uzyskana jako XOR pocz\u0105tkowych ci\u0105g\u00f3w, od kt\u00f3rych uczestnicy zacz\u0119li w (1).<\/p>\n<\/li>\n<\/ol>\n
      \"Czy<\/p>\n
      Mo\u017cna pokaza\u0107, \u017ce ten protok\u00f3\u0142 jest bezstronny i nieprzewidywalny. Rezultatem jest losowa liczba, kt\u00f3ra zostaje okre\u015blona po osi\u0105gni\u0119ciu konsensusu, ale nikomu nie jest znana, dop\u00f3ki \u2154 uczestnik\u00f3w nie zdekoduj\u0105 cz\u0119\u015bci zaszyfrowanych ich kluczem publicznym. W ten spos\u00f3b losowa liczba jest okre\u015blona wcze\u015bniej ni\u017c informacja wystarczaj\u0105ca do jej rekonstrukcji zostaje opublikowana.<\/p>\n
      Co si\u0119 stanie, je\u015bli na kroku (1) jeden z uczestnik\u00f3w wy\u015ble innym uczestnikom zakodowane udzia\u0142y, kt\u00f3re nie s\u0105 poprawnym kodem wymazuj\u0105cym dla jakiego\u015b \u0142a\u0144cucha? Bez dodatkowych zmian, r\u00f3\u017cni uczestnicy mog\u0105 nie by\u0107 w stanie w og\u00f3le zrekonstruowa\u0107 \u0142a\u0144cucha lub zrekonstruuj\u0105 r\u00f3\u017cne \u0142a\u0144cuchy, co spowoduje, \u017ce r\u00f3\u017cni uczestnicy otrzymaj\u0105 r\u00f3\u017cne losowe liczby. Aby temu zapobiec, mo\u017cna zrobi\u0107 nast\u0119puj\u0105ce: ka\u017cdy uczestnik, opr\u00f3cz zakodowanych udzia\u0142\u00f3w, oblicza r\u00f3wnie\u017c drzewo Merkle.<\/a><\/noindex> Wszystkich takich udzia\u0142\u00f3w, i ka\u017cdy uczestnik wysy\u0142a zar\u00f3wno zakodowany udzia\u0142, jak i korze\u0144 drzewa Merkle oraz dow\u00f3d w\u0142\u0105czenia udzia\u0142u do drzewa Merkle. W konsensusie na kroku (2) uczestnicy nie tylko zgadzaj\u0105 si\u0119 na wielu zestawach, ale na wielu konkretnych korzeniach takich drzew (je\u017celi jaki\u015b uczestnik odszed\u0142 od protoko\u0142u i wys\u0142a\u0142 r\u00f3\u017cne korzenie drzewa Merkle r\u00f3\u017cnym uczestnikom, a dwa takie korzenie pokazano podczas konsensusu, jego \u0142a\u0144cuch nie jest w\u0142\u0105czany do zestawu wynikowego). Po zako\u0144czeniu konsensusu b\u0119dziemy mieli 67 zakodowanych \u0142a\u0144cuch\u00f3w i odpowiadaj\u0105cych im korzeni drzewa Merkle takich, \u017ce jest co najmniej 67 uczestnik\u00f3w (niekoniecznie tych samych, kt\u00f3rzy zaproponowali odpowiednie \u0142a\u0144cuchy), dla kt\u00f3rych dla ka\u017cdego z 67 \u0142a\u0144cuch\u00f3w jest wiadomo\u015b\u0107 z udzia\u0142em kodu wymazuj\u0105cego i dow\u00f3d w\u0142\u0105czenia ich udzia\u0142u do odpowiedniego drzewa Merkle.<\/p>\n
      Kiedy na kroku (4) uczestnik odszyfrowuje 67 udzia\u0142\u00f3w dla jakiego\u015b \u0142a\u0144cucha i pr\u00f3buje na ich podstawie zrekonstruowa\u0107 oryginalny \u0142a\u0144cuch, mo\u017cliwy jest jeden z wariant\u00f3w:<\/p>\n
        \n
      1. \n
        \u0141a\u0144cuch zostaje zrekonstruowany, a je\u015bli nast\u0119pnie zostanie ponownie zakodowany kodami wymazuj\u0105cymi i obliczone zostanie drzewo Merkle dla obliczonych lokalnie udzia\u0142\u00f3w, korze\u0144 pokrywa si\u0119 z tym, na kt\u00f3rym osi\u0105gni\u0119to konsensus.<\/p>\n<\/li>\n
      2. \n
        \u0141a\u0144cuch zostaje zrekonstruowany, ale obliczony lokalnie korze\u0144 nie odpowiada temu, na kt\u00f3rym osi\u0105gni\u0119to konsensus.<\/p>\n<\/li>\n
      3. \n
        \u0141a\u0144cuch nie zostaje zrekonstruowany.<\/p>\n<\/li>\n<\/ol>\n
        \u0141atwo zauwa\u017cy\u0107, \u017ce je\u015bli chocia\u017c dla jednego uczestnika wyst\u0105pi\u0142 przypadek (1), to dla wszystkich uczestnik\u00f3w r\u00f3wnie\u017c wyst\u0105pi przypadek (1), i odwrotnie, je\u015bli tylko dla jednego uczestnika wyst\u0105pi\u0142 przypadek (2) lub (3), to dla wszystkich uczestnik\u00f3w wyst\u0105pi przypadek (2) lub (3). W ten spos\u00f3b dla ka\u017cdego wiersza w zbiorze albo wszyscy uczestnicy go pomy\u015blnie odtworz\u0105, albo wszyscy uczestnicy nie b\u0119d\u0105 mogli go odtworzy\u0107. Nast\u0119pnie wynikowa liczba losowa to XOR tylko tych wierszy, kt\u00f3re uczestnicy mogli odtworzy\u0107.<\/p>\n
        Podpisy progowe<\/h3>\n
        Innym podej\u015bciem do losowo\u015bci jest wykorzystanie tzw. podpis\u00f3w progowych BLS. Generator liczb losowych oparty na podpisach progowych ma dok\u0142adnie te same gwarancje, co opisany powy\u017cej algorytm oparty na kodach wymazuj\u0105cych, ale ma znacznie mniejsz\u0105 asymptotyk\u0119 liczby wiadomo\u015bci przesy\u0142anych przez sie\u0107 na ka\u017cd\u0105 wygenerowan\u0105 liczb\u0119.<\/p>\n
        Podpisy BLS to konstrukcja, kt\u00f3ra pozwala kilku uczestnikom stworzy\u0107 jeden wsp\u00f3lny podpis dla wiadomo\u015bci. Takie podpisy s\u0105 cz\u0119sto u\u017cywane w celu oszcz\u0119dno\u015bci miejsca i przepustowo\u015bci, poniewa\u017c nie wymagaj\u0105 rozsy\u0142ania wielu podpis\u00f3w. <\/p>\n
        Cz\u0119ste zastosowanie podpis\u00f3w BLS w protoko\u0142ach blockchain, opr\u00f3cz generowania liczb losowych, to podpisywanie blok\u00f3w w protoko\u0142ach BFT. Powiedzmy, \u017ce 100 uczestnik\u00f3w tworzy bloki, a blok uznawany jest za ostateczny, je\u015bli 67 z nich go podpisuje. Wszyscy mog\u0105 przedstawi\u0107 swoje cz\u0119\u015bci podpisu BLS i u\u017cy\u0107 jakiego\u015b algorytmu konsensusu, aby uzgodni\u0107 67 z nich, a nast\u0119pnie po\u0142\u0105czy\u0107 je w jeden podpis BLS. Dowolne 67 (lub wi\u0119cej) cz\u0119\u015bci mog\u0105 by\u0107 u\u017cywane do stworzenia ostatecznego podpisu, kt\u00f3ry b\u0119dzie zale\u017ca\u0142 od tego, kt\u00f3re dok\u0142adnie 67 podpis\u00f3w zosta\u0142o po\u0142\u0105czonych, i dlatego mo\u017ce si\u0119 r\u00f3\u017cni\u0107, ale mimo to, \u017ce r\u00f3\u017cny wyb\u00f3r 67 uczestnik\u00f3w stworzy r\u00f3\u017cny podpis, ka\u017cdy taki podpis b\u0119dzie poprawnym podpisem dla bloku. Pozosta\u0142ym uczestnikom wystarczy, by otrzyma\u0107 przez sie\u0107 i sprawdzi\u0107 tylko jeden podpis na ka\u017cdy blok, zamiast 67, co znacz\u0105co zmniejsza obci\u0105\u017cenie sieci.<\/p>\n
        Okazuje si\u0119, \u017ce je\u015bli klucze prywatne u\u017cywane przez uczestnik\u00f3w s\u0105 generowane w okre\u015blony spos\u00f3b, to niezale\u017cnie od tego, jakie 67 podpis\u00f3w (lub wi\u0119cej, ale nie mniej) zostanie zebranych, powsta\u0142y podpis b\u0119dzie identyczny. Mo\u017ce to by\u0107 wykorzystane jako \u017ar\u00f3d\u0142o losowo\u015bci: uczestnicy najpierw uzgadniaj\u0105 jakie\u015b wiadomo\u015bci, kt\u00f3re podpisz\u0105 (mo\u017ce to by\u0107 wynik RANDAO lub po prostu hasz ostatniego bloku, w rzeczywisto\u015bci nie ma to znaczenia, byleby zmienia\u0142o si\u0119 za ka\u017cdym razem i by\u0142o uzgodnione), a nast\u0119pnie tworz\u0105 dla niego podpis BLS. Wynik generacji b\u0119dzie nieprzewidywalny, dop\u00f3ki 67 uczestnik\u00f3w nie dostarczy swoich cz\u0119\u015bci, a po tym wyj\u015bciowe dane b\u0119d\u0105 ju\u017c z g\u00f3ry okre\u015blone i nie mog\u0105 zale\u017ce\u0107 od dzia\u0142a\u0144 jakiegokolwiek uczestnika.<\/p>\n
        Takie podej\u015bcie do losowo\u015bci jest wykonalne, je\u015bli przynajmniej \u2154 uczestnik\u00f3w jest online i post\u0119puje zgodnie z protoko\u0142em, i jest uczciwe oraz nieprzewidywalne, dop\u00f3ki przynajmniej \u2153 uczestnik\u00f3w przestrzega protoko\u0142u. Wa\u017cne jest, aby zauwa\u017cy\u0107, \u017ce atakuj\u0105cy, kt\u00f3ry kontroluje wi\u0119cej ni\u017c \u2153, ale mniej ni\u017c \u2154 uczestnik\u00f3w, mo\u017ce zatrzyma\u0107 protok\u00f3\u0142, ale nie mo\u017ce przewidzie\u0107 ani wp\u0142yn\u0105\u0107 na jego rezultat.<\/p>\n
        Podpisy progowe same w sobie to bardzo ciekawy temat. W drugiej cz\u0119\u015bci artyku\u0142u szczeg\u00f3\u0142owo om\u00f3wimy, jak one dzia\u0142aj\u0105 i jak dok\u0142adnie nale\u017cy generowa\u0107 klucze uczestnik\u00f3w, aby podpisy progowe mog\u0142y by\u0107 u\u017cywane jako generator liczb losowych.<\/p>\n
        Na zako\u0144czenie<\/h3>\n
        Ten artyku\u0142 to pierwszy z serii artyku\u0142\u00f3w technicznych na blogu. NEAR<\/a><\/noindex>. NEAR to protok\u00f3\u0142 blockchain i platforma do tworzenia zdecentralizowanych aplikacji z akcentem na prostot\u0119 programowania oraz \u0142atwo\u015b\u0107 u\u017cytkowania dla ko\u0144cowych u\u017cytkownik\u00f3w.<\/p>\n
        Kod protoko\u0142u jest otwarty, nasza implementacja jest napisana w Rust, mo\u017cna j\u0105 znale\u017a\u0107 tutaj<\/a><\/noindex>.<\/p>\n
        Mo\u017cna zobaczy\u0107, jak wygl\u0105da rozw\u00f3j na platformie NEAR oraz wypr\u00f3bowa\u0107 w online-IDE tutaj<\/a><\/noindex>.<\/p>\n
        \u015aledzi\u0107 wszystkie wiadomo\u015bci w j\u0119zyku rosyjskim mo\u017cna w grupie na Telegramie<\/a><\/noindex> i w grupie na VKontakte<\/a><\/noindex>, a po angielsku na oficjalnym Twitterze<\/a><\/noindex>.<\/p>\n
        Do zobaczenia wkr\u00f3tce!<\/p>\n
        \u0179r\u00f3d\u0142o: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443. \u041a\u0430\u043a \u043c\u044b \u0443\u0432\u0438\u0434\u0438\u043c \u043d\u0438\u0436\u0435, \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u0442\u044c \u201c\u043f\u043e\u0447\u0442\u0438\u201d \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u0433\u0435\u043d\u0435\u0440\u0430\u0442\u043e\u0440 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e, \u0430 \u0432\u043e\u0442 \u043e\u0447\u0435\u043d\u044c \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u2013 \u0441\u043b\u043e\u0436\u043d\u043e. \u0417\u0430\u0447\u0435\u043c \u0432\u043e\u043e\u0431\u0449\u0435 \u043d\u0443\u0436\u043d\u043e \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c, \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0449\u0438\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u041e\u0434\u043d\u0430 \u0438\u0437 \u043e\u0431\u043b\u0430\u0441\u0442\u0435\u0439 \u043f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u044f — \u044d\u0442\u043e \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u043a\u043e\u0442\u043e\u0440\u043e\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":95469,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-95468","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Czy mo\u017cna generowa\u0107 liczby losowe, je\u015bli sobie nie ufamy? Cz\u0119\u015b\u0107 1 | ProHoster","description":"Cze\u015b\u0107, Habr! W tym artykule opowiem o generacji pseudo-losowych liczb przez uczestnik\u00f3w, kt\u00f3rzy sobie nie ufaj\u0105.","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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\u041c\u043e\u0436\u043d\u043e \u043b\u0438 \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430, \u0435\u0441\u043b\u0438 \u043c\u044b \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u0435\u043c \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443? \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443 \u043f\u0440\u043e \u0433\u0435\u043d\u0435\u0440\u0430\u0446\u0438\u044e \u043f\u0441\u0435\u0432\u0434\u043e-\u0441\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0445 \u0447\u0438\u0441\u0435\u043b \u0443\u0447\u0430\u0441\u0442\u043d\u0438\u043a\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0435 \u0434\u043e\u0432\u0435\u0440\u044f\u044e\u0442 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0443.","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/mozhno-li-generirovat-sluchajnye-chisla-esli-my-ne-doveryaem-drug-drugu-chast-1","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":"2020-09-29T17:42:29+00:00","article:modified_time":"2020-09-29T17:42:29+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"95468","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:05:29","updated":"2022-09-28 01:55:15","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\/95468","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=95468"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/95468\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/95469"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=95468"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=95468"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=95468"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}