Como todos saben, blockchain es una nueva tecnología basada en criptografía, economía y redes. Para el público en general, la criptografía no es un tema de fácil acceso. Además, es el tema más “inaccesible”.
Sin embargo, aquellos en el mundo de la cadena de bloques a menudo escucharán el dicho: “Blockchain es una máquina de confianza” u otra persona de blockchain dirá, “en matemáticas, confiamos”. Ambos demuestran que la criptografía es vital y es la base de la tecnología blockchain.
Entonces aquí hay un par de preguntas:
¿En qué exactamente se usa la criptografía dentro del blockchain?
¿Por qué la criptografía es importante para la blockchain?
¿Cómo se usa la criptografía en blockchain?
Primero, imagina que eres un usuario de blockchain. En un rincón de su habitación, puede encontrar una hoja de papel con doce palabras escritas al azar. Alternativamente, puede pensar en una pequeña placa de acero grabada con estas doce palabras, que tal vez debería pensar en guardar en una caja fuerte.
¿Cómo estas doce palabras de una frase mnemotécnica (o, alternativamente, una larga lista de caracteres aleatorios que componen una clave privada), representan su propiedad de ciertos activos?
La base que hace que todo esto funcione es el principio de la criptografía. Nuestras claves, direcciones y carteras se implementan mediante criptografía. Con la ayuda de una tecnología de cifrado asimétrico, cálculo de curva elíptica (ECC), una cadena de bloques verificará que una clave privada en poder de alguien coincida con una clave pública. Mediante este procedimiento se puede determinar si una persona es titular de un activo cifrado. Aparte de la persona que posee la clave privada, no hay forma de que nadie más desbloquee el activo.
Usaremos Bitcoin para explicar los principios de claves privadas, claves públicas y generación de direcciones. Una billetera Bitcoin contiene una serie de pares de clave, y cada par de clave incluye una clave privada y una clave pública. La clave privada suele ser un número de 256 bits seleccionado al azar.
Usando la clave privada como entrada, podemos usar la función criptográfica unidireccional de la curva elíptica (del estándar secp256k1) para generar una clave pública. Usando la clave pública como entrada, podemos usar las funciones hash unidireccionales SHA256 y RIPEMD160 para crear una dirección bitcoin, y usar la codificación de verificación Base58 (letras y números) para presentar la dirección bitcoin en una forma más concisa. Las palabras mnemotécnicas de uso común son palabras en inglés aleatorias generadas según el estándar BIP 39 y se utilizan para generar claves privadas. Sin la clave privada o la frase mnemotécnica, no se pueden utilizar activos cifrados.
El proceso de generación de la clave pública y dirección Bitcoin (Imagen: “Mastering Bitcoin”)
Cuando tiene un par de claves, puede confirmar la propiedad de los activos y utilizar diferentes activos a través de varios tipos de software del lado del cliente, como carteras. Los ejemplos van desde la transferencia de BTC más sencilla hasta algo un poco más avanzado, como firmar transacciones de contratos inteligentes de Ethereum con Metamask, imToken o Alphawallet para comprar CryptoKitties, o pedir prestado en plataformas DeFi, intercambiar tokens ERC20 con Uniswap, etc.
Además de la verificación primaria, como las transferencias, con verificación de identidad en algunas plataformas, ahora puede usar claves públicas y privadas para la verificación de inicio de sesión, verificando que es el propietario de un activo para demostrar varios permisos. En resumen, la criptografía detrás del sistema de verificación de clave público-privada es un pasaporte para los usuarios que viajan por el mundo blockchain.
En las cadenas de bloques, existen otros casos de uso de la criptografía que no se pueden ignorar, como el orden de las transacciones dentro del bloque y el proceso de determinación del orden de los bloques, utilizando estructuras de datos criptográficos como el Árbol de ¨Merkle . Bitcoin cifra cada transacción con el algoritmo SHA256 para crear un valor de longitud fija (32 bytes) llamado hash. Este algoritmo de cifrado garantiza la seguridad de la cadena de bloques y es casi imposible manipularlo.
Solo se necesita el uso básico de funciones hash y firmas criptográficas para crear la base de Bitcoin, lo que lleva a la especulación de que Satoshi Nakamoto puede ser un experto en criptografía, debido a esta capacidad de construir un sistema de efectivo entre pares que utiliza la criptografía de manera tan incisiva.
Además del papel en las funciones básicas de generación de bloques y la verificación de claves público-privadas, la criptografía puede utilizarse en términos de protección de la privacidad e incluso más extensiones de los sistemas blockchain.
¿Cómo utilizan la criptografía las cadenas de bloques públicas actuales?
Una situación típica:
“Vaya, ¿es una nueva cadena de bloques pública? ¿Tiene cartera? ”
Es necesario crear y anotar más conjuntos nuevos de direcciones y palabras mnemotécnicas …
Si los usuarios están dispuestos a ser cautelosos con sus activos e invertir diligentemente en diferentes cadenas de bloques públicas, deben haberse encontrado con esta situación y ya tener varios conjuntos diferentes de palabras mnemotécnicas o claves privadas. Sin embargo, al final del día, es posible que solo almacenen adecuadamente la información que se necesita para sus activos más críticos, y algunas personas incluso olvidan el mnemónico para realizar copias de seguridad de ciertos activos.
Para solucionar este problema, algunas carteras han propuesto soluciones de optimización. Algunas carteras generan una sola frase mnemotécnica para la gestión de múltiples activos en cadenas de bloques, pero todavía hay muchos conjuntos de direcciones diferentes que deben ser administrados por los propios usuarios. Este problema puede ser más grave para muchas cadenas de bloques públicas nuevas si los usuarios necesitan varias direcciones para probar aplicaciones en cadena. Los costos de administración de claves públicas y privadas del usuario aumentarán, sin mencionar que estos no son como buzones de correo donde los propios usuarios pueden definir las contraseñas.
Pero, ¿por qué las cadenas de bloques tienen estas restricciones?
La razón es que muchas cadenas de bloques públicas incluyen actualmente el uso de primitivas criptográficas en la capa de consenso. Por lo tanto, en estas cadenas de bloques públicas, la funcionalidad como las firmas de claves públicas y privadas y las funciones hash comunes están integradas en la capa de consenso. Por ejemplo, la verificación de un valor de dirección y el algoritmo de firma utilizado en las transacciones se escribe realmente en el protocolo subyacente, lo que dificulta su cambio.
Además, el rendimiento de muchas máquinas virtuales públicas no es suficiente para admitir la implementación de primitivas criptográficas adicionales. Si la máquina virtual no es compatible con una primitiva criptográfica específica, los desarrolladores no podrán crear aplicaciones que aprovechen una nueva primitiva criptográfica directamente. Si desea cambiar algo de esto, la única forma es hacer un hard fork.
Tomando Ethereum como ejemplo, ¿qué escenarios de uso criptográfico están escritos en la capa de consenso de Ethereum?
En Ethereum, las firmas de transacciones y la verificación del cliente, a excepción de los hashes del Árbol de Merkle, se escriben en la capa de consenso. Si alguien quiere hacer cambios en estos, como reemplazar el algoritmo hash keccak-256 de la clave pública de Ethereum para derivar una dirección con otro algoritmo, la única forma es enviar un EIP (Propuesta de mejora de Ethereum), luego esperar y rezar para que la propuesta será aceptada e incluida en un hard fork. Esto se debe a que el contenido escrito en la capa de protocolo son reglas que todos los usuarios de la red deben seguir.
Desafortunadamente, los hard forks a menudo requieren largos períodos de tiempo para su implementación. Tome EIP-152, por ejemplo, esta propuesta se hizo en 2016, que esperaba agregar la función hash BLAKE2b a Ethereum, pero no se agregó hasta el hard fork de Estambul a fines de 2019, un proceso que tomó tres años.
Al examinar el ejemplo de EIP-152, encontramos otra limitación: supongamos que desea utilizar primitivas criptográficas que no son compatibles con máquinas virtuales en Ethereum, es casi imposible. Para la máquina virtual Ethereum, el rendimiento es una limitación significativa y las operaciones simples pueden consumir mucho gas.
Al revisar las bifurcaciones anteriores en Ethereum, notamos que desde la actualización de la bifurcación dura de Homestead, Ethereum ha agregado continuamente primitivas criptográficas de uso común a un emulador en la Máquina Virtual Ethereum, primitivas como la aritmética de curva elíptica, mediante el uso continuo del método de precompilación. Esto también se puede ver en la actualización de Bizancio o Estambul. Ethereum utiliza un hard fork para agregar estas primitivas criptográficas precompiladas y estandarizar el precio del gas de estas operaciones.
Si el contrato precompilado no se implementa en el nodo, la implementación de contratos inteligentes para muchos algoritmos de firma incurrirá en una tarifa de gas muy alta, lo que imposibilitará la implementación. Por ejemplo, se adoptaron EIP-196 y EIP-197 porque la verificación de prueba zk-SNARK requiere una gran cantidad de gas si se ejecuta como una operación en cadena. Por lo tanto, las primitivas de soporte de estos algoritmos de cifrado, como la suma de curvas elípticas, la multiplicación y la verificación de emparejamiento, se compilan en el EVM subyacente por adelantado y se ejecutan directamente en el nodo para reducir los costos de cálculo. Por lo tanto, podemos decir que, además de los algoritmos de firma precompilados, el uso de otros algoritmos de cifrado es básicamente imposible.
Esta solidificación de los métodos de uso criptográfico crea una gran limitación para los desarrolladores. Es por eso que, por ejemplo, en Bitcoin o Ethereum, si queremos crear una cuenta, todavía necesitamos administrar un nuevo conjunto de pares de claves.
Para los desarrolladores que desean crear una experiencia fácil de usar, esto crea muchas restricciones y luego necesitan encontrar formas de compensar una experiencia de usuario hostil forzada por la infraestructura. Por ejemplo, después de crear palabras mnemotécnicas, podemos usar FaceID en algunas carteras (como imToken). En ABC Wallet, los usuarios solo necesitan usar un código de verificación de seis caracteres desde un teléfono móvil para iniciar sesión al principio, y luego pueden exportar la clave privada o frase mnemotécnica para respaldarla.
Ambas son formas excelentes que los desarrolladores han ideado para tratar de mejorar la experiencia del usuario, pero para cada nueva cadena de bloques pública, la esencia de la gestión de pares de claves es la misma. Se requiere un nuevo conjunto de direcciones y claves y esto siempre ha sido un problema.
El método de verificación de clave pública-privada anterior tiene el problema de no ser lo suficientemente flexible. En cadenas de bloques públicas anteriores, como Bitcoin y Ethereum, estos problemas pueden no haber sido obvios, porque ya tienen usuarios existentes que se han acostumbrado a este método. Sin embargo, para las cadenas de bloques públicas emergentes, si existe la misma fricción, crea obstáculos para la incorporación de nuevos usuarios y esto también afectará la voluntad de los desarrolladores de desarrollar aplicaciones en una nueva cadena pública.
Una cadena de bloques pública que trae una nueva curva de aprendizaje para los usuarios tiene barreras inherentes para hacer crecer su base de usuarios. Incluso si estas cadenas de bloques públicas tienen otros puntos de venta y nuevas características, es posible que no sean tan atractivas para los desarrolladores que saben que muchos usuarios se verán rechazados por la experiencia hostil de descargar una nueva billetera y crear nuevos pares de claves.
Además, si los desarrolladores desean utilizar primitivas criptográficas más avanzadas, por ejemplo, las que garantizan la privacidad y la seguridad en el futuro, enfrentarán el desafío de implementar esas primitivas mediante el método de precompilación en la máquina virtual o si una nueva cadena admitirá de forma nativa una verificación de firma más novedosa. Por supuesto, esto también afectará el tema candente actual de las interacciones “entre cadenas” porque diferentes cadenas de bloques usan diferentes primitivas criptográficas, y este problema surgirá al intentar verificar transacciones a través de diferentes cadenas de bloques. Esta es la razón por la que muchas de las soluciones actuales para construir transacciones entre cadenas (Cosmos / Polkadot) son factibles en la actualidad, pero el desarrollo de soluciones heterogéneas entre cadenas permanece estancado.
¿En qué se diferencia el diseño de Nervos?
En Nervos CKB, no hay primitivas criptográficas codificadas en la capa de consenso, solo secuenciación de transacciones. La verificación de la propiedad de los activos se realiza mediante el script de bloqueo de una célula y estas reglas de verificación y las primitivas criptográficas que utilizan son autodefinidas, por lo que los desarrolladores pueden utilizar casi cualquier primitiva criptográfica de forma flexible.
Esto ha sido bien explicado por Cipher, un investigador de Nervos: “Además del orden de transacciones más básico en CKB, todo lo demás es el contenido de la capa de aplicación”. Esto brinda a los desarrolladores una gran flexibilidad al desarrollar aplicaciones, como métodos de verificación de cuentas más flexibles.
Debido a que Nervos CKB VM se basa en RISC-V, todo lo que se requiere es un conjunto de reglas de verificación que puedan cumplir con el conjunto de instrucciones RISC-V, dando a los desarrolladores mucho espacio para innovar. El siguiente ejemplo demuestra la diferencia radical en flexibilidad entre Nervos y otras cadenas de bloques públicas que admiten contratos inteligentes. Podemos ver que el contenido de la capa de aplicación indica qué se puede personalizar, mientras que la capa de protocolo representa lo que se debe cambiar a través de un hard fork.
Tomemos, por ejemplo, un proyecto creado por Lay2, un equipo de Grants de Nervos. ¿Cómo puede su pw-sdk usar direcciones Ethereum o incluso direcciones ENS para recibir CKB? Porque en CKB, la generación de direcciones es el contenido de la capa de aplicación, que los desarrolladores pueden usar como quieran. En teoría, cualquier regla de generación de direcciones se puede verificar siempre que las reglas de verificación y una biblioteca de algoritmos de cifrado asimétrico se hayan almacenado en las células de la cadena. En el ejemplo de pw-sdk, podemos usar el algoritmo de firma secp256k1 para verificar una firma y usar la función hash Keccak-256 (SHA-3) para replicar las reglas de verificación de las direcciones Ethereum. Además, SHA-256 y RIPEMD160 de Bitcoin se pueden implementar en cadena, y otros desarrolladores en el futuro pueden usar estas células para derivar direcciones de Bitcoin. Debería estar claro a estas alturas que es sencillo para los desarrolladores usar direcciones Ethereum y Bitcoin en aplicaciones creadas en Nervos.
En el futuro, si algún desarrollador desea agregar algoritmos de cifrado más avanzados para proteger los activos en CKB (como regla para desbloquear una célula), es completamente factible. Cualquiera puede implementar una variedad de bibliotecas primitivas criptográficas en CKB, y estas se pueden optimizar para ahorrar espacio de almacenamiento y reducir el recuento del ciclo de cálculo requerido para la verificación y reducir el costo de implementación. También se podría utilizar cualquier primitiva criptográfica avanzada, sin necesidad de esperar a que los hardforks las implementen.
El futuro de blockchain con CKB: una experiencia de usuario cercana al de Internet
Basándonos en las primitivas criptográficas flexibles, podemos decir que, en el futuro, las reglas de verificación a las que los usuarios de Internet están acostumbrados podrían compilarse según las instrucciones RISC-V e implementarse en cadena, por ejemplo, la verificación de clave PGP o desbloqueo de huellas dactilares en el dispositivo. Si hay una secuencia de comandos en cadena que pueda corresponder al estándar de verificación utilizado y un entorno confiable que pueda respaldar esta verificación (como la encriptación segura de un teléfono móvil), entonces estos métodos se pueden implementar. Más en profundidad, la capa de aplicación puede contener incluso más escenarios que se pueden realizar con varios otros algoritmos criptográficos.
En los últimos dos años, el campo de la expansión en capas (Capa 2) ha visto una serie de innovaciones, como la red Lightning existente, los canales de estado y las soluciones de cadena lateral, y hay una aplicación de extensión criptográfica emergente: Rollup, que utiliza algoritmos de firma para comprimir transacciones.
Actualmente, la forma más común de comprimir transacciones en Rollup es Zero Knowledge Proof (zkp), también conocido como zkRollup. Después, si hay otras soluciones más avanzadas a prueba de conocimiento cero en Rollup, o si usan otros algoritmos de anulación de firma (como BLS, etc.), en CKB, siempre que los desarrolladores puedan pensar en métodos de implementación de bajo costo, pueden realizar la verificación directamente en CKB VM sin necesidad de un hard fork. Esto no implica el contenido de la primera capa o capa de consenso y, además, el cálculo CKB-VM es más eficiente que el EVM. SECBIT Labs también está desarrollando una biblioteca de pruebas de conocimiento cero que se puede usar en CKB, para que sea más fácil para los desarrolladores de Nervos aprovecharlas en sus aplicaciones.
Además, CKB puede soportar primitivas criptográficas flexibles y tiene una ventaja significativa sobre otras cadenas públicas en la transferencia de activos de cadena cruzada de blockchain para realizar la verificación de transacciones desde diferentes cadenas, lo que brinda a CKB más oportunidades para completar transferencias de activos heterogéneos entre cadenas.
Desde que Satoshi Nakamoto compartió el whitepaper de Bitcoin, blockchain se ha convertido en una vasta área de nueva tecnología que utiliza la criptografía para demostrar el consenso en un entorno descentralizado. Esto es algo que no se puede hacer en Internet en sí. Sin embargo, si queremos que las cadenas de bloques se utilicen a gran escala, lo que necesitamos es proporcionar una experiencia que no obligue a los usuarios a comprometerse, pero como mejor dijo Frank del equipo de Lay2: “Necesitamos una forma de apoyar la infraestructura que permita que los desarrolladores “abran sus puertas” para que la cadena de bloques no se convierta en un juguete para algunos geeks o personas en el círculo interno debido a la inflexibilidad de la infraestructura".
Si una cadena pública puede admitir varias primitivas criptográficas de manera flexible, los desarrolladores pueden tener una mayor flexibilidad y omitir el proceso arrogante de “educar a los usuarios”. Porque al igual que Internet, aunque ninguno de nosotros puede vivir sin él, los usuarios finales no necesitan saber cuántas capas de Internet utilizan, o qué es una red P2P.
De manera similar, cuando se usa la tecnología blockchain, los usuarios finales no deberían necesitar tener conocimientos básicos de blockchain. Lo que se necesita son sistemas que tengan una experiencia en Internet y características blockchain. Además de infraestructura con otras características como alta seguridad y descentralización, Nervos CKB, con alta flexibilidad de programación, avanza por este camino.
Fuente original por @WilliamsBlock : https: //talk.nervos.org/t/topic/4754
(Esta es una traducción al español por @luisantoniocrag y revisada por @Lalo)