Aprender / Runtime Lab
Runtime Lab
Paralelo / Concurrente / Componible
ALUX admite transacciones de larga duración reproducibles: las tareas independientes se ejecutan a la vez y las transacciones se coordinan mediante mensajes. El escenario de reserva ilustra el modelo objetivo para liquidar efectos relacionados entre sistemas en un único resultado atómico.
Ilustración técnica de alta calidad del runtime de ALUX conectando nodos, servicios en la nube, dispositivos, agentes, tokens de capacidad y carriles de confirmación.
La diferencia sencilla
Tres palabras, tres trabajos de runtime muy distintos
El paralelismo ejecuta transacciones independientes al mismo tiempo. La concurrencia permite que las transacciones interactúen mediante canales: una puede esperar un mensaje coincidente de otra y después continuar. La componibilidad reúne transiciones de estado de distintos sistemas en una única transición atómica auditable.
En el runtime actual de ALUX, el trabajo independiente puede ejecutarse en paralelo, las transacciones se coordinan mediante mensajes y la ejecución puede reanudarse entre bloques. La composición atómica entre sistemas independientes sigue siendo un objetivo arquitectónico.
Varios carriles de ejecución aislados avanzan al mismo tiempo.
Se completa más trabajo independiente en el mismo tiempo. Pero el paralelismo por sí solo no permite que esos trabajos intercambien mensajes ni que una transacción de larga duración espere y continúe.
El paralelismo encuentra varias respuestas a la vez. No hace que esos trabajos interactúen.
Paralelo
Buscar vuelos, hotel, traslado y seguro
al mismo tiempo
- Qué significa
- La ejecución paralela significa que los trabajos independientes se ejecutan a la vez. Un agente de viajes puede buscar vuelos, habitaciones, traslados y seguros sin que una búsqueda tenga que esperar a otra.
- Cómo lo hace ALUX
- La ejecución paralela es nativa del cálculo de procesos de ALUX: las transacciones no comparten memoria y toda interacción se limita a los canales de tuple space. Por ello, las transacciones independientes avanzan por carriles TVM separados, mientras Block Merge resuelve las solapamientos de estado al confirmar.
- Qué permite
- Se completa más trabajo independiente en el mismo tiempo. Pero el paralelismo por sí solo no permite que esos trabajos intercambien mensajes ni que una transacción de larga duración espere y continúe.
El paralelismo encuentra varias respuestas a la vez. No hace que esos trabajos interactúen.
Prueba el runtime completo
Modelar una reserva atómica
Usa cuatro acciones para explorar el modelo objetivo de composición: inicia las comprobaciones de reserva y pago, deja una espera por disponibilidad de habitación, envía el mensaje coincidente del hotel y, por último, modela una confirmación conjunta.
Las comprobaciones de reserva y pago avanzan de forma independiente.
La reserva deja una condición de disponibilidad en el canal.
El mensaje coincidente activa la continuación de la reserva.
La retención de la habitación y la autorización del pago se confirman como un solo resultado.
Reproducir en orden
Empieza por el paso 1. La reserva y el pago se gestionan por separado dentro del mismo runtime.
El trabajo independiente no espera detrás de una única cola global.
La dependencia vive en un canal, en vez de bloquear el runtime.
COMM crea la continuación; ReplayTrie registra la elección solo cuando la coincidencia es no determinista.
El objetivo es un único resultado de todo o nada con pruebas de liquidación reproducibles.
Ruta del runtime
Qué mantiene vivo un servicio
Un servicio de larga duración mantiene la coherencia porque cada paso puede ejecutarse, interactuar, llevar autoridad explícita, reproducirse de forma determinista y liquidarse por una única ruta atómica verificable.
Ciclo de vida del proceso TVM
Un proceso puede crear una rama, esperar durante un bloque y reanudarse en un bloque posterior sin reiniciar su contexto de ejecución local.
Tuple space + COMM
Un consumo en espera coincide con la producción de otra transacción. La coincidencia activa la continuación mientras el trabajo no relacionado sigue avanzando.
Límites OCAP
Las referencias a capacidades imposibles de falsificar se transfieren explícitamente, de modo que cada paso recibe solo la autoridad que necesita; la identidad no incorpora automáticamente otras autoridades al ámbito.
ReplayTrie
Solo se registran las decisiones COMM no deterministas relevantes, para que los validadores puedan reproducir la misma ejecución.
BlockGit + Block Merge
El trabajo concurrente entra en fringes verificados, donde los solapamientos se clasifican como aceptados, rechazados o pendientes de decisión antes de alcanzar la finalidad.
Siguiente capa
Un runtime lógico en muchos entornos
Runtime Lab muestra la ejecución paralela y basada en mensajes actual y, después, ilustra el modelo objetivo de composición atómica. GLVM describe la arquitectura más amplia para extender ese modelo lógico entre nodos blockchain, servicios en la nube y dispositivos personales.
Por qué importa
No son bloques más rápidos. Son servicios de larga duración.
El paralelismo gestiona la ejecución independiente. La concurrencia gestiona la interacción basada en mensajes y la espera/reanudación. ALUX implementa hoy esos fundamentos del runtime y avanza hacia la composición atómica entre límites de sistemas.
Mayor rendimiento, pero sin dependencias transaccionales ni correspondencia de mensajes.
Las transacciones pueden interactuar y esperar, pero los efectos entre sistemas aún pueden liquidarse por separado.
Existe un límite atómico, pero sin interacción ni espera no puede abarcar dependencias de larga duración.