Nuevo sistema de identificación de Lisk

enero 23, 2022 VICTOR HUGO LAZARTE 0 Comments

En este artículo, brindamos una descripción general de las principales mejoras relacionadas con el nuevo sistema de identificación introducido en la plataforma Lisk, como parte de la fase de longevidad de la red de la hoja de ruta del protocolo Lisk . Todos estos cambios se especifican formalmente como propuestas de mejora de Lisk (LIP) que se han investigado y revisado a fondo.

Comenzamos introduciendo los principales conceptos técnicos utilizados en este artículo. A esto le sigue una explicación del nuevo sistema de direcciones para el ecosistema Lisk ( LIP 0018 ). Lo discutimos desde la perspectiva del protocolo y también desde la perspectiva de la interfaz de usuario. A continuación, sigue el nuevo formato de identificación para transacciones ( LIP 0019 ) y, finalmente, cubre el nuevo sistema de identificación para bloques en Lisk ( LIP 00 20).

Experiencia técnica

Este artículo menciona algunos conceptos técnicos que son importantes para comprender completamente la motivación detrás del nuevo sistema de identificación. En esta sección, explicamos brevemente estos conceptos en caso de que no esté familiarizado con ellos.

Conceptos básicos de hash

Una función hash es una función que asigna una entrada de tamaño arbitrario a una salida de tamaño fijo. Una de las funciones hash más utilizadas es SHA-256, que tiene una longitud de salida fija de 256 bits. Una función hash criptográfica es una función hash adecuada para su uso en criptografía y se requiere que tenga algunas propiedades adicionales. En este artículo, estamos particularmente interesados en las siguientes dos propiedades de las funciones hash criptográficas: resistencia a la preimagen y resistencia a la colisión.

Resistencia a la preimagen

Dada cualquier salida hash, debería ser difícil encontrar una entrada que proporcione esta salida. Las funciones que carecen de esta propiedad son vulnerables a los ataques de preimagen . Si la longitud de salida es de 128 bits, entonces hay 2 128 salidas posibles de la función hash. Para una función hash criptográfica, se supone que estas salidas son igualmente probables. Entonces, a su vez, se necesitarían 2 128 intentos para encontrar la entrada que produzca la salida hash deseada. Esto se considera lo suficientemente difícil como para que se suponga que las salidas de hash de al menos 128 bits de longitud son seguras en la comunidad criptográfica.

Resistencia a colisiones

Una función hash es resistente a colisiones, si es difícil encontrar dos entradas diferentes de modo que sus salidas hash sean las mismas. Cuando esto ocurre, lo definimos como una colisión hash. Cada función hash tiene colisiones debido al tamaño fijo de la salida y la cantidad infinita de entradas posibles. En este contexto, difícil significa que básicamente no hay mejor manera de encontrar una colisión hash que probar numerosas entradas hasta que dos de ellas produzcan el mismo resultado.

Representación de Números

En este artículo, vemos diferentes representaciones numéricas utilizadas para representar direcciones y claves públicas tanto en el formato antiguo como en el nuevo. La siguiente tabla muestra un ejemplo básico de estas representaciones numéricas y ejemplos de uso:

Nuevo sistema de direcciones para el ecosistema de Lisk

En Lisk, se genera una dirección a partir de la frase de contraseña de 12 palabras elegida inicialmente por el usuario para crear una nueva cuenta. Esta frase de contraseña se codifica con SHA-256 en una cadena de 256 bits. Esta cadena se utiliza como semilla para generar tanto la clave privada como la clave pública utilizando el esquema de firma Ed25519 . A esto le sigue un paso final que transforma la clave pública en la dirección.

En el protocolo Lisk original, este último paso consiste en tomar los primeros 64 bits del hash SHA-256 de la clave pública y revertirlos. Luego, la salida se convierte a una representación decimal y se adjunta una 'L' mayúscula al final para dar la representación final de la dirección.

Este formato de dirección fue diseñado con el objetivo de ser conveniente para los usuarios al leer, escribir o comunicar una dirección. Sin embargo, también presenta tres carencias relevantes, dos de ellas afectan a la seguridad de los usuarios:

Baja resistencia a la preimagen
En la actualidad, se recomienda encarecidamente a los titulares de Lisk que realicen al menos una transacción desde su cuenta. De esta manera, su clave pública se almacena en la cadena de bloques de Lisk como parte de la cuenta, y solo esta clave pública puede firmar transacciones futuras desde la cuenta. De lo contrario, cualquier persona que tenga una clave pública que proporcione la misma dirección podría acceder a todos los fondos de la cuenta. Para 64 bits, esto todavía es muy poco probable, pero como se mencionó anteriormente, la resistencia de preimagen de 128 bits se considera segura, mientras que la resistencia de preimagen de 64 bits generalmente se considera demasiado baja a largo plazo.
Baja resistencia a la colisión
Debido a la longitud de sólo 64 bits, la probabilidad de que haya una colisión de direcciones, es decir, dos usuarios que generen al mismo tiempo pares de claves que produzcan la misma dirección, no es insignificante. Tenga en cuenta que las colisiones no proporcionan ningún valor a un atacante per se, pero pueden provocar una pérdida accidental de dinero si un nuevo usuario genera una dirección existente.
Sin detección de errores
Las direcciones no tienen ningún mecanismo para detectar errores tipográficos o errores en una dirección. Por lo tanto, escribir mal un solo carácter de la dirección en una transacción de transferencia de saldo da como resultado el envío de fondos a una cuenta diferente. Además, esos fondos se perderán para siempre si ningún usuario tiene el par de claves correspondiente para la cuenta receptora.

Explicaremos en las siguientes subsecciones cómo el nuevo sistema de direcciones resuelve estas deficiencias y cómo planeamos migrar a él en la plataforma Lisk.

Nueva direccion

A nivel de protocolo, la nueva dirección son los 160 bits más significativos del hash SHA-256 de la clave pública de la cuenta. Por ejemplo, supongamos que tenemos una clave pública, dada en formato hexadecimal como se muestra a continuación: `0x0eb0a6d7b862dc35c856c02c47fde3b4f60f2f3571a888b9a8ca7540c6793243`, a continuación, la dirección utilizada a nivel de protocolo es el siguiente:` 0xc247a42e09e6aafd818821f75b2f5b0de47c8235` (se trata de una norma común para agregar el prefijo ` 0x` a representaciones hexadecimales).

Con una longitud de 160 bits, las nuevas direcciones son lo suficientemente largas como para que sea computacionalmente inviable encontrar un nuevo par de claves (clave pública y clave privada), que devuelva una dirección existente. Una cadena larga de 160 bits significa que uno tiene que probar 2 160 pares de claves en promedio para encontrar el par de claves para una dirección determinada (consulte Resistencia de preimagen arriba). Por lo tanto, los usuarios ya no necesitan realizar el proceso de transacción de registro inicial. Esto también significa que es prácticamente imposible que dos usuarios independientes elijan dos pares de claves que den como resultado la misma dirección.

Sin embargo, tratar con estas cadenas hexadecimales puede resultar tedioso y propenso a errores para los usuarios finales. Codificamos esta cadena de 160 bits de manera que el formato de la dirección en el nivel de la interfaz de usuario sea más fácil de usar, más compacto y evite errores de escritura o errores de copiar y pegar. Veamos cómo funciona esta codificación en la siguiente subsección.

Representación de direcciones para el nivel de interfaz de usuario

Para los usuarios de la plataforma Lisk, las direcciones siempre se mostrarán en un formato Base32 fácil de usar e incluirán una suma de verificación que detecta errores de tipeo. Esto significa que en lugar de '0xc247a42e09e6aafd818821f75b2f5b0de47c8235', la dirección de ejemplo anterior se verá como 'lsk24cd35u4jdq8szo3pnsqe5dsxwrnazyqqqg5eu' .

Esta representación de la dirección de la interfaz de usuario siempre tiene 41 caracteres, contiene dígitos decimales y letras minúsculas del alfabeto latino y comienza con el prefijo 'lsk'. Básicamente, la codificación de las direcciones para el nivel de la interfaz de usuario se divide en tres pasos principales que se enumeran a continuación:

Calcule una suma de verificación de 30 bits de la dirección de 160 bits y agregue esta suma de verificación a la dirección.
Codifique la salida en el formato Base32.
Anteponga el prefijo "lsk" a la salida anterior.

En el siguiente diagrama, podemos ver cómo funciona todo el proceso de generación de direcciones en cada paso, y cómo se aplica para nuestra clave pública inicial: `0x0eb0a6d7b862dc35c856c02c47fde3b4f60f2f3571a888b9a8ca7540c6793243`

Veamos por qué introdujimos estos pasos de suma de verificación de código BCH y codificación Base32 en las siguientes subsecciones.

Capacidades de suma de comprobación y detección de errores

Una suma de comprobación es un pequeño fragmento de datos redundantes añadido a un determinado bloque de datos, concretamente con el fin de detectar errores que pueden haberse introducido durante su transmisión o manipulación. El ejemplo más simple y común de suma de comprobación es el bit de paridad. Esto significa que agrega un 0 o 1 adicional a los datos de modo que el número total de 1 en la representación binaria sea par. Esto le permite detectar cambios de un solo bit o un número impar de bits. Con este objetivo, introdujimos una suma de comprobación de 30 bits para que formara parte de la dirección. Esto se calcula usando el mismo código BCH que se usa en bech32 para Bitcoin.

Gracias a esta suma de verificación añadida, un usuario puede escribir mal hasta 4 caracteres en la dirección y se garantiza que la aplicación lo detectará. No importa si los errores se introducen en la parte de checksum, y/o en la parte que representa la dirección de 160 bits. Si el usuario introduce más de 4 errores, ya no hay garantía de detección, pero sí una probabilidad de detección muy alta. Por ejemplo, la probabilidad de detectar 5 errores es superior al 99,9999999%.

Consideremos nuevamente la dirección anterior: 'lsk24cd35u4jdq8szo3pnsqe5dsxwrnazyqqqg5eu' . Para esta dirección, la suma de comprobación (en Base32) es 'qqg5eu'. Imagina que un usuario quiere enviar LSK a esta dirección, el siguiente gráfico muestra cómo enviar una transacción a una dirección que incluye 4 errores sería rechazada por la billetera:

Codificación en formato Base32

Una codificación Base32 básicamente significa que usamos un conjunto de 32 dígitos, cada uno de los cuales representa 5 bits (tenga en cuenta que 32 es 2 5 ). Base32 es especialmente interesante para nuestro caso porque nos permite usar números y letras comunes para representar estos 32 dígitos. Dado que el alfabeto latino moderno tiene 26 letras y hay 10 dígitos decimales, es decir, en total 36 caracteres distintos, tenemos que elegir qué caracteres van a representar nuestro formato Base32. Así, quedan excluidos los caracteres más ambiguos, “i”, “l”, “0” y “1”. Además, por razones de legibilidad, solo usamos letras minúsculas. Por lo tanto, los 32 caracteres utilizados en nuestro formato Base32 en orden de codificación son los siguientes:

“ zxvcpmbn3465o978uyrtkqew2adsjhfg ”

Una dirección en Lisk que contenga un carácter que no esté en esta lista resultará automáticamente en una dirección no válida (excluyendo el 'prefijo lsk)'. Para convertir la dirección a su representación Base32, cada fragmento de 5 bits se asigna al carácter Base32 correspondiente.

Migración al Nuevo Sistema de Direcciones

Para la mayoría de los usuarios, la migración a este nuevo sistema de direcciones se realizará sin problemas. Una vez que se introduzca el nuevo sistema de direcciones, los usuarios aún podrán iniciar sesión en Lisk Mobile o Lisk Desktop con la frase de contraseña como antes. La única diferencia será que ahora la interfaz mostrará la nueva dirección de Lisk en formato Base32, y los usuarios solo podrán enviar dinero a direcciones en este nuevo formato. Por lo tanto, el único requisito para los usuarios es familiarizarse con el nuevo formato de dirección y su apariencia, para que puedan continuar usando la plataforma como de costumbre. Este es el caso de las cuentas con clave pública asociada, que son la mayoría en Lisk.

Solo las cuentas que nunca envían una transacción no se pueden migrar al nuevo sistema de direcciones automáticamente, ya que la clave pública no se almacena en la cadena de bloques de Lisk. Para estas cuentas, los usuarios deberán enviar una vez una transacción de reclamación especial , firmada con su par de claves original para realizar la migración.

Nuevo sistema de identificación para transacciones

En Lisk, cada transacción tiene un identificador, abreviado como un ID de transacción que se supone que identifica de manera única una transacción, ya sea incluida en la cadena de bloques o en espera de inclusión. Actualmente, este ID de transacción es un valor de 64 bits que se muestra en representación decimal en las interfaces de usuario. Por ejemplo, una de las primeras transacciones incluidas en el bloque de génesis de Lisk tiene el ID de transacción de ' 5449806225917864483'. Los identificadores de transacciones no sufren las mismas vulnerabilidades de seguridad que las direcciones. Sin embargo, la longitud actual de 64 bits tiene algunos inconvenientes en la experiencia del usuario, ya que la probabilidad de una colisión de hash no es despreciable. Por ejemplo, si cada bloque contiene 120 transacciones, se espera una colisión en aproximadamente 11 años. Esto significa que los usuarios pueden experimentar un escenario en el que la red rechaza una transacción firmada válidamente, debido al requisito de unicidad de los ID de transacción. Más importante aún, el nivel de la interfaz de usuario (por ejemplo, Lisk explorer ) también se vería afectado ya que la transacción ya incluida y la transacción rechazada tienen ID iguales.

La solución para este problema es tan sencilla como puede suponer aquí, y es que necesitamos definir ID de transacciones más largas . Por lo tanto, la nueva ID de transacción es la salida SHA-256 completa de la transacción, que tiene una longitud de 256 bits. Con esta longitud de ID, asumiendo que cada bloque contiene alrededor de 120 transacciones, la probabilidad de tener una colisión dentro de los próximos 50 años es prácticamente nula. Para una representación más compacta en las interfaces de usuario para ID de 256 bits, cambiamos aún más de una representación decimal a una representación hexadecimal. Esto significa que en el futuro aparecerá un ID de transacción como el siguiente: '0xda63e78daf2096db8316a157a839c8b9a616d3ce6692cfe61d6d380a623a1902' en lugar de ' 15822870279184933850' .

Nuevo sistema de identificación para bloques

Los identificadores actuales para bloques, también indicados por ID de bloque, tienen el mismo formato que los ID de transacción, es decir, un valor de 64 bits derivado del encabezado del bloque y que se muestra en representación decimal. Para los identificadores de bloque, el rango limitado de posibles valores de hash proporciona solo una protección relativamente débil contra los ataques previos a la imagen. Esto significa que un atacante podría intentar crear un bloque alternativo con el mismo ID de bloque y también la misma propiedad de bloque anterior que un bloque determinado en la cadena de bloques. Si tienen éxito, se podría engañar a otros miembros de la comunidad para que sincronicen desde la cadena del atacante, ya que podrían estar convencidos de que esto es genuino, ya que la cadena alterada sería válida. Para poder realizar todo el ataque, el atacante necesitaría el par de claves para el delegado de la ranura de bloque correspondiente, para completar ~2 64pasos de cálculo, y también los usuarios objetivo tendrían que sincronizarse con la cadena de bloques alterada. Esto significa que este ataque es muy costoso y complejo de lograr en la práctica.

Sin embargo, para garantizar la inmutabilidad de la cadena de bloques Lisk durante mucho tiempo en el futuro, la nueva identificación del bloque es la salida SHA-256 completa del encabezado del bloque. Esta longitud de 256 bits proporciona resistencia contra ataques de preimagen de 256 bits, lo que hace que el ataque explicado sea inviable en cualquier situación en el futuro previsible.

Esta publicación de blog brinda una descripción general del nuevo sistema de identificación, pero todos los detalles se brindan en los LIP específicos. Para más preguntas y comentarios sobre el tema, organizaremos un AMA en Lisk.chat con Iker Alustiza (Investigador científico) este viernes 24 de julio a las 4 p. m. CEST . También invitamos a todos los miembros de la comunidad a ir al foro de investigación de Lisk, donde siempre nos complace escuchar sus comentarios y participar en debates sobre este y otros temas.

Lisk tiene la misión de permitirle crear aplicaciones de cadena de bloques descentralizadas, eficientes y transparentes.