Como todos saben, blockchain es una nueva tecnología basada en criptografía, economía y ciencia de 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" entre los tres mencionados anteriormente.
Sin embargo, aquellos en el mundo de blockchain a menudo oirá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:
¿Cómo usan blockchain las criptografías exactamente? ¿Por qué es importante la criptografía para la tecnología blockchain?
Primero, imagina que eres un usuario de blockchain. En una esquina de su habitación, puede encontrar un pedazo de papel con doce palabras aleatorias escritas en él. Alternativamente, puede ver una pequeña placa de acero grabada con estas doce palabras, que tal vez debería pensar en encerrar en una caja fuerte.
¿Cómo representan estas doce palabras de una frase mnemónica (o, alternativamente, una larga lista de caracteres aleatorios que forman una clave privada) su propiedad de ciertos activos?
La base que hace que todo esto funcione es el principio de la criptografía. Nuestras claves, direcciones y billeteras 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 otra persona desbloquee el activo.
Usaremos Bitcoin para explicar los principios de las claves privadas, las claves públicas y la generación de direcciones. Una billetera de Bitcoin contiene una serie de pares de claves, y cada par de claves 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 de bitcoin, y usar la codificación de verificación Base58 (letras y números) para presentar la dirección de bitcoin en una forma más concisa. Las palabras mnemotécnicas comúnmente utilizadas son palabras aleatorias en inglés generadas en base al estándar BIP 39 y se utilizan para generar claves privadas. Sin la clave privada o la frase mnemotécnica, los activos cifrados no se pueden usar.
Clave pública y generación de direcciones a partir de clave privada (Crédito: "Dominar Bitcoin")
Cuando tiene un par de claves, puede confirmar la propiedad de los activos y usar diferentes activos a través de varios tipos de software del lado del cliente, como billeteras. 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 en 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 la 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 usted es el propietario de un activo para probar varios permisos. En resumen, la criptografía detrás del sistema de verificación de clave pública-privada es un pasaporte para los usuarios que viajan por el mundo blockchain.
En blockchains, hay otros casos de uso de criptografía que no se pueden ignorar, como el orden de las transacciones en el bloque y el proceso de determinar el 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 de manipular.
Solo se necesita el uso básico de las funciones hash y las firmas criptográficas para crear la base de Bitcoin, lo que lleva a especular que Satoshi Nakamoto puede ser un experto en criptografía, debido a esta capacidad de construir un sistema de efectivo entre pares que utiliza criptografía de manera tan incisiva .
Además de su papel en las funciones básicas de generación de bloques y verificación de clave pública-privada, la criptografía puede ser útil en términos de protección de la privacidad e incluso extensiones adicionales de los sistemas blockchain.
Una situación típica:
“Wow, ¿es esa una nueva blockchain pública? ¿Tiene una billetera?
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 blockchains públicos, deben haber encontrado 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 necesaria para sus activos más críticos, y algunas personas incluso olvidan la mnemotécnica para respaldar ciertos activos.
Para resolver este problema, algunas billeteras han propuesto soluciones para la optimización. Algunas billeteras generan una sola frase mnemónica para la administración de múltiples activos en blockchains, 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 nuevas cadenas de bloques públicas 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 los buzones donde las contraseñas pueden ser definidas por los propios usuarios.
Pero, ¿por qué las blockchains tienen tales restricciones?
La razón es que muchas blockchains públicas actualmente incluyen 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 transacciones se escribe en el protocolo subyacente, lo que dificulta el cambio.
Además, el rendimiento de muchas máquinas virtuales de cadena pública no es suficiente para admitir el despliegue de primitivas criptográficas adicionales. Si la máquina virtual subyacente ya no admite 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 bifurcar!
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 de Merkle Tree, se escriben en la capa de consenso. Si alguien quiere hacer cambios a estos, como reemplazar el algoritmo hash keccak-256 de la clave pública Ethereum para derivar una dirección con otro algoritmo, la única forma es enviar una EIP (Propuesta de Mejora 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, las horquillas duras a menudo requieren largos períodos de tiempo para implementarse. Tomemos 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 la bifurcación de Estambul a finales de 2019, un proceso que tomó tres años de principio a fin .
Examinando el ejemplo de EIP-152, encontramos otra limitación: supongamos que desea usar 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 bajo 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 usa un hard fork para agregar estas primitivas criptográficas precompiladas y para 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, por lo que será imposible implementarla. Por ejemplo, se adoptaron EIP-196 y EIP-197 porque la verificación a prueba de 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 adición de curva elíptica, la multiplicación y la verificación de emparejamiento, se compilan de antemano en el EVM subyacente y se ejecutan directamente en el nodo para reducir los costos de cálculo. Por lo tanto, podemos decir que, aparte 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, aún 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 solidificada. Por ejemplo, después de crear palabras mnemotécnicas, podemos usar FaceID en algunas billeteras (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 la frase mnemónica para hacer una copia de seguridad.
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 administració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 blockchains públicos 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 disposición de los desarrolladores para desarrollar aplicaciones en una nueva cadena pública.
Una cadena de bloques pública que ofrece una nueva curva de aprendizaje para los usuarios tiene barreras inherentes en el crecimiento de su base de usuarios. Incluso si estas cadenas de bloques públicas tienen otros puntos de venta y nuevas características, pueden no ser tan atractivas para los desarrolladores que saben que muchos usuarios se verán rechazados por la experiencia poco amigable del usuario 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, se enfrentarán al desafío de implementar esas primitivas a través del método de precompilación en la máquina virtual o si una nueva cadena admitirá de forma nativa nueva verificación de firma. Por supuesto, esto también afectará el tema candente actual de las interacciones de "cadena cruzada" porque las diferentes cadenas de bloques usan diferentes primitivas criptográficas, y este problema surgirá al intentar verificar las transacciones a través de diferentes cadenas de bloques. Esta es la razón por la cual muchas soluciones actuales para construir transacciones entre cadenas (Cosmos / Polkadot) son factibles hoy en día, pero el desarrollo heterogéneo de soluciones entre cadenas sigue estancado.
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 celda y estas reglas de verificación y las primitivas criptográficas que utilizan son autodefinidas, por lo que los desarrolladores pueden usar casi cualquier primitiva criptográfica.
Cipher, un investigador de Nervos, ha explicado bien esto: "Además del pedido 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 la máquina virtual Nervos CKB 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, lo que brinda a los desarrolladores mucho espacio para innovar. El siguiente ejemplo demuestra la diferencia radical en la 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 lo que se puede personalizar, mientras que la capa de protocolo representa lo que debe cambiarse a través de un hard fork.
Tomemos, por ejemplo, un proyecto construido por Lay2, un equipo de Grants de Nervos. ¿Cómo pueden sus 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. Teóricamente, cualquier regla de generación de direcciones puede verificarse siempre que las reglas de verificación y una biblioteca de algoritmos de cifrado asimétrico se hayan almacenado en celdas de la cadena. En el ejemplo 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 de Ethereum. Además, SHA-256 y RIPEMD160 de Bitcoin se pueden implementar en la cadena, y otros desarrolladores en el futuro pueden usar estas celdas para derivar direcciones de Bitcoin. Ahora debería estar claro 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 encriptación más avanzados para asegurar los activos en el CKB (como regla para desbloquear una celda), es completamente factible. Cualquiera puede implementar una variedad de bibliotecas primitivas criptográficas en CKB, y estas pueden optimizarse para ahorrar espacio de almacenamiento y reducir el recuento del ciclo de cómputo requerido para la verificación para reducir el costo de implementación. También se podría usar cualquier primitiva criptográfica avanzada, sin necesidad de esperar a que los tenedores duros las implementen.
Según 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 y desplegarse en cadena, por ejemplo, la verificación de clave PGP o el desbloqueo de huellas digitales en el dispositivo. Si hay una secuencia de comandos en cadena que puede corresponder con el estándar de verificación utilizado y un entorno confiable que puede admitir esta verificación (como el enclave seguro de un teléfono móvil), estos métodos de uso convenientes se pueden realizar en el futuro. 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 emergente de extensión criptográfica: 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. En el futuro, si hay otras soluciones a prueba de conocimiento cero más avanzadas en Rollup, o usa otros algoritmos 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 requerir una bifurcación dura. Esto no implica el contenido de la capa de consenso y, además, el cálculo de CKB-VM es más eficiente que el EVM. SECBIT Labs también está desarrollando una biblioteca de prueba de conocimiento cero que se puede utilizar en CKB, para facilitar a los desarrolladores de Nervos aprovechar pruebas de conocimiento cero en sus aplicaciones en el futuro.
Además, CKB puede admitir primitivas criptográficas flexibles y tiene una ventaja inherente significativa sobre otras cadenas públicas en la transferencia de activos de cadenas cruzadas de blockchain para realizar la verificación de transacciones de diferentes cadenas, lo que le da a CKB más oportunidades para completar transferencias de activos heterogéneos de cadenas cruzadas.
Desde que Satoshi Nakamoto compartió el documento técnico 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. Sin embargo, si queremos ver las cadenas de bloques utilizadas a gran escala, lo que necesitamos para proporcionar una experiencia que no obligue a los usuarios a comprometerse, pero como mejor dijo Frank del equipo Lay2: “Necesitamos una forma de soportar la infraestructura que permita desarrolladores para "abrir 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 las instalaciones subyacentes ".
Si una cadena pública puede soportar 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 como Internet, aunque ninguno de nosotros puede vivir sin él, los usuarios finales nunca necesitan saber cuántas capas forman Internet o qué es una red P2P.
Del mismo modo, cuando se usa la tecnología blockchain, los usuarios puramente finales no deberían necesitar tener conocimientos básicos de blockchain. Lo que se necesita son sistemas que tengan tanto experiencia en Internet como características de blockchain. Además de la infraestructura con otras características como alta seguridad y descentralización, Nervos CKB, con alta flexibilidad de programación, se está moviendo en este camino.
Fuente: https: //talk.nervos.org/t/topic/4754 por Williams, traducido por Ashlee, editado por Matt