Autenticación y Autorización en blockchain

Las blockchains son registros públicos que las personas usan para crear, almacenar y mover valor de manera abierta, y diseñar métodos para asegurar su seguridad es crítico para su uso en el mundo real. Existen varios mecanismos de seguridad en la tecnología blockchain, pero los detalles y las implementaciones pueden variar entre las diferentes redes.

Dos de estos mecanismos son la autenticación y la autorización, que son conceptos similares y a menudo se usan indistintamente, pero en realidad significan cosas diferentes. La autenticación responde a la pregunta: “¿Eres quien dices ser?” mientras que la autorización responde a la pregunta: “¿Qué se te permite hacer?”. Ambos trabajan juntos para verificar identidades, controlar el acceso basado en esas identidades y aprovechar diversas características de blockchain, como contratos inteligentes y firmas digitales, para gestionar y hacer cumplir esos controles.

Digamos que vas a salir por una noche de karaoke en un bar para mayores de 21 años. Muestras tu identificación para entrar (autenticación, el portero revisa la foto de tu identificación para verificar que eres quien dices ser). Una vez dentro y después de un par de tragos, decides cantar “I Want It That Way” de Backstreet Boys, y llevas esta petición al anfitrión. Desafortunadamente, el anfitrión ha decidido que la única canción que cualquiera puede cantar esa noche es “Margaritaville” de Jimmy Buffett, y tu petición es denegada (autorización, has sido autenticado, pero no puedes cantar tu canción elegida basado en las reglas del anfitrión).

Como se ve en este ejemplo, la autenticación determina si alguien es quien dice ser, mientras que la autorización determina si pueden realizar una acción específica. Juntos, la autenticación y la autorización en blockchain ayudan a asegurar la seguridad y el control del usuario, al mismo tiempo que hacen cumplir la descentralización.

La blockchain de Stellar ha manejado la autenticación y autorización con pesos de firma, multisig, y umbrales, pero con la introducción de contratos inteligentes, estos métodos pueden volverse más flexibles y complejos. Vamos a entrar en algunos conceptos básicos de autenticación y autorización y cómo se ven en Stellar y Soroban.

La verificación de identidad en blockchain típicamente usa firmas digitales con pares de claves criptográficas. Un par de claves consiste en dos claves: una clave pública y una clave privada, que se generan como un par usando algoritmos criptográficos como el esquema de firma Rivest–Shamir–Adleman (RSA) o Criptografía de Curva Elíptica (ECC) (Stellar usa el esquema de firma Ed25519, que es un tipo de ECC). Estos algoritmos criptográficos aseguran que una clave privada y su clave pública correspondiente estén matemáticamente vinculadas.

Para generar un par de claves, la clave privada se crea primero usando un generador de números aleatorios. La clave pública se deriva entonces de la clave privada basado en el algoritmo criptográfico utilizado (como ECC, mencionado anteriormente — si estás interesado en la matemática detrás de ECC, revisa este artículo que lo explica en detalle). Este proceso de generación de claves es una función unidireccional, lo que significa que es computacionalmente factible generar la clave pública a partir de la clave privada pero prácticamente imposible derivar la clave privada de la clave pública. Una clave pública se comparte con otros para recibir y enviar transacciones, mientras que una clave privada siempre debe mantenerse en secreto.

Los usuarios firman transacciones de blockchain con su clave privada, creando una firma digital única para la transacción y la clave privada utilizada. Cuando la transacción se transmite a la red, los nodos ejecutan la firma y la clave pública a través de un algoritmo para verificar que la firma digital fue producida por la clave privada. Una firma digital también es una función unidireccional — un usuario nunca puede derivar una clave privada de la firma digital.

Una vez completada la autenticación, la autorización determina el control de acceso o qué tipo de privilegios tiene un usuario. Fuera de los contratos inteligentes en Stellar, los usuarios controlan lo que se puede hacer usando pesos de firma, multisig y umbrales. Cada operación de Stellar tiene una categoría de umbral estático (bajo, medio o alto) que está cableada en el código de Stellar Core, y una cuenta asigna a cada categoría de umbral un número entre 0 y 255. Este umbral determina qué peso de firma se necesita para autorizar una operación. Las cuentas también establecen sus propios pesos de firma y claves de firma adicionales. Para determinar si una transacción tiene la autorización necesaria para ejecutarse, los pesos de todas las firmas en la transacción se suman, y si la suma es igual o mayor a los umbrales para las operaciones, entonces la transacción está autorizada para proceder.

Entonces, por ejemplo, si una cuenta establece su peso de umbral medio a 5, su peso de firma maestra a 3, y el peso de firma de la Cuenta 2 a 2, una transacción con la operación change_trust (umbral medio) debe tener pesos de firma que sean iguales o mayores a 5 — así que usando multisig, la firma de la cuenta maestra y la Cuenta 2 pueden autorizar la transacción.

Aunque este escenario otorga cierta flexibilidad, las reglas de autenticación y autorización en contratos inteligentes pueden hacer más para automatizar y hacer cumplir la verificación de identidad y los controles de acceso — los escritores de contratos pueden definir lógicas mucho más complejas que permiten métodos y mecanismos adaptables a una amplia gama de escenarios.

Ahora que tenemos algunos conceptos básicos, por supuesto, necesitamos hablar sobre la autorización en Soroban, la plataforma de contratos inteligentes en Stellar. El marco de autorización de Soroban está integrado en el protocolo central, lo que significa que la autenticación específica del contrato se puede implementar sin necesidad de cambios a nivel de protocolo. La autorización de Soroban tiene implementaciones integradas para características estándar, como la verificación de firmas y la prevención de ataques de repetición, esta última ayuda a reducir la probabilidad de errores, al tiempo que proporciona un marco para reglas de autenticación y autorización más complicadas y personalizables.

Una característica notable del marco de autorización de Soroban incluye la abstracción de cuentas, que es una forma de implementar contratos que realizan autenticación y autorización personalizadas.

Vamos a profundizar.

Soroban admite cuentas regulares o “clásicas” de Stellar (representadas por una dirección G) y cuentas de contrato inteligente (también llamadas cuentas personalizadas, representadas por una dirección C): cada cuenta, ya sea una cuenta “clásica” de Stellar o una cuenta de contrato, está representada por una Dirección al interactuar dentro de Soroban, lo que permite la interoperabilidad entre sistemas.

Aunque se representan de la misma manera, la autenticación se maneja de manera diferente para cada tipo de cuenta. Las cuentas “clásicas” de Stellar se autentican de la manera típica explicada anteriormente: con multisig, pesos de firma y umbrales. Sin embargo, las cuentas de contrato inteligente tienen mucha más flexibilidad cuando se trata de autenticación y pueden escribir lógica de autenticación y autorización personalizada (incluyendo multisig, autenticación web, autenticación móvil y más) en sus contratos gracias a la abstracción de cuentas.

Por definición, la abstracción de cuentas permite a los usuarios usar contratos inteligentes como cuentas y les permite interactuar con otros contratos incluso con lógicas de autenticación diferentes.

Proporcionaré un ejemplo simple de cómo funciona esto:

• Digamos que el contrato de token para el token FINE ha implementado una regla de autorización donde una transferencia de tokens de Usuario A a Usuario B debe ser autorizada por Usuario A.
• La Cuenta de Contrato A (Usuario A) está intentando enviar 5 tokens FINE a otra cuenta (Usuario B) usando el contrato de token FINE.
• El anfitrión de Soroban reconoce que se requiere autorización para realizar esta acción.
• La Cuenta de Contrato A tiene lógica de autenticación personalizada escrita en ella que dice que está permitido realizar esta acción con una firma WebAuthn de sí misma y también incluye reglas de autorización que indican que cualquier transferencia o asignación está limitada por un máximo de 10 tokens FINE.
• Con la firma WebAuthn y la confirmación de que esta acción no transferirá más de 10 tokens FINE, la acción está autorizada.
• El contrato de token FINE reconoce que la acción está autorizada, la acepta y la transacción se ejecuta.

En este caso, el contrato de token FINE no tiene idea cómo fue autenticada la acción, solo reconoció que fue autenticada. Esta capacidad permite a los escritores de contratos crear lógica de autenticación personalizada y específica del contrato compatible con las reglas de autorización genéricas de otros contratos.

Con la abstracción de cuentas integrada en el marco de autorización de Soroban, los contratos escritos ahora serán compatibles con contratos escritos en el futuro lejano con nuevos métodos de autenticación que aún se están desarrollando, como criptografía post-cuántica.

El marco de autorización de Soroban y la introducción de cuentas de contrato facilitan una mayor expresividad a través de la construcción de transacciones detalladas. Los desarrolladores pueden construir capacidades de autorización personalizadas en sus contratos que requieren aprobación para acciones individuales por múltiples partes, no solo el invocador del contrato. Estas capacidades de autorización detalladas ayudan a los desarrolladores a adaptar sus contratos para satisfacer sus necesidades específicas y permiten la creación de aplicaciones más dinámicas.

Además, al construir una llamada de contrato, puede ser difícil determinar la tarifa de recurso (que incluye lecturas/escrituras, CPU, etc.) y la autorización necesaria para su ejecución. Para ayudar con esto, Soroban ofrece un punto final de simulación que ejecuta la transacción de prueba contra una instantánea temporal del libro mayor, creando una huella de transacción que le dice al usuario la tarifa estimada y la autorización necesaria para que la transacción se ejecute.

Ser capaz de estimar la cantidad de tarifa de recurso y las firmas necesarias para que una transacción sea exitosa antes de intentar enviarla a la red ayuda a prevenir transacciones fallidas, ya que los contratos pueden tener firmas requeridas anidadas profundamente dentro de su construcción que pueden ser fáciles de pasar por alto.

La introducción de contratos inteligentes en la red de Stellar abre enormes oportunidades para la innovación en la blockchain. Con el marco de autorización de Soroban, los desarrolladores pueden construir contratos sofisticados e interoperables con lógica compleja de autenticación y autorización. Tras una votación validadora exitosa el 19 de marzo, Soroban ahora está en la Fase 2 de su lanzamiento por fases, lo que significa que está listo para los usuarios, y cualquiera puede desplegar e interactuar con contratos inteligentes en la red. ¡Es un momento emocionante para construir en Stellar!

Involúcrate y mantente al día sobre todo lo relacionado con Stellar y Soroban uniéndote al Discord de Desarrolladores de Stellar, donde se realizan discusiones animadas todos los días. También puedes revisar varias propuestas en GitHub, como CAP-51: Funcionalidad de Host de Contrato Inteligente: Verificación Secp256r1, donde el ecosistema de Stellar está explorando un nuevo mecanismo de verificación de firma integrado para contratos inteligentes de Soroban que soporta autenticación web y passkeys.