úvod

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

Stejně jako u konceptu absolutně silné šifry z kryptografie se skutečné protokoly „Publicly Verifiable Random Beacon“ (dále PVRB) pouze snaží co nejvíce přiblížit ideálnímu schématu, protože v reálných sítích není použitelný v čisté podobě: je nutné se striktně dohodnout na jednom bitu, musí být mnoho kol a všechny zprávy musí být dokonale rychlé a vždy doručené. Ve skutečných sítích tomu tak samozřejmě není. Při navrhování PVRB pro konkrétní úkoly v moderních blockchainech proto kromě nemožnosti kontroly výsledné náhodnosti a kryptografické síly vyvstává mnohem více čistě architektonických a technických problémů.

Pro PVRB je samotný blockchain v podstatě komunikačním médiem, ve kterém zprávy = transakce. To umožňuje částečně abstrahovat od síťových problémů, nedoručování zpráv, problémů s middleware – všechna tato rizika na sebe decentralizovaná síť přebírá a její hlavní hodnotou pro PVRB je nemožnost odvolat či zkorumpovat již odeslanou transakci – to ano nedovolit účastníkům odmítnout účast na protokolu, pokud neprovedli úspěšný útok na konsensus. Tato úroveň zabezpečení je přijatelná, takže PVRB by měl být odolný vůči tajným dohodám účastníků přesně ve stejném rozsahu jako hlavní blockchainový řetězec. To také naznačuje, že PVRB musí být součástí konsensu, pokud se síť dohodne na hlavním blockchainu, i když se také dohodne na jediném spravedlivém výsledném náhodném. Nebo je PVRB jednoduše samostatný protokol implementovaný inteligentní smlouvou, která funguje asynchronně s ohledem na blockchain a bloky. Obě metody mají své výhody a nevýhody a výběr mezi nimi je extrémně netriviální.

Dva způsoby implementace PVRB

Popišme si podrobněji dvě možnosti implementace PVRB – samostatnou verzi, která funguje pomocí chytré smlouvy nezávislé na blockchainu, a verzi integrovanou do konsenzu, zabudovanou do protokolu, podle které se síť dohodne na blockchainu a transakce, které mají být zahrnuty. Ve všech případech budu mít na mysli populární blockchainové motory: Ethereum, EOS a všechny jim podobné ve způsobu, jakým hostují a zpracovávají chytré smlouvy.

Samostatná smlouva

PVRB je v této verzi chytrý kontrakt, který přijímá transakce náhodných producentů (dále jen RP), zpracovává je, kombinuje výsledky a ve výsledku se dostává k určité hodnotě, kterou může z tohoto kontraktu získat každý uživatel. Tato hodnota nemusí být uložena přímo ve smlouvě, ale může být reprezentována pouze daty, ze kterých lze deterministicky získat pouze jednu hodnotu výsledného náhodného. V tomto schématu jsou RP uživateli blockchainu a komukoli může být umožněno zúčastnit se procesu generování.

Možnost se samostatnou smlouvou je dobrá:

• přenositelnost (smlouvy lze přetáhnout z blockchainu do blockchainu)
• snadná implementace a testování (smlouvy lze snadno psát a testovat)
• pohodlí při implementaci ekonomických schémat (je snadné vytvořit si vlastní token, jehož logika slouží účelům PVRB)
• možnost spuštění na již fungujících blockchainech

Má také nevýhody:

• silná omezení na výpočetní zdroje, objem transakcí a úložiště (jinými slovy, cpu/mem/io)
• omezení provozu v rámci smlouvy (není k dispozici všechny návody, je obtížné připojit externí knihovny)
• neschopnost organizovat zasílání zpráv rychleji, než jsou transakce zahrnuty do blockchainu

Tato možnost je vhodná pro implementaci PVRB, kterou je třeba provozovat na existující síti, neobsahuje složitou kryptografii a nevyžaduje velké množství interakcí.

Konsensuálně integrované

V této verzi je PVRB implementován v kódu uzlu blockchainu, vestavěný nebo běžící paralelně s výměnou zpráv mezi uzly blockchainu. Výsledky protokolu se zapisují přímo do vytvořených bloků a zprávy protokolu se mezi uzly zasílají po síti p2p. Protože protokol má za následek čísla, která mají být zapsána v blocích, musí na nich síť dosáhnout konsensu. To znamená, že zprávy PVRB, stejně jako transakce, musí být ověřeny uzly a zahrnuty do bloků, aby každý účastník sítě mohl ověřit shodu s protokolem PVRB. To nás automaticky vede k zřejmému řešení – pokud se síť dohodne na konsensu o bloku a transakcích v něm, pak by PVRB měl být součástí konsenzu, a nikoli samostatný protokol. V opačném případě je možné, že blok je platný z hlediska konsenzu, ale není dodržován protokol PVRB a z hlediska PVRB nelze blok přijmout. Pokud je tedy zvolena možnost „integrovaná shoda“, PVRB se stává důležitou součástí konsenzu.

Při popisu implementací PVRB na úrovni síťového konsenzu se nelze v žádném případě vyhnout otázkám konečnosti. Finalita je mechanismus používaný v deterministických konsensech, který uzamkne blok (a řetězec k němu vedoucí), který je konečný a nikdy nebude zahozen, i když dojde k paralelní vidlici. Například v bitcoinu takový mechanismus neexistuje – pokud zveřejníte řetězec větší složitosti, nahradí jakýkoli méně složitý, bez ohledu na délku řetězců. A například v EOS jsou finální tzv. 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 v podstatě čeká na podpisy 2/3 výrobců bloků (dále jen BP). Když se objeví vidličky, které jsou starší než poslední LIB, jsou jednoduše vyřazeny. Tento mechanismus umožňuje zaručit, že transakce je zahrnuta do blockchainu a nikdy nebude vrácena zpět, bez ohledu na to, jaké zdroje má útočník. Posledními bloky jsou také bloky podepsané 2/3 BP v Hyperledger, Tendermint a dalších konsensech založených na pBFT. Také má smysl vytvořit protokol pro zajištění finality jako doplněk ke konsensu, protože může pracovat asynchronně s produkcí a publikováním bloků. Tady je dobrý článek o definitivnosti v Ethereu.

Finalita je extrémně důležitá pro uživatele, kteří se bez ní mohou stát obětí útoku „double spend“, kdy BP „drží“ bloky a zveřejňuje je poté, co síť „uvidí“ dobrou transakci. Pokud neexistuje konečná platnost, pak zveřejněný fork nahradí blok „dobrou“ transakcí jinou, ze „špatného“ forku, ve kterém jsou stejné prostředky převedeny na adresu útočníka. V případě PVRB jsou požadavky na finalitu ještě přísnější, protože budování forků pro PVRB znamená pro útočníka možnost připravit si několik náhodných možností, aby zveřejnil tu nejziskovější, a omezení doby možného útoku je otázkou. dobré řešení.

Nejlepší možností je tedy spojit PVRB a finalitu do jednoho protokolu – pak finalizovaný blok = finalizovaný náhodný, a to je přesně to, co jsme potřebovali získat. Nyní hráči obdrží zaručenou náhodu za N sekund a mohou si být jisti, že ji nelze vrátit zpět nebo ji znovu přehrát.

Možnost integrovaná konsensem je dobrá:

• možnost asynchronní implementace ve vztahu k výrobě bloků - bloky jsou vyráběny jako obvykle, ale paralelně s tím může fungovat protokol PVRB, který neprodukuje náhodnost pro každý blok
• schopnost implementovat i těžkou kryptografii, bez omezení kladených na smart kontrakty
• schopnost organizovat výměnu zpráv rychleji, než jsou transakce zahrnuty v blockchainu, například část protokolu může fungovat mezi uzly bez distribuce zpráv po síti

Má také nevýhody:

• Potíže s testováním a vývojem – budete muset emulovat síťové chyby, chybějící uzly, hard forky sítě
• Chyby při implementaci vyžadují hardfork sítě

Oba způsoby implementace PVRB mají právo na život, ale implementace na smart kontraktech v moderních blockchainech je stále poměrně omezená ve výpočetních zdrojích a jakýkoli přechod na seriózní kryptografii je často jednoduše nemožný. A budeme potřebovat seriózní kryptografii, jak bude ukázáno níže. Přestože je tento problém zjevně dočasný, k vyřešení mnoha problémů je zapotřebí seriózní kryptografie ve smlouvách a postupně se objevuje (například systémové smlouvy pro zkSNARK v Ethereu)

Blockchain, který poskytuje transparentní a spolehlivý protokol pro zasílání zpráv, to nedělá zadarmo. Každý decentralizovaný protokol musí počítat s možností útoku Sybil, jakoukoli akci mohou provádět spojené síly více účtů, proto je při návrhu nutné vzít v úvahu schopnost útočníků vytvořit libovolný počet protokolů účastníci jednající v tajné dohodě.

PVRB a blokové proměnné.

Nelhal jsem, když jsem řekl, že ještě nikdo neimplementoval dobrý PVRB, testovaný mnoha hazardními aplikacemi, v blockchainech. Odkud se na Ethereu a EOS bere tolik aplikací pro hazardní hry? To mě překvapuje stejně jako vás, kde vzali tolik „trvalých“ náhod v naprosto deterministickém prostředí?

Oblíbeným způsobem, jak získat náhodnost v blockchainu, je vzít z bloku nějakou „nepředvídatelnou“ informaci a na jejím základě vytvořit náhodnou – jednoduše hashováním jedné nebo více hodnot. Dobrý článek o problémech takových schémat zde. Můžete vzít kteroukoli z „nepředvídatelných“ hodnot v bloku, například hash bloku, počet transakcí, složitost sítě a další předem neznámé hodnoty. Pak je hashujte, jeden nebo více, a teoreticky byste měli získat skutečnou náhodu. Můžete dokonce do wihitepaper přidat, že vaše schéma je „post-kvantově bezpečné“ (protože existují kvantově odolné hašovací funkce :)).

Ale ani postkvantové bezpečné hashe bohužel nestačí. Tajemství spočívá v požadavcích na PVRB, dovolte mi je připomenout z předchozího článku:

1. Výsledek musí mít prokazatelně rovnoměrné rozložení, tedy být založen na prokazatelně silné kryptografii.
2. Není možné ovládat žádný z bitů výsledku. V důsledku toho nelze výsledek předem předvídat.
3. Protokol generování nemůžete sabotovat tím, že se nebudete na protokolu podílet nebo že přetížíte síť útočnými zprávami
4. Vše výše uvedené musí být odolné vůči tajné dohodě s přípustným počtem nepoctivých účastníků protokolu (například 1/3 účastníků).

V tomto případě je splněn pouze požadavek 1 a není splněn požadavek 2. Hašováním nepředvídatelných hodnot z bloku získáme rovnoměrné rozdělení a dobré náhody. Ale BP má alespoň možnost „zveřejnit blok nebo ne“. BP si tedy může vybrat alespoň ze DVOU náhodných možností: „své vlastní“ a té, která se ukáže, pokud blok udělá někdo jiný. BP může předem „odposlouchávat“, co se stane, pokud zveřejní blok, a jednoduše se rozhodne, zda to udělá nebo ne. Při hraní například „sudý-lichý“ nebo „červený/černý“ v ruletě tak může zveřejnit blok pouze v případě, že vidí výhru. To také znemožňuje použití strategie použití například blokového hashe „z budoucnosti“. V tomto případě říkají, že „bude použit náhodný, který se získá hašováním aktuálních dat a hash budoucího bloku o výšce např. N + 42, kde N je aktuální výška bloku. Toto schéma trochu posiluje, ale stále umožňuje společnosti BP, i když v budoucnu, vybrat si, zda blokovat nebo publikovat.

Software BP se v tomto případě stává složitějším, ale ne moc. Jednoduše při validaci a zařazení transakce do bloku dochází k rychlé kontrole, zda dojde k výhře a případně k výběru jednoho transakčního parametru pro získání vysoké pravděpodobnosti výhry. Zároveň je téměř nemožné chytit chytrého BP za takové manipulace, pokaždé můžete použít nové adresy a vyhrát kousek po kousku, aniž byste vzbudili podezření.

Metody využívající informace z bloku tedy nejsou vhodné jako univerzální implementace PVRB. V omezené verzi, s omezením velikosti sázek, omezením počtu hráčů a/nebo registrací KYC (aby jeden hráč nemohl používat více adres), mohou tato schémata fungovat pro malé hry, ale nic víc.

PVRB a commit-reveal.

Dobře, díky hašování a alespoň relativní nepředvídatelnosti blokového haše a dalších proměnných. Pokud řešíte problém předních těžařů, měli byste si pořídit něco vhodnějšího. Přidejme do tohoto schématu uživatele – nechme je také ovlivnit náhodnost: každý zaměstnanec technické podpory vám řekne, že nejnáhodnější věcí v IT systémech jsou akce uživatelů :)

Naivní schéma, kdy uživatelé jednoduše pošlou náhodná čísla a výsledek se vypočítá jako například hash jejich součtu, není vhodné. V tomto případě může poslední hráč výběrem vlastního náhodného výběru řídit, jaký bude výsledek. To je důvod, proč se používá velmi široce používaný vzor commit-reveal. Účastníci nejprve odesílají hashe ze svých náhod (commits) a poté sami otevírají náhody (reveals). Fáze „odhalení“ začíná až poté, co byly shromážděny potřebné commity, takže účastníci mohou poslat přesně ten náhodný hash, ze kterého odeslali dříve. Nyní to vše dáme dohromady s parametry bloku, a to lepšího než jednoho převzatého z budoucnosti (náhodnost lze nalézt pouze v jednom z budoucích bloků) a voila - náhodnost je připravena! Nyní každý hráč ovlivňuje výslednou náhodnost a může „porazit“ škodlivý BP tím, že ho přepíše svou vlastní, předem neznámou, náhodností... Můžete také přidat ochranu proti sabotování protokolu tím, že jej neotevřete ve fázi odhalení – jednoduše požadavkem, aby byla k transakci při zavázání přiložena určitá částka — kauce, která bude vrácena pouze během odhalovací procedury. V tomto případě bude spáchání a neodhalení nerentabilní.

Byl to dobrý pokus a taková schémata existují i ​​v herních DApps, ale bohužel to opět nestačí. Nyní může výsledek ovlivnit nejen těžař, ale i kterýkoli účastník protokolu. Hodnotu samotnou je stále možné kontrolovat, s menší variabilitou a nákladem, ale stejně jako v případě těžaře, pokud jsou výsledky losování hodnotnější než poplatek za účast v protokolu PVRB, pak náhodný -producer(RP) se může rozhodnout, zda odhalit, a přesto si může vybrat z alespoň dvou náhodných možností.
Ale bylo možné potrestat ty, kteří se dopustí a neodhalí, a toto schéma se bude hodit. Jeho jednoduchost je vážnou výhodou – serióznější protokoly vyžadují mnohem výkonnější výpočty.

PVRB a deterministické signatury.

Existuje další způsob, jak donutit RP k poskytnutí pseudonáhodného čísla, které nemůže ovlivnit, pokud je opatřeno „předobrazem“ – jedná se o deterministický podpis. Takový podpis je například RSA a není to ECS. Pokud má RP pár klíčů: RSA a ECC a podepíše svým soukromým klíčem určitou hodnotu, tak v případě RSA získá JEDEN A JEN JEDEN podpis a v případě ECS může vygenerovat libovolný počet různé platné podpisy. Je tomu tak proto, že při vytváření ECS podpisu se používá náhodné číslo, zvolené podepisovatelem, a může být zvoleno libovolným způsobem, což dává podepisujícímu možnost vybrat si jeden z více podpisů. V případě RSA: „jedna vstupní hodnota“ + „jeden pár klíčů“ = „jeden podpis“. Je nemožné předvídat, jaký podpis získá další RP, takže PVRB s deterministickými podpisy lze organizovat kombinací RSA podpisů několika účastníků, kteří podepsali stejnou hodnotu. Například předchozí náhodný. Toto schéma šetří spoustu zdrojů, protože podpisy jsou jak potvrzením správného chování podle protokolu, tak zdrojem náhodnosti.

Avšak i s deterministickými podpisy je schéma stále citlivé na problém „posledního aktéra“. Poslední účastník se stále může rozhodnout, zda podpis zveřejní nebo ne, a tím kontrolovat výsledek. Schéma můžete upravovat, přidávat do něj blokové hashe, zaokrouhlovat, takže výsledek nelze předem předvídat, ale všechny tyto techniky, i když vezmou v úvahu mnoho úprav, stále nechávají nevyřešený problém vlivu jednoho účastníka na kolektiv. výsledkem je nedůvěryhodné prostředí a může fungovat pouze v ekonomických a časových omezeních. Navíc velikost RSA klíčů (1024 a 2048 bitů) je poměrně velká a velikost pro blockchainové transakce je extrémně důležitý parametr. Zřejmě neexistuje jednoduchý způsob, jak problém vyřešit, pojďme dál.

PVRB a schémata tajného sdílení

V kryptografii existují schémata, která umožňují síti dohodnout se na jedné a pouze jedné hodnotě PVRB, přičemž taková schémata jsou odolná vůči jakémukoli škodlivému jednání některých účastníků. Jedním z užitečných protokolů, se kterými stojí za to se seznámit, je Shamirovo schéma tajného sdílení. Slouží k rozdělení tajemství (například tajného klíče) na několik částí a distribuci těchto částí N účastníkům. Tajemství je distribuováno tak, že M dílů z N stačí k jeho obnovení, a to může být libovolné M dílů. Pokud na prstech, pak mají graf neznámé funkce, účastníci si vymění body na grafu a po obdržení M bodů lze celou funkci obnovit.
Dobré vysvětlení je uvedeno v wiki ale hrát si s tím prakticky za účelem přehrání protokolu v hlavě je užitečné demonstrace strana.

Pokud by bylo schéma FSSS (Fiat-Shamir Secret Sharing) použitelné ve své čisté podobě, byl by to nezničitelný PVRB. Ve své nejjednodušší podobě může protokol vypadat takto:

• Každý účastník si vygeneruje svůj vlastní náhodný výběr a rozdělí z něj sdílení ostatním účastníkům
• Každý účastník odhalí svou část tajemství ostatních účastníků
• Pokud má účastník více než M podílů, lze počet tohoto účastníka vypočítat a bude jedinečný, bez ohledu na množinu odhalených účastníků
• Kombinace odhalených náhod je žádoucí PVRB

Zde již jednotlivý účastník neovlivňuje výsledky protokolu, s výjimkou případů, kdy dosažení prahu odhalení náhodnosti závisí pouze na něm. Proto tento protokol, pokud existuje požadovaný podíl RP pracujících na protokolu a dostupných, funguje, implementuje požadavky na šifrovací sílu a je odolný vůči problému „posledního aktéra“.

To by mohla být ideální možnost, toto schéma PVRB založené na sdílení tajemství Fiat-Shamir je popsáno např. tohle článek. Ale jak je uvedeno výše, pokud se to pokusíte použít přímo v blockchainu, objeví se technická omezení. Zde je příklad testovací implementace protokolu v EOS smart kontraktu a jeho nejdůležitější části – kontroly zveřejněného účastníka sdílení: kód. Z kódu můžete vidět, že ověření ověření vyžaduje několik skalárních násobení a použitá čísla jsou velmi velká. Je třeba si uvědomit, že v blockchainech k verifikace dochází v okamžiku, kdy výrobce bloku zpracovává transakci, a obecně platí, že každý účastník musí snadno ověřit správnost protokolu, takže požadavky na rychlost ověřovací funkce jsou velmi závažné . U této možnosti se tato možnost ukázala jako neúčinná, protože ověření se nevešlo do limitu transakce (0.5 sekundy).

Účinnost ověřování je jedním z nejdůležitějších požadavků na použití obecně všech pokročilých kryptografických schémat v blockchainu. Vytváření nátisků, příprava zpráv – tyto procedury lze odpojit od řetězu a provádět je na výkonných počítačích, ale ověření nelze obejít – to je další důležitý požadavek na PVRB.

PVRB a prahové signatury

Po seznámení se schématem tajného sdílení jsme objevili celou třídu protokolů spojených klíčovým slovem „threshold“. Když zveřejnění nějaké informace vyžaduje účast M poctivých účastníků z N a množina poctivých účastníků může být libovolnou podmnožinou N, hovoříme o „prahových“ schématech. Právě ony nám umožňují vypořádat se s problémem „posledního aktéra“, pokud nyní útočník neprozradí svou část tajemství, udělá to za něj jiný, čestný účastník. Tato schémata umožňují shodu na jednom a pouze jednom smyslu, i když je protokol některými účastníky sabotován.

Kombinace deterministických signatur a prahových schémat umožnila vyvinout velmi pohodlné a slibné schéma pro implementaci PVRB - jedná se o deterministické prahové signatury. Tady článek o různých použitích prahových podpisů a tady je další dobrý longread od Dash.

Poslední článek popisuje podpisy BLS (BLS znamená Boneh-Lynn-Shacham, zde článek), které mají velmi důležitou a pro programátory mimořádně pohodlnou kvalitu – veřejné, tajné, veřejné klíče a podpisy BLS lze vzájemně kombinovat pomocí jednoduchých matematických operací, přičemž jejich kombinace zůstávají platnými klíči a podpisy, což vám umožní snadno agregovat mnoho podpisy do jednoho a mnoho veřejných klíčů do jednoho. Jsou také deterministické a poskytují stejný výsledek pro stejná vstupní data. Díky této kvalitě jsou kombinace podpisů BLS samy o sobě platnými klíči, což umožňuje implementaci možnosti, ve které M z N účastníků vytvoří jeden a pouze jeden podpis, který je deterministický, veřejně ověřitelný a nepředvídatelný, dokud jej neotevře Mth. účastník .

Ve schématu s prahovými podpisy BLS každý účastník podepíše něco pomocí BLS (například předchozí náhodný podpis) a společný prahový podpis je požadovaný náhodný. Kryptografické vlastnosti podpisů BLS splňují požadavky na náhodnou kvalitu, prahová část chrání před „posledním aktérem“ a jedinečná kombinovatelnost klíčů umožňuje implementovat mnoho zajímavějších algoritmů, které umožňují například efektivní agregaci protokolových zpráv. .

Pokud tedy stavíte PVRB na svém blockchainu, s největší pravděpodobností skončíte se schématem prahových podpisů BLS, několik projektů jej již používá. Například DFinity (zde benchmark, který implementuje obvod, a zde příklad implementace ověřitelného sdílení tajemství) nebo Keep.network (zde je jejich náhodný maják žlutý papír, Ale příklad inteligentní smlouva obsluhující protokol).

Realizace PVRB

Bohužel stále nevidíme hotový protokol implementovaný v blockchainech PVRB, který by prokázal svou bezpečnost a stabilitu. I když jsou samotné protokoly připraveny, technicky je aplikovat na stávající řešení není jednoduché. Pro centralizované systémy nedává PVRB smysl a decentralizované jsou přísně omezeny ve všech výpočetních zdrojích: CPU, paměť, úložiště, I/O. Návrh PVRB je kombinací různých protokolů s cílem vytvořit něco, co splňuje všechny požadavky na alespoň nějaký životaschopný blockchain. Jeden protokol počítá efektivněji, ale vyžaduje více zpráv mezi RP, zatímco druhý vyžaduje velmi málo zpráv, ale vytvoření důkazu může být úkol, který trvá desítky minut nebo dokonce hodiny.

Uvedu faktory, které budete muset vzít v úvahu při výběru kvalitního PVRB:

• Kryptografická síla. Vaše PVRB musí být přísně nezaujaté, bez schopnosti ovládat jediný bit. V některých schématech tomu tak není, proto zavolejte kryptografa
• Problém „posledního aktéra“.. Vaše PVRB musí být odolné vůči útokům, kdy si útočník ovládající jedno nebo více RP může vybrat jeden ze dvou výsledků.
• Problém se sabotáží protokolu. Vaše PVRB musí být odolné vůči útokům, kdy se útočník ovládající jedno nebo více RP rozhodne, zda bude náhodný nebo ne, a může být zaručeno, nebo s danou pravděpodobností toto ovlivnit.
• Problém s počtem zpráv. Vaše RP by měly do blockchainu posílat minimum zpráv a co nejvíce se vyhýbat synchronním akcím, jako jsou situace 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, byste neměli počítat s rychlou odezvou
• Problém výpočetní složitosti. Ověření jakékoli fáze PVRB on-chain by mělo být extrémně snadné, protože je prováděno všemi plnohodnotnými klienty sítě. Pokud se implementace provádí pomocí chytré smlouvy, pak jsou požadavky na rychlost velmi přísné
• Problém dostupnosti a živosti. Váš PVRB by se měl snažit být odolný vůči situacím, kdy se část sítě stane po určitou dobu nedostupnou a část RP prostě přestane fungovat
• Problém důvěryhodného nastavení a počáteční distribuce klíčů. Pokud vaše PVRB používá primární nastavení protokolu, pak je to samostatný velký a vážný příběh. Tady příklad. Pokud si účastníci musí před zahájením protokolu sdělit své klíče, je to také problém, pokud se změní složení účastníků
• Vývojové problémy. Dostupnost knihoven v požadovaných jazycích, jejich zabezpečení a výkon, publicita, komplexní testy atd.

Například signatury BLS s prahovou hodnotou mají významný problém – než začnou pracovat, účastníci si musí navzájem distribuovat klíče a zorganizovat skupinu, ve které bude prahová hodnota fungovat. To znamená, že minimálně jedno kolo výměny v decentralizované síti bude muset počkat, a vzhledem k tomu, že vygenerovaný rand je například nezbytný ve hrách, téměř v reálném čase, znamená to, že v této fázi je možná sabotáž protokolu a výhody systému prahových hodnot jsou ztraceny. Tento problém je již jednodušší než předchozí, ale stále vyžaduje vypracování samostatného postupu pro vytváření prahových skupin, které bude nutné ekonomicky chránit prostřednictvím vkladů a výběrů finančních prostředků (srážení) od účastníků, kteří nedodržují protokol. Ověření BLS s přijatelnou úrovní zabezpečení se také jednoduše nehodí například do standardní transakce EOS nebo Ethereum – na ověření prostě není dostatek času. Kód smlouvy je WebAssembly nebo EVM, spouštěný virtuálním strojem. Kryptografické funkce nejsou (zatím) nativně implementovány a fungují desítkykrát pomaleji než běžné kryptografické knihovny. Mnoho protokolů nesplňuje požadavky jednoduše na základě objemu klíče, například 1024 a 2048 bitů pro RSA, 4-8krát větší než standardní transakční podpis v bitcoinech a ethereu.

Svou roli hraje také přítomnost implementací v různých programovacích jazycích - kterých je málo, zejména u nových protokolů. Možnost s integrací do konsensu vyžaduje napsání protokolu v jazyce platformy, takže budete muset hledat kód v Go for goth, v Rust pro Parity, v C++ pro EOS. Každý bude muset hledat kód JavaScript, a protože JavaScript a kryptografie nejsou nijak zvlášť blízcí přátelé, pomůže WebAssembly, které se nyní definitivně hlásí k dalšímu důležitému internetovému standardu.

Závěr

Doufám, že v předchozí článek Podařilo se mi vás přesvědčit, že generování náhodných čísel na blockchainu je kritické pro mnoho aspektů života decentralizovaných sítí, a tímto článkem jsem ukázal, že tento úkol je extrémně ambiciózní a obtížný, ale dobrá řešení již existují. Obecně platí, že konečný návrh protokolu je možný pouze po provedení masivních testů, které berou v úvahu všechny aspekty od nastavení až po emulaci chyb, takže je nepravděpodobné, že byste našli hotové recepty v týmových whitepaperech a článcích, a my je rozhodně nenajdeme během příštího roku nebo dvou se rozhodněte a napište „udělejte to takto, přesně správně“.

Sbohem, pro naše PVRB ve vyvíjeném blockchainu Haya, jsme se rozhodli pro použití prahových BLS podpisů, plánujeme implementovat PVRB na konsensuální úrovni, protože ověření v chytrých kontraktech s přijatelnou úrovní zabezpečení zatím není možné. Je možné, že použijeme dvě schémata najednou: za prvé drahé tajné sdílení k vytvoření dlouhodobého random_seed a poté jej použijeme jako základ pro vysokofrekvenční náhodné generování pomocí deterministických prahových BLS signatur, možná se omezíme pouze na jedno ze schémat. Bohužel nelze předem říci, jaký bude protokol, jediné dobré je, že stejně jako ve vědě, i v inženýrských problémech je výsledkem také negativní výsledek a každý nový pokus o vyřešení problému je dalším krokem pro výzkum všech zúčastněných na problému. Abychom vyhověli obchodním požadavkům, řešíme konkrétní praktický problém – poskytování herních aplikací spolehlivým zdrojem entropie, takže musíme věnovat pozornost i samotnému blockchainu, zejména otázkám finality řetězce a správy sítě.

A i když zatím v blockchainech nevidíme prokázaný odolný PVRB, který by byl dostatečně dlouho používán na to, aby byl testován reálnými aplikacemi, vícenásobnými audity, zátěžemi a samozřejmě reálnými útoky, ale množství možných cest potvrzuje, že řešení existuje, a který z těchto algoritmů nakonec problém vyřeší. Rádi se podělíme o výsledky a poděkujeme ostatním týmům, které na tomto problému také pracují, za články a kód, který inženýrům umožní dvakrát nešlápnout na stejné hrábě.

Takže, když potkáte programátora, který navrhuje decentralizované náhodné, buďte pozorní a starostliví a v případě potřeby poskytněte psychologickou pomoc :)

Zdroj: www.habr.com