Introducció

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

Igual que amb el concepte d'un xifrat absolutament fort de la criptografia, els protocols reals de "Baliza aleatòria verificable públicament" (d'ara endavant PVRB) només intenten apropar-se el més possible a l'esquema ideal, perquè a les xarxes reals no és aplicable en la seva forma pura: cal posar-se d'acord estrictament en un bit, hi ha d'haver moltes rondes i tots els missatges han de ser perfectament ràpids i sempre lliurats. Per descomptat, aquest no és el cas de les xarxes reals. Per tant, quan es dissenyen PVRB per a tasques específiques en les cadenes de blocs modernes, a més de la impossibilitat de controlar l'aleatorietat i la força criptogràfica resultants, sorgeixen molts més problemes purament arquitectònics i tècnics.

Per a PVRB, la cadena de blocs en si és essencialment un mitjà de comunicació en el qual missatges = transaccions. Això us permet abstraure parcialment els problemes de xarxa, la no entrega de missatges, els problemes amb el programari intermedi; tots aquests riscos els assumeix la xarxa descentralitzada i el seu principal valor per a PVRB és la incapacitat de revocar o corrompre una transacció ja enviada; això sí. No permetre que els participants es neguin a participar en el protocol, tret que hagin dut a terme un atac amb èxit al consens. Aquest nivell de seguretat és acceptable, de manera que PVRB hauria de ser resistent a la connivència dels participants exactament en la mateixa mesura que la cadena de blocs principal. A més, això insinua que el PVRB ha de formar part del consens si la xarxa està d'acord en la cadena de blocs principal, fins i tot si també està d'acord en l'únic aleatori resultant just. O, PVRB és simplement un protocol autònom implementat per un contracte intel·ligent que funciona de manera asíncrona respecte a la cadena de blocs i els blocs. Tots dos mètodes tenen els seus avantatges i desavantatges, i l'elecció entre ells és extremadament no trivial.

Dues maneres d'implementar PVRB

Descrivim amb més detall dues opcions per implementar PVRB: la versió autònoma, que funciona mitjançant un contracte intel·ligent independent de la cadena de blocs, i la versió integrada per consens, integrada al protocol, segons la qual la xarxa accepta la cadena de blocs i la transaccions a incloure. En tots els casos, em referiré als motors de blockchain populars: Ethereum, EOS i tots els que s'hi assemblen en la manera com allotgen i processen els contractes intel·ligents.

Contracte autònom

En aquesta versió, PVRB és un contracte intel·ligent que accepta transaccions de productors aleatoris (d'ara endavant RP), les processa, combina els resultats i, en conseqüència, arriba a un valor determinat que qualsevol usuari pot rebre d'aquest contracte. Aquest valor no es pot emmagatzemar directament al contracte, sinó que es representa només per dades a partir de les quals es pot obtenir determinísticament un i només un valor de l'atzar resultant. En aquest esquema, els RP són usuaris de la cadena de blocs i es pot permetre que qualsevol persona participi en el procés de generació.

L'opció amb contracte autònom és bona:

• portabilitat (els contractes es poden arrossegar de blockchain a blockchain)
• facilitat d'implementació i prova (els contractes són fàcils d'escriure i provar)
• comoditat en la implementació d'esquemes econòmics (és fàcil fer el vostre propi testimoni, la lògica del qual serveix als propòsits de PVRB)
• possibilitat de llançar-se a blockchains que ja funcionen

També té desavantatges:

• fortes limitacions en els recursos informàtics, el volum de transaccions i l'emmagatzematge (és a dir, cpu/mem/io)
• restriccions a les operacions dins del contracte (no totes les instruccions estan disponibles, és difícil connectar biblioteques externes)
• incapacitat per organitzar la missatgeria més ràpid que les transaccions que s'inclouen a la cadena de blocs

Aquesta opció és adequada per implementar un PVRB que s'ha d'executar en una xarxa existent, no conté criptografia complexa i no requereix un gran nombre d'interaccions.

Integrat en el consens

En aquesta versió, PVRB s'implementa al codi del node blockchain, integrat o en paral·lel amb l'intercanvi de missatges entre nodes blockchain. Els resultats del protocol s'escriuen directament als blocs produïts i els missatges del protocol s'envien a través de la xarxa p2p entre nodes. Com que el protocol dóna com a resultat números que s'han d'escriure en blocs, la xarxa ha d'arribar a un consens sobre ells. Això vol dir que els missatges PVRB, com les transaccions, han de ser validats per nodes i inclosos en blocs perquè qualsevol participant de la xarxa pugui validar el compliment del protocol PVRB. Això ens porta automàticament a la solució òbvia: si la xarxa està d'acord en un consens sobre un bloc i transaccions en ell, aleshores PVRB hauria de formar part del consens, i no un protocol autònom. En cas contrari, és possible que un bloc sigui vàlid des del punt de vista del consens, però no es segueix el protocol PVRB, i des del punt de vista del PVRB no es pot acceptar el bloc. Així, si s'escull l'opció "integrada en el consens", el PVRB esdevé una part important del consens.

Quan es descriuen les implementacions de PVRB a nivell de consens de xarxa, no es pot evitar de cap manera els problemes de finalitat. La finalitat és un mecanisme utilitzat en els consensos deterministes que compromet un bloc (i la cadena que hi porta) que és definitiu i mai es llençarà, encara que es produeixi una bifurcació paral·lela. Per exemple, a Bitcoin no hi ha aquest mecanisme: si publiqueu una cadena de major complexitat, substituirà qualsevol de menys complexa, independentment de la longitud de les cadenes. I a EOS, per exemple, els definitius són els anomenats Last Irreversible Blocks, que apareixen de mitjana cada 432 blocs (12*21 + 12*15, pre-vot + pre-commit). Aquest procés està esperant essencialment 2/3 de les signatures dels productors de blocs (d'ara endavant BP). Quan apareixen forquilles que són més antigues que l'última LIB, simplement es descarten. Aquest mecanisme permet garantir que la transacció s'inclou a la cadena de blocs i no es revertirà mai, independentment dels recursos que tingui l'atacant. A més, els blocs finals són blocs signats per 2/3 BP a Hyperledger, Tendermint i altres consensos basats en pBFT. A més, té sentit fer un protocol per garantir la finalitat un complement al consens, ja que pot funcionar de manera asíncrona amb la producció i publicació de blocs. Aquí n'hi ha un de bo article sobre la finalitat a Ethereum.

La finalitat és extremadament important per als usuaris, que sense ella poden trobar-se víctimes d'un atac de "doble despesa", on BP "manté" blocs i els publica després que la xarxa hagi "visit" una bona transacció. Si no hi ha finalitat, la bifurcació publicada substitueix el bloc amb una transacció "bona" ​​per una altra, d'una bifurcació "dolenta", en la qual es transfereixen els mateixos fons a l'adreça de l'atacant. En el cas de PVRB, els requisits de finalitat són encara més estrictes, ja que construir forks per a PVRB suposa l'oportunitat per a un atacant de preparar diverses opcions aleatòries per tal de publicar-ne la més rendible, i limitar el temps d'un possible atac és un problema. bona solució.

Per tant, la millor opció és combinar PVRB i finalitat en un sol protocol; aleshores el bloc finalitzat = finalitzat aleatori, i això és exactament el que necessitàvem obtenir. Ara els jugadors rebran una aleatoria garantida en N segons, i poden estar segurs que és impossible tornar-la a enrere o tornar-la a reproduir.

L'opció integrada per consens és bona:

• la possibilitat d'implementació asíncrona en relació a la producció de blocs: els blocs es produeixen com és habitual, però paral·lelament a això, pot funcionar el protocol PVRB, que no produeix aleatorietat per a cada bloc
• la capacitat d'implementar fins i tot criptografia pesada, sense les restriccions imposades als contractes intel·ligents
• la capacitat d'organitzar l'intercanvi de missatges més ràpidament que les transaccions que s'inclouen a la cadena de blocs, per exemple, part del protocol pot funcionar entre nodes sense distribuir missatges a la xarxa

També té desavantatges:

• Dificultats en les proves i el desenvolupament: haureu d'emular errors de xarxa, nodes que falten, forquilles de xarxa
• Els errors d'implementació requereixen un hardfork de xarxa

Tots dos mètodes d'implementació de PVRB tenen dret a la vida, però la implementació de contractes intel·ligents a les cadenes de blocs modernes encara és força limitada en els recursos informàtics, i qualsevol transició a una criptografia seriosa sovint és simplement impossible. I necessitarem una criptografia seriosa, com es demostrarà a continuació. Tot i que aquest problema és clarament temporal, es necessita una criptografia seriosa en els contractes per resoldre molts problemes, i va apareixent gradualment (per exemple, contractes de sistema per a zkSNARKs a Ethereum)

Blockchain, que proporciona un canal de missatgeria de protocol transparent i fiable, no ho fa de manera gratuïta. Qualsevol protocol descentralitzat ha de tenir en compte la possibilitat d'un atac Sybil; qualsevol acció pot ser realitzada per les forces concertades de múltiples comptes, per tant, a l'hora de dissenyar, cal tenir en compte la capacitat dels atacants per crear un nombre arbitrari de protocols. participants que actuen en connivència.

PVRB i variables de bloc.

No vaig mentir quan vaig dir que ningú encara ha implementat un bon PVRB, provat per moltes aplicacions de jocs d'atzar, en blockchains. D'on provenen tantes aplicacions de jocs d'atzar a Ethereum i EOS? Això em sorprèn tant com et sorprèn a tu, d'on van treure tants aleatoris "persistents" en un entorn completament determinista?

La manera preferida d'aconseguir l'aleatorietat a la cadena de blocs és agafar algun tipus d'informació "impredictible" del bloc i fer-ne una aleatòria basant-s'hi, simplement fent hash un o més valors. Bon article sobre els problemes d'aquests esquemes aquí. Podeu prendre qualsevol dels valors "impredictibles" del bloc, per exemple, el hash del bloc, el nombre de transaccions, la complexitat de la xarxa i altres valors desconeguts per endavant. A continuació, tritureu-los, un o més, i, en teoria, hauríeu d'obtenir un aleatori real. Fins i tot podeu afegir al paper blanc que el vostre esquema és "segur post-quàntic" (ja que hi ha funcions hash a prova quàntica :)).

Però fins i tot els hash segurs postquàntics no són suficients, per desgràcia. El secret rau en els requisits per a PVRB, deixeu-me que us els recordi de l'article anterior:

1. El resultat ha de tenir una distribució prou uniforme, és a dir, basar-se en una criptografia prou forta.
2. No és possible controlar cap dels bits del resultat. Com a conseqüència, el resultat no es pot predir amb antelació.
3. No podeu sabotejar el protocol de generació no participant en el protocol o sobrecarregant la xarxa amb missatges d'atac
4. Tot l'anterior ha de ser resistent a la connivència d'un nombre admissible de participants del protocol deshonestos (per exemple, 1/3 dels participants).

En aquest cas, només es compleix el requisit 1 i no es compleix el requisit 2. Mitjançant l'hashing valors impredictibles del bloc, obtindrem una distribució uniforme i bons aleatoris. Però BP almenys té l'opció de "publicar el bloc o no". Així, BP pot triar almenys entre DUES opcions aleatòries: "la seva" i la que resultarà si algú altre fa el bloqueig. BP pot "espigar" per endavant què passarà si publica un bloc, i simplement decideix fer-ho o no. Així, quan juga, per exemple, "par-senir" o "vermell/negre" a la ruleta, només pot publicar un bloc si veu una victòria. Això també fa que l'estratègia d'utilitzar, per exemple, un hash de blocs "del futur" sigui inviable. En aquest cas, diuen que “s'utilitzarà l'atzar, que s'obté fent hash les dades actuals i el hash d'un bloc futur amb una alçada de, per exemple, N + 42, on N és l'alçada del bloc actual. Això reforça una mica l'esquema, però encara permet a BP, encara que en el futur, escollir si mantenir el bloc o publicar.

El programari BP en aquest cas es fa més complicat, però no gaire. Simplement, en validar i incloure una transacció en un bloc, es fa una comprovació ràpida per veure si hi haurà una victòria i, possiblement, la selecció dels paràmetres d'una transacció per obtenir una alta probabilitat de guanyar. Al mateix temps, és gairebé impossible atrapar un BP intel·ligent per aquestes manipulacions; cada vegada podeu utilitzar noves adreces i guanyar a poc a poc sense despertar sospita.

Per tant, els mètodes que utilitzen informació del bloc no són adequats com a implementació universal de PVRB. En una versió limitada, amb restriccions a la mida de les apostes, restriccions al nombre de jugadors i/o registre KYC (per evitar que un jugador utilitzi diverses adreces), aquests esquemes poden funcionar per a jocs petits, però res més.

PVRB i commit-reveal.

D'acord, gràcies al hash i almenys la relativa imprevisibilitat del hash del bloc i altres variables. Si resoleu el problema dels miners d'avantguarda, hauríeu d'aconseguir alguna cosa més adequada. Afegim usuaris a aquest esquema; deixeu que també influeixin en l'aleatorietat: qualsevol empleat de suport tècnic us dirà que el més aleatori dels sistemes informàtics són les accions dels usuaris :)

Un esquema ingenu, quan els usuaris simplement envien números aleatoris i el resultat es calcula com, per exemple, un hash de la seva suma, no és adequat. En aquest cas, l'últim jugador pot, escollint el seu propi aleatori, controlar quin serà el resultat. És per això que s'utilitza el patró commit-reveal molt utilitzat. Els participants primer envien hash des dels seus aleatoris (commits) i després obren els mateixos aleatoris (revela). La fase de "revelació" només comença després que s'hagin recollit els compromisos necessaris, de manera que els participants poden enviar exactament el hash aleatori des del qual han enviat anteriorment. Ara posem tot això juntament amb els paràmetres d'un bloc, i millor que un pres del futur (l'aleatorietat només es pot trobar en un dels blocs futurs), i voilà: l'aleatorietat està a punt! Ara qualsevol jugador influeix en l'aleatorietat resultant, i pot "derrotar" el BP maliciós anul·lant-lo amb el seu propi, desconegut per endavant, aleatorietat... També podeu afegir protecció contra el saboteig del protocol no obrir-lo en l'etapa de revelació, simplement. en exigir que s'adjunti una quantitat determinada a la transacció quan es compromet: un dipòsit de seguretat, que només es retornarà durant el procediment de revelació. En aquest cas, comprometre's i no revelar no serà rendible.

Va ser un bon intent, i aquests esquemes també existeixen a les DApps de jocs, però, per desgràcia, això no és suficient. Ara no només el miner, sinó també qualsevol participant del protocol pot influir en el resultat. Encara és possible controlar el valor en si, amb menys variabilitat i amb un cost, però, com en el cas del miner, si els resultats del sorteig són més valuosos que la quota de participació en el protocol PVRB, llavors l'atzar -El productor (RP) pot decidir si vol revelar i encara pot triar entre almenys dues opcions aleatòries.
Però es va fer possible castigar els que cometen i no revelen, i aquest esquema serà útil. La seva senzillesa és un avantatge seriós: els protocols més seriosos requereixen càlculs molt més potents.

PVRB i signatures deterministes.

Hi ha una altra manera de forçar l'RP a proporcionar un nombre pseudoaleatori que no pot influir si se li proporciona una "preimatge": aquesta és una signatura determinista. Aquesta signatura és, per exemple, RSA i no ECS. Si RP té un parell de claus: RSA i ECC, i signa un determinat valor amb la seva clau privada, aleshores en el cas de RSA obtindrà UNA I NOMÉS UNA signatura, i en el cas de l'ECS pot generar qualsevol nombre de claus. diferents signatures vàlides. Això es deu al fet que quan es crea una signatura ECS, s'utilitza un número aleatori, escollit pel signant, i es pot escollir de qualsevol manera, donant-li l'oportunitat de triar una entre diverses signatures. En el cas de RSA: "un valor d'entrada" + "un parell de claus" = "una signatura". És impossible predir quina signatura obtindrà un altre RP, de manera que es pot organitzar un PVRB amb signatures deterministes combinant les signatures RSA de diversos participants que han signat el mateix valor. Per exemple, l'atzar anterior. Aquest esquema estalvia molts recursos, perquè Les signatures són alhora una confirmació del comportament correcte segons el protocol i una font d'aleatorietat.

Tanmateix, fins i tot amb signatures deterministes, l'esquema encara és vulnerable al problema de l'"últim actor". L'últim participant encara pot decidir si publica la signatura o no, controlant així el resultat. Podeu modificar l'esquema, afegir-hi hash de blocs, fer rondes perquè el resultat no es pugui predir amb antelació, però totes aquestes tècniques, fins i tot tenint en compte moltes modificacions, encara deixen sense resoldre el problema de la influència d'un participant en el col·lectiu. donar lloc a un entorn poc fiable i només pot funcionar sota limitacions econòmiques i de temps. A més, la mida de les claus RSA (1024 i 2048 bits) és bastant gran i la mida de les transaccions blockchain és un paràmetre extremadament important. Aparentment no hi ha una manera senzilla de resoldre el problema, seguim endavant.

PVRB i esquemes d'intercanvi secret

En criptografia, hi ha esquemes que poden permetre a la xarxa acordar un i només un valor PVRB, mentre que aquests esquemes són resistents a qualsevol acció maliciosa d'alguns participants. Un protocol útil amb el qual val la pena familiaritzar-se és l'esquema de compartició secreta de Shamir. Serveix per dividir un secret (per exemple, una clau secreta) en diverses parts i distribuir aquestes parts a N participants. El secret es distribueix de tal manera que M parts de N són suficients per recuperar-lo, i aquestes poden ser qualsevol M parts. Si els dits tenen un gràfic d'una funció desconeguda, els participants intercanvien punts al gràfic i, després de rebre M punts, es pot restaurar tota la funció.
Es dóna una bona explicació wiki però jugar-hi pràcticament per reproduir el protocol al teu cap és útil Demo pàgina.

Si l'esquema FSSS (Fiat-Shamir Secret Sharing) fos aplicable en la seva forma pura, seria un PVRB indestructible. En la seva forma més senzilla, el protocol podria semblar així:

• Cada participant genera el seu propi aleatori i en distribueix accions a altres participants
• Cada participant revela la seva part dels secrets dels altres participants
• Si un participant té més de M accions, es pot calcular el nombre d'aquest participant i serà únic, independentment del conjunt de participants revelats.
• La combinació d'aleatoris revelats és el PVRB desitjat

Aquí, un participant individual ja no influeix en els resultats del protocol, excepte en els casos en què l'assoliment del llindar de divulgació de l'aleatorietat depèn únicament d'ell. Per tant, aquest protocol, si hi ha una proporció requerida de RP que treballin en el protocol i estigui disponible, funciona, implementant els requisits de força criptogràfica i sent resistent al problema de l'"últim actor".

Aquesta podria ser una opció ideal, aquest esquema PVRB basat en la compartició secreta de Fiat-Shamir es descriu, per exemple, a això article. Però, com s'ha esmentat anteriorment, si intenteu aplicar-ho frontalment a la cadena de blocs, apareixen limitacions tècniques. Aquí teniu un exemple d'implementació de prova del protocol al contracte intel·ligent d'EOS i la seva part més important: comprovar el participant compartit publicat: codi. Podeu veure al codi que la validació de la prova requereix diverses multiplicacions escalars i els nombres utilitzats són molt grans. S'ha d'entendre que a les cadenes de blocs, la verificació es produeix en el moment en què el productor de blocs processa la transacció i, en general, qualsevol participant ha de verificar fàcilment la correcció del protocol, de manera que els requisits per a la velocitat de la funció de verificació són molt greus. . En aquesta opció, l'opció va resultar ineficaç, ja que la verificació no encaixava dins del límit de transacció (0.5 segons).

L'eficiència de la verificació és un dels requisits més importants per a l'ús, en general, de qualsevol esquema criptogràfic avançat a la cadena de blocs. Creació de proves, preparació de missatges: aquests procediments es poden treure fora de la cadena i realitzar-se en ordinadors d'alt rendiment, però la verificació no es pot obviar: aquest és un altre requisit important per a PVRB.

PVRB i signatures de llindar

Després d'haver conegut l'esquema de compartició secreta, vam descobrir tota una classe de protocols units per la paraula clau "llindar". Quan la divulgació d'alguna informació requereix la participació de M participants honestos de N, i el conjunt de participants honestos pot ser un subconjunt arbitrari de N, parlem d'esquemes de "llindar". Són ells els que ens permeten fer front al problema de l'"últim actor", ara si l'atacant no revela la seva part del secret, un altre participant honest ho farà per ell. Aquests esquemes permeten acordar un i només un significat, encara que el protocol sigui sabotejat per alguns dels participants.

La combinació de signatures deterministes i esquemes de llindar va permetre desenvolupar un esquema molt convenient i prometedor per a la implementació de PVRB: aquestes són signatures de llindar deterministes. Aquí article sobre els diferents usos de les signatures de llindar, i aquí n'hi ha un altre de bo llarga lectura de Dash.

L'últim article descriu les signatures de BLS (BLS significa Boneh-Lynn-Shacham, aquí article), que tenen una qualitat molt important i extremadament convenient per als programadors: les claus públiques, secretes, públiques i signatures BLS es poden combinar entre si mitjançant operacions matemàtiques senzilles, mentre que les seves combinacions segueixen sent claus i signatures vàlides, cosa que us permet agregar fàcilment moltes signatures en una i moltes claus públiques en una. També són deterministes i produeixen el mateix resultat per a les mateixes dades d'entrada. Gràcies a aquesta qualitat, les combinacions de signatures BLS són en si mateixes claus vàlides, la qual cosa permet la implementació d'una opció en la qual M de N participants produeixen una i només una signatura que és determinista, verificable públicament i impredictible fins que és oberta pel Mth. participant.

En un esquema amb signatures BLS de llindar, cada participant signa alguna cosa utilitzant BLS (per exemple, l'atzar anterior) i la signatura de llindar comú és l'atzar desitjat. Les propietats criptogràfiques de les signatures BLS compleixen els requisits de qualitat aleatòria, la part de llindar protegeix contra el "últim actor" i la combinabilitat única de claus permet implementar molts més algorismes interessants que permeten, per exemple, l'agregació eficient de missatges de protocol. .

Per tant, si esteu construint PVRB a la vostra cadena de blocs, el més probable és que acabeu amb l'esquema de signatures de llindar BLS, ja l'estan utilitzant diversos projectes. Per exemple, DFinity (aquí punt de referència que implementa el circuit, i aquí exemple d'implementació de compartició secreta verificable) o Keep.network (aquí hi ha la seva balisa aleatòria paper groc, Però, exemple contracte intel·ligent al servei del protocol).

Implementació de PVRB

Malauradament, encara no veiem un protocol preparat implementat a les cadenes de blocs PVRB que hagi demostrat la seva seguretat i estabilitat. Tot i que els protocols estan preparats, tècnicament aplicar-los a les solucions existents no és fàcil. Per als sistemes centralitzats, PVRB no té sentit, i els descentralitzats estan estrictament limitats en tots els recursos informàtics: CPU, memòria, emmagatzematge, E/S. Dissenyar un PVRB és una combinació de diferents protocols per crear alguna cosa que compleixi tots els requisits d'almenys una cadena de blocs viable. Un protocol calcula de manera més eficient, però requereix més missatges entre RP, mentre que l'altre requereix molt pocs missatges, però crear una prova pot ser una tasca que triga desenes de minuts, o fins i tot hores.

Enumeraré els factors que haureu de tenir en compte a l'hora d'escollir un PVRB de qualitat:

• Força criptogràfica. El vostre PVRB ha de ser estrictament imparcial, sense poder controlar ni un sol bit. En alguns esquemes, aquest no és el cas, així que truqueu a un criptògraf
• El problema de l'"últim actor".. El vostre PVRB ha de ser resistent als atacs en què un atacant que controli un o més RP pot triar un dels dos resultats.
• Problema de sabotatge del protocol. El vostre PVRB ha de ser resistent als atacs en què un atacant que controla un o més RP decideix si és aleatori o no i es pot garantir o amb una probabilitat determinada d'influir en això.
• Problema amb el nombre de missatges. Els vostres RP haurien d'enviar un mínim de missatges a la cadena de blocs i evitar tant com sigui possible accions sincròniques, com ara situacions com "He enviat informació, estic esperant una resposta d'un participant específic". A les xarxes p2p, especialment les disperses geogràficament, no hauríeu de comptar amb una resposta ràpida
• El problema de la complexitat computacional. La verificació de qualsevol etapa del PVRB en cadena hauria de ser extremadament fàcil, ja que la realitzen tots els clients complets de la xarxa. Si la implementació es fa mitjançant un contracte intel·ligent, els requisits de velocitat són molt estrictes
• El problema de l'accessibilitat i la vivacitat. El vostre PVRB hauria d'esforçar-se per ser resistent a situacions en què part de la xarxa no estigui disponible durant un període de temps i una part del RP simplement deixa de funcionar.
• El problema de la configuració de confiança i la distribució inicial de claus. Si el vostre PVRB utilitza la configuració principal del protocol, aquesta és una història gran i seriosa a part. Aquí exemple. Si els participants s'han d'informar mútuament de les seves claus abans d'iniciar el protocol, això també és un problema si canvia la composició dels participants
• Problemes de desenvolupament. Disponibilitat de biblioteques en els idiomes requerits, la seva seguretat i rendiment, publicitat, proves complexes, etc.

Per exemple, les signatures de llindar BLS tenen un problema important: abans de començar a treballar, els participants s'han de distribuir les claus entre ells, organitzant un grup dins del qual funcionarà el llindar. Això vol dir que almenys una ronda d'intercanvi en una xarxa descentralitzada s'haurà d'esperar, i tenint en compte que el rand generat, per exemple, és necessari en els jocs, gairebé en temps real, això significa que el sabotatge del protocol és possible en aquesta etapa. , i es perden els avantatges de l'esquema de llindars. Aquest problema ja és més senzill que els anteriors, però encara requereix el desenvolupament d'un procediment separat per a la formació de grups de llindar, que s'hauran de protegir econòmicament, mitjançant dipòsits i retirades de fons (tallar) als participants que no segueixin el protocol. A més, la verificació BLS amb un nivell acceptable de seguretat simplement no encaixa, per exemple, en una transacció estàndard d'EOS o Ethereum; simplement no hi ha prou temps per a la verificació. El codi del contracte és WebAssembly o EVM, executat per una màquina virtual. Les funcions criptogràfiques no estan implementades de manera nativa (encara) i funcionen desenes de vegades més lent que les biblioteques criptogràfiques convencionals. Molts protocols no compleixen els requisits simplement basats en el volum de claus, per exemple 1024 i 2048 bits per a RSA, 4-8 vegades més gran que la signatura de transacció estàndard a Bitcoin i Ethereum.

També hi juga un paper la presència d'implementacions en diferents llenguatges de programació, de les quals n'hi ha poques, especialment per als nous protocols. L'opció amb integració en consens requereix escriure un protocol en l'idioma de la plataforma, així que hauràs de buscar codi a Go for geth, a Rust for Parity, a C++ per a EOS. Tothom haurà de buscar codi JavaScript, i com que JavaScript i la criptografia no són amics especialment íntims, WebAssembly ajudarà, que ara definitivament afirma ser el següent estàndard important d'Internet.

Conclusió

Espero que en l'anterior article Vaig aconseguir convèncer-vos que generar números aleatoris a la cadena de blocs és fonamental per a molts aspectes de la vida de les xarxes descentralitzades, i amb aquest article vaig demostrar que aquesta tasca és extremadament ambiciosa i difícil, però que ja existeixen bones solucions. En general, el disseny final del protocol només és possible després de realitzar proves massives que tinguin en compte tots els aspectes, des de la configuració fins a l'emulació d'errors, de manera que és poc probable que trobeu receptes ja fetes als articles i articles de l'equip, i certament no ho farem. decidiu durant els propers dos anys escriviu "feu-ho així, exactament bé".

Adéu, pel nostre PVRB a la cadena de blocs que s'està desenvolupant Hi hagi, ens vam decidir a utilitzar signatures BLS de llindar, tenim previst implementar PVRB a nivell de consens, ja que la verificació en contractes intel·ligents amb un nivell de seguretat acceptable encara no és possible. És possible que utilitzem dos esquemes alhora: primer, compartició secreta costosa per crear random_seed a llarg termini, i després l'utilitzem com a base per a la generació aleatòria d'alta freqüència mitjançant signatures BLS de llindar deterministes, potser ens limitarem només a un dels esquemes. Malauradament, és impossible dir per endavant quin serà el protocol; l'únic bo és que, com en la ciència, en els problemes d'enginyeria, un resultat negatiu també és un resultat, i cada nou intent de resoldre el problema és un pas més per a la recerca de tots els implicats en el problema. Per satisfer els requisits empresarials, resolem un problema pràctic específic: proporcionar aplicacions de jocs amb una font fiable d'entropia, de manera que també hem de prestar atenció a la cadena de blocs en si, en particular als problemes de la finalitat de la cadena i el govern de la xarxa.

I tot i que encara no veiem un PVRB resistent demostrat a les cadenes de blocs, que s'hauria utilitzat durant prou temps per ser provat per aplicacions reals, auditories múltiples, càrregues i, per descomptat, atacs reals, però el nombre de camins possibles ho confirma. existeix una solució, i quins d'aquests algorismes acabaran per resoldre el problema. Estarem encantats de compartir els resultats i agrair als altres equips que també estan treballant en aquest tema per articles i codis que permetin als enginyers no trepitjar el mateix rastell dues vegades.

Per tant, quan us trobeu amb un programador que dissenya aleatòriament descentralitzat, sigueu atent i atent, i proporcioneu ajuda psicològica si cal :)

Font: www.habr.com