Bevezetés

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

Ahogyan a kriptográfiából származó abszolút erős titkosítás koncepciója, a valódi „nyilvánosan ellenőrizhető véletlenszerű jeladó” (továbbiakban PVRB) protokollok csak arra törekednek, hogy a lehető legközelebb kerüljenek az ideális sémához, mert valós hálózatokban nem alkalmazható tiszta formájában: szigorúan egy bitben kell megegyezni, sok körnek kell lennie, és minden üzenetnek tökéletesen gyorsnak és mindig kézbesítettnek kell lennie. Természetesen ez nem így van a valódi hálózatokban. Ezért, amikor a PVRB-ket speciális feladatokra tervezzük a modern blokkláncokban, amellett, hogy az ebből eredő véletlenszerűség és kriptográfiai erősség nem kontrollálható, számos pusztán építészeti és technikai probléma is felmerül.

A PVRB esetében maga a blokklánc lényegében egy kommunikációs közeg, amelyben üzenetek = tranzakciók. Ez lehetővé teszi a részleges elvonatkoztatást a hálózati problémáktól, az üzenetek kézbesítésének elmaradásától, a köztes szoftverrel kapcsolatos problémáktól - mindezeket a kockázatokat a decentralizált hálózat vállalja, és a PVRB számára a fő értéke az, hogy nem tud visszavonni vagy megrontani egy már elküldött tranzakciót - ez ne engedjék meg a résztvevőknek, hogy megtagadják a protokollban való részvételt, kivéve, ha sikeres támadást hajtanak végre a konszenzus ellen. Ez a biztonsági szint elfogadható, ezért a PVRB-nek pontosan olyan mértékben kell ellenállnia a résztvevők összejátszásának, mint a fő blokklánc-láncnak. Ez arra is utal, hogy a PVRB-nek a konszenzus részének kell lennie, ha a hálózat megegyezik a fő blokkláncban, még akkor is, ha az egyetlen tisztességes eredő véletlenben is egyetért. Vagy a PVRB egyszerűen egy intelligens szerződéssel megvalósított önálló protokoll, amely aszinkron módon működik a blokklánc és a blokkok tekintetében. Mindkét módszernek megvannak a maga előnyei és hátrányai, és a választás közöttük rendkívül nem triviális.

A PVRB megvalósításának két módja

Ismertessen meg részletesebben a PVRB megvalósításának két lehetőségét - az önálló verziót, amely a blokklánctól független intelligens szerződéssel működik, és a protokollba épített konszenzusba integrált verziót, amely szerint a hálózat megállapodik a blokkláncról és a beszámítandó tranzakciók. Minden esetben a népszerű blokklánc-motorokra gondolok: az Ethereumra, az EOS-re és mindazokra, amelyek hasonlóak az intelligens szerződések tárolására és feldolgozására.

Önálló szerződés

Ebben a verzióban a PVRB egy intelligens szerződés, amely elfogadja a véletlenszerű gyártók (továbbiakban: RP) tranzakcióit, feldolgozza azokat, egyesíti az eredményeket, és ennek eredményeként elér egy bizonyos értéket, amelyet bármely felhasználó megkaphat ebből a szerződésből. Ezt az értéket nem lehet közvetlenül a szerződésben tárolni, hanem csak olyan adatokkal ábrázolható, amelyekből a kapott véletlennek csak egy értéke határozható meg. Ebben a sémában az RP-k a blokklánc felhasználói, és bárki részt vehet a generálási folyamatban.

Az önálló szerződéses lehetőség jó:

• hordozhatóság (a szerződések áthúzhatók a blokkláncról a blokkláncra)
• egyszerű megvalósítás és tesztelés (a szerződéseket könnyű megírni és tesztelni)
• kényelem a gazdasági sémák megvalósításában (könnyű saját token elkészítése, amelynek logikája a PVRB céljait szolgálja)
• a már működő blokkláncokon való indítás lehetősége

Ennek is vannak hátrányai:

• erős korlátozások a számítási erőforrásokra, a tranzakciók mennyiségére és a tárhelyre vonatkozóan (más szóval, cpu/mem/io)
• a szerződésen belüli műveletekre vonatkozó korlátozások (nem minden utasítás érhető el, nehéz külső könyvtárakat csatlakoztatni)
• képtelenség gyorsabban megszervezni az üzenetküldést, mint ahogy a tranzakciók szerepelnek a blokkláncban

Ez az opció olyan PVRB megvalósítására alkalmas, amelyet meglévő hálózaton kell futtatni, nem tartalmaz bonyolult titkosítást és nem igényel nagyszámú interakciót.

Konszenzus-integrált

Ebben a verzióban a PVRB a blokklánc csomópont kódjában van megvalósítva, beépítve vagy párhuzamosan fut a blokklánc csomópontok közötti üzenetváltással. A protokoll eredményeit közvetlenül az előállított blokkokba írják, és a protokoll üzeneteket a p2p hálózaton keresztül küldik a csomópontok között. Mivel a protokoll blokkokban írandó számokat eredményez, a hálózatnak konszenzusra kell jutnia ezekről. Ez azt jelenti, hogy a PVRB üzeneteket a tranzakciókhoz hasonlóan a csomópontoknak kell érvényesíteniük, és blokkokban kell szerepelniük, hogy bármely hálózati résztvevő ellenőrizhesse a PVRB protokollnak való megfelelést. Ez automatikusan elvezet bennünket a kézenfekvő megoldáshoz – ha a hálózat konszenzusban állapodik meg egy blokkról és a benne lebonyolított tranzakciókról, akkor a PVRB-nek a konszenzus része kell legyen, nem pedig egy önálló protokoll. Ellenkező esetben előfordulhat, hogy egy blokk konszenzusos szempontból érvényes, de a PVRB protokollt nem követik, és PVRB szempontból a blokk nem fogadható el. Tehát ha a „konszenzusba integrált” opciót választják, a PVRB a konszenzus fontos részévé válik.

Amikor a PVRB implementációit hálózati konszenzus szinten írjuk le, semmi esetre sem kerülhetjük el a véglegesség kérdéseit. A véglegesség egy olyan mechanizmus, amelyet a determinisztikus konszenzusokban használnak, és egy blokkot (és a hozzá vezető láncot) véglegesít, és soha nem dobják el, még akkor sem, ha párhuzamos elágazás történik. Például a Bitcoinban nincs ilyen mechanizmus - ha egy nagyobb összetettségű láncot tesz közzé, az minden kevésbé összetettet helyettesít, függetlenül a láncok hosszától. Az EOS-ben pedig például a végsők az úgynevezett Last Irreversible Blocks, amelyek átlagosan 432 blokkonként jelennek meg (12*21 + 12*15, előszavazás + előzetes commit). Ez a folyamat lényegében a blokkgyártók (a továbbiakban: BP) 2/3 aláírására vár. Amikor olyan villák jelennek meg, amelyek régebbiek az utolsó LIB-nél, egyszerűen eldobják őket. Ez a mechanizmus lehetővé teszi annak garantálását, hogy a tranzakció bekerüljön a blokkláncba, és soha nem kerül visszaállításra, függetlenül attól, hogy milyen erőforrásokkal rendelkezik a támadó. Ezenkívül az utolsó blokkok 2/3 BP által aláírt blokkok a Hyperledger, a Tendermint és más pBFT-alapú konszenzusokban. Ezenkívül érdemes a véglegességet biztosító protokollt a konszenzus kiegészítéseként elkészíteni, mivel ez aszinkron módon működhet a blokkok előállításával és közzétételével. Itt van egy jó cikk az Ethereumban való véglegességről.

A véglegesség rendkívül fontos a felhasználók számára, akik enélkül egy „kettős költés” ​​támadás áldozatai lehetnek, ahol a BP „tartja” a blokkokat, és közzéteszi azokat, miután a hálózat „látott” egy jó tranzakciót. Ha nincs véglegesség, akkor a közzétett fork a blokkot egy „jó” tranzakcióval helyettesíti egy másikkal, „rossz” elágazásból, amelyben ugyanazt a pénzt utalják át a támadó címére. A PVRB esetében a véglegességre vonatkozó követelmények még szigorúbbak, mivel a PVRB építési villái azt jelentik, hogy a támadó több véletlenszerű lehetőséget készíthet elő, hogy a legjövedelmezőbbet publikálja, és az esetleges támadás idejének korlátozása jó megoldás.

Ezért a legjobb megoldás az, ha a PVRB-t és a véglegességet egy protokollba egyesítjük - ekkor a véglegesített blokk = véglegesített véletlen, és pontosan ezt kellett kapnunk. Mostantól a játékosok N másodpercen belül garantált véletlenszerűséget kapnak, és biztosak lehetnek abban, hogy nem lehet visszaforgatni vagy újra lejátszani.

A konszenzusba integrált lehetőség jó:

• aszinkron megvalósítás lehetősége a blokkok előállításával kapcsolatban - a blokkok a szokásos módon készülnek, de ezzel párhuzamosan működhet a PVRB protokoll, amely nem produkál minden blokkra véletlenszerűséget
• még a nehéz kriptográfia megvalósításának képessége az intelligens szerződésekre vonatkozó korlátozások nélkül
• az üzenetváltás gyorsabb megszervezésének képessége, mint a tranzakciók a blokkláncban, például a protokoll egy része működhet a csomópontok között anélkül, hogy az üzeneteket elosztaná a hálózaton

Ennek is vannak hátrányai:

• Nehézségek a tesztelés és a fejlesztés során – emulálnia kell a hálózati hibákat, a hiányzó csomópontokat, a hálózati kemény villákat
• Az implementációs hibákhoz hálózati hardfork szükséges

A PVRB megvalósításának mindkét módszerének joga van az élethez, de az intelligens szerződéseken való megvalósítás a modern blokkláncokban még mindig meglehetősen korlátozott a számítási erőforrások terén, és a komoly kriptográfiára való átállás gyakran egyszerűen lehetetlen. És komoly kriptográfiára lesz szükségünk, amint azt alább bemutatjuk. Bár ez a probléma egyértelműen átmeneti, sok probléma megoldásához komoly kriptográfiára van szükség a szerződésekben, és ez fokozatosan megjelenik (például a zkSNARK-ok rendszerszerződései az Ethereumban)

Az átlátható és megbízható protokoll üzenetküldő csatornát biztosító Blockchain ezt nem teszi meg ingyen. Minden decentralizált protokollnak figyelembe kell vennie a Sybil támadás lehetőségét, bármilyen műveletet több fiók összehangolt erői is végrehajthatnak, ezért tervezéskor figyelembe kell venni, hogy a támadók tetszőleges számú protokollt hozhatnak létre. az összejátszásban fellépő résztvevők.

PVRB és blokkváltozók.

Nem hazudtam, amikor azt mondtam, hogy még senki sem implementált jó PVRB-t, amelyet sok szerencsejáték-alkalmazás tesztelt, blokkláncokban. Akkor honnan származik ennyi szerencsejáték-alkalmazás az Ethereum és az EOS rendszeren? Ez engem éppúgy meglep, mint téged, honnan szereztek ennyi „tartós” randomot egy teljesen determinisztikus környezetben?

A véletlenszerűség elérésének kedvenc módja a blokkláncban az, hogy valamilyen „megjósolhatatlan” információt veszünk ki a blokkból, és ezek alapján véletlenszerűt készítünk – egyszerűen egy vagy több érték kivonatozásával. Jó cikk az ilyen rendszerek problémáiról itt. A blokkban lévő „kiszámíthatatlan” értékek bármelyikét felveheti, például a blokk hash-ét, a tranzakciók számát, a hálózat összetettségét és egyéb, előre ismeretlen értékeket. Ezután kivonatolja őket, egy vagy több, és elméletileg valódi véletlenszerűséget kell kapnia. Még azt is hozzáteheted a papírhoz, hogy a sémád "utólagos kvantumbiztos" (mivel vannak kvantumbiztos hash függvények :)).

De sajnos még a kvantum utáni biztonságos kivonatok sem elegendőek. A titok a PVRB követelményeiben rejlik, hadd emlékeztesselek rájuk az előző cikkből:

1. Az eredménynek bizonyíthatóan egyenletes eloszlásúnak kell lennie, azaz bizonyíthatóan erős kriptográfián kell alapulnia.
2. Az eredmény egyetlen bitjét sem lehet szabályozni. Emiatt nem lehet előre megjósolni az eredményt.
3. Nem szabotálhatja a generálási protokollt úgy, hogy nem vesz részt a protokollban, vagy túlterheli a hálózatot támadási üzenetekkel
4. A fentiek mindegyikének ellenállónak kell lennie a tisztességtelen protokoll résztvevőinek megengedett számú (például a résztvevők 1/3-a) összejátszásával szemben.

Ebben az esetben csak az 1. követelmény teljesül, a 2. feltétel nem teljesül. A blokkból kiszámíthatatlan értékek kivonásával egyenletes eloszlást és jó véletleneket kapunk. De a BP-nek legalább lehetősége van „közzé tenni a blokkot vagy sem”. Így a BP legalább KÉT véletlenszerű lehetőség közül választhat: a „saját” és azt, amelyik akkor derül ki, ha valaki más készíti el a blokkot. A BP előre „kitalálhatja”, hogy mi történik, ha közzétesz egy blokkot, és egyszerűen úgy dönt, hogy megteszi vagy sem. Így például „páros-páratlan” vagy „piros/fekete” rulettben csak akkor tehet közzé blokkot, ha nyer. Ez azt a stratégiát is megvalósíthatatlanná teszi, hogy például egy blokk-kivonatot „a jövőből” használjunk. Ebben az esetben azt mondják, hogy „véletlenszerű lesz, amelyet az aktuális adatok és egy jövőbeli blokk hash-ének kivonatolása útján kapunk, például N + 42 magassággal, ahol N az aktuális blokk magassága. Ez egy kicsit megerősíti a sémát, de lehetővé teszi a BP-nek, hogy a jövőben is döntsön, hogy megtartja a blokkot vagy közzéteszi.

A BP szoftver ebben az esetben bonyolultabbá válik, de nem sokkal. Egyszerűen, amikor egy tranzakciót egy blokkban érvényesítünk és beépítünk egy gyors ellenőrzésre, hogy kiderüljön, lesz-e nyeremény, és esetleg kiválasztunk egy tranzakciós paramétert, hogy nagy valószínűséggel nyerjünk. Ugyanakkor szinte lehetetlen okos BP-t fogni az ilyen manipulációkhoz, minden alkalommal új címeket használhat, és apránként nyerhet anélkül, hogy gyanút kelt.

Tehát a blokkból származó információkat használó módszerek nem alkalmasak a PVRB univerzális megvalósítására. Korlátozott változatban a tétméretekre, a játékosok számára és/vagy a KYC regisztrációra vonatkozó korlátozásokkal (hogy egy játékos ne használjon több címet) ezek a sémák működhetnek kis játékoknál, de semmi több.

PVRB és commit-reveal.

Oké, a kivonatolásnak és legalábbis a blokk hash és egyéb változók viszonylagos kiszámíthatatlanságának köszönhetően. Ha megoldja az élvonalbeli bányászok problémáját, akkor valami alkalmasabbat kell szereznie. Adjunk hozzá felhasználókat ebbe a sémába – hagyjuk, hogy ők is befolyásolják a véletlenszerűséget: a technikai támogatás bármely munkatársa megmondja, hogy az informatikai rendszerekben a legvéletlenebb dolog a felhasználók tevékenysége :)

Az a naiv séma, amikor a felhasználók egyszerűen véletlen számokat küldenek, és az eredményt például az összegük hash-jeként számítják ki, nem megfelelő. Ebben az esetben az utolsó játékos a saját véletlenszerű választásával szabályozhatja, hogy mi lesz az eredmény. Ez az oka annak, hogy a nagyon széles körben használt commit-reveal mintát alkalmazzák. A résztvevők először kivonatokat küldenek véletlenszerűségeikből (commit), majd maguk nyitják meg a véletleneket (felfed). A „felfedezési” fázis csak a szükséges commitok összegyűjtése után kezdődik, így a résztvevők pontosan azt a véletlenszerű hash-t küldhetik el, amelyből korábban küldtek. Most tegyük össze mindezt egy blokk paramétereivel, és jobb, mint a jövőből vett blokk (a véletlenszerűség csak az egyik jövőbeli blokkban található), és íme, kész a véletlenszerűség! Mostantól bármelyik játékos befolyásolja a keletkező véletlenszerűséget, és „le tudja győzni” a rosszindulatú BP-t, ha felülírja azt a saját, előre ismeretlen véletlenszerűségével... A protokoll szabotálása ellen úgy is védelmet nyújthat, hogy nem nyitja meg a felfedés szakaszában – egyszerűen azzal, hogy az ügylethez bizonyos összeget – óvadékot – kell kötni, amely csak a feltárási eljárás során kerül visszafizetésre. Ebben az esetben az elköteleződés és a felfedés elmulasztása veszteséges.

Jó próbálkozás volt, és vannak ilyen sémák a játékra szánt DApp-okban is, de sajnos ez megint nem elég. Most már nem csak a bányász, hanem a protokoll bármely résztvevője is befolyásolhatja az eredményt. Továbbra is lehetséges magát az értéket szabályozni, kisebb változékonysággal és költséggel, de a bányászhoz hasonlóan, ha a sorsolás eredménye értékesebb, mint a PVRB protokollban való részvétel díja, akkor a véletlenszerű A -producer(RP) eldöntheti, hogy felfedje-e, és továbbra is legalább két véletlenszerű lehetőség közül választhat.
De lehetővé vált, hogy megbüntessék azokat, akik elkövetik, és nem fedik fel, és ez a rendszer jól fog jönni. Komoly előnye az egyszerűsége – a komolyabb protokollokhoz sokkal erőteljesebb számítások szükségesek.

PVRB és determinisztikus aláírások.

Van egy másik módja annak, hogy az RP-t egy ál-véletlen szám megadására kényszerítsük, amelyet nem befolyásolhat, ha „előképe” van ellátva - ez egy determinisztikus aláírás. Az ilyen aláírás például RSA, és nem ECS. Ha az RP-nek van egy kulcspárja: RSA és ECC, és egy bizonyos értéket ír alá a privát kulcsával, akkor RSA esetén EGY ÉS CSAK EGY aláírást kap, ECS esetén pedig tetszőleges számú aláírást generálhat. különböző érvényes aláírások. Az ECS-aláírás létrehozásakor ugyanis az aláíró által választott véletlenszerű szám kerül felhasználásra, és ez tetszőleges módon választható, lehetőséget adva az aláírónak, hogy válasszon egyet a több aláírás közül. RSA esetén: „egy bemeneti érték” + „egy kulcspár” = „egy aláírás”. Lehetetlen megjósolni, hogy egy másik RP milyen aláírást kap, ezért determinisztikus aláírásokkal rendelkező PVRB szervezhető több, azonos értéket aláíró résztvevő RSA aláírásának kombinálásával. Például az előző véletlenszerű. Ez a rendszer sok erőforrást takarít meg, mert Az aláírások egyrészt a protokoll szerinti helyes viselkedés megerősítése, másrészt a véletlenszerűség forrása.

A rendszer azonban még determinisztikus aláírások esetén is sebezhető az „utolsó szereplő” problémával szemben. Az utolsó résztvevő továbbra is eldöntheti, hogy közzéteszi-e az aláírást vagy sem, így ellenőrizheti az eredményt. Módosíthatja a sémát, blokkkivonatokat adhat hozzá, köröket tehet úgy, hogy az eredményt ne lehessen előre megjósolni, de mindezek a technikák, még sok módosítást is figyelembe véve, továbbra is megoldatlanul hagyják az egyik résztvevő kollektívára gyakorolt ​​befolyásának problémáját. megbízhatatlan környezetet eredményez, és csak gazdasági és időbeli korlátok mellett működhet. Ráadásul az RSA kulcsok mérete (1024 és 2048 bit) meglehetősen nagy, és a blokklánc-tranzakciók mérete rendkívül fontos paraméter. Úgy tűnik, nincs egyszerű módja a probléma megoldásának, menjünk tovább.

PVRB és titkos megosztási rendszerek

A kriptográfiában vannak olyan sémák, amelyek lehetővé teszik a hálózat számára, hogy egy és csak egy PVRB értékben állapodjon meg, miközben az ilyen sémák ellenállnak egyes résztvevők rosszindulatú tevékenységeinek. Az egyik hasznos protokoll, amellyel érdemes megismerkedni, Shamir titkos megosztási rendszere. Arra szolgál, hogy egy titkot (például egy titkos kulcsot) több részre osszanak fel, és ezeket a részeket N résztvevőnek osszák szét. A titok úgy van elosztva, hogy N-ből M rész elegendő a visszanyeréséhez, és ez tetszőleges M rész lehet. Ha ujjakon, akkor egy ismeretlen funkciójú grafikon birtokában a résztvevők pontot cserélnek a grafikonon, és M pont vétele után a teljes függvény visszaállítható.
Jó magyarázat található benne wiki de a játék vele gyakorlatilag azért hasznos, hogy fejben lejátssza a protokollt demó oldalon.

Ha az FSSS (Fiat-Shamir titkos megosztás) séma tiszta formájában alkalmazható lenne, az egy elpusztíthatatlan PVRB lenne. A legegyszerűbb formájában a protokoll így nézhet ki:

• Minden résztvevő létrehozza a saját véletlenszerűségét, és kiosztja belőle a megosztásokat a többi résztvevőnek
• Minden résztvevő felfedi a saját részét a többi résztvevő titkaiból
• Ha egy résztvevőnek több mint M részvénye van, akkor ennek a résztvevőnek a száma kiszámítható, és ez egyedi lesz, függetlenül a feltárt résztvevők halmazától
• A feltárt véletlenek kombinációja a kívánt PVRB

Itt az egyéni résztvevő már nem befolyásolja a protokoll eredményeit, kivéve azokat az eseteket, amikor a véletlenszerűségi feltárási küszöb elérése csak tőle függ. Ezért ez a protokoll, ha van a protokollon dolgozó és elérhető RP-k szükséges aránya, működik, megvalósítja a kriptográfiai erősség követelményeit, és ellenáll az „utolsó szereplő” problémának.

Ez egy ideális megoldás lehet, ezt a Fiat-Shamir titkos megosztáson alapuló PVRB-sémát például a cikkben ismertetjük ezt cikk. De amint fentebb említettük, ha megpróbálja közvetlenül alkalmazni a blokkláncban, technikai korlátok jelennek meg. Íme egy példa a protokoll tesztimplementációjára az EOS intelligens szerződésben, és annak legfontosabb részére - a közzétett megosztási résztvevő ellenőrzésére: kód. A kódból látható, hogy a bizonyítás érvényesítéséhez több skaláris szorzás szükséges, és a felhasznált számok nagyon nagyok. Meg kell érteni, hogy a blokkláncokban az ellenőrzés abban a pillanatban történik, amikor a blokkgyártó feldolgozza a tranzakciót, és általában minden résztvevőnek könnyen ellenőriznie kell a protokoll helyességét, így az ellenőrzési funkció sebességére vonatkozó követelmények nagyon komolyak. . Ennél a lehetőségnél az opció hatástalannak bizonyult, mivel az ellenőrzés nem fért bele a tranzakciós limitbe (0.5 másodperc).

Az ellenőrzés hatékonysága az egyik legfontosabb követelmény általában a blokkláncban található fejlett kriptográfiai sémák használatához. Bizonyítások készítése, üzenetek készítése - ezek az eljárások leválaszthatók a láncról és végrehajthatók nagy teljesítményű számítógépeken, de az ellenőrzést nem lehet megkerülni - ez egy másik fontos követelmény a PVRB-vel szemben.

PVRB és küszöb aláírások

Miután megismerkedtünk a titkos megosztási sémával, a protokollok egész osztályát fedeztük fel, amelyeket a „küszöb” kulcsszó egyesít. Ha bizonyos információk nyilvánosságra hozatalához N közül M becsületes résztvevő részvétele szükséges, és a becsületes résztvevők halmaza N tetszőleges részhalmaza lehet, akkor „küszöb” sémákról beszélünk. Ők teszik lehetővé, hogy az „utolsó szereplő” problémájával foglalkozzunk, most, ha a támadó nem fedi fel a titok részét, egy másik, őszinte résztvevő megteszi helyette. Ezek a sémák egyetlen jelentésben tesznek lehetővé megállapodást, még akkor is, ha a protokollt a résztvevők egy része szabotálja.

A determinisztikus aláírások és a küszöbsémák kombinációja lehetővé tette egy nagyon kényelmes és ígéretes séma kidolgozását a PVRB megvalósításához - ezek determinisztikus küszöb aláírások. Itt cikk a küszöb-aláírások különféle felhasználásairól, és itt van egy másik jó longread a Dash-től.

Az utolsó cikk a BLS aláírásokat írja le (a BLS a Boneh-Lynn-Shacham, itt cikk), amelyek a programozók számára nagyon fontos és rendkívül kényelmes minőséget képviselnek - a nyilvános, titkos, nyilvános kulcsok és BLS-aláírások egyszerű matematikai műveletekkel kombinálhatók egymással, miközben ezek kombinációi továbbra is érvényes kulcsok és aláírások maradnak, lehetővé téve sokféle egyszerű összesítést. aláírásokat egy és sok nyilvános kulcsot egybe. Ezenkívül determinisztikusak, és ugyanazt az eredményt adják ugyanazon bemeneti adatokra. Ennek a minőségnek köszönhetően a BLS-aláírások kombinációi önmagukban is érvényes kulcsok, ami lehetővé teszi egy olyan opció megvalósítását, amelyben N-ből M résztvevő egy és csak egy olyan aláírást állít elő, amely determinisztikus, nyilvánosan ellenőrizhető és kiszámíthatatlan mindaddig, amíg az Mth meg nem nyitja. résztvevő .

A küszöbérték BLS-aláírásokkal rendelkező sémában minden résztvevő aláír valamit a BLS segítségével (például az előző véletlenszerűt), és a közös küszöb-aláírás a kívánt véletlen. A BLS-aláírások kriptográfiai tulajdonságai kielégítik a véletlenszerű minőség követelményeit, a küszöbrész véd az „utolsó szereplő” ellen, a kulcsok egyedi kombinálhatósága pedig sokkal érdekesebb algoritmusok megvalósítását teszi lehetővé, amelyek lehetővé teszik például a protokollüzenetek hatékony aggregálását. .

Tehát, ha PVRB-t épít a blokkláncára, akkor nagy valószínűséggel a BLS küszöb-aláírási séma lesz a vége, számos projekt már használja. Például DFinity (itt benchmark, amely megvalósítja az áramkört, és itt példa az ellenőrizhető titkos megosztás megvalósítására), vagy a Keep.network (itt van a véletlenszerű jeladójuk). sárga papír, De példa protokollt kiszolgáló intelligens szerződés).

A PVRB megvalósítása

Sajnos még mindig nem látunk olyan kész protokollt a PVRB blokkláncokban implementálva, amely bizonyította volna biztonságát és stabilitását. Annak ellenére, hogy maguk a protokollok készen állnak, technikailag nem könnyű alkalmazni őket a meglévő megoldásokra. A központosított rendszerek esetében a PVRB-nek nincs értelme, és a decentralizáltak szigorúan korlátozottak minden számítási erőforrásban: CPU, memória, tároló, I/O. A PVRB tervezése különböző protokollok kombinációja annak érdekében, hogy valami olyasmit hozzunk létre, amely megfelel legalább néhány életképes blokklánc minden követelményének. Az egyik protokoll hatékonyabban számol, de több üzenetet igényel az RP-k között, míg a másik nagyon kevés üzenetet igényel, de a bizonyítás elkészítése több tíz percet, de akár órákat is igénybe vehet.

Felsorolom azokat a tényezőket, amelyeket figyelembe kell vennie a minőségi PVRB kiválasztásakor:

• Kriptográfiai erősség. A PVRB-nek szigorúan elfogulatlannak kell lennie, egyetlen bit vezérlésére sem. Egyes sémákban ez nem így van, ezért hívjon titkosítót
• Az „utolsó szereplő” probléma. A PVRB-nek ellenállónak kell lennie azokkal a támadásokkal szemben, ahol egy vagy több RP-t irányító támadó két kimenet közül választhat.
• Protokollszabotázs probléma. A PVRB-dnek ellenállónak kell lennie azokkal a támadásokkal szemben, ahol egy vagy több RP-t irányító támadó dönti el, hogy véletlenszerű-e vagy sem, és garantált, vagy adott valószínűséggel befolyásolhatja ezt.
• Üzenetek száma probléma. Az RP-knek minimális üzenetet kell küldeniük a blokkláncnak, és a lehető legnagyobb mértékben kerülniük kell a szinkron műveleteket, például az olyan helyzeteket, mint például: „Küldtem néhány információt, egy adott résztvevő válaszát várom”. A p2p hálózatokban, különösen a földrajzilag szétszórt hálózatokban, nem szabad gyors reagálásra számítani
• A számítási komplexitás problémája. A PVRB on-chain bármely szakaszának ellenőrzése rendkívül egyszerű legyen, mivel azt a hálózat összes teljes kliense végzi. Ha a megvalósítás okos szerződéssel történik, akkor a sebességi követelmények nagyon szigorúak
• A hozzáférhetőség és az életszerűség problémája. A PVRB-nek törekednie kell arra, hogy ellenálló legyen az olyan helyzetekben, amikor a hálózat egy része elérhetetlenné válik egy ideig, és az RP egy része egyszerűen leáll.
• A megbízható beállítás és a kezdeti kulcselosztás problémája. Ha a PVRB a protokoll elsődleges beállítását használja, akkor ez egy külön nagy és komoly történet. Itt példa. Ha a résztvevőknek meg kell adniuk egymásnak a kulcsaikat a protokoll elindítása előtt, az is probléma, ha a résztvevők összetétele megváltozik
• Fejlesztési problémák. A könyvtárak elérhetősége a szükséges nyelveken, biztonságuk és teljesítményük, nyilvánosság, komplex tesztek stb.

Például a threshold BLS aláírásokkal van egy jelentős probléma – a munka megkezdése előtt a résztvevőknek kulcsokat kell kiosztaniuk egymásnak, és meg kell szervezniük egy csoportot, amelyen belül a küszöb működni fog. Ez azt jelenti, hogy egy decentralizált hálózatban legalább egy cserekört várni kell, és mivel a generált rand például játékokban szükséges, szinte valós időben, ez azt jelenti, hogy ebben a szakaszban lehetséges a protokoll szabotálása. , és a küszöbrendszer előnyei elvesznek. Ez a probléma már egyszerűbb, mint a korábbiak, de még külön eljárás kidolgozását igényli a küszöbcsoportok kialakítására, amelyeket gazdaságosan kell majd védeni, betétekkel és pénzkivonásokkal (levágással) azoktól a résztvevőktől, akik nem követik az előírást. jegyzőkönyv. Ezenkívül az elfogadható biztonsági szinttel rendelkező BLS-ellenőrzés egyszerűen nem illeszkedik például egy szabványos EOS- vagy Ethereum-tranzakcióba - egyszerűen nincs elég idő az ellenőrzésre. A szerződés kódja WebAssembly vagy EVM, amelyet egy virtuális gép hajt végre. A kriptográfiai funkciók natív módon (még) nincsenek implementálva, és tízszer lassabban működnek, mint a hagyományos kriptográfiai könyvtárak. Sok protokoll nem felel meg a követelményeknek pusztán a kulcs mennyisége alapján, például 1024 és 2048 bit az RSA esetében, ami 4-8-szor nagyobb, mint a Bitcoin és az Ethereum szabványos tranzakciós aláírása.

A különböző programozási nyelveken való implementációk jelenléte is szerepet játszik - amiből kevés van, különösen az új protokollok esetében. A konszenzusba integrált opcióhoz protokollt kell írni a platform nyelvén, így a kódot Go for geth-ben, Rust for Parity-ben, C++-ban EOS-ban kell keresni. Mindenkinek meg kell keresnie a JavaScript-kódot, és mivel a JavaScript és a kriptográfia nem különösebben közeli barátság, a WebAssembly segít, amely immár határozottan a következő fontos internetes szabványnak vallja magát.

Következtetés

Remélem az előzőben cikk Sikerült meggyőznöm, hogy a blokkláncon véletlen számok generálása kritikus fontosságú a decentralizált hálózatok életének számos területén, és ezzel a cikkel megmutattam, hogy ez a feladat rendkívül ambiciózus és nehéz, de már léteznek jó megoldások. Általánosságban elmondható, hogy a protokoll végleges kialakítása csak hatalmas tesztek elvégzése után lehetséges, amelyek minden szempontot figyelembe vesznek a beállítástól a hiba emulációig, így nem valószínű, hogy kész recepteket fog találni a csapatok tanulmányaiban és cikkeiben, és biztosan nem is fogunk. döntsd el a következő egy-két évben, és írd be: „Így csináld, pontosan helyesen”.

Viszlát, a PVRB-nknek a fejlesztés alatt álló blokkláncban Haya, a küszöbértékes BLS aláírások mellett döntöttünk, a PVRB konszenzusos szintű bevezetését tervezzük, mivel az intelligens szerződésekben elfogadható biztonsági szinttel még nem lehet hitelesíteni. Lehetséges, hogy egyszerre két sémát használunk: először a drága titkos megosztást a hosszú távú random_seed létrehozásához, majd ezt használjuk a nagyfrekvenciás véletlenszerű generálás alapjául determinisztikus küszöbértékű BLS aláírások segítségével. az egyik séma. Sajnos nem lehet előre megmondani, hogy mi lesz a protokoll, csak az a jó, hogy mint a tudományban, úgy a mérnöki problémáknál is negatív eredmény van, és minden újabb próbálkozás a probléma megoldására újabb lépést jelent a problémában érintettek kutatása. Az üzleti igények kielégítése érdekében egy konkrét gyakorlati problémát oldunk meg - a játékalkalmazások megbízható entrópiaforrással való ellátását, így magára a blokkláncra is figyelnünk kell, különös tekintettel a láncvégesség és a hálózatirányítás kérdéseire.

És bár még nem látunk bizonyítottan ellenálló PVRB-t a blokkláncokban, amelyet elég ideig használtak volna valódi alkalmazások, többszörös auditok, betöltések és természetesen valódi támadások általi teszteléshez, de a lehetséges utak száma megerősíti, hogy létezik megoldás, és ezek közül az algoritmusok közül melyik oldja meg végül a problémát. Örömmel megosztjuk az eredményeket, és köszönetet mondunk a többi csapatnak, akik szintén ezen a témán dolgoznak a cikkekért és a kódokért, amelyek lehetővé teszik a mérnökök számára, hogy ne lépjenek kétszer ugyanarra a rake-re.

Tehát ha egy decentralizált véletlenszerűséget tervező programozóval találkozol, légy figyelmes és gondoskodó, és szükség esetén adj pszichológiai segítséget :)

Forrás: will.com