La Fundación Quantum Resistant Ledger (QRL) anunció el mes pasado, enQlave, la primera billetera digital segura post-cuántica basada en Ethereum del mundo.
Si aún no lo captó, puede leer una introducción a enQlave por Peter Waterland o profundizar con Trayendo seguridad post-cuántica a Ethereum por Charlie Thompson, quien lo resume bien con:
QRL enQlave llevará la seguridad post-cuántica de XMSS (eXtended Merkle Signature Scheme) a mainnet Ethereum, y eventualmente a cualquier otra plataforma blockchain con capacidades de contrato inteligente suficientemente expresivas.
Más allá de brindar la capacidad para cualquiera de las casi 100 millones de direcciones únicas de ethereum que representan 31 mil millones en valor solo en seguridad post-cuántica ETH, enQlave tiene la posibilidad de brindar seguridad post-cuántica a los usuarios de plataformas como Tezos y eosio con suficiente interés y capacidades de contrato inteligente suficientemente expresivas.
El progreso continúa: la auditoría de contratos inteligentes no se queda atrás
En este momento hay una interfaz de trabajo que le permite firmar transacciones, agregar y reemplazar cualquier cantidad de claves y crear tokens resistentes a la cantidad de Ethereum (eQRT).
El contrato inteligente está pasando por algunos toques finales y se está acercando a una revisión final, que será seguida por una auditoría.
La versión se puede encontrar en github: no es una actualización obligatoria, ¡pero ofrece algunas funciones especiales!
Anotaciones de Google para soporte REST para PublicAPI y agregado de google-api-python-client
Esto le dará a cualquier persona una resolución de dirección URL inmediata a PublicAPI de QRL sin tener que instalar, ejecutar y mantener componentes de servidor separados.
Anteriormente, de manera predeterminada, solo tenía acceso a la API del nodo QRL, lo cual está bien cuando se conecta a través de la terminal, pero no es útil al crear aplicaciones, ya que no es tan expresivo y alienta el uso de las funciones ejecutivas de sus idiomas , algo que, según el idioma, puede ser más difícil de mantener seguro.
Pronto podrá utilizar una API REST para devolver información útil. Si, por ejemplo, instala el nodo a través de pip3 y utiliza envoy-proxy, para devolver la altura de bloqueo, la dirección sería https://127.0.0.1:7778/api/height
Si instaló docker, esto sería similar, pero necesitaría obtener la dirección IP de su contenedor.
Otras actualizaciones
Versión actualizada de setuptools a 46.4.0 y protobuf a 3.6.0
El QRL-CLI ha pasado de v1.4.5 → 1.7.1 y ha agregado mejoras, especialmente a nuestro sistema de Sistema de mensajería efímera (EMS).
Oculto en el (los) anuncio (s) de enQlave es que hemos estado trabajando para llevar los contratos inteligentes de OCAML a la plataforma del Libro mayor resistente a la cuantía (QRL) para el próximo hardfork, Cesium.
Del resumen de OCAML:
(OCAML) se usa en entornos donde un solo error puede costar millones y acelerar las cosas. … Es un lenguaje seguro. El compilador verifica los programas antes de que puedan ejecutarse, lo que descarta muchos errores de programación, como, por ejemplo, confundir un número entero para un puntero o acceder a un campo inexistente en un registro.
Si bien actualmente es una vulnerabilidad de riesgo extremadamente bajo, la protección contra ataques de repetición debería considerarse e implementarse idealmente en el próximo hard fork para mitigar completamente este vector de ataque.
El escenario de ataque implica una transacción de una red blockchain que se retransmite a otra a través de un nodo malicioso. Esto es algo posible entre QRL Testnet y QRL Mainnet, sin embargo, no se recomienda utilizar la misma cuenta QRL XMSS en testnet y mainnet debido al riesgo potencial de reutilización de OTS.
Cuando esto se vuelve más pertinente es cuando hay un aumento de múltiples cadenas existentes que persisten donde las personas son más propensas a confundir en qué cadena se encuentran o se inclinan a cambiar entre cadenas y reutilizar cuentas. La posibilidad de que ocurra tal escenario aumentará a medida que se acumule más interés y con ciertos eventos de bifurcación, como el cambio de prueba de trabajo a prueba de participación.
Algunas soluciones propuestas en el QIP son:
Identificación de red – Un identificador numérico único, los nodos en cada red encontrarán inválida cualquier transacción que no use el identificador correcto. Un ejemplo sería '0000' = devnet, '0001' = testnet, '0002' = mainnet, '0003' = mainnet pos, o simplemente estampar el hash del bloque de génesis en cada transacción. Tenga en cuenta que esto no evita los ataques de repetición en bifurcaciones posteriores de una red que utilizan el mismo identificador.
bloquear hash – cada bloque en la cadena tiene un valor hash único obtenido al agregar y trocear el encabezado del bloque (e incorporar el hash del encabezado del bloque anterior). Por lo tanto, estampar cada transacción con un hash de encabezado de bloque de 32 bytes reciente es una forma simple de prevenir un ataque de repetición. La desventaja significativa es que esto requiere que el firmante de la transacción sepa algo sobre la cadena QRL actual, lo que podría ser un problema para la firma de la transacción fuera de línea. Otra consideración es que elegir el bloque más reciente podría llevar a que una transacción ingrese al mempool solo para que el bloque se descarte en un mini tenedor y luego la transacción se vuelva inválida. Entonces tendría sentido elegir un hash de bloque a una profundidad dada desde la punta de la cadena o bloques de época específicos a intervalos de 1k (o algo adecuado).
tx hash – es posible que cada transacción incluya opcionalmente el txhash de la última transacción de la cuenta. Por lo tanto, obligaría a un atacante a reproducir todas las transacciones históricas desde la bifurcación para lograr el éxito; si no hay transacciones desde la bifurcación, esto no sería efectivo para evitar un ataque de repetición.
Si bien este tema ha sido discutido previamente por el equipo central de desarrollo, nos gustaría agradecer a red4sec (quien realizó una de nuestras auditorías) por recordarnos.
La descripción general y la discusión de QIP012 se pueden encontrar en github.
