Introdución

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

Do mesmo xeito que co concepto de cifrado absolutamente forte da criptografía, os protocolos reais de "Baliza aleatoria verificable públicamente" (en diante PVRB) só intentan achegarse o máis posible ao esquema ideal, porque nas redes reais non é aplicable na súa forma pura: hai que poñerse de acordo estrictamente nun bit, debe haber moitas roldas e todas as mensaxes deben ser perfectamente rápidas e sempre entregadas. Por suposto, este non é o caso das redes reais. Polo tanto, ao deseñar PVRB para tarefas específicas nas cadeas de bloques modernas, ademais da imposibilidade de controlar a aleatoriedade e a forza criptográfica resultantes, xorden moitos máis problemas puramente arquitectónicos e técnicos.

Para PVRB, a propia cadea de bloques é esencialmente un medio de comunicación no que mensaxes = transaccións. Isto permítelle abstraer parcialmente os problemas de rede, a non entrega de mensaxes, os problemas co middleware - todos estes riscos son asumidos pola rede descentralizada e o seu principal valor para PVRB é a incapacidade de revogar ou corromper unha transacción xa enviada - isto fai. non permitir que os participantes se neguen a participar no protocolo, a non ser que realizasen un ataque exitoso ao consenso. Este nivel de seguridade é aceptable, polo que PVRB debe ser resistente á connivencia dos participantes exactamente na mesma medida que a cadea de bloques principal. Ademais, isto insinúa que o PVRB debe formar parte do consenso se a rede está de acordo na cadea de bloques principal, aínda que tamén estea de acordo no único aleatorio xusto resultante. Ou, PVRB é simplemente un protocolo autónomo implementado por un contrato intelixente que funciona de forma asíncrona con respecto á cadea de bloques e aos bloques. Ambos métodos teñen as súas vantaxes e desvantaxes, e a elección entre eles é moi pouco trivial.

Dúas formas de implementar PVRB

Describamos con máis detalle dúas opcións para implementar PVRB: a versión independente, que funciona mediante un contrato intelixente independente da cadea de bloques, e a versión integrada por consenso, integrada no protocolo, segundo a cal a rede acorda a cadea de bloques e a transaccións a incluír. En todos os casos, voume dicir motores de cadea de bloques populares: Ethereum, EOS e todos aqueles que se lles parezan na forma en que aloxan e procesan contratos intelixentes.

Contrato autónomo

Nesta versión, PVRB é un contrato intelixente que acepta transaccións de produtores aleatorios (en diante RP), procesaas, combina os resultados e, como resultado, chega a un determinado valor que calquera usuario pode recibir deste contrato. Este valor pode non almacenarse directamente no contrato, senón que só se representa mediante datos a partir dos cales se pode obter determinísticamente un e só un valor do aleatorio resultante. Neste esquema, os RP son usuarios da cadea de bloques e calquera pode ser autorizado a participar no proceso de xeración.

A opción con contrato autónomo é boa:

• portabilidade (os contratos pódense arrastrar de blockchain a blockchain)
• facilidade de implementación e proba (os contratos son fáciles de escribir e probar)
• conveniencia na implementación de esquemas económicos (é doado facer o teu propio token, cuxa lóxica serve aos propósitos de PVRB)
• posibilidade de lanzar en blockchains que xa funcionan

Tamén ten desvantaxes:

• fortes limitacións nos recursos informáticos, o volume de transaccións e o almacenamento (noutras palabras, cpu/mem/io)
• restricións nas operacións dentro do contrato (non todas as instrucións están dispoñibles, é difícil conectar bibliotecas externas)
• incapacidade para organizar a mensaxería máis rápido que as transaccións incluídas na cadea de bloques

Esta opción é adecuada para implementar un PVRB que debe executarse nunha rede existente, non contén criptografía complexa e non require un gran número de interaccións.

Integrado en consenso

Nesta versión, PVRB está implementado no código do nodo blockchain, incorporado ou funcionando en paralelo co intercambio de mensaxes entre os nodos blockchain. Os resultados do protocolo escríbense directamente nos bloques producidos e as mensaxes do protocolo envíanse a través da rede p2p entre os nodos. Dado que o protocolo dá como resultado números que se van escribir en bloques, a rede debe chegar a un consenso sobre eles. Isto significa que as mensaxes PVRB, como as transaccións, deben ser validadas por nodos e incluídas en bloques para que calquera participante da rede poida validar o cumprimento do protocolo PVRB. Isto lévanos automaticamente á solución obvia: se a rede acorda un consenso sobre un bloque e transaccións nel, entón PVRB debería formar parte do consenso e non un protocolo autónomo. En caso contrario, é posible que un bloque sexa válido dende o punto de vista de consenso, pero non se segue o protocolo PVRB, e dende o punto de vista do PVRB non se pode aceptar o bloqueo. Polo tanto, se se elixe a opción "integrada no consenso", o PVRB convértese nunha parte importante do consenso.

Ao describir as implementacións de PVRB a nivel de consenso de rede, non se pode evitar de ningún xeito cuestións de finalidade. A finalidade é un mecanismo empregado nos consensos deterministas que encerra nun bloque (e a cadea que leva a el) que é definitivo e que nunca será tirado, aínda que se produza unha bifurcación paralela. Por exemplo, en Bitcoin non existe tal mecanismo: se publicas unha cadea de maior complexidade, substituirá a outra menos complexa, independentemente da lonxitude das cadeas. E en EOS, por exemplo, os definitivos son os chamados Últimos Bloques Irreversibles, que aparecen de media cada 432 bloques (12*21 + 12*15, pre-voto + pre-commit). Este proceso está esencialmente á espera de 2/3 das firmas dos produtores de bloques (en diante BP). Cando aparecen garfos que son máis antigos que a última LIB, simplemente descartanse. Este mecanismo permite garantir que a transacción está incluída na cadea de bloques e que nunca se revertirá, sen importar os recursos que teña o atacante. Ademais, os bloques finais son bloques asinados por 2/3 BP en Hyperledger, Tendermint e outros consensos baseados en pBFT. Ademais, ten sentido facer un protocolo para garantir a finalidade un complemento ao consenso, xa que pode funcionar de forma asíncrona coa produción e publicación de bloques. Aquí tes un bo artigo sobre a finalidade en Ethereum.

A finalidade é extremadamente importante para os usuarios, que sen ela poden verse vítimas dun ataque de "dobre gasto", onde BP "retén" bloques e publícaos despois de que a rede "vira" unha boa transacción. Se non hai finalidade, entón a bifurcación publicada substitúe o bloque cunha transacción "boa" por outra, procedente dunha garfo "mala", na que se transfiren os mesmos fondos ao enderezo do atacante. No caso de PVRB, os requisitos de finalidade son aínda máis estritos, xa que construír bifurcacións para PVRB supón a oportunidade para un atacante de preparar varias opcións aleatorias para publicar a máis rendible, e limitar o tempo dun posible ataque é un problema. boa solución.

Polo tanto, a mellor opción é combinar PVRB e finalidade nun só protocolo; entón o bloque finalizado = finalizado aleatorio, e isto é exactamente o que necesitabamos conseguir. Agora os xogadores recibirán un aleatorio garantido en N segundos e poden estar seguros de que é imposible retroceder ou reproducilo de novo.

A opción integrada no consenso é boa:

• a posibilidade de implementación asíncrona en relación á produción de bloques: os bloques prodúcense como de costume, pero paralelamente a isto, pode funcionar o protocolo PVRB, que non produce aleatoriedade para cada bloque
• a capacidade de implementar incluso criptografía pesada, sen as restricións impostas aos contratos intelixentes
• a capacidade de organizar o intercambio de mensaxes máis rápido que as transaccións que se inclúen na cadea de bloques, por exemplo, parte do protocolo pode funcionar entre nós sen distribuír mensaxes pola rede

Tamén ten desvantaxes:

• Dificultades nas probas e no desenvolvemento: terás que emular os erros de rede, os nodos que faltan, as bifurcacións de rede.
• Os erros de implementación requiren un hardfork de rede

Ambos os métodos de implementación de PVRB teñen dereito á vida, pero a implementación en contratos intelixentes nas cadeas de bloques modernas aínda é bastante limitada nos recursos informáticos e calquera transición a unha criptografía seria adoita ser simplemente imposible. E necesitaremos unha criptografía seria, como se demostrará a continuación. Aínda que este problema é claramente temporal, é necesaria unha criptografía seria nos contratos para resolver moitos problemas e vai aparecendo gradualmente (por exemplo, contratos do sistema para zkSNARK en Ethereum)

Blockchain, que ofrece unha canle de mensaxería de protocolo transparente e fiable, non o fai de forma gratuíta. Calquera protocolo descentralizado debe ter en conta a posibilidade dun ataque Sybil; calquera acción pode ser realizada polas forzas concertadas de múltiples contas, polo tanto, ao deseñar, é necesario ter en conta a capacidade dos atacantes para crear un número arbitrario de protocolos. participantes que actúan en connivencia.

PVRB e variables de bloque.

Non mentín cando dixen que aínda ninguén implementou un bo PVRB, probado por moitas aplicacións de xogos de azar, en blockchains. De onde veñen, entón, tantas aplicacións de xogos de azar en Ethereum e EOS? Isto sorpréndeme tanto como a vostede, de onde sacaron tantos aleatorios "persistentes" nun ambiente completamente determinista?

A forma favorita de obter aleatoriedade na cadea de bloques é tomar algún tipo de información "imprevisible" do bloque e facer unha aleatoria baseada nel, simplemente co hash dun ou máis valores. Bo artigo sobre os problemas deste tipo de esquemas aquí. Podes tomar calquera dos valores "imprevisibles" do bloque, por exemplo, o hash do bloque, o número de transaccións, a complexidade da rede e outros valores descoñecidos de antemán. A continuación, trituralos, un ou máis, e, en teoría, deberías obter un aleatorio real. Incluso podes engadir ao papel blanco que o teu esquema é "seguro poscuántico" (xa que hai funcións hash a proba cuántica :)).

Pero mesmo os hash seguros poscuánticos non son suficientes, por desgraza. O segredo reside nos requisitos para PVRB, permíteme lembralos do artigo anterior:

1. O resultado debe ter unha distribución probabelmente uniforme, é dicir, basearse nunha criptografía probabelmente forte.
2. Non é posible controlar ningún dos bits do resultado. Como consecuencia, o resultado non se pode prever con antelación.
3. Non pode sabotear o protocolo de xeración non participando no protocolo ou sobrecargando a rede con mensaxes de ataque
4. Todo o anterior debe ser resistente á connivencia dun número permitido de participantes de protocolo deshonestos (por exemplo, 1/3 dos participantes).

Neste caso, só se cumpre o requisito 1 e non se cumpre o requisito 2. Ao hash valores imprevisibles do bloque, obteremos unha distribución uniforme e boas aleatorias. Pero BP polo menos ten a opción de "publicar o bloque ou non". Así, BP pode polo menos escoller entre DÚAS opcións aleatorias: "a súa propia" e a que resultará se outra persoa fai o bloqueo. BP pode "espigar" con antelación o que ocorrerá se publica un bloque e simplemente decide facelo ou non. Así, cando xoga, por exemplo, "par-impar" ou "vermello/negro" na ruleta, só pode publicar un bloque se ve unha vitoria. Isto tamén fai inviable a estratexia de usar, por exemplo, un bloque hash "do futuro". Neste caso, din que “utilizarase o aleatorio, que se obtén co hash dos datos actuais e o hash dun bloque futuro cunha altura de, por exemplo, N + 42, onde N é a altura do bloque actual. Isto fortalece un pouco o esquema, pero aínda así permite que BP, aínda que no futuro, elixa se manter o bloqueo ou publicar.

O software BP neste caso faise máis complicado, pero non moito. Simplemente, ao validar e incluír unha transacción nun bloque, hai unha comprobación rápida para ver se haberá unha vitoria e, posiblemente, selección de parámetros dunha transacción para obter unha alta probabilidade de gañar. Ao mesmo tempo, é case imposible atrapar un BP intelixente para tales manipulacións; cada vez podes usar novos enderezos e gañar pouco a pouco sen espertar sospeitas.

Polo tanto, os métodos que usan información do bloque non son axeitados como implementación universal de PVRB. Nunha versión limitada, con restricións no tamaño das apostas, restricións no número de xogadores e/ou rexistro KYC (para evitar que un xogador use varios enderezos), estes esquemas poden funcionar para xogos pequenos, pero nada máis.

PVRB e commit-reveal.

Vale, grazas ao hash e polo menos á relativa imprevisibilidade do bloque hash e outras variables. Se resolves o problema dos mineiros de cabeza, deberías conseguir algo máis axeitado. Engademos usuarios a este esquema; deixe que tamén inflúan na aleatoriedade: calquera empregado de soporte técnico dirá que o máis aleatorio dos sistemas informáticos son as accións dos usuarios :)

Un esquema inxenuo, cando os usuarios simplemente envían números aleatorios e o resultado se calcula como, por exemplo, un hash da súa suma, non é adecuado. Neste caso, o último xogador pode, escollendo o seu propio chou, controlar cal será o resultado. É por iso que se usa o patrón de revelación de compromiso moi utilizado. Os participantes primeiro envían hashes dos seus aleatorios (commits) e despois abren os propios aleatorios (revela). A fase de "revelación" comeza só despois de que se recolleron os compromisos necesarios, polo que os participantes poden enviar exactamente o hash aleatorio desde o que enviaron anteriormente. Agora imos xuntar todo isto cos parámetros dun bloque, e mellor que un tomado do futuro (a aleatoriedade só se pode atopar nun dos bloques futuros), e listo - a aleatoriedade está lista! Agora calquera xogador inflúe na aleatoriedade resultante e pode "derrotar" o BP malicioso anulándoo coa súa propia aleatoriedade, descoñecida de antemán... Tamén podes engadir protección contra sabotear o protocolo sen abrilo na fase de revelación, simplemente. ao esixir que se achegue unha determinada cantidade á transacción ao realizar a transacción: un depósito de seguridade, que só se devolverá durante o procedemento de revelación. Neste caso, cometer e non revelar non será rendible.

Foi un bo intento, e tales esquemas tamén existen nas DApps de xogos, pero por desgraza, isto de novo non é suficiente. Agora non só o mineiro, senón tamén calquera participante no protocolo pode influír no resultado. Aínda é posible controlar o valor en si, con menor variabilidade e cun custo, pero, como no caso do mineiro, se os resultados do sorteo son máis valiosos que a taxa de participación no protocolo PVRB, entón o aleatorio. -producer(RP) pode decidir se quere revelar e aínda pode escoller entre polo menos dúas opcións aleatorias.
Pero fíxose posible castigar aos que cometen e non revelan, e este esquema será útil. A súa sinxeleza é unha vantaxe importante: os protocolos máis serios requiren cálculos moito máis potentes.

PVRB e sinaturas deterministas.

Hai outra forma de forzar o RP a proporcionar un número pseudoaleatorio que non pode influír se se lle proporciona unha "preimaxe": esta é unha sinatura determinista. Tal sinatura é, por exemplo, RSA e non ECS. Se RP ten un par de claves: RSA e ECC, e asina un determinado valor coa súa clave privada, entón no caso de RSA obterá UNHA E SÓ UNHA sinatura, e no caso de ECS pode xerar calquera número de claves. diferentes sinaturas válidas. Isto débese a que ao crear unha sinatura ECS utilízase un número aleatorio, elixido polo asinante, e pódese escoller de calquera forma, dándolle a oportunidade de elixir unha das varias sinaturas. No caso de RSA: "un valor de entrada" + "un par de claves" = "unha sinatura". É imposible predicir que sinatura obterá outro RP, polo que se pode organizar un PVRB con sinaturas deterministas combinando as sinaturas RSA de varios participantes que asinaron o mesmo valor. Por exemplo, o aleatorio anterior. Este esquema aforra moitos recursos, porque as sinaturas son á vez a confirmación do comportamento correcto segundo o protocolo e unha fonte de aleatoriedade.

Non obstante, mesmo con sinaturas deterministas, o esquema segue sendo vulnerable ao problema do "último actor". O último participante aínda pode decidir se publica a sinatura ou non, controlando así o resultado. Pode modificar o esquema, engadirlle hash de bloque, facer roldas para que o resultado non se poida prever con antelación, pero todas estas técnicas, aínda tendo en conta moitas modificacións, aínda deixan sen resolver o problema da influencia dun participante no colectivo. dar lugar a un ambiente pouco fiable e só pode funcionar baixo limitacións económicas e de tempo. Ademais, o tamaño das claves RSA (1024 e 2048 bits) é bastante grande e o tamaño para as transaccións en cadea de bloques é un parámetro moi importante. Ao parecer non hai unha forma sinxela de resolver o problema, sigamos adiante.

PVRB e esquemas de compartición de segredos

En criptografía, hai esquemas que poden permitir que a rede acorde un e só un valor PVRB, mentres que tales esquemas son resistentes a calquera acción maliciosa dalgúns participantes. Un protocolo útil co que paga a pena familiarizarse é o esquema de compartición secreta de Shamir. Serve para dividir un segredo (por exemplo, unha clave secreta) en varias partes e distribuír estas partes a N participantes. O segredo distribúese de tal xeito que M partes de N son suficientes para recuperalo, e estas poden ser calquera M partes. Se nos dedos, tendo unha gráfica dunha función descoñecida, os participantes intercambian puntos na gráfica e, despois de recibir M puntos, pódese restaurar toda a función.
Dáse unha boa explicación wiki pero xogar con el practicamente para xogar o protocolo na túa cabeza é útil para demostración páxina.

Se o esquema FSSS (Fiat-Shamir Secret Sharing) fose aplicable na súa forma pura, sería un PVRB indestructible. Na súa forma máis sinxela, o protocolo pode verse así:

• Cada participante xera o seu propio azar e distribúe as accións a outros participantes
• Cada participante revela a súa parte dos segredos dos demais participantes
• Se un participante ten máis de M accións, pódese calcular o número deste participante e será único, independentemente do conxunto de participantes revelados.
• A combinación de aleatorios revelados é o PVRB desexado

Aquí, un participante individual xa non inflúe nos resultados do protocolo, agás nos casos nos que a consecución do limiar de divulgación de aleatoriedade depende só del. Polo tanto, este protocolo, se hai unha proporción requirida de RPs traballando no protocolo e dispoñible, funciona, implementando os requisitos de forza criptográfica e sendo resistente ao problema do "último actor".

Esta podería ser unha opción ideal, este esquema PVRB baseado no intercambio de segredos Fiat-Shamir descríbese, por exemplo, en isto artigo. Pero, como se mencionou anteriormente, se tentas aplicalo frontalmente na cadea de bloques, aparecen limitacións técnicas. Aquí tes un exemplo de implementación de proba do protocolo no contrato intelixente EOS e a súa parte máis importante: comprobar o participante compartido publicado: código. Podes ver no código que a validación da proba require varias multiplicacións escalares e que os números utilizados son moi grandes. Débese entender que nas cadeas de bloques, a verificación ocorre no momento en que o produtor de bloques procesa a transacción e, en xeral, calquera participante debe verificar facilmente a corrección do protocolo, polo que os requisitos para a velocidade da función de verificación son moi serios. . Nesta opción, a opción resultou ser ineficaz, xa que a verificación non se axustaba ao límite de transacción (0.5 segundos).

A eficiencia da verificación é un dos requisitos máis importantes para o uso, en xeral, de calquera esquema criptográfico avanzado na cadea de bloques. Creación de probas, preparación de mensaxes - estes procedementos pódense sacar fóra da cadea e realizarse en ordenadores de alto rendemento, pero a verificación non se pode ignorar - este é outro requisito importante para PVRB.

PVRB e sinaturas de limiar

Coñecendo o esquema de compartición secreta, descubrimos toda unha clase de protocolos unidos pola palabra clave "limiar". Cando a divulgación dalgunha información require a participación de M participantes honestos de N, e o conxunto de participantes honestos pode ser un subconxunto arbitrario de N, falamos de esquemas "limiar". Son eles os que nos permiten tratar o problema do "último actor", agora se o atacante non revela a súa parte do segredo, outro participante honesto farao por el. Estes esquemas permiten acordar un e só un significado, aínda que o protocolo sexa saboteado por algúns dos participantes.

A combinación de sinaturas deterministas e esquemas de limiar fixo posible desenvolver un esquema moi cómodo e prometedor para a implementación de PVRB: son sinaturas de limiar deterministas. Aquí artigo sobre os distintos usos das sinaturas de limiar, e aquí tes outro bo longa lectura de Dash.

O último artigo describe as sinaturas BLS (BLS significa Boneh-Lynn-Shacham, velaquí artigo), que teñen unha calidade moi importante e extremadamente conveniente para os programadores: as claves públicas, secretas, públicas e as sinaturas BLS pódense combinar entre si mediante operacións matemáticas sinxelas, mentres que as súas combinacións seguen sendo claves e sinaturas válidas, o que lle permite agregar facilmente moitas sinaturas nunha e moitas claves públicas nunha. Tamén son deterministas e producen o mesmo resultado para os mesmos datos de entrada. Debido a esta calidade, as combinacións de sinaturas BLS son en si mesmas claves válidas, o que permite a implementación dunha opción na que M de N participantes producen unha e só unha sinatura que é determinista, verificable publicamente e impredicible ata que sexa aberta polo Mth. participante.

Nun esquema con sinaturas BLS de limiar, cada participante asina algo usando BLS (por exemplo, o aleatorio anterior) e a sinatura de limiar común é a aleatoria desexada. As propiedades criptográficas das sinaturas BLS satisfacen os requisitos de calidade aleatoria, a parte limiar protexe contra o "último actor" e a combinabilidade única de claves permite implementar moitos algoritmos máis interesantes que permiten, por exemplo, a agregación eficiente de mensaxes de protocolo. .

Entón, se está a construír PVRB na súa cadea de bloques, o máis probable é que acabe co esquema de sinaturas de limiar BLS, xa o están a usar varios proxectos. Por exemplo, DFinity (aquí punto de referencia que implementa o circuíto, e aquí exemplo de implementación de compartición de segredos verificables) ou Keep.network (aquí está a súa baliza aleatoria papel amareloe aquí exemplo contrato intelixente ao servizo do protocolo).

Implantación de PVRB

Desafortunadamente, aínda non vemos un protocolo listo implementado nas cadeas de bloques PVRB que demostre a súa seguridade e estabilidade. Aínda que os propios protocolos están listos, aplicalos tecnicamente ás solucións existentes non é doado. Para os sistemas centralizados, PVRB non ten sentido, e os descentralizados están estrictamente limitados en todos os recursos informáticos: CPU, memoria, almacenamento, E/S. Deseñar un PVRB é unha combinación de diferentes protocolos para crear algo que cumpra todos os requisitos para polo menos algunha cadea de bloques viable. Un protocolo calcula de forma máis eficiente, pero require máis mensaxes entre RP, mentres que o outro require moi poucas mensaxes, pero crear unha proba pode ser unha tarefa que leva decenas de minutos ou incluso horas.

Listarei os factores que terás que ter en conta ao elixir un PVRB de calidade:

• Forza criptográfica. O seu PVRB debe ser estrictamente imparcial, sen poder controlar un só bit. Nalgúns esquemas este non é o caso, así que chame a un criptógrafo
• O problema do "último actor".. O teu PVRB debe ser resistente aos ataques nos que un atacante que controla un ou máis RP pode escoller un dos dous resultados.
• Problema de sabotaxe do protocolo. O teu PVRB debe ser resistente aos ataques nos que un atacante que controla un ou máis RP decide se é aleatorio ou non e pode estar garantido ou cunha probabilidade determinada de influír neste
• Problema de número de mensaxes. Os teus RP deberían enviar un mínimo de mensaxes á cadea de bloques e evitar na medida do posible accións sincrónicas, como situacións como "Enviei información, estou esperando unha resposta dun participante específico". Nas redes p2p, especialmente as dispersas xeograficamente, non debes contar cunha resposta rápida
• O problema da complexidade computacional. A verificación de calquera fase da cadea PVRB debería ser extremadamente sinxela, xa que a realizan todos os clientes completos da rede. Se a implementación faise mediante un contrato intelixente, os requisitos de velocidade son moi estritos
• O problema da accesibilidade e da vida. O seu PVRB debe esforzarse por ser resistente ás situacións nas que parte da rede non está dispoñible durante un período de tempo e parte do RP simplemente deixa de funcionar
• O problema da configuración de confianza e da distribución inicial de chaves. Se o teu PVRB usa a configuración principal do protocolo, esta é unha historia grande e seria. Aquí exemplo. Se os participantes deben comunicarse mutuamente as súas chaves antes de iniciar o protocolo, isto tamén é un problema se cambia a composición dos participantes
• Problemas de desenvolvemento. Dispoñibilidade de bibliotecas nos idiomas requiridos, a súa seguridade e rendemento, publicidade, probas complexas, etc.

Por exemplo, as sinaturas de limiar BLS teñen un problema importante: antes de comezar a traballar, os participantes deben distribuír as claves entre si, organizando un grupo dentro do cal funcionará o limiar. Isto significa que polo menos unha rolda de intercambio nunha rede descentralizada terá que esperar, e dado que o rand xerado, por exemplo, é necesario nos xogos, case en tempo real, isto significa que a sabotaxe do protocolo é posible nesta fase. , e pérdense as vantaxes do esquema de limiar . Este problema xa é máis sinxelo que os anteriores, pero aínda así require o desenvolvemento dun procedemento separado para a formación de grupos limiares, que terán que ser protexidos economicamente, mediante depósitos e retirada de fondos (recorte) aos participantes que non sigan o protocolo. Ademais, a verificación BLS cun nivel aceptable de seguridade simplemente non encaixa, por exemplo, nunha transacción estándar EOS ou Ethereum; simplemente non hai tempo suficiente para a verificación. O código do contrato é WebAssembly ou EVM, executado por unha máquina virtual. As funcións criptográficas non se implementan de forma nativa (aínda) e funcionan decenas de veces máis lento que as bibliotecas criptográficas convencionais. Moitos protocolos non cumpren os requisitos simplemente baseándose no volume de claves, por exemplo 1024 e 2048 bits para RSA, 4-8 veces maior que a sinatura estándar de transacción en Bitcoin e Ethereum.

Tamén xoga un papel a presenza de implementacións en diferentes linguaxes de programación, das que hai poucas, especialmente para novos protocolos. A opción con integración en consenso require escribir un protocolo na linguaxe da plataforma, polo que terás que buscar código en Go for geth, en Rust for Parity, en C++ para EOS. Todo o mundo terá que buscar código JavaScript, e dado que JavaScript e a criptografía non son amigos especialmente íntimos, WebAssembly axudará, que agora definitivamente afirma ser o seguinte estándar importante de Internet.

Conclusión

Espero que no anterior Artigo Conseguín convencerte de que xerar números aleatorios na cadea de bloques é fundamental para moitos aspectos da vida das redes descentralizadas, e con este artigo demostrei que esta tarefa é extremadamente ambiciosa e difícil, pero que xa existen boas solucións. En xeral, o deseño final do protocolo só é posible despois de realizar probas masivas que teñan en conta todos os aspectos, desde a configuración ata a emulación de fallos, polo que é improbable que atopes receitas preparadas nos artigos e artigos do equipo, e certamente non o imos facer. decide no próximo ano ou dous escribe "faino deste xeito, exactamente correcto".

Adeus, para o noso PVRB na cadea de bloques que se está a desenvolver Haya, decidimos usar sinaturas BLS de limiar, pensamos implementar PVRB a nivel de consenso, xa que aínda non é posible a verificación en contratos intelixentes cun nivel de seguridade aceptable. É posible que usemos dous esquemas á vez: primeiro, compartir segredos caros para crear random_seed a longo prazo, e despois usámolo como base para a xeración aleatoria de alta frecuencia usando sinaturas BLS de limiar deterministas, quizais limitarémonos a só un dos esquemas. Desafortunadamente, é imposible dicir de antemán cal será o protocolo; o único bo é que, como na ciencia, nos problemas de enxeñaría, un resultado negativo tamén é un resultado, e cada novo intento de resolver o problema é un paso máis para a investigación de todos os implicados no problema. Para satisfacer os requisitos empresariais, resolvemos un problema práctico específico: proporcionar aplicacións de xogos cunha fonte fiable de entropía, polo que tamén temos que prestar atención á propia cadea de bloques, en particular aos problemas de finalidade da cadea e goberno da rede.

E aínda que aínda non vemos un PVRB resistente comprobado nas cadeas de bloques, que tería sido usado durante o tempo suficiente para ser probado por aplicacións reais, auditorías múltiples, cargas e, por suposto, ataques reais, pero o número de camiños posibles confirma que existe unha solución, e cal destes algoritmos acabará por resolver o problema. Estaremos encantados de compartir os resultados e agradecer a outros equipos que tamén están a traballar neste tema por artigos e códigos que permitan aos enxeñeiros non pisar o mesmo anciño dúas veces.

Entón, cando coñeces a un programador que deseña un programa aleatorio descentralizado, estea atento e coidadoso e proporciona axuda psicolóxica se é necesario :)

Fonte: www.habr.com