Ir al contenido
ORBITRAONE

Orbitra L1 · Capa de ejecución

El entorno donde las aplicaciones acceden al mercado.

NexusWASM es el entorno de ejecución de contratos de Orbitra L1. Permite que una cadena nativa para mercados siga abierta a pagos, tokenización, juegos, datos y servicios de agentes, mientras sus módulos de mercado permanecen nativos y deterministas.

Ilustración: Orbitra L1 representada como seis capas apiladas: la experiencia en la parte superior, seguida de los servicios de mercado, la ejecución, el consenso, los datos y la red en la base. La luz desciende a través de las capas mientras una transacción se ejecuta y se finaliza, y vuelve a ascender como estado confirmado.
  1. 01ExperienciaOrbitra Prime · billeteras · aplicaciones · API institucionales
  2. 02Servicios de mercadoApexMatch · Aegis · Prism · compensación · liquidación
  3. 03EjecuciónVectorLanes · planificador determinista · NexusWASM
  4. 04ConsensoCuórum de QSE · certificados de finalidad · política de validadores
  5. 05DatosCompromisos de estado · historial · flujos de índices · pruebas
  6. 06RedEntrada regional · transporte cifrado · malla de disponibilidad

Capa · Ejecución

Función en la arquitectura de Orbitra L1

Dentro de la capa de ejecución, NexusWASM ejecuta el código de los contratos mientras VectorLanes y el planificador determinista deciden dónde y en qué orden se ejecuta. Cada transacción declara sus lecturas y escrituras, lo que permite compartir carriles paralelos con la actividad de mercado en lugar de esperar detrás de ella.

Los contratos acceden a la capa de servicios de mercado —ApexMatch, Aegis y Prism— mediante capacidades concedidas, no mediante acceso irrestricto. Sus resultados siguen el recorrido de cualquier transición: la capa de datos los registra y QSE los finaliza.

Junto a NexusWASM se encuentra EVM Capsule, un dominio aislado para el código de bytes y las herramientas de Ethereum. Amplía el alcance para desarrolladores en el borde de la arquitectura; nunca sustituye el entorno principal ni le impone las restricciones de EVM.

Ilustración: Un contrato de NexusWASM se ejecuta dentro de un entorno aislado (sandbox). Solo puede acceder a las capacidades que declaró —incluidos los módulos de mercado nativos—, mientras el cómputo y el almacenamiento se miden, y su acceso declarado al estado permite que el planificador lo ejecute en paralelo con trabajo no relacionado.
Contrato
  • Capacidades

  • Cómputo medido

  • Almacenamiento medido

Qué aporta NexusWASM a la arquitectura

  • 01

    Apertura con límites

    Las aplicaciones generales se ejecutan en la red, pero cada contrato solo accede a los activos, estados y módulos para los que tiene autorización.

  • 02

    Contratos preparados para el paralelismo

    Los conjuntos de acceso declarados permiten al planificador situar las llamadas de contratos junto a las transiciones de mercado, sin hacerlas esperar detrás.

  • 03

    Recursos con costes explícitos

    La tarificación explícita de cómputo y almacenamiento hace que las aplicaciones paguen lo que consumen, incluido el estado persistente.

  • 04

    Composición con los mercados

    Un contrato puede combinar su propia lógica con envío de órdenes, controles de riesgo y consultas de precios en una sola transición.