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 anclar el enlace a 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: la 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 cambio, 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 de 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 de correo electrónico específico del evento. Esto nos ayudó a priorizar la 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 llave de paso

La billetera de cada usuario era gestionada 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 la 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 llave de paso se registra en el Contrato de Cuenta, permitiendo que las transacciones futuras sean firmadas vía biometría o PIN del dispositivo y validadas 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 una llave de paso sincronizada 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 para firmar conjuntamente (multi-firma) con el fin de recuperar la cuenta. Sin embargo, las llaves de paso perdidas pueden ser reemplazadas 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éndolos firmar con su llave de paso para cada acción individual.

Introduciendo: el Contrato de Multicall. Basado en el Contrato de Router Stellar de Creit Tech, el Contrato de 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 siendo ejecutadas a la vez en cadena.

Esto se usó para acciones como canjear múltiples artículos de mercancía en una sola transacción o transferir muchos NFTs a la vez. Mejoró tanto el rendimiento como la experiencia del usuario, reduciendo múltiples viajes de ida y vuelta 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 en 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ó que reclamaran sus XLM con su llave de paso. Recibieron inmediatamente los XLM en su billetera. La mejor parte? El equipo de ingeniería no estaba gestionando ni 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 se creara la billetera 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 la lista completa. Almacenas el hash raíz en cadena, permitiendo costos de almacenamiento mínimos, y luego los usuarios prueban elegibilidad al enviar 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 participaron en una activación de máquina de selfies por Checkpoint y Refraction que estaba en Meridian in situ. 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.