Desarrollo de aplicaciones financieras en Arc: cuatro aspectos que funcionan de forma diferente

Quicknode

8 de octubre de 2026 — 6 minutos de lectura

Compartir

Añadir como fuente preferida

Arc Está diseñado para aplicaciones que gestionan valor en el mundo real. Mantiene el entorno de ejecución EVM, por lo que los contratos Solidity existentes y las herramientas habituales de Ethereum siguen siendo útiles, al tiempo que traslada las comisiones, la liquidación y otros requisitos financieros a la propia red.

Esas decisiones modifican los sistemas relacionados con el contrato. Dos de las cuatro diferencias que se indican a continuación ya están disponibles en Arc ; las otras dos forman parte de la hoja de ruta y deben interpretarse como una orientación, no como una funcionalidad.

1. El USDC como gas

Una aplicación de stablecoins suele necesitar dos activos para completar una acción: la stablecoin que se va a transferir y un token independiente para pagar la ejecución. Esto genera otro saldo que hay que financiar, otro activo al que hay que asignar un precio y otro error mode cuando un usuario tiene dinero pero no suficiente gas.

Arc Elimina esa división al convertir el USDC en su activo de gas nativo. Las comisiones por transacción y el valor de la aplicación comparten la misma unidad de cuenta, por lo que los usuarios pueden realizar transacciones sin necesidad de adquirir un token de gas independiente. Los sistemas de tesorería y contabilidad también pueden registrar la transferencia y su coste de ejecución en dólares sin necesidad de introducir otro paso de conversión de precios. El diseño de comisiones de Arc suaviza las variaciones en la demanda de la red para facilitar la estimación de los costes, mientras que los métodos RPC de comisiones estándar permiten a las aplicaciones leer los valores actuales en tiempo de ejecución.

Hay un detalle de integración que merece la pena tener en cuenta a la hora de diseñar. El USDC nativo utiliza 18 decimales para las transferencias de gas y de valores EVM, mientras que su interfaz ERC-20 utiliza la conocida representación del USDC con 6 decimales. Se trata de dos vistas del mismo saldo, no de dos activos distintos. Por lo tanto, las carteras y los libros mayores deben normalizar estas vistas en lugar de mostrar ambas o sumarlas. Los indexadores deben aplicar la misma disciplina, ya que la actividad ERC-20 puede generar tanto un evento del sistema nativo como un evento de interfaz para un mismo movimiento, mientras que los envíos nativos solo generan el evento del sistema. Un ejemplo de « mainnet » (Envío de gas) de nuestra guía de indexación de USDCArc muestra cuatro registros con forma de transferencia para dos movimientos reales de USDC. La conclusión: « Arc » elimina el activo de gas independiente, no la necesidad de una visión canónica del USDC.

2. Finalidad determinista

En muchas redes, el hecho de que una transacción aparezca en un bloque no significa que una aplicación pueda considerarla liquidada con total seguridad. Los servicios esperan a recibir más confirmaciones, mantienen la actividad reciente como provisional y conservan rutas de reversión por si la cadena se reorganizara.

ArcEl consenso Malachite BFT elimina ese estado intermedio. Una transacción es o bien no confirmada o bien definitiva, y un bloque validado no puede reorganizarse. Las aplicaciones pueden actuar cuando el bloque se valida, en lugar de traducir la profundidad de confirmación en una puntuación de confianza.

Esto simplifica los flujos de trabajo que comienzan en otro lugar tras un resultado en cadena: actualizar un libro mayor, liberar existencias, notificar a otro servicio o iniciar la siguiente transacción. Los umbrales de confirmación y la lógica de reversión por reorganización pueden salir de la máquina de estados de la aplicación. Arc documenta la liquidación irreversible en menos de un segundo como una propiedad del diseño de la red, no como un acuerdo de nivel de servicio medido en producción, por lo que los equipos deben seguir midiendo la ruta completa que experimentan sus usuarios.

La finalidad no sustituye a la fiabilidad operativa. Las conexiones fallan, los consumidores se reinician, las entregas se vuelven a intentar y las bases de datos agotan el tiempo de espera. La ingesta duradera, las escrituras idempotentes, los efectos seguros para la reproducción y la conciliación siguen siendo esenciales. La propiedad « Arc » hace que la respuesta de la cadena sea definitiva. La aplicación sigue teniendo que procesar esa respuesta de forma fiable.

3. La privacidad como modelo de ejecución independiente

Las aplicaciones financieras suelen necesitar confidencialidad sin tener que trasladar la actividad a un sistema desconectado. Las condiciones de las transacciones, los saldos, las posiciones o las contrapartes pueden requerir una divulgación controlada, mientras que el movimiento de valor resultante debe seguir integrándose en la actividad pública de la cadena de bloques.

Arc El «Privacy Sector» (APS) es la respuesta prevista por Arc. Forma parte de la hoja de ruta y aún no está disponible, por lo que debería servir de base para la arquitectura futura, más que para las promesas actuales sobre el producto.

APS está diseñado como un entorno de ejecución confidencial para contratos Solidity junto con la EVM pública. Los estados públicos y privados se registrarían en el mismo bloque, lo que permitiría que los contratos de ambos entornos interactuaran de forma atómica. Un flujo de trabajo podría mantener privado un estado sensible al tiempo que se resuelve un efecto público relacionado, sin necesidad de recurrir a un puente independiente ni a una capa de mensajería diferida.

El límite de privacidad sería explícito. Las funciones, el almacenamiento y los eventos están ocultos por defecto, y son las aplicaciones las que deciden qué se puede exponer y qué contratos pueden interactuar. Esto hace que la confidencialidad forme parte del diseño de la ejecución, en lugar de ser una capa que intente ocultar los datos públicos una vez que ya se han generado. APS aún no está disponible, pero su ventaja prevista es clara: privacidad sin renunciar a Solidity ni a la composición atómica.

4. Firmas de carteras poscuánticas

Es posible que los sistemas de firma que protegen actualmente los monederos no sigan siendo seguros frente a ordenadores cuánticos lo suficientemente potentes. En el caso de las aplicaciones que conservan su valor a largo plazo, prepararse para esa posibilidad es una cuestión de migración, no una actualización de software de última hora.

ArcLa hoja de ruta poscuántica de ' comienza con una compatibilidad beta, opcional, con las firmas de monedero SLH-DSA-SHA2-128s en mainnet. Un monedero que active esta opción puede utilizar el nuevo esquema para autorizar transacciones. Esa protección se aplica al monedero. No se extiende a las firmas de los validadores ni convierte el consenso de Arc en poscuántico.

La compatibilidad con el protocolo es solo el primer paso. Las carteras de hardware, los servicios de firma, los SDK, las políticas de custodia, los sistemas de recuperación y las herramientas de transacción deben gestionar el esquema correctamente. Las normas siguen evolucionando, por lo que Arc prevé que la adopción se produzca mediante una transición, en lugar de un cambio inmediato.

La hoja de ruta amplía la protección por etapas. El cifrado poscuántico para la ejecución privada y las mejoras en la infraestructura fuera de cadena se llevarán a cabo tras el trabajo en las carteras, mientras que las firmas de los validadores siguen siendo un objetivo a largo plazo. Por lo tanto, el valor práctico de la versión beta es concreto: ofrece a las carteras participantes una vía temprana para probar y adoptar un esquema de autorización poscuántico sin exagerar el nivel de protección disponible en el resto de la red.

Desde el diseño de la red hasta el comportamiento de las aplicaciones

Estas diferencias comparten un objetivo común. « Arc » acerca los requisitos financieros recurrentes a la red: una unidad estable para el valor y las comisiones, un límite de liquidación claro, una vía para la ejecución confidencial y una forma de hacer evolucionar la autorización de los monederos. La compatibilidad con EVM permite a los desarrolladores utilizar esa base sin tener que renunciar a los contratos y las herramientas con los que ya están familiarizados.

Las aplicaciones siguen necesitando una contabilidad correcta, canales de datos fiables, controles de acceso bien definidos y una infraestructura de monederos segura. El « Arc » cambia los cimientos sobre los que se asientan esos sistemas, eliminando algunas complicaciones habituales e introduciendo nuevas limitaciones que es necesario comprender con precisión.

Quicknode admite Arc a través de puntos finales JSON-RPC y WSS, acceso completo al archivo con espacios de nombres de depuración y seguimiento, suscripciones a WebSocket, Webhooks, y Streams. Empieza a desarrollar en Arc desde Quicknode hoy mismo.