Nous contacter

Découvrir / GLVM

GLVM

Machine virtuelle logique globale

Une seule couche d’exécution logique, coordonnée sur de nombreuses machines.

GLVM est l’abstraction d’exécution destinée aux développeurs qu’ALUX construit à partir de son environnement d’exécution concurrent. Une TVM fournit le moteur concret sur chaque machine participante ; le modèle GLVM réunit l’état d’exécution, les processus, le rejeu, la réplication et le consensus dans une seule couche logique.

Modèle physiqueUne TVM par machine
Modèle logiqueUne GLVM au-dessus d’elles
OrientationDe la chaîne au cloud, puis à l’appareil

La définition fondamentale

Une TVM par machine, avec un seul modèle d’exécution logique pour les coordonner

TVM est le moteur d’exécution de bytecode d’une machine. GLVM définit l’abstraction d’exécution à l’échelle du système, pour l’ensemble des TVM participantes. Il ne s’agit pas d’une autre machine virtuelle de bytecode : les développeurs ciblent un seul modèle logique, tandis que le rejeu déterministe, la continuité d’exécution, la réplication, la finalisation et le consensus sont coordonnés sous cette abstraction.

TVM

Machine virtuelle à espace de tuples

Le moteur d’exécution concret d’ALUX. Il exécute le bytecode Tolang, coordonne des processus indépendants par des canaux et des événements COMM, et enregistre les choix non déterministes nécessaires au rejeu déterministe.

Un moteur concret au sein d’une machine
GLVM

Machine virtuelle logique globale

GLVM définit le modèle logique proposé aux développeurs pour l’ensemble des TVM participantes. Il fournit un périmètre unique pour l’état d’exécution et les processus, tandis que le rejeu, la réplication, la finalisation et le consensus restent sous cette abstraction.

Un système logique au-dessus de nombreuses machines
Abstraction des machines virtuellesEn expansion
Atomicité verticaleCœur d’exécution
Atomicité horizontaleFeuille de route
Sécurité composableCœur d’exécution

Architecture à trois couches

Trois couches, un seul modèle d’exécution pour les développeurs

Les machines physiques exécutent des TVM ; dans l’architecture GLVM, ces moteurs participent à un même modèle d’exécution logique. Un futur système d’exploitation mondial organisera cette couche en services découvrables et orchestrés, régis par des capacités explicites.

Sélectionnez une couche pour mettre à jour le panneau de détails.

Exécution et atomicité

Une transaction peut attendre sur plusieurs blocs, puis être finalisée comme un tout

L’exécution évolue de tâches séquentielles et parallèles vers des processus concurrents qui communiquent, attendent et reprennent leur exécution. L’exécution composite étend le modèle pour permettre à plusieurs transactions concurrentes de partager un périmètre de finalisation de niveau supérieur ; la continuité sur plusieurs blocs constitue le socle vertical de cette évolution.

Cœur d’exécution

Concurrent

Les processus communiquent, attendent et reprennent leur exécution par des canaux.

Atomicité verticale · cœur d’exécutionL’exécution sur plusieurs blocs préserve un seul contexte transactionnel.
  1. 01 · Démarrage Un seul démarrage

    Démarrez une transaction avec un seul ensemble de capacités à portée limitée.

  2. 02 · Suspension Attendre sans finalisation partielle

    Si une réponse ou une correspondance de canal manque, préservez la continuation au lieu de finaliser prématurément.

  3. 03 · Enregistrement Consigner le choix

    ReplayTrie enregistre le choix non déterministe ou la réponse authentifiée nécessaire pour reproduire le chemin.

  4. 04 · Reprise Poursuivre la même transaction

    Un événement COMM correspondant ou une réponse enregistrée réveille la continuation préservée dans un bloc ultérieur.

  5. 05 · Finalisation Valider par commit ou abandonner

    À la frontière de finalisation, l’état admissible est validé par commit ; l’état provisoire rejeté est abandonné.

Chemin d’exécution principal

Exécution TVM concurrente · attente et reprise COMM · ReplayTrie · continuation et finalisation sur plusieurs blocs

Modèle d’atomicité

L’état intermédiaire provisoire ne devient un état confirmé qu’à la finalisation ; un chemin qui échoue est abandonné au lieu d’être réparé ultérieurement par des transactions compensatoires.

Lecture native hors chaîne

Un GET HTTPS authentifié peut être suspendu, enregistrer la réponse, être rejoué puis reprendre. La source des données reste déterminante pour leur véracité, et les effets de bord irréversibles hors chaîne restent en dehors du périmètre d’annulation.

Atomicité horizontale

L’exécution atomique entre shards et la composition avec des systèmes externes indépendants définissent la prochaine extension du modèle.

Sécurité par capacités objet

Donnez à la tâche une clé, pas le badge de l’utilisateur

Dans l’exemple du PDG et de Bob, l’accès fondé sur l’identité peut introduire dans la tâche l’autorité ambiante que représente le badge du PDG. Avec les capacités objet, la tâche reçoit une seule clé qui désigne le dossier de Bob. TVM impose à l’exécution la limite des objets accessibles. Sans référence de capacité vers un autre objet préexistant, la tâche ne peut ni le nommer ni y accéder.

Autorité étendue fondée sur l’identité

Le badge introduit dans la tâche des accès sans rapport avec elle

Même lorsque la tâche concerne uniquement Bob, l’autorité liée à l’identité que représente le badge du PDG peut toujours couvrir les données financières et les dossiers d’Alice, de Carol et de Bob.

Capacité objet explicite

La tâche reçoit une clé qui désigne le dossier de Bob

Cette clé représente un nom infalsifiable qui identifie le dossier de Bob. Sans référence de capacité vers un autre objet préexistant, la tâche ne peut ni le nommer ni y accéder. TVM vérifie cette limite à l’exécution.

Terminologie

Ici, la « clé » représente visuellement un nom infalsifiable OCAP, c’est-à-dire une référence de capacité. Ce n’est pas une clé cryptographique. Cette garantie s’applique aux interactions natives de TVM régies par des capacités ; les permissions des EVM hébergées et les services externes nécessitent leurs propres contrôles.

Explorateur de workflows

Choisissez l’environnement d’exécution selon la confiance, le temps de réponse et la localisation des données

Prenons la réparation d’un appareil impliquant plusieurs entreprises : le séquestre exige une vérification indépendante, les diagnostics ont besoin de ressources de calcul élastiques et le propriétaire de l’appareil doit approuver l’accès local. Dans le modèle GLVM, chaque tâche est affectée à l’environnement d’exécution adapté à ses exigences de confiance, de latence et de périmètre des données, tout en conservant une autorité explicite.

Choisir un besoin
Cœur d’exécution

TVM sur chaîne publique + hôte EVM

Conserver les fonds de garantie sous séquestre et enregistrer leur parcours d’approbation là où des validateurs indépendants peuvent vérifier la transition.

Suivre le flux cible0 / 6

Prêt. Lancez la simulation pour découvrir le flux logique cible.

01

Capacité à portée limitée

L’agent de réparation reçoit uniquement les droits nécessaires à cette intervention.

02

Planifier la répartition

Le workflow répartit des sous-tâches au périmètre délimité entre les TVM sur chaîne, privées ou dans le cloud et sur appareils clients.

03

Attente / suspension

Dans l’environnement d’exécution de la chaîne, l’absence de réponse préserve la continuation au lieu de finaliser prématurément la transaction.

04

Correspondance COMM

Un résultat produit rencontre la continuation en attente sur un canal ; le workflow reprend.

05

Preuve de rejeu

ReplayTrie enregistre les choix nécessaires pour qu’un autre validateur reproduise l’exécution.

06

Frontière de finalisation

BlockGit et Block Merge font converger les résultats vérifiables côté chaîne. Étendre un même commit atomique à tous les environnements d’exécution constitue l’horizon de GLVM.

Anatomie de l’environnement d’exécution

Neuf domaines de capacités derrière l’abstraction GLVM

GLVM n’est pas une seconde machine virtuelle de bytecode. Ces neuf vues de l’architecture, de l’exécution TVM, des capacités objet et du rejeu à BlockGit, aux machines virtuelles invitées et aux outils pour développeurs, présentent le système de capacités qui sous-tend son modèle d’exécution logique.

  1. 01
    Machine virtuelle de bytecodeCœur d’exécution

    TVM · espace de tuples · COMM

    Le moteur concurrent concret exécute le bytecode et permet à des processus indépendants d’échanger des données et des continuations par des canaux.

  2. 02
    SécuritéCœur d’exécution

    Capacités objet natives

    Les références infalsifiables rendent explicite l’autorité accessible et permettent à l’environnement d’exécution d’imposer les limites de la moindre autorité.

  3. 03
    AtomicitéCœur d’exécution

    Exécution atomique sur plusieurs blocs

    Les contextes d’exécution peuvent être suspendus sur plusieurs blocs, reprendre à partir de continuations préservées et atteindre une frontière de finalisation différée.

  4. 04
    FinalitéCœur d’exécution

    BlockGit · frange · fusion

    Un DAG de blocs, une rotation déterministe du leader et des règles de fusion font converger les tâches concurrentes côté chaîne sans leader permanent.

  5. 05
    RejeuCœur d’exécution

    ReplayTrie · trace

    Les choix non déterministes enregistrés et les traces d’exécution permettent aux validateurs de reproduire le chemin accepté.

  6. 06
    RéseauCœur d’exécution

    Réseau de pairs et de validateurs

    La couche des nœuds transporte les propositions, les blocs, les preuves d’état et la coordination des validateurs sous l’abstraction d’exécution.

  7. 07
    LangageCœur d’exécution

    Tolang → tolangc → .tox

    Tolang décrit des processus concurrents ; le compilateur transforme le code source en bytecode exécutable par TVM.

  8. 08
    Machines virtuelles invitéesSocle EVM · WASM prévu

    Hôte EVM · WASM prévu

    L’EVM s’exécute comme machine invitée avec état, via une coordination de type TSAC. WASM prolonge l’orientation vers des machines virtuelles hétérogènes.

  9. 09
    OutilsOutils pour développeurs

    Compilateur · LSP · espace d’expérimentation

    Le compilateur, le LSP, l’espace d’expérimentation, la suite de tests et les diagnostics intègrent le modèle d’exécution aux workflows des développeurs.

Horizon de développement

Le cœur d’exécution prend forme tandis que GLVM s’étend à de nouveaux environnements

GLVM se développe à partir de l’environnement d’exécution concurrent d’ALUX sur la chaîne. Le cloud privé constitue la prochaine étape d’intégration ; l’exécution sur appareils clients et entre shards reste inscrite dans la feuille de route. La carte ci-dessous distingue le cœur d’exécution, les environnements en cours d’extension et le prochain horizon architectural.

Cœur d’exécution

  • TVM concurrente et COMM
  • ReplayTrie et traces d’exécution
  • Chemins de suspension / reprise sur plusieurs blocs
  • Fondements OCAP natifs
  • Voie d’hébergement EVM
  • DAG, frange et fusion BlockGit

Extension du système

  • Déploiement de moteurs privés ou dans le cloud
  • Abstraction GLVM entre environnements de déploiement
  • Durcissement pour une exploitation en production à grande échelle
  • Politiques enrichies et contrôles des canaux protégés
  • Observabilité de l’environnement d’exécution et outils d’exploitation

Feuille de route

  • Atomicité horizontale entre shards
  • Machine virtuelle invitée WASM
  • Déploiement de TVM sur appareils clients
  • Abstraction de compte et registre de capacités
  • Resynchronisation des pairs après une panne et changements dynamiques de l’ensemble des validateurs
  • Couche programmable de système d’exploitation mondial

Poursuivre la découverte

Explorez l’environnement d’exécution, les charges de travail des agents et les comparaisons entre systèmes

Runtime Lab explique le modèle d’exécution. La page Pour les agents IA présente le profil des charges de travail. ALUX face aux autres compare l’architecture et les capacités des différents systèmes.