5 publicaciones etiquetados con "Account Abstraction"

AllScale.io es una plataforma de pago de stablecoins legítima y respaldada por capital de riesgo —no un proyecto de token— dirigida a freelancers y pequeñas empresas en mercados emergentes. Fundada en febrero de 2025 y respaldada por $6.5M de VCs cripto de renombre, incluyendo YZi Labs, Draper Dragon y KuCoin Ventures, la compañía muestra señales positivas: un equipo públicamente identificado con experiencia verificable en Kraken, Capital One y Block, además de respaldo institucional de la incubadora Cyberport de Hong Kong. Sin embargo, la ausencia de auditorías de seguridad públicas y la extrema juventud de la plataforma (menos de un año) justifican una diligencia debida cuidadosa antes de una participación significativa.

Qué hace AllScale y qué problema resuelve​

AllScale se posiciona como el "primer neobanco de stablecoins con autocustodia del mundo", diseñado específicamente para los más de 600 millones de microempresas globales —freelancers, creadores de contenido, pymes y contratistas remotos— que tienen dificultades con los pagos transfronterizos tradicionales. El problema central: los freelancers internacionales se enfrentan a barreras de cuentas bancarias, altas tarifas de transferencia, pérdidas por conversión de moneda y retrasos en la liquidación que a menudo superan los 5 días hábiles.

La plataforma permite a las empresas crear facturas, recibir pagos en USDT o USDC independientemente de cómo paguen los clientes (tarjeta de crédito, transferencia bancaria o cripto), y acceder a los fondos instantáneamente a través de una billetera no custodial. Los productos clave incluyen AllScale Invoice (activo desde septiembre de 2025), AllScale Pay (comercio social a través de Telegram, WhatsApp, Line) y AllScale Payroll (pagos transfronterizos a contratistas). La empresa enfatiza el "cripto invisible": los clientes pueden no saber que están utilizando la infraestructura blockchain mientras los comerciantes reciben stablecoins.

Etapa actual de desarrollo: La plataforma se encuentra en beta pública con un producto funcional en la mainnet de BNB Chain. Los usuarios pueden acceder al panel de control en dashboard.allscale.io, aunque puede aplicarse una lista de espera.

La arquitectura técnica se basa en BNB Chain y la abstracción de cuentas​

AllScale se basa en la infraestructura blockchain existente en lugar de operar su propia cadena. La pila tecnológica principal incluye:

El enfoque basado en passkey elimina la notoria fricción de UX de la gestión de frases semilla, reduciendo la barrera para la adopción masiva. La arquitectura de patrocinio de paymaster multi-cadena gestiona los costos de transacción entre bastidores.

Lo que falta: AllScale no mantiene repositorios públicos en GitHub —la infraestructura es propietaria y de código cerrado. No se han publicado direcciones de contratos inteligentes, no hay APIs o SDKs públicos disponibles, y la documentación técnica en docs.allscale.io se centra en guías de usuario en lugar de especificaciones de arquitectura. Esta opacidad impide la verificación técnica independiente de sus afirmaciones.

Sin token nativo —la plataforma utiliza USDT y USDC​

AllScale no tiene un token de criptomoneda nativo. Esta es una distinción crítica de muchos proyectos Web3: no hay ICO, IDO, venta de tokens o activo especulativo involucrado. La empresa opera como una corporación C tradicional de Delaware que recauda financiación de capital.

La plataforma utiliza stablecoins de terceros —principalmente USDT y USDC— como medio de pago. Los usuarios reciben pagos en stablecoins, con conversión automática de pagos fiduciarios o con tarjeta. La integración con BNB Chain también proporciona acceso a USD1 (la stablecoin afiliada a Binance).

Modelo de ingresos (estimado, no divulgado públicamente):

• Tarifas de transacción por procesamiento de facturas/pagos
• Márgenes de conversión de moneda en intercambios de fiat a stablecoin
• Servicios de gestión de nóminas B2B
• Tarifas de integración de on/off-ramp

La ausencia de un token elimina ciertos riesgos (volatilidad especulativa, manipulación de tokenomics, preocupaciones regulatorias de valores) pero también significa que no hay exposición basada en tokens para los inversores más allá de la participación en el capital.

Cuatro fundadores públicamente identificados con antecedentes verificables​

El equipo de AllScale demuestra una gran transparencia: todos los fundadores están públicamente identificados con historiales profesionales verificables:

Shawn Pang (CEO y Co-Fundador): Ciencias de la Computación y Negocios de Western University. Ex-Gerente de Producto para fraude de pagos en Capital One; primer PM en Canadá en TikTok; co-fundador de HashMatrix, una agencia de marketing de crecimiento para productos de IA.

Ruoyang "Leo" Wang (COO y Co-Fundador): Ingeniería Informática de la Universidad de Toronto. Experiencia en PingCAP (bases de datos distribuidas), IBM, AMD y Scotiabank. Experiencia previa en startups con CP Clickme.

Jun Li y Khalil Lin (Co-Fundadores): Co-fundadores adicionales con experiencia legal/de cumplimiento, que según se informa incluyen antecedentes en OKX. Perfiles de LinkedIn disponibles.

Avrilyn Li (Gerente de Producto Fundadora): Emprendedora de IA a Web3 de Ivey Business School, liderando el producto de nóminas.

El equipo afirma tener experiencia colectiva de Binance, OKX, Kraken, Block (Square), Amazon, Dell y HP. El tamaño total del equipo es de aproximadamente 7-11 empleados.

Financiación e inversores​

Entre los inversores participantes notables se encuentran KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures y V3V Ventures. Los inversores ángeles incluyen a Gracy Chen y Jedi Lu. La empresa es miembro del Programa de Incubación Cyberport de Hong Kong, una aceleradora tecnológica respaldada por el gobierno.

Principal preocupación de seguridad: sin auditorías públicas ni programa de recompensas por errores​

Esta es la señal de alerta más significativa en la investigación. A pesar de gestionar fondos de usuarios a través de billeteras de contratos inteligentes:

• Sin auditorías públicas de contratos inteligentes de firmas reconocidas (CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)
• No listado en CertiK Skynet o bases de datos de seguridad similares
• Sin programa de recompensas por errores en Immunefi, HackerOne o Bugcrowd
• Sin mecanismos de seguro o cobertura divulgados
• Sin política de divulgación de seguridad visible públicamente

AllScale afirma tener características de seguridad que incluyen arquitectura de autocustodia, cumplimiento automatizado de KYC/KYB/KYT, integración de módulo de seguridad de hardware (HSM) para passkeys y soporte 2FA. El modelo de autocustodia reduce el riesgo de contraparte de la plataforma: si AllScale se viera comprometida, los fondos de los usuarios en sus propias billeteras estarían teóricamente más seguros que en un servicio de custodia.

En el lado positivo: No se han reportado incidentes de seguridad, hacks o exploits para AllScale. Sin embargo, dada la juventud de la plataforma, esta ausencia de incidentes puede simplemente reflejar una exposición limitada en lugar de una seguridad robusta.

Panorama competitivo y posicionamiento en el mercado​

AllScale compite en el espacio de pagos con stablecoins, que evoluciona rápidamente:

Factores de diferenciación de AllScale:

• Modelo de autocustodia (los usuarios controlan los fondos)
• Autenticación con passkey que elimina la fricción de UX de las frases semilla
• Cero tarifas de gas a través de la abstracción de cuentas
• Enfoque en mercados emergentes (África, América Latina, Sudeste Asiático)
• Orientación a pymes de "última milla" frente al enfoque empresarial

Desventajas: Extrema juventud, equipo pequeño, trayectoria limitada, compitiendo contra empresas establecidas y bien financiadas con canales de distribución consolidados.

La presencia comunitaria es incipiente y centrada en B2B​

AllScale mantiene los canales sociales estándar de Web3:

• X (Twitter): @allscaleio (activo desde abril de 2025)
• Telegram: Grupo comunitario AllScaleHQ
• Discord: Servidor activo con ID de comunidad visible
• LinkedIn: Página de empresa AllScale Inc
• Newsletter: "The Stablecoin Scoop" en Substack

La comunidad está en una etapa inicial, con la participación principalmente a través de sesiones AMA, X Spaces y anuncios de asociaciones. AllScale organizó la Cumbre Scale Stablecoin en Hong Kong (junio de 2025) con HashKey Group y Amber Group.

No se aplican métricas DeFi tradicionales: AllScale es una plataforma de pagos, no un protocolo DeFi, por lo que las métricas de TVL (Valor Total Bloqueado) no son aplicables. La plataforma no está listada en DeFiLlama o Dune Analytics. Las métricas de recuento de usuarios y retención son mencionadas por los inversores pero no se divulgan públicamente.

Las asociaciones notables incluyen BNB Chain (socio oficial del ecosistema), Skill Afrika (comunidades de freelancers africanos), Ethscriptions (permanencia L1) y Asseto (tokenización RWA para productos de rendimiento).

La evaluación de riesgos revela una empresa en etapa inicial de riesgo moderado​

Señales positivas de legitimidad​

• Equipo públicamente identificado con antecedentes profesionales verificables
• VCs cripto de renombre (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• Respaldo institucional de Hong Kong Cyberport
• Estructura legal de Delaware C-corp
• Producto funcional en la mainnet de BNB Chain
• No se encontraron acusaciones de estafa, quejas de BBB o advertencias de la comunidad
• Sin preocupaciones por equipo anónimo
• Sin promesas de rendimiento poco realistas o especulación de tokens
• Posicionamiento pro-cumplimiento (GENIUS Act, Ordenanza de Stablecoins de Hong Kong)

Áreas que requieren precaución​

• Extrema juventud: Fundada en febrero de 2025, con menos de un año de antigüedad
• Sin auditorías de seguridad públicas a pesar de manejar fondos
• Sin programa de recompensas por errores
• Sin reseñas de usuarios independientes o comentarios de la comunidad disponibles
• Infraestructura de código cerrado —no se pueden verificar las afirmaciones de forma independiente
• Cobertura de prensa principalmente sindicación de comunicados de prensa, no periodismo independiente
• Riesgos de centralización: Plataforma operada por la empresa, dependencia de BNB Chain
• Equipo pequeño (~7-11 personas) ejecutando un ambicioso alcance global

No encontrado (posibles señales de alerta por ausencia)​

• Sin métricas de usuario divulgadas públicamente
• Sin cifras de ingresos
• Sin una junta asesora formal
• Sin licencias regulatorias específicas (el marco de Hong Kong aún no es efectivo)

Desarrollos recientes y hoja de ruta​

Hitos recientes (2025):

• 8 de diciembre: Anunciada ronda semilla de $5M (liderada por YZi Labs)
• Noviembre: AllScale Pay en vivo en BNB Chain; asociación con Skill Afrika
• Octubre: Asociación con Ethscriptions para la permanencia L1
• Septiembre: Lanzamiento del producto AllScale Invoice
• Agosto: Integración de BNB Chain con soporte USD1
• Junio: Cumbre Scale Stablecoin Hong Kong; financiación pre-semilla de $1.5M

Próximo:

• Q1 2026: Expansión al mercado de América Latina
• Futuro: Opciones de rendimiento DeFi, capacidades cross-chain expandidas, soluciones empresariales B2B

Conclusión​

AllScale.io emerge como una startup legítima en etapa inicial en lugar de una preocupación por estafa, respaldada por inversores creíbles y un equipo transparente y verificable. El proyecto aborda un problema real del mercado —la fricción en los pagos transfronterizos para freelancers de mercados emergentes— con un enfoque técnico bien pensado que aprovecha la abstracción de cuentas y las stablecoins.

Sin embargo, dos brechas significativas exigen atención antes de una participación significativa: la ausencia total de auditorías de seguridad públicas y la infraestructura de código cerrado que impide la verificación independiente. Para una plataforma que maneja fondos de usuarios, estas omisiones son preocupaciones materiales independientemente de las credenciales del equipo.

Calificación de riesgo general: Moderado. La empresa muestra fuertes señales de legitimidad pero conlleva riesgos inherentes a la etapa inicial. Los usuarios potenciales deben comenzar con pequeñas cantidades hasta que se publiquen las auditorías de seguridad. Los socios potenciales deben solicitar acceso directo a las especificaciones técnicas y a los informes de auditoría. Vale la pena monitorear el proyecto a medida que madura, particularmente por cualquier anuncio de auditoría de seguridad en el primer trimestre de 2026.

Imagina un mundo donde los usuarios puedan interactuar con tu dApp de forma fluida, sin necesidad de poseer tokens nativos (SUI). Esto ya no es un sueño lejano. Con la Gas Station de Sui (también conocida como Paymaster), los desarrolladores pueden cubrir las tarifas de gas en nombre de sus usuarios, eliminando por completo una de las mayores barreras para los nuevos participantes en Web3 y habilitando una experiencia verdaderamente sin fricción en cadena.

Este artículo ofrece una guía completa para actualizar tu dApp y hacerla sin gas. Profundizaremos en los conceptos centrales del Sui Paymaster, su arquitectura, patrones de implementación y mejores prácticas.

1. Antecedentes y conceptos clave: ¿Qué es una transacción patrocinada?​

En el mundo de la blockchain, cada transacción requiere una tarifa de red, o “gas”. Para los usuarios acostumbrados a la fluidez de Web2, esto representa un obstáculo cognitivo y operativo significativo. Sui aborda este desafío a nivel de protocolo con Transacciones Patrocinadas.

La idea central es simple: permitir que una parte (el Patrocinador) pague las tarifas de gas en SUI por la transacción de otra parte (el Usuario). De este modo, incluso si un usuario no tiene SUI en su billetera, puede iniciar acciones en cadena con éxito.

Paymaster ≈ Gas Station​

En el ecosistema Sui, la lógica para patrocinar transacciones suele ser manejada por un servicio fuera de cadena o en cadena llamado Gas Station o Paymaster. Sus responsabilidades principales incluyen:

1. Evaluar la transacción: recibe los datos de la transacción sin gas del usuario (GasLessTransactionData).
2. Proveer gas: bloquea y asigna la tarifa de gas necesaria para la transacción. Esto normalmente se gestiona mediante un pool de gas compuesto por muchos objetos SUI Coin.
3. Generar una firma del patrocinador: tras aprobar el patrocinio, la Gas Station firma la transacción con su clave privada (SponsorSig), certificando su disposición a pagar la tarifa.
4. Devolver la transacción firmada: envía de vuelta el TransactionData, que ahora incluye los datos de gas y la firma del patrocinador, a la espera de la firma final del usuario.

En resumen, una Gas Station actúa como un servicio de repostaje para los usuarios de tu dApp, asegurando que sus “vehículos” (transacciones) puedan viajar sin problemas por la red Sui.

2. Arquitectura de alto nivel y flujo de interacción​

Una transacción sin gas típica implica coordinación entre el usuario, el frontend de la dApp, la Gas Station y un nodo completo de Sui. La secuencia de interacción es la siguiente:

Desglose del flujo:

1. El Usuario realiza una acción en la UI de la dApp, que construye un paquete de datos de transacción sin información de gas.
2. La dApp envía estos datos a su Gas Station designada para solicitar patrocinio.
3. La Gas Station verifica la validez de la solicitud (p. ej., comprueba si el usuario es elegible para el patrocinio), luego rellena la transacción con una Gas Coin y su firma, devolviendo la transacción semicompleta a la dApp.
4. El Usuario ve los detalles completos de la transacción en su billetera (p. ej., “Comprar un NFT”) y proporciona la firma final. Este paso es crucial para garantizar que el usuario mantenga su consentimiento y control sobre sus acciones.
5. La dApp difunde la transacción completa, que contiene tanto la firma del usuario como la del patrocinador, a un Nodo Completo de Sui.
6. Tras la finalización en cadena, la Gas Station puede confirmar esto escuchando eventos o recibos en cadena y luego notificar al backend de la dApp mediante un webhook para cerrar el bucle del proceso de negocio.

3. Tres modelos de interacción principales​

Puedes usar los siguientes tres modelos de interacción de forma individual o combinada, según tus necesidades comerciales.

Modelo 1: Iniciado por el usuario → Aprobado por el patrocinador (más común)​

Este es el modelo estándar, adecuado para la gran mayoría de interacciones dentro de la dApp.

1. El usuario construye GasLessTransactionData: el usuario realiza una acción dentro de la dApp.
2. El patrocinador añade GasData y firma: el backend de la dApp envía la transacción a la Gas Station, que la aprueba, adjunta una Gas Coin y añade su firma.
3. El usuario revisa y da la firma final: el usuario confirma los detalles finales en su billetera y firma. La dApp entonces la envía a la red.

Este modelo logra un excelente equilibrio entre seguridad y experiencia de usuario.

Modelo 2: Patrocinador inicia airdrops/incentivos​

Este modelo es perfecto para airdrops, incentivos a usuarios o distribuciones masivas de activos.

1. Patrocinador pre‑llena TransactionData + firma: el patrocinador (normalmente el equipo del proyecto) construye la mayor parte de la transacción (p. ej., airdrop de un NFT a una dirección específica) y adjunta su firma de patrocinio.
2. La segunda firma del usuario la hace efectiva: el usuario solo necesita firmar esta transacción “pre‑aprobada” una vez para que se ejecute.

Esto crea una experiencia de usuario extremadamente fluida. Con un solo clic para confirmar, los usuarios pueden reclamar recompensas o completar tareas, aumentando drásticamente las tasas de conversión de campañas de marketing.

Modelo 3: GasData comodín (modelo de línea de crédito)​

Este es un modelo más flexible y basado en permisos.

1. El patrocinador transfiere un objeto GasData: primero crea uno o varios objetos Gas Coin con un presupuesto específico y transfiere la propiedad directamente al usuario.
2. El usuario gasta libremente dentro del presupuesto: el usuario puede usar esos Gas Coins para pagar cualquier transacción que inicie, siempre que se mantenga dentro de los límites y el periodo de validez del presupuesto.
3. El Gas Coin se devuelve: una vez agotado o expirado, el objeto Gas Coin puede ser diseñado para destruirse automáticamente o volver al patrocinador.

Este modelo equivale a entregar al usuario una “tarjeta de crédito de tarifas de gas” limitada en tiempo y presupuesto, adecuada para escenarios que requieren alta autonomía del usuario, como ofrecer una experiencia free‑to‑play durante una temporada de juego.

4. Escenarios de aplicación típicos​

El poder del Sui Paymaster no solo radica en resolver el problema de las tarifas de gas, sino también en su capacidad de integrarse profundamente con la lógica de negocio para crear nuevas posibilidades.

Escenario 1: Paywalls​

Muchas plataformas de contenido o servicios de dApp requieren que los usuarios cumplan ciertos criterios (p. ej., poseer un NFT VIP, alcanzar un nivel de membresía) para acceder a funcionalidades. El Paymaster puede implementar esta lógica de forma perfecta.

• Flujo: un usuario solicita una acción → el backend de la dApp verifica las calificaciones del usuario (p. ej., propiedad de NFT) → si es elegible, llama al Paymaster para patrocinar la tarifa de gas; si no, simplemente niega la solicitud de firma.
• Ventaja: este modelo es inherentemente resistente a bots y abusos. Dado que la decisión de patrocinio se toma en el backend, los usuarios malintencionados no pueden eludir la verificación de calificaciones para drenar fondos de gas.

Escenario 2: Checkout con un clic​

En e‑commerce o compras dentro de juegos, simplificar el proceso de pago es crítico.

• Flujo: el usuario hace clic en “Comprar ahora” en la página de checkout. La dApp construye una transacción que incluye la lógica de negocio (p. ej., transfer_nft_to_user). El usuario solo necesita firmar para aprobar la transacción de negocio en su billetera, sin preocuparse por el gas. La tarifa de gas la cubre el patrocinador de la dApp.
• Ventaja: puedes codificar parámetros de negocio como un order_id directamente en el ProgrammableTransactionBlock, permitiendo una atribución on‑chain precisa para los pedidos del backend.

Escenario 3: Atribución de datos​

El seguimiento preciso de datos es fundamental para la optimización del negocio.

• Flujo: al construir la transacción, escribe un identificador único (como un order_hash) en los parámetros de la transacción o en un evento que se emitirá al ejecutarse.
• Ventaja: cuando la Gas Station recibe el recibo on‑chain de una transacción exitosa, puede extraer fácilmente ese order_hash analizando el evento o los datos de la transacción. Esto permite mapear con precisión los cambios de estado on‑chain a pedidos o acciones específicas del backend.

5. Esqueleto de código (basado en el SDK de Rust)​

A continuación se muestra un fragmento simplificado que demuestra los pasos centrales de interacción.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Para una implementación completa, consulta el Tutorial de Gas Station de la documentación oficial de Sui, que ofrece ejemplos de código listos para usar.

6. Riesgos y protecciones​

Aunque potente, desplegar una Gas Station en producción requiere considerar cuidadosamente los siguientes riesgos:

• Equivocación (doble gasto): un usuario malicioso podría intentar usar la misma Gas Coin en múltiples transacciones paralelas, lo que bloquearía la Gas Coin en la red Sui. Esto se mitiga eficazmente asignando una Gas Coin única por usuario o por transacción, manteniendo una lista negra y limitando la tasa de solicitudes de firma.
• Gestión del pool de gas: en escenarios de alta concurrencia, una sola Gas Coin de gran valor puede convertirse en un cuello de botella de rendimiento. El servicio de Gas Station debe ser capaz de dividir automáticamente grandes SUI Coins en muchas Gas Coins de menor valor y recuperarlas eficientemente después de su uso. Proveedores profesionales de Gas Station como Shinami ofrecen soluciones gestionadas y maduras para esto.
• Autorización y limitación de velocidad: es imprescindible establecer políticas estrictas de autorización y limitación de velocidad. Por ejemplo, gestionar límites y frecuencias de patrocinio basados en la IP del usuario, la dirección de la billetera o tokens API para evitar que el servicio sea drenado por actores malintencionados.

7. Herramientas del ecosistema​

El ecosistema Sui ya ofrece un conjunto rico de herramientas para simplificar el desarrollo y despliegue de Paymasters:

• SDK oficiales (Rust/TypeScript): incluyen APIs de alto nivel como sponsor_transaction_block(), reduciendo significativamente la complejidad de integración.
• Shinami Gas Station: proporciona un servicio gestionado todo‑en‑uno, que incluye división/reclamación automática de Gas Coins, métricas detalladas y notificaciones webhook, permitiendo a los desarrolladores centrarse en la lógica de negocio.
• Enoki / Demos de Mysten: la comunidad y Mysten Labs también ofrecen implementaciones de Paymaster de código abierto que pueden usarse como referencia para construir tu propio servicio.

8. Lista de verificación de implementación​

¿Listo para actualizar tu dApp a la era sin gas? Recorre esta lista antes de comenzar:

• Planifica tu flujo de financiación: define la fuente de fondos del patrocinador, el presupuesto y la estrategia de reposición. Configura monitoreo y alertas para métricas clave (p. ej., saldo del pool de gas, tasa de consumo).
• Reserva campos de atribución: al diseñar los parámetros de tu transacción, asegura reservar campos para identificadores de negocio como order_id o user_id.
• Despliega políticas anti‑abuso: implementa autorización estricta, limitación de velocidad y mecanismos de registro antes de lanzar.
• Ensaya en testnet: ya sea construyendo tu propio servicio o integrando una Gas Station de terceros, realiza pruebas exhaustivas de concurrencia y estrés en una testnet o devnet primero.
• Optimiza continuamente: después del lanzamiento, monitorea continuamente las tasas de éxito de transacciones, razones de fallos y costos de gas. Ajusta tu presupuesto y estrategias basándote en los datos.

Conclusión​

El Sui Paymaster (Gas Station) es mucho más que una herramienta para cubrir tarifas de gas de los usuarios. Es un paradigma poderoso que combina elegantemente una experiencia “cero SUI en cadena” para el usuario con la necesidad empresarial de “atribución a nivel de orden on‑chain” dentro de una única transacción atómica. Allana el camino para que usuarios de Web2 ingresen a Web3 y brinda a los desarrolladores una flexibilidad sin precedentes para la personalización de negocios.

Con un ecosistema de herramientas cada vez más maduro y los actuales bajos costos de gas en la red Sui, nunca ha habido un mejor momento para actualizar los flujos de pago e interacción de tu dApp a la era sin gas.

Cómo eliminar la fricción de la billetera, mantener el flujo de usuarios y prever el potencial de crecimiento

¿Qué pasaría si tu aplicación Web3 tuviera el mismo flujo de registro fluido que un servicio Web2 moderno? Esa es la promesa central de zkLogin en la blockchain Sui. Funciona como OAuth para Sui, permitiendo a los usuarios iniciar sesión con cuentas conocidas de Google, Apple, X y más. Una prueba de conocimiento cero (ZKP) vincula de forma segura esa identidad Web2 a una dirección de Sui en la cadena — sin ventanas emergentes de billeteras, sin frases semilla y sin deserción de usuarios.

El impacto es real e inmediato. Con cientos de miles de cuentas zkLogin ya activas, los casos de estudio informan ganancias masivas en la conversión de usuarios, saltando de un desastroso 17 % a un saludable 42 % después de eliminar las barreras tradicionales de las billeteras. Analicemos cómo funciona y qué puede hacer por tu proyecto.

Por qué las billeteras matan la conversión inicial​

Has construido una dApp innovadora, pero tu embudo de adquisición de usuarios tiene fugas. El culpable es casi siempre el mismo: el botón "Connect Wallet". El onboarding estándar de Web3 es un laberinto de instalaciones de extensiones, advertencias de frases semilla y cuestionarios de jerga cripto.

Es una barrera masiva para los recién llegados. Los investigadores de UX observaron una asombrosa caída del 87 % en el momento en que aparecía un aviso de billetera. En un experimento revelador, simplemente redirigir ese aviso a una etapa posterior en el proceso de pago cambió la tasa de finalización al 94 %. Incluso para los usuarios curiosos por las criptomonedas, el temor principal es: "Podría perder mis fondos si hago clic en el botón equivocado". Eliminar ese único e intimidante paso es la clave para desbloquear el crecimiento exponencial.

Cómo funciona zkLogin (en lenguaje sencillo)​

zkLogin esquiva elegantemente el problema de la billetera utilizando tecnologías en las que todos los usuarios de Internet ya confían. La magia ocurre entre bastidores en unos pocos pasos rápidos:

1. Par de claves efímeras: Cuando un usuario quiere iniciar sesión, se genera localmente en su navegador un par de claves temporales para una sola sesión. Piensa en ello como una clave de acceso temporal, válida solo para esta sesión.
2. Proceso OAuth: El usuario inicia sesión con su cuenta de Google, Apple u otra cuenta social. Tu aplicación inserta hábilmente un valor único (nonce) en esta solicitud de inicio de sesión.
3. Servicio ZKP: Después de un inicio de sesión exitoso, un servicio ZKP (Zero-Knowledge Proof) genera una prueba criptográfica. Esta prueba confirma: "Este token de OAuth autoriza al propietario de la clave de acceso temporal", sin revelar nunca la identidad personal del usuario en la cadena.
4. Derivar dirección: El JWT (JSON Web Token) del usuario proporcionado por el proveedor de OAuth se combina con un salt único para generar de manera determinista su dirección permanente de Sui. El salt se mantiene privado, ya sea en el lado del cliente o en un backend seguro.
5. Enviar transacción: Tu aplicación firma las transacciones con la clave temporal y adjunta la prueba ZK. Los validadores de Sui verifican la prueba en la cadena, confirmando la legitimidad de la transacción sin que el usuario necesite nunca una billetera tradicional.

Guía de integración paso a paso​

¿Listo para implementar esto? Aquí tienes una guía rápida utilizando el SDK de TypeScript. Los principios son idénticos para Rust o Python.

1. Instalar el SDK​

El paquete @mysten/sui incluye todos los ayudantes de zklogin que necesitarás.

pnpm add @mysten/sui

2. Generar claves y Nonce​

Primero, crea un par de claves efímeras y un nonce vinculado a la época actual en la red Sui.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Redirigir a OAuth​

Construye la URL de inicio de sesión OAuth adecuada para el proveedor que estés utilizando (por ejemplo, Google, Facebook, Apple) y redirige al usuario.

4. Decodificar JWT y obtener el Salt del usuario​

Después de que el usuario inicie sesión y sea redirigido de vuelta, toma el id_token de la URL. Úsalo para obtener el salt específico del usuario desde tu backend, luego deriva su dirección de Sui.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. Solicitar prueba ZK​

Envía el JWT a un servicio probador (prover) para obtener la prueba ZK. Para el desarrollo, puedes usar el probador público de Mysten. En producción, deberías alojar el tuyo propio o usar un servicio como Enoki.

const proof = await fetch('/api/prove', {
  method:'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Firmar y enviar​

Ahora, construye tu transacción, establece el remitente como la dirección zkLogin del usuario y ejecútala. El SDK se encarga de adjuntar automáticamente los zkLoginInputs (la prueba). ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // Cualquier llamada a Move
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // La magia ocurre aquí
});

7. Persistir la sesión​

Para una experiencia de usuario más fluida, cifra y almacena el par de claves y el salt en IndexedDB o en el almacenamiento local. Recuerda rotarlos cada pocas épocas para mejorar la seguridad.

Plantilla de Proyección de KPI​

La diferencia que marca zkLogin no es solo cualitativa; es cuantificable. Compare un embudo de incorporación típico con uno impulsado por zkLogin:

👉 Lo que esto significa: Para una campaña que atrae 10,000 visitantes únicos, esa es la diferencia entre 300 acciones on-chain el primer día y más de 2,500.

Buenas Prácticas y Aspectos a Considerar​

Para crear una experiencia aún más fluida, tenga en cuenta estos consejos profesionales:

• Use Transacciones Patrocinadas: Pague las tarifas de las primeras transacciones de sus usuarios. Esto elimina toda fricción y ofrece un increíble momento "¡ajá!".
• Maneje los Salts con cuidado: Cambiar el salt de un usuario generará una nueva dirección. Solo haga esto si controla una ruta de recuperación confiable para ellos.
• Exponga la Dirección de Sui: Después del registro, muestre a los usuarios su dirección on-chain. Esto permite a los usuarios avanzados importarla a una billetera tradicional más adelante si así lo desean.
• Evite los bucles de actualización: Almacene en caché el JWT y el par de claves efímeras hasta que expiren para evitar pedir al usuario que inicie sesión repetidamente.
• Monitoree la latencia del Prover: Vigile el tiempo de ida y vuelta de la generación de pruebas. Si supera los 2 segundos, considere alojar un prover regional para mantener la rapidez.

Dónde BlockEden.xyz aporta valor​

Mientras que zkLogin perfecciona el flujo de cara al usuario, escalarlo introduce nuevos desafíos en el backend. Ahí es donde entra BlockEden.xyz.

• Capa de API: Nuestros nodos RPC de alto rendimiento y enrutamiento geográfico garantizan que sus transacciones de zkLogin se procesen con una latencia mínima, independientemente de la ubicación del usuario.
• Observabilidad: Obtenga paneles de control listos para usar para rastrear métricas clave como la latencia de las pruebas, los ratios de éxito/fallo y la salud de su embudo de conversión.
• Cumplimiento: Para las aplicaciones que conectan con fiat, nuestro módulo opcional de KYC proporciona una rampa de entrada (on-ramp) compatible directamente desde la identidad verificada del usuario.

¿Listo para lanzar?​

La era de los flujos de billetera toscos e intimidantes ha terminado. Inicie un sandbox de zkLogin, conecte el endpoint de nodo completo de BlockEden y vea cómo sube su gráfico de registros, mientras sus usuarios ni siquiera tienen que escuchar la palabra “wallet”. 😉

Durante años, el mundo cripto ha estado limitado por un problema crítico de usabilidad: la cartera. Las carteras tradicionales, conocidas como Cuentas Externamente Poseídas (EOA), son implacables. Una sola frase semilla perdida significa que tus fondos se van para siempre. Cada acción requiere una firma y las tarifas de gas deben pagarse con el token nativo de la cadena. Esta experiencia torpe y de alto riesgo es una barrera importante para la adopción masiva.

Entra Abstracción de Cuentas (AA), un cambio de paradigma que redefinirá cómo interactuamos con la cadena de bloques. En esencia, AA transforma la cuenta del usuario en un contrato inteligente programable, desbloqueando funciones como recuperación social, transacciones con un clic y pagos de gas flexibles.

El camino hacia este futuro más inteligente se está desarrollando a lo largo de tres rutas distintas: el probado ERC-4337, el eficiente Native AA y el muy esperado EIP-7702. Analicemos qué significa cada enfoque para desarrolladores y usuarios.

💡 Ruta 1: El Pionero — ERC-4337​

ERC-4337 fue el avance que llevó la abstracción de cuentas a Ethereum y a las cadenas EVM sin modificar el protocolo central. Piensa en ello como una capa inteligente añadida sobre el sistema existente.

Introduce un nuevo flujo de transacciones que involucra:

• UserOperations: Un nuevo objeto que representa la intención del usuario (p. ej., “intercambiar 100 USDC por ETH”).
• Bundlers: Actores fuera de la cadena que recogen UserOperations, los agrupan y los envían a la red.
• EntryPoint: Un contrato inteligente global que valida y ejecuta las operaciones agrupadas.

Lo Bueno:

• Compatibilidad Universal: Puede desplegarse en cualquier cadena EVM.
• Flexibilidad: Permite funciones avanzadas como claves de sesión para juegos, seguridad multfirmas y patrocinio de gas mediante Paymasters.

El Compromiso:

• Complejidad y Coste: Introduce una sobrecarga de infraestructura significativa (ejecución de Bundlers) y tiene los costos de gas más altos de los tres enfoques, ya que cada operación pasa por la lógica adicional de EntryPoint. Por eso, su adopción se ha concentrado principalmente en L2s de bajo costo como Base y Polygon.

ERC-4337 abrió el camino para que otras soluciones AA pudieran funcionar. Demostró la demanda y sentó las bases para una experiencia Web3 más intuitiva.

🚀 Ruta 2: El Ideal Integrado — Native Account Abstraction​

Si ERC-4337 es un complemento, Native AA construye funciones inteligentes directamente en la base de la cadena. Cadenas como zkSync Era y Starknet fueron diseñadas desde cero con AA como principio central. En estas redes, cada cuenta es un contrato inteligente.

Lo Bueno:

• Eficiencia: Al integrar la lógica AA en el protocolo, se eliminan capas extra, lo que genera costos de gas significativamente menores en comparación con ERC-4337.
• Simplicidad para los Desarrolladores: No es necesario gestionar Bundlers ni un mempool separado. El flujo de transacciones se asemeja mucho al de una operación estándar.

El Compromiso:

• Fragmentación del Ecosistema: Native AA es específico de cada cadena. Una cuenta en zkSync es distinta de una cuenta en Starknet, y ninguna es nativa de Ethereum mainnet. Esto crea una experiencia fragmentada para usuarios y desarrolladores que operan en múltiples cadenas.

Native AA nos muestra el “juego final” en términos de eficiencia, pero su adopción está ligada al crecimiento de los ecosistemas que la alojan.

🌉 Ruta 3: El Puente Pragmático — EIP-7702​

Programado para incluirse en la actualización “Pectra” de Ethereum en 2025, EIP-7702 es un cambio de juego diseñado para llevar funciones AA a la masa de usuarios de EOAs existentes. Adopta un enfoque híbrido: permite que una EOA delegue temporalmente su autoridad a un contrato inteligente para una única transacción.

Piensa en ello como otorgar superpoderes temporales a tu EOA. No necesitas migrar fondos ni cambiar tu dirección. Tu cartera simplemente añade una autorización a la transacción, permitiendo ejecutar operaciones agrupadas (p. ej., aprobar + intercambiar con un clic) o recibir patrocinio de gas.

Lo Bueno:

• Compatibilidad Retroactiva: Funciona con los miles de millones de dólares asegurados por EOAs actuales. No se requiere migración.
• Baja Complejidad: Utiliza el pool de transacciones estándar, eliminando la necesidad de Bundlers y simplificando drásticamente la infraestructura.
• Catalizador de Adopción Masiva: Al hacer que funciones inteligentes estén al alcance de cualquier usuario de Ethereum de la noche a la mañana, podría acelerar rápidamente la adopción de mejores patrones de UX.

El Compromiso:

• No es “AA Completa”: EIP-7702 no resuelve la gestión de claves de la propia EOA. Si pierdes tu clave privada, sigues sin suerte. Se trata más de mejorar las capacidades de transacción que de rehacer la seguridad de la cuenta.

Comparación Directa: Un Análisis Claro​

El Futuro es Convergente y Centrado en el Usuario​

Estas tres rutas no son mutuamente excluyentes; están convergiendo hacia un futuro donde la cartera deja de ser un punto de fricción.

1. La Recuperación Social se Vuelve Estándar 🛡️: La era de “claves perdidas, fondos perdidos” está terminando. AA permite la recuperación basada en guardianes, haciendo que la auto‑custodia sea tan segura y indulgente como una cuenta bancaria tradicional.
2. UX de Juegos Rediseñada 🎮: Las claves de sesión permitirán una jugabilidad fluida sin constantes ventanas de “aprobar transacción”, logrando que los juegos Web3 se sientan como los juegos Web2.
3. Carteras como Plataformas Programables: Las carteras se volverán modulares. Los usuarios podrán añadir un “módulo DeFi” para farming automatizado o un “módulo de seguridad” que requiera 2FA para transferencias grandes.

Para desarrolladores y proveedores de infraestructura como Blockeden.xyz, esta evolución es increíblemente emocionante. La complejidad de Bundlers, Paymasters y los distintos estándares AA crea una gran oportunidad para ofrecer infraestructura robusta, fiable y abstracta. El objetivo es una experiencia unificada donde el desarrollador pueda integrar fácilmente funciones AA, y la cartera utilice inteligentemente ERC-4337, Native AA o EIP-7702 bajo el capó, según lo que soporte la cadena.

La cartera finalmente recibe la actualización que merece. La transición de EOAs estáticas a cuentas inteligentes dinámicas no es solo una mejora—es la revolución que hará que Web3 sea accesible y segura para el próximo billón de usuarios.

¡Hola y bienvenidos de nuevo a nuestro blog de blockchain! Hoy nos sumergiremos en una nueva propuesta emocionante llamada ERC-4337, que introduce la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. En su lugar, esta propuesta se basa en infraestructura de capa superior para lograr sus objetivos. Exploremos lo que ERC-4337 tiene para ofrecer y cómo aborda las limitaciones del ecosistema actual de Ethereum.

¿Qué es ERC-4337?​

ERC-4337 es una propuesta que introduce la abstracción de cuentas en Ethereum mediante el uso de un mempool separado y un nuevo tipo de objeto pseudo‑transacción llamado UserOperation. Los usuarios envían objetos UserOperation al mempool alternativo, donde una clase especial de actores llamados bundlers los empaquetan en una transacción que realiza una llamada handleOps a un contrato dedicado. Estas transacciones se incluyen luego en un bloque.

La propuesta busca lograr varios objetivos:

1. Permitir a los usuarios utilizar carteras de contratos inteligentes con lógica de verificación arbitraria como sus cuentas principales.
2. Eliminar por completo la necesidad de que los usuarios tengan cuentas externas (EOAs).
3. Garantizar la descentralización permitiendo que cualquier bundler participe en el proceso de inclusión de operaciones de usuario con abstracción de cuentas.
4. Permitir que toda la actividad ocurra a través de un mempool público, eliminando la necesidad de que los usuarios conozcan direcciones de comunicación directa de actores específicos.
5. Evitar suposiciones de confianza sobre los bundlers.
6. Evitar requerir cambios en el consenso de Ethereum para una adopción más rápida.
7. Soportar otros casos de uso como aplicaciones que preservan la privacidad, multi‑operaciones atómicas, pagar tarifas de transacción con tokens ERC‑20 y transacciones patrocinadas por desarrolladores.

Compatibilidad hacia atrás​

Dado que ERC-4337 no modifica la capa de consenso, no existen problemas directos de compatibilidad hacia atrás para Ethereum. Sin embargo, las cuentas anteriores a ERC-4337 no son fácilmente compatibles con el nuevo sistema porque carecen de la función validateUserOp necesaria. Esto puede solucionarse creando una cuenta compatible con ERC-4337 que re‑implemente la lógica de verificación como un wrapper y configurándola como el remitente de operaciones de confianza de la cuenta original.

Implementación de referencia​

Para quienes estén interesados en profundizar en los detalles técnicos de ERC-4337, hay una implementación de referencia disponible en https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Consideraciones de seguridad​

El contrato de punto de entrada para ERC-4337 debe ser auditado exhaustivamente y verificado formalmente, ya que sirve como punto central de confianza para todo el sistema. Si bien este enfoque reduce la carga de auditoría y verificación formal para cuentas individuales, concentra el riesgo de seguridad en el contrato de punto de entrada, que debe ser verificado de manera robusta.

La verificación debe cubrir dos afirmaciones principales:

1. Seguridad contra secuestros arbitrarios: el punto de entrada solo llama a una cuenta de forma genérica si la función validateUserOp de esa cuenta específica ha pasado.
2. Seguridad contra el drenaje de tarifas: si el punto de entrada llama a validateUserOp y pasa, también debe realizar la llamada genérica con calldata igual a op.calldata.

Conclusión​

ERC-4337 es una propuesta emocionante que busca introducir la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. Al utilizar infraestructura de capa superior, abre nuevas posibilidades para la descentralización, la flexibilidad y diversos casos de uso. Aunque existen consideraciones de seguridad que abordar, esta propuesta tiene el potencial de mejorar significativamente el ecosistema de Ethereum y la experiencia del usuario.