Bevezetés

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

Ahogyan az abszolút ellenálló titkosítási koncepció esetében is, a valós "Nyilvánosan Ellenőrizhető Véletlenszerű Jelző" (PVRB) protokollok csak igyekeznek a lehető legjobban megközelíteni az ideális sémát, mivel a valós hálózatokban tiszta formájukban nem alkalmazhatók: szigorúan egy bitben kell megállapodni, sok körre van szükség, és minden üzenetet tökéletesen gyorsan kell kézbesíteni. Nyilvánvaló, hogy a valós hálózatokban ez nem így van. Ezért, a PVRB tervezése során a modern blockchainekhez, a megkapott véletlen és a kriptográfiai ellenállás mellett számos tisztán architekturális és technikai probléma is felmerül.

A blokklánc lényegében a PVRB kommunikációs közege, ahol az üzenetek tranzakciókként jelennek meg. Ez lehetővé teszi a hálózati problémákból, üzenetkihagyásokból és köztes szoftverproblémákból való részleges elvonatkoztatást — minden ilyen kockázatot a decentralizált hálózat vállal, és a legfőbb értéke a PVRB számára — hogy már elküldött tranzakciót visszavonni vagy elrontani nem lehet — ez megakadályozza, hogy a résztvevők visszautasítsák a protokollban való részvételt, hacsak nem hajtottak végre sikeres támadást a konszenzus ellen. Ez a biztonsági szint elfogadható, így a PVRB-nek meg kell felelnie a résztvevők összeesküvésével szembeni eltérő ellenállásnak, pont úgy, mint a blokklánc fő lánca. Ez azt is jelenti, hogy a PVRB-nek része kell, hogy legyen a konszenzusnak, ha a hálózat megállapodott a fő blokk láncról, akkor egyidejűleg egyet kell értenie a tisztességes véletlenszámra is. Vagy a PVRB egyszerűen egy önálló protokoll, amelyet okos szerződés valósít meg, asszinkron módon a blokklánchoz és a blokkokhoz viszonyítva. Mindkét módszernek vannak előnyei és hátrányai, és a választás közöttük rendkívül nem triviális.

Két módszer a PVRB megvalósítására

Részletesebben bemutatjuk a PVRB két megvalósítási módját — az önálló verziót, amely független, blokklánctól független okos szerződést használ, és a konszenzusba integráltat, amely a protokollba van beépítve, ahol a hálózat megállapodik a blokk láncról és a bevonásra kerülő tranzakciókról. Minden esetben a népszerű blokklánc motorokra fogok gondolni: Ethereum, EOS, és minden hasonló, az okos szerződések elhelyezésének és feldolgozásának módja szerint.

Önálló szerződés

Ebben a változatban a PVRB egy okosszerződés, amely a random-producer-ek (továbbiakban RP) tranzakcióit fogadja, feldolgozza őket, kombinálja az eredményeket, és végül egy olyan értéket kap, amelyet bármely felhasználó kinyerhet ebből a szerződésből. Ez az érték nem feltétlenül tárolódik közvetlenül a szerződésben, hanem csak olyan adatok formájában jelenik meg, amelyekből determinisztikusan egyetlen eredeti véletlenszám nyerhető. Ebben a rendszerben az RP a blokklánc felhasználói, és a generálási folyamatban bárki részt vehet.

Az önálló szerződés változata előnyös:

átjárhatóság (a szerződések átvihetők a blokkláncból a blokkláncba)
egyszerűség a megvalósításban és tesztelésben (a szerződések írása és tesztelése kényelmes)
gazdasági rendszerek megvalósításának kényelme (könnyen létrehozható a saját tokenje, amelynek logikája a PVRB céljait szolgálja)
a lehetőség, hogy már működő blokkláncokban indítsunk

De hátrányai is vannak:

erős korlátozások az erőforrások tekintetében számításoknál, tranzakciós mennyiség és tárolás (egyszerűbben fogalmazva cpu/mem/io)
korlátozások a szerződésen belüli műveletekre (nem minden utasítás érhető el, nehéz külső könyvtárakat csatlakoztatni)
nem lehetséges gyorsabb üzenetváltás megszervezése, mint ahogy a tranzakciók beillesztésre kerülnek a blokkláncba

Ez a változat alkalmas a PVRB megvalósítására, amelyet már létező hálózaton kell indítani, nem tartalmaz bonyolult kriptográfiát, és nem igényel nagy mennyiségű kölcsönhatást.

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 működik a blokklánc csomópontjai közötti üzenetváltással. A protokoll eredményei közvetlenül a létrehozott blokkokba kerülnek rögzítésre, míg a protokoll üzenetei p2p hálózaton keresztül küldésre kerülnek a csomópontok között. Mivel a protokoll eredményei számok, amelyeket a blokkokba kell rögzíteni, a hálózatnak konszenzusra kell jutnia ezekkel kapcsolatban. Ezért a PVRB üzeneteknek, akárcsak a tranzakcióknak, validálva kell lenniük a csomópontok által, és be kell kerülniük a blokkokba, hogy a hálózat bármely résztvevője validálni tudja a PVRB protokoll betartását. Ez automatikusan nyilvánvaló megoldáshoz vezet minket – ha a hálózat konszenzusra jut a blokkkal és annak tranzakcióival kapcsolatban, akkor a PVRB-nek a konszenzus fontos részének kell lennie, nem pedig egy különálló protokollnak. Különben előfordulhat, hogy a blokk érvényes a konszenzus szempontjából, de a PVRB protokollt nem tartják be, és a PVRB szempontjából a blokk nem fogadható el. Tehát ha a “konszenzus-integrált” változatot választják, a PVRB a konszenzus lényeges részévé válik.

A PVRB konszenzus szintű implementációinak leírásakor semmiképpen sem szabad figyelmen kívül hagyni a véglegesség kérdéseit. A véglegesség egy olyan mechanizmus, amelyet a determinisztikus konszenzusokban használnak, rögzítve egy blokkot (és a hozzá vezető láncot), amely végleges, és soha nem lesz elvetve, még akkor sem, ha párhuzamos fork jelenik meg. Például a Bitcoinban nincs ilyen mechanizmus – ha egy nagyobb nehézségű láncot publikálunk, az felváltja bármelyik kevesebb nehézségűt, függetlenül a láncok hosszától. Az EOS-ban a végleges blokkokat úgynevezett Utolsó Visszavonhatatlan Blokkoknak (Last Irreversible Blocks) nevezik, amelyek átlagosan 432 blokkanként jelennek meg (12*21 + 12*15, előzetes szavazás + előzetes kötelezettségvállalás). Ez a folyamat lényegében a block-producerek (BP) 2/3 aláírásának várakozása. A forkok, amelyek idősebbek, mint az utolsó LIB, egyszerűen elvetésre kerülnek. Ez a mechanizmus lehetővé teszi, hogy garantáljunk, hogy a tranzakció be van zárva a blokkláncba, és soha nem fog elvontatódni, bármilyen erőforrásokkal rendelkezzen is a támadó. Ezenkívül a végleges blokkok a Hyperledgerben, Tendermintben és más pBFT-alapú konszenzusokban a 2/3 BP által aláírt blokkok. cikk a végeredmény az Ethereum-ban.

A végeredmény rendkívül fontos a felhasználók számára, akik enélkül a "double spend" támadás áldozataivá válhatnak, amikor a BP "megtartja" a blokkokat, és azokat közzéteszi, miután a hálózat "látott" egy jó tranzakciót. Ha nincs végeredmény, akkor a közzétett fork felváltja a "jó" tranzakciót tartalmazó blokkot egy másikkal a "rossz" forkból, ahol ugyanaz az összeg átkerül a támadó címére. A PVRB esetén a végeredmény követelményei még szigorúbbá válnak, mivel a PVRB forkok készítése lehetőséget ad a támadónak, hogy több véletlen változatot készítsen azzal a céllal, hogy a számára legkedvezőbbet publikálja, és korlátozza a támadás idejét – ez egy jó megoldás.

Ezért a legjobb megoldás a PVRB és a végeredmény egy protokollba való egyesítése – ekkor a végleges blokk = végleges véletlen, ami pontosan az, amire szükség volt. Most a játékosok garantált véletlent kapnak N másodperc alatt, és biztosak lehetnek benne, hogy azt visszavonni vagy újrajátszani lehetetlen.

A consensus-integrált megoldás jó:

az aszinkron végrehajtás lehetőségével a blokkok előállításához képest – a blokkok a megszokott módon készülnek, de ezzel párhuzamosan a PVRB protokoll is működhet, amely nem minden blokkhoz termel véletleneket
a nehéz kriptográfiai megoldások implementálásának lehetőségével, anélkül, hogy a smart contractok által támasztott korlátok lépnének fel
a kommunikációs csere megszervezésének lehetőségével gyorsabban, mint ahogy a tranzakciók bekerülnek a blokkláncba, például a protokoll egy része a node-ok között működhet anélkül, hogy üzeneteket terjesztene a hálózaton

De hátrányai is vannak:

a tesztelés és fejlesztés nehézségeivel – hálózati hibák, elérhetetlen node-ok, hard fork-ok emulációját kell végezni
a megvalósítási hibák hard fork-ot követelnek meg a hálózaton

Mindkét PVRB implementálási módnak van létjogosultsága, de a modern blokkláncokban a smart contractok megvalósítása még mindig jelentősen korlátozott az erőforrások szempontjából, és bármilyen komolyabb kriptográfiai áttérés gyakran egyszerűen lehetetlen. A komoly kriptográfiára szükségünk lesz, ahogyan azt a továbbiakban be fogjuk mutatni. Bár ez a probléma egyértelműen átmeneti, a komoly kriptográfia a szerződésekben számos feladat megoldásához szükséges, és fokozatosan megjelenik (például a zkSNARKs rendszerszerződései az Ethereum-ban)

A blokklánc, amely átlátható és megbízható üzenetküldési csatornát biztosít a protokoll számára, nem ingyenes. Bármely decentralizált protokollnak figyelembe kell vennie a Sybil támadás lehetőségét, bármilyen cselekvést egyes fiókok számosával, összehangolt erővel lehet végrehajtani, ezért a tervezés során figyelembe kell venni a támadók lehetőségeit, akik tetszőleges számú résztvevőt képesek létrehozni a protokollban, akik összejátszanak.

PVRB és blokk változók.

Nem hazudtam, amikor azt mondtam, hogy jó PVRB, amelyet számos szerencsejáték-alkalmazás tesztelt, a blokkláncokban eddig még senki sem valósított meg. Honnan van akkor annyi szerencsejáték-alkalmazás az Ethereumon és az EOS-on? Ez engem ugyanúgy meglep, mint téged, hát honnan került elő ennyi „ellenálló” véletlenszám egy teljesen determinisztikus környezetben?

A blokkláncon történő véletlenszám-generálás kedvenc módja az, hogy valamilyen „megjósolhatatlan” információt veszünk a blokkból, és annak alapján generálunk véletlenszámot – egyszerűen hash-eljük egy vagy több értékét. Jó cikk a hasonló schémák problémáiról. ittVálaszthatunk valamilyen „megjósolhatatlan” értéket a blokkban, például a blokk hash-jét, a tranzakciók számát, a hálózat nehézségét és egyéb, előre nem látható értékeket. Ezeket ezután hash-eljük, egyet vagy többet, és elvileg igazi véletlenszámot kellene kapnunk. Még azt is hozzáadhatjuk a whitepaperhez, hogy az Ön terve „poszt-kvantum biztonságos” (hiszen léteznek kvantumbiztos hash függvények :)).

De sajnos még a poszt-kvantum biztonságú hash-ek sem elegendők. A titok a PVRB követelményeiben rejlik, emlékeztetek a korábbi cikkemben említettekre:

Az eredménynek bizonyíthatóan egyenletes eloszlásúnak kell lennie, azaz bizonyíthatóan ellenálló kriptográfián kell alapulnia.
Nem lehet ellenőrizni az eredmény egyetlen bitjét sem. Ennek következtében az eredmény előre nem tudható.
A generálási protokoll szabotálása nem lehetséges a protokollban való részvétel elmulasztásával vagy a hálózat túlterhelésével támadó üzenetek révén.
Mindezeknek ellenállónak kell lenniük a protokollban részt vevő becstelen résztvevők elfogadható számú összehangolt támadásaival szemben (például a résztvevők 1/3-a).

Ebben az esetben csak az 1. követelmény teljesül, a 2. viszont nem. Ha a blokkból előre nem látható értékeket hash-eljük, egyenletes eloszlást és jó véletlenszerűséget kapunk. De az BP-nek legalább van lehetősége "publikálni a blokkot, vagy sem". Így BP legalább választhat KÉT véletlenszerűség közül: a "saját" és a "más által létrehozott" opció közül. BP előre "meglesheti", hogy mi fog történni, ha publikálja a blokkot, és egyszerűen dönthet róla, hogy megteszi-e vagy sem. Így amikor például "páratlan-páros" vagy "piros/fekete" játékot játszik a rulettben, csak akkor publikálja a blokkot, ha nyerést lát. Ez egyúttal meghiúsítja a blokk "jövőbeli" hash-ának használatára vonatkozó stratégiát is. Ilyen esetben azt mondják, hogy "a véletlenszámtartalom a jelenlegi adatok és a jövőbeli blokk hash-ának hash-elésével létrejött véletlenszám lesz, amelynek magassága például N + 42, ahol N a blokk jelenlegi magassága. Ez kicsit megerősíti a sémát, de BP-t így is engedi, hogy a jövőben döntést hozzon a blokk visszatartásáról vagy publikálásáról.

BP szoftvere ebben az esetben bonyolultabbá válik, de nem jelentősen. Csak a tranzakciók érvényesítése és a blokkba való felvétele során gyors ellenőrzést végeznek arról, hogy lesz-e nyerés, és esetleg egy tranzakciós paramétert is optimalizálnak a magas nyerési valószínűség érdekében. Ezzel együtt, hogy elkapjunk egy okos BP-t, az ilyen manipulációkat szinte lehetetlenség észlelni, mindig új címeket használhatunk, és fokozatosan nyerhetünk anélkül, hogy gyanút keltenénk.

Így a blokk információinak felhasználásával kapcsolatos módszerek nem alkalmasak az általános PVRB implementáció szerepére. Korlátozott lehetőségekkel, tétméret-korlátokkal, a játékosok számának korlátozásával és/vagy KYC regisztrálással (hogy ne engedjük meg egy játékosnak, hogy több címet használjon), ezek a sémák kisebb játékoknál működhetnek, de nem többre.

PVRB és commit-reveal.

Rendben, köszönjük a hash-nek és legalább a blokk hash-ának és más változóknak a relatív kiszámíthatatlanságát. Ha megoldjuk a bányászok elöl futásának problémáját, valami értékesebbet kellene kapnunk. Adjunk hozzá ebbe a sémába a felhasználókat is – hadd befolyásolják ők is a véletlent: bármelyik ügyfélszolgálati munkatárs elmondja, hogy az IT rendszerekben a legvéletlenszerűbb dolog a felhasználók cselekedetei 🙂

A naivete scheme where users simply send random numbers, and the result is calculated as, for example, the hash of their sum, is not suitable. In this case, the last player can control what the outcome will be by choosing their own random number. Therefore, a widely used pattern called commit-reveal is employed. Participants first send hashes of their randoms (commits), and then reveal their actual random numbers (reveals). The 'reveal' phase only starts after the necessary commits have been collected, so participants can send the exact random number from which they previously sent the hash. Now, let's combine all this with the parameters of the block, preferably taken from the future (the random number can be known only in one of the future blocks), and voila — the random number is ready! Now any player influences the resulting random number and can 'defeat' the malicious BP by overriding their random number with their own, which is unknown in advance… It is also possible to add protection against protocol sabotage by requiring a certain amount to be attached to the transaction during the commit phase as an insurance deposit, which will only be returned during the reveal process. In this case, making a commit but not revealing it would be disadvantageous.

This was a good attempt, and such schemes also exist in gaming DApps, but unfortunately, it is still not enough. Now, not only the miner but also any participant in the protocol can influence the outcome. The value can still be controlled, albeit with less variability and at a cost, but just like with the miner, if the lottery results are worth more than the fee for participating in the PVRB protocol, then the random producer (RP) can decide whether to reveal and can still choose from at least two random options.
However, there is now the possibility to punish those who make a commit and do not do a reveal, and this scheme will still be useful. Its simplicity is a significant advantage — more serious protocols require much more powerful computations.

PVRB and deterministic signatures.

Van egy másik módja is annak, hogy a RP olyan pszeudo-véletlen számot adjon, amelyre nem tud hatással lenni, ha egy „prototípust” adunk neki – ez a determinisztikus aláírás. Az RSA például egy ilyen aláírás, míg az ECS nem. Ha a RP rendelkezik egy RSA és egy ECC kulcspárral, és a magánkulcsával aláír egy értéket, akkor az RSA esetén EGY ÉS CSAK EGY aláírást kap, míg az ECS esetén számos különböző érvényes aláírást generálhat. Ez azért történik, mert az ECS aláírás létrehozásakor egy véletlen számot választanak ki, amelyet az aláíró választhat, lehetővé téve, hogy az aláíró egy több aláírás közül válasszon. RSA esetében: „egy bemeneti érték” + „egy kulcspár” = „egy aláírás”. Nem lehet megjósolni, hogy milyen aláírást generál a másik RP, ezért a determinisztikus aláírásokkal rendelkező PVRB egyes résztvevők RSA aláírásainak kombinálásával szervezhető, akik ugyanazt az értéket írták alá. Például – a korábbi véletlen. Ezen a scheme jelentős erőforrások takaríthatók meg, mivel az aláírások egyben a protokoll szerinti helyes viselkedés igazolásaként és a véletlen forrásaként is szolgálnak.

Mindazonáltal, még a determinisztikus aláírásokkal is, a rendszer továbbra is sebezhető az „utolsó szereplő” problémájára. Az utolsó résztvevő továbbra is eldöntheti, hogy közzéteszi-e az aláírását vagy sem, ezáltal irányítva az eredményt. A rendszert tovább lehet fejleszteni, blokkok hash értékeivel, körökkel, hogy az eredmény előre ne legyen kiszámítható, de ezek az eljárások, még számos módosítás figyelembevételével is, továbbra is megoldatlanul hagyják egy résztvevő befolyásának problémáját a kollektív eredményre megbízhatatlan környezetben, és csak gazdasági és időbeli korlátozások között működhetnek. Ezen kívül az RSA kulcsmérete (1024 és 2048 bit) meglehetősen nagy, míg a blokklánc tranzakciók mérete rendkívül fontos paraméter. Láthatóan, a problémát nem lehet egyszerűen megoldani, folytatjuk.

A kriptográfiában léteznek olyan sémák, amelyek lehetővé teszik, hogy a hálózat megegyezzen egyetlen, és csak egyetlen PVRB értékben, miközben ezek a sémák ellenállnak bármilyen rosszindulatú cselekvésnek a résztvevők közül. Az egyik hasznos protokoll, amellyel érdemes megismerkedni, a Shamir titkosítási séma. Ez a titok (például egy titkos kulcs) több részre osztását szolgálja, amelyeket N résztvevőnek osztanak ki. A titok úgy van elosztva, hogy a helyreállításához elegendő M rész az N-ből, amely bármely M rész lehet. Ha egyszerűen fogalmazva, akkor a résztvevők pontokat cserélnek egy ismeretlen funkció grafikonján, és M pont megszerzése után a teljes funkció helyreállítható.
Jó magyarázat található itt: wiki és érdemes vele gyakorolni, hogy a protokollt a fejünkben eljátszhassuk a demo oldalon.

Ha a FSSS (Fiat-Shamir Secret Sharing) séma tisztán alkalmazható lenne — akkor ez lenne a megsemmisíthetetlen PVRB. A legegyszerűbb változatban a protokoll így nézne ki:

Minden résztvevő generál egy saját randomot, és megosztja a többi résztvevővel a kapott részeket.
Minden résztvevő feloldja a többi résztvevő titkait.
Ha egy résztvevőnek több mint M része gyűlt össze, akkor a résztvevő száma kiszámítható, és ez egyedülálló lesz, függetlenül a feloldott résztvevők összességétől.
A feloldott randomok kombinációja adja meg a keresett PVRB-t.

Itt egy külön résztvevő már nem befolyásolja a protokoll eredményeit, kivéve azokat az eseteket, amikor a random feloldása során a threshold eléréséhez csak tőle függ. Ennek a protokollnak, a szükséges arányú dolgozók és elérhető RP meglétével, teljesítenie kell a kriptográfiai ellenállásra vonatkozó követelményeket, és ellenáll a “legutolsó színész” problémának.

Ez lenne az ideális változat, ez a PVRB séma a Fiat-Shamir titkosítási eljárás alapján le van írva például itt: ebben cikkben. De ahogy fentebb említettük, ha megpróbáljuk közvetlenül alkalmazni a blokkláncon, technikai korlátok merülnek fel. Íme egy példa a protokoll tesztelési megvalósítására az EOS okosszerződésében, és a legfontosabb része — a résztvevő által közzétett share ellenőrzése: a kódotA kód alapján látható, hogy a proof validálásához több skaláris szorzás szükséges, és a számok nagyon nagyok. Ezzel együtt meg kell érteni, hogy a blokkláncokban a verify akkor történik, amikor a block-producer feldolgozza a tranzakciót, és bárki, aki részt vesz, könnyen ellenőrizheti a protokoll helyességét, ezért a verify funkció sebességére vonatkozó követelmények nagyon szigorúak. Ebben a változatban a megoldás nem működött, mivel a verifikáció nem fért bele a tranzakció (0,5 másodperc) korlátok közé.

A verifikáció hatékonysága — az egyik legfontosabb követelmény a blockchainben bármilyen fejlett kriptográfiai séma használatakor. A proof-ok létrehozása, az üzenetek előkészítése — ezeket a folyamatokat off-chain lehet végezni és nagy teljesítményű számítógépeken végrehajtani, de a verifikációt nem lehet megkerülni — ez még egy fontos követelmény a PVRB számára.

PVRB és threshold aláírások

A secret sharing séma megismerésével egy egész protokollosztályra bukkantunk, amelyet a "threshold" kulcsszó köt össze. Amikor bizonyos információk felfedéséhez M becsületes résztvevő részvétele szükséges N-ből, és a becsületes résztvevők halmaza bármilyen T részhalmaz lehet N-ből, threshold sémákról beszélünk. Ezek segítenek megoldani az „utolsó színész” problémát; most, ha a támadó nem fedi fel titka egy részét, ezt egy másik, becsületes résztvevő megteszi. Ezek a sémák lehetővé teszik, hogy egy és csak egy értékről állapodjanak meg, még akkor is, ha a protokollt egyes résztvevők szabotálják.

A determinisztikus aláírások és threshold sémák kombinációja lehetővé tette egy nagyon kényelmes és ígéretes séma kifejlesztését a PVRB megvalósításához — ez a determinisztikus threshold-aláírások. Íme cikk különböző threshold-aláírások alkalmazásáról, itt van még egy jó hosszú olvasmányomat a Dash-től.

Az utolsó cikkben BLS aláírásokat írnak le (a BLS a Boneh-Lynn-Shacham rövidítése). itt van cikk ), amelyek rendkívül fontos és rendkívül kényelmes tulajdonsággal bírnak a programozók számára – a nyilvános, titkos, nyilvános kulcsok és a BLS aláírások egyszerű matematikai műveletekkel kombinálhatók egymással, ugyanakkor a kombinációik érvényes kulcsok és aláírások maradnak, lehetővé téve, hogy könnyen aggregálj sok aláírást egybe és sok nyilvános kulcsot egybe. Emellett rendelkeznek determinálhatósággal is, és azonos bemeneti adatokra azonos eredményt adnak. Ennek a tulajdonságnak köszönhetően a BLS aláírások kombinációi maguk érvényes kulcsok, ami lehetővé teszi, hogy megvalósítsuk azt a változatot, amelyben M a N résztvevő egyetlen és egyedülálló aláírást hoz létre, amely determinált, nyilvánosan ellenőrizhető és előre nem látható, amíg ki nem derül az M-edik résztvevő által.

A threshold BLS aláírások sémában minden résztvevő BLS segítségével aláír valamit (például a korábbi véletlent), és a teljes threshold-aláírás az keresett véletlen. A BLS aláírások kriptográfiai tulajdonságai megfelelnek a véletlen minőségi követelményeknek, a threshold rész védi a "last-actor" helyzettől, és az egyedi kulcskombinációk lehetővé teszik számos érdekes algoritmus megvalósítását, amelyek például hatékonyan aggregálják a protokoll üzeneteit.

Tehát, ha PVRB-t építesz a blokkláncodban, nagy valószínűséggel egy BLS threshold signature sémához jutsz, amelyet már több projekt is használ. Például a DFinity (itt benchmark, amely megvalósítja a sémát, valamint itt az verifiable secret sharing megvalósítása) yellowpaper, de példám a protokollt kiszolgáló okosszerződés.

A PVRB megvalósítása

Sajnos eddig még nem látunk olyan PVRB protokollt, amely a blokkláncokban megvalósult, bizonyítva ezzel biztonságát és ellenállóságát. Annak ellenére, hogy maguk a protokollok készen állnak, technikailag nehéz azokat meglévő megoldásokhoz alkalmazni. A központosított rendszerekhez a PVRB jelentősége nem áll fenn, és a decentralizált megoldások szigorúan korlátozottak minden számítási erőforrás tekintetében: CPU, memória, tárolás, I/O. A PVRB tervezése különböző protokollok kombinációját jelenti, hogy olyan megoldást nyerjünk, ami megfelel legalább valamelyik életképes blokklánc követelményeinek. Az egyik protokoll hatékonyabban számít, de több üzenetet igényel az RP között, míg a másik rendkívül kevés üzenetet igényel, de a proof létrehozása órákig is eltarthat.

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

Kibervédelmi ellenállóság. A PVRB-nek szigorúan torzítatlanul kell működnie, anélkül, hogy bármelyik bitet irányítani lenne lehetőség. Egyes sémákban ez nem így van, ezért hívjon kriptográfust.
Az "utolsó szereplő" problémája. A PVRB-nek ellenállónak kell lennie azokkal a támadásokkal szemben, amikor a támadó, aki egy vagy több RP-t irányít, az eredmény egyik vagy másik lehetőségét választhatja.
A protokoll ellehetetlenítése. A PVRB-nek ellenállónak kell lennie azokkal a támadásokkal szemben, amikor a támadó, aki egy vagy több RP-t irányít, dönt arról, hogy legyen-e véletlenszerűség, vagy sem, és garantáltan, vagy megadott valószínűséggel befolyásolhatja ezt.
Üzenetek számának problémája. Az RP-knek a blokkláncra minimális számú üzenetet kell küldeniük, és maximálisan kerüljék az olyan szinkron műveleteket, mint a "küldtem némi információt, várom a választ egy adott résztvevőtől". A p2p hálózatokban, különösen földrajzilag elosztottakban, nem érdemes gyors válaszra számítani.
Számítási összetettség problémája. A PVRB bármely szakaszának on-chain ellenőrzése nagyon egyszerűnek kell lennie, mivel azt a hálózat összes teljes kliense végzi. Ha a megvalósítást okos szerződéssel hajtják végre, a sebességre vonatkozó követelmények nagyon szigorúak.
Hozzáférés és életképesség problémája. A PVRB-nek arra kell törekednie, hogy ellenállónak bizonyuljon azokkal a helyzetekkel szemben, amikor a hálózat egy része egy időre elérhetetlenné válik, és egyes RP-k egyszerűen leállnak.
A megbízható beállítás és a kulcsok kezdeti elosztásának problémája. Ha a PVRB elsődleges protokollbeállítással működik, az egy másik nagy és komoly téma. Íme példám. Ha a résztvevőknek a protokoll megkezdése előtt meg kell osztaniuk egymással a kulcsaikat, az is probléma, ha a résztvevők összetétele változik
Fejlesztési problémák. A megfelelő nyelveken elérhető könyvtárak, azok biztonsága és teljesítménye, nyilvánosság, összetett tesztek stb.

Például a threshold BLS aláírásoknál van egy jelentős probléma — a munka megkezdése előtt a résztvevőknek kötelezően át kell adniuk egymásnak a kulcsokat, így létrehozva egy csoportot, amelyen belül dolgozni fognak. Ez azt jelenti, hogy legalább egy kört várni kell a decentralizált hálózatban, és figyelembe véve, hogy a generált véletlenszámra, például, szükség van a játékokban, gyakorlatilag valós időben, ez azt jelenti, hogy a protokoll megszakítása lehetséges ebben a szakaszban, és a threshold séma előnyei elvesznek. Ez a probléma egyszerűbb, mint az előző, de még mindig külön eljárást igényel a threshold csoportok kialakítására, amelyet gazdaságilag is védeni kell, betétekkel és a protokollt be nem tartó résztvevők pénzeszközeinek visszavételével (slashing). Ezenkívül a BLS verifikáció megfelelő biztonsági szinttel egyszerűen nem fér el például az EOS vagy az Ethereum standard tranzakcióiban — egyszerűen nem elegendő idő áll rendelkezésre a verifikációhoz. A szerződés kódja WebAssembly vagy EVM, amelyet virtuális gép hajt végre. A kriptográfiai funkciók jelenleg nem natívan valósulnak meg, és tízszer lassabban működnek, mint a szokásos kriptográfiai könyvtárak. Számos protokoll nem felel meg a követelményeknek, pusztán a kulcsok mennyisége miatt, például ez 1024 és 2048 bit az RSA esetében, 4-8-szor nagyobb, mint a Bitcoin és Ethereum standard tranzakciós aláírása.

Szerepet játszik emellett a különböző programozási nyelveken való implementációk elérhetősége is — ezekből van kevés, különösen az új protokollok esetében. Az integrációs lehetőség a konszenzusba megköveteli, hogy a protokollt a platform nyelvén írják, így keresi az ember a Go kódot a geth-hez, Rustot a Parity-hez, C++-t az EOS-hoz. A JavaScript kódot mindenkinek meg kell keresnie, és mivel a JavaScript és a kriptográfia nem igazán barátok, a WebAssembly segít, amely most már biztosan a következő fontos internetes szabvány szerepére aspirál.

Zárás

Remélem, az előzőben a Spotify döntéshozatali módszertanáról. Egyre több felhasználó preferálja a zenehallgatást mobilon a streaming szolgáltatásban, de a cégnél túlnyomórészt webprogramozók dolgoznak. A Spotify elemezte ezt a helyzetet, és úgy döntött, hogy több mobilfejlesztőt vesz fel, valamint átnevezi a webes szakembereket új irányba: Sikerült meggyőznöm Önt, hogy a blokkláncon történő véletlenszám-generálás kritikus fontosságú számos, a decentralizált rendszerek életében rejlik, és ez a cikk bemutatja, hogy ez a feladat rendkívül ambiciózus és nem egyszerű, de már léteznek jó megoldások. Az alap protokoll végleges tervezése általában csak jelentős tesztelés után lehetséges, amely figyelembe veszi a setup-tól kezdve a hibák szimulálásáig minden aspektust, így valószínűleg nem talál kész recepteket a csapatok whitepapereiben és cikkeiben, sőt, mi sem merünk “csinálja így, így helyes” kijelentéseket tenni az elkövetkező egy-két évben.

Jelenleg a fejlesztés alatt álló blokkláncunknál, a PVRB-nél Haya, a threshold BLS aláírások alkalmazásánál döntöttünk, és a PVRB-t a konszenzus szintjén kívánjuk megvalósítani, mivel a beleegyezések okosszerződésekben megfelelő biztonsági szinttel még nem lehetségesek. Lehetséges, hogy egyszerre két megoldást fogunk alkalmazni: először a drága titkos megosztást a hosszú távú random_seed létrehozására, majd ezt használjuk a magas frekvenciájú véletlenszám-generáláshoz a determinisztikus threshold BLS aláírások segítségével, bár lehet, hogy végül csak az egyik rendszert alkalmazzuk. Előre megmondani, hogy milyen lesz a protokoll, sajnos lehetetlen, ám ami megnyugtató, hogy ahogyan a tudományban, az mérnöki feladatokban egy negatív eredmény is eredmény, és minden újabb próbálkozás a probléma megoldására egy újabb lépcsőfok a kutatások számára, akik ezzel a kérdéssel foglalkoznak. Az üzleti követelmények teljesítése érdekében egy konkrét gyakorlati problémát oldunk meg — megbízható entropiaforrást biztosítunk a játékalkalmazások számára, ezért figyelmet kell fordítanunk magára a blokkláncra is, különösen a lánc véglegességi kérdéseire és a hálózat irányítására.

Bár jelenleg még nem látunk olyan blokkláncokat, amelyek bizonyítottan tartós PVRB-t alkalmaznak, és amelyek már elegendő ideje működnek ahhoz, hogy átestek a valós alkalmazások, többszörös auditálás, terhelések és természetesen valós támadások próbáin, a lehetséges megoldások száma megerősíti, hogy létezik megoldás, és ezek közül valamikor egy algoritmus meg fogja oldani a problémát. Örömmel osztjuk meg az eredményeket, és köszönjük a többi csapatnak is, akik szintén foglalkoznak ezzel a kérdéssel, a cikkekért és a kódért, amelyek lehetővé teszik az mérnökök számára, hogy ne lépjenek kétszer ugyanabba a hibába.

Amikor találkozol egy programozóval, aki decentralizált véletlent tervez, légy óvatos és figyelmes, és ha szükséges, nyújts pszichológiai támogatást 🙂

Forrás: habr.com