Construyendo Meridian Pay: Una Billetera Inteligente Escalable en Stellar

Meridian Pay fue desarrollado como una experiencia basada en web, accesible desde cualquier navegador sin instalar una app. Los usuarios pueden fijar el enlace en su pantalla de inicio para un fácil acceso.

Al diseñar Meridian Pay, sabíamos que necesitábamos una experiencia de incorporación instantánea y segura que eliminara uno de los mayores obstáculos de blockchain: gestión de claves. Creemos que los usuarios no deberían esperar recordar frases semilla o preocuparse por almacenar credenciales de forma segura para usar una billetera blockchain.

Esto nos llevó a llaves de paso, que resuelven la autenticación con WebAuthn. Los usuarios de Meridian Pay nunca tienen que ver o gestionar su clave privada, ni preocuparse por frases semilla o contraseñas. En su lugar, pueden autenticarse usando métodos familiares en los que ya confían como Face ID, Touch ID, o su PIN de dispositivo. Esto hizo que Meridian Pay se sintiera como cualquier producto web2 simple mientras todo bajo el capó sucedía en cadena.

Si puedes manejar abrir la pantalla de inicio de tu teléfono, puedes manejar usar una billetera como Meridian Pay.

Un poco más sobre llaves de paso:

Las llaves de paso son una solución criptográficamente segura creada por la Alianza FIDO para ser resistente al phishing, y para sincronizarse a través de dispositivos mediante proveedores en la nube. Meridian Pay utiliza llaves de paso tanto para el inicio de sesión inicial como para firmar transacciones. Si un usuario perdiera su dispositivo, podría reautenticarse usando su llave de paso sincronizada en la nube o un mecanismo de recuperación por correo electrónico específico del evento. Esto nos ayudó a priorizar velocidad, seguridad y simplicidad en el diseño de Meridian Pay.

Así es como funciona:

1. Configuración: Cuando un usuario crea una cuenta, el dispositivo genera un par de claves de llave de paso y el contrato de la billetera almacena la clave pública como su firmante

2. Inicio de Transacción: El usuario inicia una transacción (ej: para reclamar un NFT o hacer un pago) y el frontend construye un desafío WebAuthn para ser firmado

3. Autenticación: El dispositivo solicita al usuario Face ID, Touch ID, o PIN y firma el desafío, creando una afirmación

4. Verificación: El contrato de la cuenta verifica la firma de la afirmación contra la clave pública almacenada para ese usuario

5. Autorización y Ejecución: Si es válida, la transacción se ejecuta en cadena

Para el usuario, esto parece escanear un código QR, tocar un enlace y autenticarse con Face ID, con confirmación casi instantánea. En realidad, esos toques desencadenan la creación de billeteras o transacciones, patrocinio de tarifas, y ejecución de contratos en cadena en unos pocos segundos.

Meridian Pay se basó en contratos inteligentes de Stellar para el comportamiento programable de la billetera. Aquí hay un poco más sobre lo que estaba sucediendo detrás de escena.

Contrato de cuenta con autenticación de passkey

La billetera de cada usuario se gestionaba con un Contrato de Cuenta, que definía cómo funcionaban la autenticación y la recuperación. El Contrato de Cuenta de Meridian Pay actuaba como una billetera programable que autorizaba acciones de usuario basadas en credenciales WebAuthn, en lugar de llaves estáticas. Las cuentas tradicionales de Stellar usan un par de llaves ed25519 estático para autorización. Las billeteras inteligentes van un paso más allá: pueden implementar lógica de autenticación personalizada a través de una función de contrato especial llamada __check_auth que valida firmas WebAuthn. Cuando un usuario configura su billetera por primera vez, la llave pública de su passkey se registra en el Contrato de Cuenta, permitiendo que las transacciones futuras se firmen vía biométricos o PIN del dispositivo y se validen en cadena.

Esto hizo que las billeteras fueran sin semilla, recuperables y diseñadas para ser resistentes al phishing. Si un usuario perdía su dispositivo, podían reautenticarse vía un passkey sincronizado en la nube o un flujo de recuperación de correo electrónico específico del evento.

Para Meridian Pay, la recuperación se realizaba autorizando a dos servidores distintos a firmar conjuntamente (multi-firma) para recuperar la cuenta. Sin embargo, los passkeys perdidos pueden ser reemplazados de múltiples maneras. En la práctica, las billeteras inteligentes pueden definir cualquier lógica que deseen para la recuperación, incluyendo frases de recuperación, servicios multi-firma distribuidos, firmantes de billetera dura, etc.

Contrato de multicall: transacciones agrupadas

Para los desarrolladores acostumbrados a agrupar operaciones en una sola transacción en Stellar, la restricción de solo poder ejecutar una invocación de contrato a la vez puede parecer extraña. Sabíamos que los usuarios de Meridian Pay necesitarían realizar múltiples acciones a la vez y no queríamos sacrificar la experiencia del usuario haciéndoles firmar con su passkey para cada acción individual.

Entra: el Contrato Multicall. Basado en el Contrato de Router Stellar de Creit Tech, el Contrato Multicall permite que múltiples invocaciones de contrato se ejecuten en una sola transacción en cadena. El contrato valida la autenticación, luego ejecuta todas las acciones agrupadas atómicamente. Esto nos permitió agrupar múltiples invocaciones de contrato en una sola transacción, con el usuario autenticándose una vez y todas las acciones ejecutándose a la vez en cadena.

Esto se usó para acciones como canjear varios artículos de merchandising en una sola transacción o transferir muchos NFTs a la vez. Mejoró tanto el rendimiento como la experiencia del usuario, reduciendo múltiples idas y vueltas a una sola interacción con la blockchain.

Distribuidor Merkle: reclamos masivos eficientes

Para apoyar distribuciones a gran escala, Meridian Pay también incluyó un Contrato Distribuidor Merkle. Construimos este contrato para facilitar el envío de tokens a miles de personas en un solo momento, sin recopilar sus direcciones de antemano, como una total sorpresa para los receptores. Esto permitió un momento especial en el escenario de Meridian cuando la CEO y Directora Ejecutiva de Stellar Development Foundation, Denelle Dixon, anunció en su discurso de apertura que todos los asistentes podrían abrir sus teléfonos para reclamar 500 XLM con Meridian Pay. Los asistentes fueron a la página web de Meridian Pay y se les pidió reclamar sus XLM con su passkey. Inmediatamente recibieron los XLM en su billetera. La mejor parte? El equipo de ingeniería no estaba gestionando o monitoreando 1000 transacciones separadas. Todo el trabajo administrativo se había hecho de antemano. El árbol Merkle con direcciones elegibles se había configurado temprano, incluso antes de que los asistentes crearan sus billeteras Meridian Pay, y operó sin problemas mientras los asistentes verificaban y reclamaban sus tokens.

Esto fue posible porque las direcciones de contrato no son pares de llaves aleatorios. Se derivan de manera determinista de la dirección del desplegador y una sal. Para Meridian Pay, usamos direcciones de correo electrónico registradas como la sal, lo que significa que podríamos calcular la dirección de billetera de cada asistente antes de que la billetera se creara y sin ninguna interacción con los usuarios. Esto nos permitió configurar con confianza un Árbol Merkle de direcciones de billetera para la distribución masiva.

Generalmente, los Árboles Merkle te permiten probar que un valor está en una lista sin almacenar toda la lista. Almacenas el hash raíz en cadena, lo que permite costos de almacenamiento mínimos, y luego los usuarios prueban la elegibilidad enviando un "recibo" criptográfico (una prueba Merkle) para reclamar fondos. El contrato está prefinanciado, lo que permite a los receptores reclamar en masa o de manera asincrónica en su propio tiempo. Los tokens no reclamados permanecen en el contrato y pueden ser recuperados después de un cierto período de tiempo, lo que evita enviar tokens a direcciones inactivas. Usar esta estructura permite distribuciones turboalimentadas con casi ningún límite en el número de personas a las que puedes pagar a la vez.

La combinación de escalabilidad eficiente, participación ligera del usuario, administración sin intervención y la protección de fondos no utilizados hace que los contratos de Árbol Merkle sean ideales para distribuciones controladas. Usamos Árboles Merkle para distribuir XLM y tokens SWAG cuando los usuarios participaban en una activación de máquina de selfies por Checkpoint y Refraction que estaba en Meridian en el sitio. Sin embargo, el cielo es el límite. Ya sea iniciando airdrops, recompensas o incluso algo como distribuciones de ayuda a personas afectadas por desastres, usar un Árbol Merkle para gestionar pagos en cadena puede ayudarte a distribuir eficientemente a los receptores correctos con costos mínimos y sobrecarga administrativa.