Úvod

function getAbsolutelyRandomNumer() {
        return 4; // vrací absolutně náhodné číslo!
}

Stejně jako v případě koncepce absolutně bezpečného šifrování z kryptografie se skutečné protokoly „Publicly Verifiable Random Beacon“ (dále jen PVRB) snaží co nejvíce přiblížit ideálnímu schématu, protože v reálných sítích není čistě v platnosti: je třeba se dohodnout výhradně na jednom bitu, kolikrát se musí něco poslat, a všechny zprávy musí být ideálně rychlé a vždy doručeny. Samozřejmě, v reálných sítích tomu tak není. Proto při návrhu PVRB pro konkrétní úkoly v moderních blockchainech, kromě nemožnosti kontroly získaného náhodného čísla a kryptografické odolnosti, vzniká také mnoho čistě architektonických a technických problémů.

Sám blockchain je pro PVRB v podstatě prostředím pro komunikaci, kde zprávy = transakce. To umožňuje částečně se distancovat od síťových problémů, nedoručování zpráv, problémů s prostředním softwarem — všechny tyto rizika přebírá decentralizovaná síť a hlavní její hodnota pro PVRB — nemožnost odvolat nebo zkazit již odeslanou transakci — to znemožňuje účastníkům odstoupit od účasti v protokolu, pokud jen neprovedli úspěšný útok na konsensus. Taková úroveň bezpečnosti je přijatelná, proto musí být PVRB odolné vůči spiklením stejně jako hlavní řetězec blockchainu. To také naznačuje, že PVRB by měl být součástí konsensu, pokud se síť dohodla na hlavním řetězci bloků, ať už se zároveň dohodne na jediném čestném výsledném náhodném čísle. Nebo, PVRB je prostě samostatný protokol realizovaný chytrou smlouvou, fungující asynchronně vůči blockchainu a blokům. Obě metody mají své výhody a nevýhody a volba mezi nimi je vysoce netriviální.

Dva způsoby implementace PVRB

Podrobně popíšeme dvě varianty implementace PVRB — standalone verzi, která funguje pomocí smart kontraktu nezávislého na blockchainu, a consensus-integrated — integrovanou do protokolu, podle kterého se síť dohodne na řetězci bloků a zahrnutých transakcích. Ve všech případech budu mít na mysli populární blockchainové motoriky: Ethereum, EOS a všechny podobné podle způsobu nasazení a zpracování smart kontraktů.

Standalone contract

V této variantě je PVRB smart kontrakt, který přijímá transakce od random-producerů (RP), zpracovává je, kombinuje výsledky a na základě toho dospívá k nějaké hodnotě, kterou může získat jakýkoli uživatel z tohoto kontraktu. Tato hodnota nemusí být přímo uložena v kontraktu, ale může být reprezentována pouze daty, z nichž lze deterministicky získat jednu a pouze jednu hodnotu výsledného rampup. V tomto schématu jsou RP uživatelé blockchainu a účastnit se procesu generování může kdokoli.

Varianta se standalone-contract je dobrá:

nositelností (kontrakty lze přenášet z blockchainu na blockchain)
jednoduchostí implementace a testování (kontrakty se dobře píší a testují)
pohodlností pro realizaci ekonomických schémat (snadno lze vytvořit vlastní token, jehož logika slouží cílům PVRB)
možnostmi spuštění v již fungujících blockchainech

Má však i nevýhody:

silná omezení na zdroje při výpočtech, objemu transakcí a úložišti (jednoduše řečeno cpu/mem/io)
omezení na operace uvnitř kontraktu (ne všechny instrukce jsou dostupné, obtížné připojit externí knihovny)
nemožnost organizovat výměnu zpráv rychleji, než jsou transakce zahrnuty do blockchainu

Tato varianta vyhovuje implementaci PVRB, kterou je nutné spustit v již existující síti, neobsahující složitou kryptografii a nevyžadující velké množství interakcí.

Consensus-integrated

V této variantě je PVRB implementován v kódu blockchainové uzlu, je zabudován nebo pracuje paralelně s výměnou zpráv mezi uzly blockchainu. Výsledky protokolu jsou zapisovány přímo do vytvářených bloků a zprávy protokolu jsou odesílány přes p2p síť mezi uzly. Jelikož protokol produkuje čísla, která musí být zapsána do bloků, síť se musí dohodnout na konsensu ohledně nich. To znamená, že zprávy PVRB, stejně jako transakce, musí být validovány uzly a zahrnuty do bloků, aby jakýkoli účastník sítě mohl ověřit dodržování protokolu PVRB. To nás automaticky vede k zřejmému řešení – pokud se síť dohodne na konsensu ohledně bloku a transakcí v něm, PVRB by měl být součástí konsensu, nikoli odděleným protokolem. Jinak může nastat situace, kdy je blok validní z hlediska konsensu, ale protokol PVRB nebyl dodržen, a z pohledu PVRB nemůže být blok přijat. Takže pokud je vybrána varianta „consensus-integrated“, PVRB se stává důležitou součástí konsensu.

Při popisování implementací PVRB na úrovni konsensu v síti nelze v žádném případě minout otázky finálnosti. Finálnost je mechanismus používaný v deterministických konsensech, který zajišťuje blok (a řetězec vedoucí k němu), který je finální a nikdy nebude zrušen, i když se objeví paralelní fork. Například Bitcoin tento mechanismus nemá – pokud publikujete řetězec větší složitosti, nahradí jakýkoli méně složitý, bez ohledu na délku řetězců. A v EOS jsou například finálními takzvané Last Irreversible Blocks, které se objevují v průměru každých 432 bloků (12*21 + 12*15, pre-vote + pre-commit). Tento proces je v podstatě čekání na 2/3 podpisů block-producerů (dále BP). Při vzniku forků, které jsou starší než poslední LIB, jsou jednoduše vyřazeny. Tento mechanismus zaručuje, že transakce je zahrnuta do blockchainu a nikdy nebude odvolána, bez ohledu na zdroje, kterými disponuje útočník. Taktéž finálními bloky jsou bloky, které podepsalo 2/3 BP v Hyperledger, Tendermint a dalších konsensech založených na pBFT. Protokol pro zajištění finálnosti je logické udělat jako nadstavbu nad konsensem, protože může pracovat asynchronně s výrobou a publikací bloků. To je dobré. neaktuální statistika o finalitě v Ethereum.

Finalita je extrémně důležitá pro uživatele, kteří bez ní mohou být obětí útoku „double spend“, kdy BP „zadržuje“ bloky a publikuje je poté, co síť „viděla“ dobrou transakci. Pokud není finalita, pak publikovaný fork nahradí blok s „dobrou“ transakcí jiným z „špatného“ forku, ve kterém jsou prostředky převedeny na adresu útočníka. V případě PVRB se požadavky na finalitu ještě zpřísňují, protože konstrukce forků pro PVRB znamená možnost pro útočníka připravit několik variant náhody s cílem publikovat tu nejvýhodnější, a omezit čas pro možný útok — dobré řešení.

Proto je nejlepší variantou zkombinovat PVRB a finalitu do jednoho protokolu — pak finalizovaný blok = finalizovaná náhoda, a to je přesně to, co bylo třeba získat. Nyní hráči obdrží garantovanou náhodu za N sekund a mohou si být jisti, že není možné ji převrátit nebo hrát znovu.

Varianta se souvisejícím konsenzem je dobrá:

s možností asynchronní realizace ve vztahu k výrobě bloků — bloky se vyrábějí jako obvykle, ale paralelně s tím může pracovat protokol PVRB, který generuje náhody ne každý blok
s možností implementovat i těžkou kryptografii, bez omezení kladených na smart kontrakty
s možností organizovat výměnu zpráv rychleji, než jsou transakce zahrnuty do blockchainu, například část protokolu může pracovat mezi nody bez šíření zpráv po síti

Má však i nevýhody:

složitosti při testování a vývoji — bude nutné emulovat síťové chyby, chybějící nody, hard forky sítě
chyby v implementaci vyžadují hard fork sítě

Oba způsoby implementace PVRB mají právo na život, ale implementace ve smart kontraktech v moderních blockchainech je přece jen dost silně omezena ve výpočetních zdrojích, a jakýkoli přechod na vážnou kryptografii je často prostě nemožný. A vážná kryptografie bude potřeba, jak bude dále demonstrováno. I když, tento problém je zjevně dočasného charakteru, vážná kryptografie v kontraktech je potřebná k řešení mnoha úkolů a postupně se objevuje (například systémové kontrakty pro zkSNARKs v Ethereum).

Blockchain, který zajišťuje transparentní a spolehlivý kanál pro výměnu zpráv protokolu, to nedělá zadarmo. Každý decentralizovaný protokol musí zohlednit možnost Sybil útoku, jakékoli akce mohou být provedeny v konsensu s množstvím účtů, a proto je při návrhu nutné vzít v úvahu možnosti útočníků k vytvoření libovolného počtu účastníků protokolu, kteří jednají ve spiknutí.

PVRB a proměnné bloku.

Nelhal jsem, když jsem říkal, že dobrý PVRB, který byl ověřen mnoha gamblovacími aplikacemi, zatím nikdo v blockchainech neimplementoval. Odkud tedy pochází tolik gamblovacích aplikací na Ethereu a EOS? To mě překvapuje stejně jako vás, odkud se v plně deterministickém prostředí vzalo tolik "odolných" náhodností?

Oblíbený způsob, jak získávat náhodnost v blockchainu, je vzít nějakou "nepředvídatelnou" informaci z bloku a na jejím základě vytvořit náhodnost — prostým hashováním jedné nebo několika hodnot. Dobrý článek o problémech takových schémat. zde. Můžete si vzít nějakou z "nepředvídatelných" hodnot v bloku, například hash bloku, počet transakcí, obtížnost sítě a další, předem neznámé hodnoty. Pak je můžete hashovat, jednu nebo více, a mělo by z toho vyjít skutečné náhodno. Můžete dokonce uvést do whitepaperu, že vaše schéma je "post-quantum secure" (protože existují kvantově odolné hash funkce :)).

Ale bohužel ani post-quantum secure hashování nestačí. Tajemství spočívá v požadavcích na PVRB, připomínám je z předchozího článku:

Výsledek by měl mít prokazatelně rovnoměrné rozložení, tedy být založen na prokazatelně odolné kryptografii.
Není možné kontrolovat žádný bit výsledku. V důsledku toho nelze výsledek předem předpovědět.
Nelze sabotovat protokol generace tím, že se na něm neúčastníte, nebo přetížením sítě útočnými zprávami.
Všechno výše uvedené musí být odolné vůči spolčení akceptovatelného počtu nečestných účastníků protokolu (např. 1/3 účastníků).

V tomto případě je splněn pouze požadavek 1 a 2 není dodrženo. Hashováním nepředvídatelných hodnot z bloku získáme rovnoměrné rozdělení a dobré náhodné výsledky. Ale BP má alespoň možnost „publikovat blok, nebo ne“. Takže BP může vybírat alespoň ze DVOU variant náhody: „své“ a té, která vznikne, pokud blok udělá někdo jiný. BP může předem „nahlédnout“, co se stane, pokud publikuje blok, a jednoduše se rozhodnout, zda to udělat, nebo ne. Takto, když například hraje v „sud-lichý“ nebo „červené/černé“ na ruletě, může publikovat blok pouze, pokud vidí výhru. To také činí neefektivní strategii používání například hashe bloku „z budoucnosti“. V tomto případě se říká, že „bude použit náhodný výsledek, který vzniká hashováním aktuálních dat a hashe budoucího bloku na výšce, například N + 42, kde N je aktuální výška bloku. To mírně posiluje schéma, ale stále umožňuje BP, i když v budoucnosti, vybírat, zda blok zadržet nebo publikovat.

Software BP se v tomto případě zhoršuje, ale ne příliš. Při validaci a zařazení transakce do bloku probíhá rychlá kontrola, zda bude výhra, a možná výběr jednoho parametrů transakce, aby se dosáhlo vysoké pravděpodobnosti výhry. Přitom je téměř nemožné chytit inteligentního BP při podobných manipulacích, pokaždé lze použít nové adresy a vyhrávat kousek po kousku, aniž by se vzbudily podezření.

Takže způsoby využívající informace z bloku nejsou vhodné jako univerzální implementace PVRB. V omezeném variantě, s omezeními na velikosti sázek, omezeními počtu hráčů a/nebo KYC registrací (aby se jednomu hráči nedalo možnost používat více adres), tyto schémata mohou fungovat pro malé hry, ale ne víc.

PVRB a commit-reveal.

Dobře, díky hashování a alespoň relativní nepředvídatelnosti hashe bloku a dalších proměnných. Pokud vyřešíme problém front-runningu těžařů, mělo by to vyústit v něco utilitnějšího. Pojďme přidat do tohoto schématu uživatele – ať také ovlivňují náhodu: každý pracovník technické podpory vám řekne, že to nejvíce náhodné v IT systémech jsou činnosti uživatelů 🙂

Naivní schéma, kdy uživatelé jen posílají náhodná čísla, a výsledek se počítá například jako hash jejich součtu, není vhodné. V tomto případě může poslední, kdo hraje, kontrolovat, jaký výsledek bude, výběrem vlastního náhodného čísla. Proto se používá velmi široce rozšířený vzor commit-reveal. Účastníci nejprve posílají hashe svých náhodných čísel (commity), a poté odhalují sama náhodná čísla (revealy). Fáze „reveal“ začíná až poté, co byly shromážděny potřebné commity, takže účastníci mohou poslat přesně to náhodné číslo, jehož hash poslali dříve. Teď spojíme všechno toto s parametry bloku, ideálně vzatého z budoucnosti (náhodné číslo bude možné poznat až v jednom z budoucích bloků), a voilà — náhodné číslo je připravené! Nyní každý hráč ovlivňuje výslednou náhodnost a může „porazit“ zlovolný BP tím, že zakryje jeho náhodnost svou, předem neznámou, náhodností... Ještě můžeme přidat ochranu proti sabotování protokolu tím, že na fázi reveal prostě požádáme, aby při commit-u byla k transakci přiložena určitá částka — zajišťovací depozit, který se vrátí pouze při proceduře reveal. V tomto případě není výhodné provádět commit a neprovádět reveal.

Byl to dobrý pokus a takové schémy existují i v herních DApp, ale bohužel, to opět nestačí. Nyní může na výsledek mít vliv nejen těžař, ale i kterýkoli účastník protokolu. Samotnou hodnotu je stále možné kontrolovat, s menší proměnlivostí a za peníze, ale, jak v případě těžaře, pokud jsou výsledky losování cennější než poplatek za účast na protokolu PVRB, může random-producer (RP) rozhodnout, zda provést reveal a stále může vybírat z minimálně dvou variant náhodnosti.
Zato se objevila možnost trestat ty, kteří provedou commit a neprovedou reveal, a tento vzor se ještě hodí. Jeho jednoduchost je vážnou výhodou — složitější protokoly vyžadují mnohem silnější výpočty.

PVRB a deterministické podpisy.

Existuje další způsob, jak donutit RP poskytnout pseudonáhodné číslo, na které nemůže mít vliv, pokud mu poskytneme „prototyp“ — to je determinovaný podpis. Takovým podpisem je například RSA, nikoli ECS. Pokud má RP pár klíčů: RSA a ECC, a podepisuje svou privátní klíčem určitou hodnotu, pak v případě RSA získá JEDEN A JEDINÝ podpis, zatímco v případě ECS může vygenerovat libovolný počet různých platných podpisů. To se děje proto, že při vytváření ECS podpisu se používá náhodné číslo, které si podepisující vybírá, a to může být vybráno jakkoli, což podepisujícímu dává možnost vybrat si jeden z několika podpisů. V případě RSA: „jedna vstupní hodnota“ + „jeden pár klíčů“ = „jeden podpis“. Předpovědět, jaký podpis obdrží jiný RP, nelze, proto může být PVRB s determinovanými podpisy uspořádáno kombinací RSA podpisů několika účastníků, kteří podepsali stejnou hodnotu. Například — předchozí náhodné číslo. V takovém schématu se ušetří spousta zdrojů, protože podpisy jsou zároveň potvrzením správného chování podle protokolu a zdrojem náhody.

Nicméně, i s determinovanými podpisy je schéma stále zranitelné vůči problému „posledního aktéra“. Poslední účastník stále může rozhodovat, zda publikovat svůj podpis nebo ne, čímž kontroluje výsledek. Schéma je možné přepracovat, přidávat do něj hash bloků, provádět kola, aby nebylo možné předem předpovědět výsledek, ale všechny tyto techniky, i s ohledem na mnoho vylepšení, stále neřeší problém vlivu jednoho účastníka na kolektivní výsledek v nedůvěryhodném prostředí a mohou fungovat pouze za podmínek ekonomických a časových omezení. Kromě toho je velikost klíčů RSA (1024 a 2048 bitů) poměrně velká, a velikost pro blockchainové transakce je extrémně důležitý parametr. Zřejmě problém jednoduše vyřešit nelze, jdeme dál.

V kryptografii existují schémata, která umožňují síti dohodnout se na jedné a jediné hodnotě PVRB, přičemž jsou tato schémata odolná vůči jakýmkoli zlověstným činům některých účastníků. Jeden z užitečných protokolů, se kterými se vyplatí seznámit, je schéma dělení tajemství Shamir. To slouží k rozdělení tajemství (například tajného klíče) na několik částí, které se rozdají N účastníkům. Tajemství se rozděluje tak, že k jeho obnovení stačí M částí z N, přičemž to mohou být jakékoli M části. Pokud bychom to zjednodušili, účastníci si vyměňují body na grafu neznámé funkce, a po získání M bodů může být celá funkce obnovena.
Dobré vysvětlení je uvedeno v wiki a hrát si s ním prakticky, aby si celé protokol lépe zapamatovali, je užitečné na demo stránce.

Kdyby byla schéma FSSS (Fiat-Shamir Secret Sharing) použita v čisté podobě — byl by to nezničitelný PVRB. V nejjednodušším provedení může protokol vypadat takto:

Každý účastník vygeneruje svůj vlastní random a rozdá podíly od něj ostatním účastníkům.
Každý účastník odhalí své části tajemství ostatních účastníků.
Pokud má účastník více než M podílů, lze vypočítat číslo tohoto účastníka, a to bude jediné, bez ohledu na soubor odhalených účastníků.
Kombinace odhalených randomů je požadovaný PVRB.

Zde již jednotlivý účastník neovlivňuje výsledky protokolu, kromě případů, kdy od něj závisí dosažení thresholdu odhalení randomu. Proto tento protokol, při наличии potřebného podílu pracujících podle protokolu a dostupných RP, funguje tak, že splňuje požadavky na kryptografickou odolnost a je odolný vůči problému "last actor".

To by mohl být ideální případ, toto schéma PVRB založené na dělení tajemství Fiata-Shamira je popsáno například v tato článku. Ale, jak bylo řečeno výše, pokud se pokusíme aplikovat ho přímo v blockchainu, objevují se technická omezení. Zde je příklad testovací implementace protokolu ve smart kontraktu EOS a jeho nejdůležitější část — kontrola zveřejněného podílu účastníka: kód. Z kódu je patrné, že validace proofu vyžaduje několik skalárních násobení a čísla jsou velmi velká. Je třeba si uvědomit, že v blockchainu probíhá verifikace ve chvíli, kdy block-producer zpracovává transakci, a jakýkoliv účastník by měl být schopen snadno ověřit správnost protokolu, proto jsou požadavky na rychlost funkce verify velmi přísné. Tento variant se ukázal jako nefunkční, protože verifikace se nevešla do časového limitu na transakci (0,5 sekundy).

Efektivita verifikace je jedním z nejdůležitějších požadavků na použití vlastně jakýchkoliv pokročilých kryptografických schémat v blockchainu. Vytváření proofů, příprava zpráv — tyto postupy lze provádět off-chain na vysoce výkonných počítačích, ale verifikaci nelze obejít — to je další důležitý požadavek na PVRB.

PVRB a threshold podpisy

Seznámením se s schématem secret sharing jsme otevřeli celou třídu protokolů, spojovaných klíčovým slovem 'threshold'. Když je pro odhalení určité informace potřeba účast M čestných účastníků z N, a soubor čestných účastníků může být libovolnou podmnožinou N, mluvíme o 'threshold' schématech. Právě ta umožňují vyřešit problém 'last actor', nyní pokud útočník neodhalí svou část tajemství, za něj to udělá jiný čestný účastník. Tato schémata umožňují dohodnout se na jedné a pouze jedné hodnotě, i při sabotování protokolu částí účastníků.

Kombinace deterministických podpisů a threshold schémat umožnila vyvinout velmi pohodlné a slibné schéma pro realizaci PVRB — to jsou deterministické threshold podpisy. Tady neaktuální statistika o různých aplikacích threshold podpisů, a tady je ještě jeden dobrý longread od Dash.

V posledním článku jsou popsány BLS podpisy (BLS se rozebírá jako Boneh-Lynn-Shacham, tady je článek), které mají velmi důležitou a extrémně pohodlnou vlastnost pro programátory – veřejné, tajné, veřejné klíče a BLS podpisy mohou být kombinovány navzájem pomocí jednoduchých matematických operací, přičemž jejich kombinace zůstávají platnými klíči a podpisy, což umožňuje snadno agregovat mnoho podpisů do jedné a mnoho veřejných klíčů do jednoho. Mají také deterministickou povahu a na stejných vstupních datech vracejí stejný výsledek. Díky této vlastnosti jsou kombinace BLS podpisů samy o sobě platnými klíči, což umožňuje realizaci varianty, při které M z N účastníků produkuje právě jeden jediný podpis, který je determinován, veřejně ověřitelný a nepředvídatelný, dokud není odhalen M-tým účastníkem.

V schématu s threshold BLS podpisy každý účastník podpisuje pomocí BLS něco (například předchozí náhodu), a celkový threshold-podpis je požadovaná náhoda. Kryptografické vlastnosti BLS podpisů splňují požadavky na kvalitu náhody, threshold-část chrání proti „last-actor“, a jedinečná kombinovatelnost klíčů umožňuje realizovat další zajímavé algoritmy, které umožňují například efektivně agregovat zprávy protokolu.

Takže, pokud budujete PVRB ve své blockchainu, pravděpodobně přijdete ke schématu BLS threshold podpisů, které již používá několik projektů. Například DFinity (zde benchmark, který implementuje schéma, a tady příklad implementace verifiable secret sharing), nebo Keep.network (tady je jejich random beacon yellowpaper, a to je příklad smart kontraktu, který obsluhuje protokol).

Implementace PVRB

Bohužel dosud nevidíme připravený, v blockchainech PVRB realizovaný protokol, který by prokázal svou bezpečnost a odolnost. I když jsou samotné protokoly připravené, technicky je jejich aplikace na stávající řešení složitá. Pro centralizované systémy PVRB nedává smysl, zatímco decentralizované jsou přísně omezené ve všech výpočetních zdrojích: CPU, paměti, úložišti, I/O. Návrh PVRB spočívá v kombinaci různých protokolů, abychom přece jen vytvořili něco, co splní všechny požadavky alespoň pro nějaký životaschopný blockchain. Jeden protokol efektivněji počítá, ale vyžaduje více zpráv mezi RP, zatímco jiný vyžaduje velmi málo zpráv, ale vytvoření proof může být úlohou na desítky minut, nebo dokonce hodin.

Vyjmenuji faktory, které musíte zohlednit při výběru kvalitního PVRB:

Kryptografická odolnost. Vaše PVRB by mělo být naprosto neovlivnitelné, bez možnosti kontroly jediného bitu. V některých schématech tomu tak není, proto si pozvěte kryptografa.
Problém „posledního aktéra“. Vaše PVRB by mělo být odolné vůči útokům, kdy útočník, kontrolující jednoho nebo více RP, může vybírat mezi dvěma variantami výsledku.
Problém sabotáže protokolu. Vaše PVRB by mělo být odolné vůči útokům, kdy útočník, kontrolující jednoho nebo více RP, rozhodne, zda bude výběr náhodný nebo ne, a může garantovaně, nebo s danou pravděpodobností na to mít vliv.
Problém počtu zpráv. Vaše RP by měly posílat do blockchainu minimum zpráv a maximálně se vyhnout synchronním akcím typu „poslal jsem nějaké informace, čekám na odpověď od konkrétního účastníka“. V p2p sítích, zejména geograficky rozptýlených, nelze počítat s rychlou odpovědí.
Problém výpočetní složitosti. Ověření jakékoli fáze PVRB on-chain by mělo být extrémně jednoduché, protože to vykonávají všechny plné klienty sítě. Pokud je realizace provedena pomocí smart kontraktu, musí být požadavky na rychlost velmi přísné.
Problém dostupnosti a životnosti. Vaše PVRB by mělo usilovat o to, aby bylo odolné vůči situacím, kdy část sítě byla nějakou dobu nedostupná a část RP prostě přestala fungovat.
Problém důvěryhodného nastavení a počátečního rozdělení klíčů. Pokud váš PVRB používá primární setup protokolu, je to zcela jiný velký a vážný příběh. Tady příklad. Pokud musí účastníci před začátkem protokolu oznámit své klíče, je to také problém, pokud se složení účastníků mění.
Problémy s vývojem. Důležitá je přítomnost knihoven ve správných jazycích, jejich bezpečnost a výkon, veřejný přístup, složité testy atd.

Například u threshold BLS podpisů existuje zásadní problém – než začnou pracovat, účastníci si musí navzájem rozdat klíče a organizovat skupinu, v jejímž rámci bude threshold fungovat. To znamená, že se musí čekat alespoň na jedno kolo výměny v decentralizované síti, a vzhledem k tomu, že generovaný random, například, je potřebný ve hrách prakticky v reálném čase, znamená to, že na této úrovni je možné sabotáží protokolu, a výhody threshold schématu se ztrácejí. Tento problém je už jednodušší než předchozí, ale stále si vyžaduje vývoj samostatné procedury pro formování threshold skupin, kterou bude nutné ekonomicky chránit prostřednictvím vkladů a odejmutí prostředků (slashing) od účastníků, kteří se nenechají řídit protokolem. Navíc, ověření BLS s přijatelnou úrovní bezpečnosti se prostě nevejde například do standardní transakce EOS nebo Ethereum – prostě není dost času na ověření. Kód kontraktů – to je WebAssembly nebo EVM, vykonáváno virtuální stroj. Kryptografické funkce zatím nejsou nativně implementovány a pracují několikanásobně pomaleji než obyčejné kryptografické knihovny. Mnoho protokolů nesplňuje požadavky vycházející jednoduše z objemu klíčů, například to je 1024 a 2048 bit pro RSA, 4-8 krát více než standardní podpis transakce v Bitcoin a Ethereum.

Hraje roli i přítomnost implementací v různých programovacích jazycích – které jsou vzácné, zejména pro nové protokoly. Možnost integrace do konsensu vyžaduje napsat protokol v jazyce platformy, takže budete muset hledat kód v Go pro geth, v Rust pro Parity, v C++ pro EOS. Kód v JavaScriptu bude muset hledat každý, a protože JavaScript a kryptografie nejsou zrovna blízcí přátelé, pomůže WebAssembly, který nyní má na dosah role důležitého internetového standardu.

Závěr

Doufám, že v předchozím článku Uvěřil jsem vás, že generování náhodných čísel na blockchainu je kriticky důležité pro mnoho aspektů života decentralizovaných sítí, a tímto článkem ukazuji, že úkol je mimořádně ambiciózní a obtížný, ale existují již dobrá řešení. Konečný návrh protokolu je možné navrhnout až po provedení rozsáhlých testů, které zohledňují všechny aspekty od nastavení po simulaci selhání, takže jen těžko naleznete hotové recepty v whitepapers týmů a v článcích, a my se v následujících roce či dvou určitě neodvážíme psát „dělejte to takto, tak je to správně“.

Zatím, pro náš PVRB v připravovaném blockchainu Haya, jsme se rozhodli pro použití threshold BLS podpisů, plánujeme implementovat PVRB na úrovni konsensu, protože verifikace ve smart kontraktech s přijatelnou úrovní zabezpečení zatím není možná. Možná použijeme rovnou dvě schémata: nejprve drahou secret sharing pro vytvoření dlouhodobého random_seed, a ten pak použijeme jako základ pro vysoce frekventovanou generaci náhody pomocí deterministických threshold BLS podpisů, možná se omezíme jen na jedno ze schémat. Předem říct, jaký bude protokol, bohužel nelze, ale těší mě, že jako v vědě, i v inženýrských úlohách je negativní výsledek také výsledkem, a každý nový pokus vyřešit úkol je další krokem pro všechny, kdo se tímto problémem zabývají. Abychom splnili požadavky z pohledu byznysu, řešíme konkrétní praktický úkol — zajištění herních aplikací spolehlivým zdrojem entropie, proto se musíme věnovat také samotnému blockchainu, zejména otázkám finálnosti řetězce a governance sítě.

A i když zatím nevidíme v blockchainech prokázaně odolný PVRB, který by byl používán dostatečně dlouho na to, aby prošel testy skutečnými aplikacemi, mnoha audity, zátěžemi a samozřejmě skutečnými útoky, počet možných cest potvrzuje, že řešení existuje, a nějaký z těchto algoritmů nakonec problém vyřeší. Rádi se podělíme o výsledky a děkujeme ostatním týmům, kteří se také zabývají touto záležitostí za články a kód, které umožňují inženýrům nenarazit dvakrát na stejné hrábě.

Pokud se setkáte s programátorem, který navrhuje decentralizovaný generátor náhodných čísel, buďte opatrní a ohleduplní, a pokud je to nutné, poskytněte psychologickou pomoc 🙂

Zdroj: habr.com