Aprende / GLVM
GLVM
Máquina virtual lógica global
Una capa lógica de ejecución, coordinada entre muchas máquinas.
GLVM es la abstracción de ejecución para desarrolladores que ALUX está construyendo a partir de su runtime concurrente. Cada TVM proporciona el motor concreto en una máquina participante; el modelo GLVM reúne el estado de ejecución, los procesos, la reproducción, la replicación y el consenso en una sola capa lógica.
La definición fundamental
Una TVM por máquina, coordinada mediante un modelo lógico de ejecución
TVM es el motor de ejecución de bytecode en una máquina. GLVM define la abstracción de ejecución a nivel de sistema entre las TVM participantes. No es otra VM de bytecode: los desarrolladores trabajan con un único modelo lógico mientras la reproducción determinista, la continuidad de ejecución, la replicación, la finalización y el consenso se coordinan por debajo de esa abstracción.
Máquina virtual de espacio de tuplas
El motor concreto de ejecución de ALUX. Ejecuta bytecode de Tolang, coordina procesos independientes mediante canales y eventos COMM, y registra las elecciones no deterministas necesarias para la reproducción determinista.
Un motor concreto dentro de una máquinaMáquina virtual lógica global
GLVM define el modelo lógico orientado a desarrolladores para las TVM participantes. Ofrece un límite común para el estado de ejecución y los procesos; la reproducción, replicación, finalización y el consenso permanecen por debajo de esta abstracción.
Un sistema lógico sobre muchas máquinasArquitectura de tres capas
Tres capas, un modelo de ejecución para desarrolladores
Las máquinas físicas ejecutan TVM; en la arquitectura GLVM, esos motores participan en un modelo lógico de ejecución compartido. Un futuro World OS organizará esa capa como servicios localizables y orquestados, regidos por capacidades explícitas.
Selecciona cualquier capa para actualizar el panel de detalles.
Ejecución y atomicidad
Una transacción puede esperar entre bloques y liquidarse como una sola
La ejecución evoluciona desde el trabajo secuencial y paralelo hacia procesos concurrentes que se comunican, esperan y reanudan. La ejecución compuesta amplía el modelo para que varias transacciones concurrentes compartan un límite de liquidación de nivel superior; la continuidad entre bloques proporciona la base vertical para esa dirección.
Secuencial
Una transición sigue a otra.
Paralela
Las transiciones independientes avanzan al mismo tiempo.
Concurrente
Los procesos se comunican, esperan y reanudan a través de canales.
Compuesta
Varias transacciones concurrentes comparten un objetivo atómico de nivel superior.
-
01 · Iniciar
Empezar una vez
Inicia una transacción con un conjunto de capacidades de alcance limitado.
-
02 · Suspender
Esperar sin liquidación parcial
Si falta una respuesta o una coincidencia de canal, conserva la continuación en vez de finalizar antes de tiempo.
-
03 · Registrar
Capturar la elección
ReplayTrie registra la elección no determinista o la respuesta autenticada necesaria para reproducir la ruta.
-
04 · Reanudar
Continuar la misma transacción
Un evento COMM coincidente o una respuesta registrada reactiva la continuación conservada en un bloque posterior.
-
05 · Finalizar
Confirmar o descartar
En el límite de finalización, se confirma el estado apto y se descarta el estado provisional rechazado.
Ejecución concurrente de TVM · espera y reanudación con COMM · ReplayTrie · continuación y finalización entre bloques
El estado intermedio provisional no pasa a ser estado confirmado hasta la finalización; si una ruta falla, se descarta en vez de repararse después mediante transacciones compensatorias.
Una solicitud HTTPS GET autenticada puede suspender la ejecución, registrar la respuesta, reproducirla y reanudarla. La fuente de datos sigue determinando la verdad, y los efectos secundarios irreversibles off-chain quedan fuera del rollback.
La ejecución atómica entre shards y la composición con sistemas externos independientes definen la próxima ampliación del modelo.
Seguridad basada en capacidades de objeto
Da a la tarea una sola clave, no la insignia del usuario
En el ejemplo del CEO y Bob, el acceso basado en identidad puede introducir en la tarea la autoridad ambiental que representa la insignia del CEO. Con capacidades de objeto, la tarea recibe una única clave que identifica el registro de Bob. La TVM aplica durante la ejecución el límite de lo que se puede alcanzar. Sin una referencia de capacidad a otro objeto preexistente, la tarea no puede nombrarlo ni acceder a él.
La insignia introduce en la tarea accesos que no guardan relación
Aunque la tarea solo trate de Bob, la autoridad de identidad representada por la insignia del CEO puede abarcar Finanzas y los registros de Alice, Carol y Bob.
La tarea recibe una clave que identifica el registro de Bob
Esta clave representa un nombre infalsificable que identifica el registro de Bob. Sin una referencia de capacidad a otro objeto preexistente, la tarea no puede nombrarlo ni acceder a él. La TVM comprueba ese límite durante la ejecución.
Aquí, «clave» representa visualmente un nombre infalsificable de OCAP: una referencia de capacidad. No es una clave criptográfica. Esta garantía se aplica a las interacciones nativas de TVM mediadas por capacidades; los permisos de EVM alojada y los servicios externos necesitan sus propios controles.
Explorador de flujos de trabajo
Elige la superficie de ejecución según la confianza, el tiempo de respuesta y la localidad de los datos
Imagina una reparación de dispositivos entre empresas: el escrow necesita una verificación independiente, los diagnósticos requieren cómputo elástico y el propietario del dispositivo debe aprobar el acceso local. En el modelo GLVM, cada tarea se asigna a la superficie de ejecución adecuada según la confianza, la latencia y los límites de datos, mientras la autoridad sigue siendo explícita.
TVM de cadena pública + host EVM
Mantén el escrow de garantía y registra su ruta de aprobación para que validadores independientes puedan verificar la transición.
Listo. Inicia la simulación para ver el flujo lógico objetivo.
Capacidad de alcance limitado
El agente de reparación recibe únicamente los derechos necesarios para este trabajo.
Planificar la distribución
El flujo de trabajo asigna subtareas acotadas a TVM de cadena, privadas o en la nube y de dispositivos cliente.
Esperar / suspender
En el runtime de la cadena, si falta una respuesta, se conserva la continuación en vez de finalizar la transacción antes de tiempo.
Coincidencia COMM
Un resultado producido coincide con la continuación en espera a través de un canal; el flujo de trabajo se reanuda.
Prueba de reproducción
ReplayTrie registra las elecciones necesarias para que otro validador pueda reproducir la ejecución.
Límite de finalización
BlockGit y Block Merge hacen converger resultados verificables de la cadena. Extender un único commit atómico a todas las superficies de ejecución es el horizonte de GLVM.
Anatomía del runtime
Nueve áreas de capacidades detrás de la abstracción GLVM
GLVM no es una segunda VM de bytecode. Estas nueve vistas de la arquitectura —desde la ejecución TVM, las capacidades de objeto y la reproducción hasta BlockGit, las VM invitadas y las herramientas para desarrolladores— muestran el sistema de capacidades que sustenta su modelo lógico de ejecución.
-
01
VM de bytecodeRuntime principal
TVM · tuple space · COMM
El motor concurrente concreto ejecuta bytecode y permite que procesos independientes intercambien datos y continuaciones mediante canales.
-
02
SeguridadRuntime principal
Capacidades de objeto nativas
Las referencias infalsificables hacen explícita la autoridad alcanzable y permiten que el runtime aplique los límites de mínima autoridad.
-
03
AtomicidadRuntime principal
Ejecución atómica entre bloques
Los contextos de ejecución pueden suspenderse entre bloques, reanudarse a partir de continuaciones conservadas y llegar a un límite de finalización diferida.
-
04
FinalidadRuntime principal
BlockGit · fringe · merge
Un DAG de bloques, la rotación determinista del líder y las reglas de combinación hacen converger el trabajo concurrente de la cadena sin un líder permanente.
-
05
ReproducciónRuntime principal
ReplayTrie · trace
Las elecciones no deterministas registradas y los rastros de ejecución permiten que los validadores reproduzcan la ruta aceptada.
-
06
RedRuntime principal
Red de pares y validadores
La capa de nodos transporta propuestas, bloques, pruebas de estado y coordinación de validadores bajo la abstracción de ejecución.
-
07
LenguajeRuntime principal
Tolang → tolangc → .tox
Tolang describe procesos concurrentes; el compilador convierte el código fuente en bytecode ejecutable por TVM.
-
08
VM invitadasEVM principal · WASM en la hoja de ruta
Host EVM · WASM en la hoja de ruta
La EVM se ejecuta como invitada con estado mediante una coordinación al estilo TSAC. WASM amplía la dirección de VM heterogéneas.
-
09
HerramientasSuperficie para desarrolladores
Compilador · LSP · playground
El compilador, LSP, playground, suite de pruebas y diagnósticos integran el modelo de ejecución en los flujos de trabajo de desarrollo.
Horizonte de desarrollo
El runtime principal toma forma mientras GLVM se expande a otros entornos
GLVM se expande desde el runtime concurrente de cadena de ALUX. La nube privada es la próxima superficie de integración; la ejecución en dispositivos cliente y entre shards sigue en la hoja de ruta. El mapa siguiente distingue entre el runtime principal, las superficies que se están ampliando y el próximo horizonte arquitectónico.
Runtime principal
- TVM concurrente y COMM
- ReplayTrie y rastros de ejecución
- Rutas de suspensión y reanudación entre bloques
- Fundamentos OCAP nativos
- Ruta del host EVM
- DAG de BlockGit, fringe y merge
Ampliación del sistema
- Despliegue de motores privados o en la nube
- Abstracción GLVM entre superficies de despliegue
- Endurecimiento para escala de producción
- Controles más completos de políticas y canales protegidos
- Observabilidad del runtime y herramientas de operación
Hoja de ruta
- Atomicidad horizontal entre shards
- VM invitada WASM
- Despliegue de TVM en dispositivos cliente
- Abstracción de cuentas y registro de capacidades
- Resincronización entre pares tras fallos y cambios dinámicos en el conjunto de validadores
- Capa programable de World OS