Comprendre / Runtime Lab
Runtime Lab
Parallèle / Concurrent / Composable
ALUX prend en charge les transactions longues rejouables : les tâches indépendantes s’exécutent ensemble et les transactions se coordonnent par messages. Le scénario de réservation illustre le modèle visé pour finaliser les effets liés entre systèmes en un résultat atomique unique.
Illustration technique haut de gamme de l’environnement d’exécution d’ALUX reliant des nœuds, des services cloud, des appareils, des agents, des jetons de capacité et des voies de validation.
La différence en quelques mots
Trois mots, trois fonctions d’exécution très différentes
Le parallélisme exécute des transactions indépendantes en même temps. La concurrence permet aux transactions d’interagir par des canaux : une transaction peut attendre un message correspondant provenant d’une autre, puis continuer. La composabilité lie les transitions d’état de différents systèmes en une transition atomique unique et auditable.
Dans l’environnement d’exécution actuel d’ALUX, les tâches indépendantes peuvent s’exécuter en parallèle, les transactions se coordonnent par messages et l’exécution peut reprendre d’un bloc à l’autre. La composition atomique entre systèmes indépendants reste un objectif architectural.
Plusieurs voies d’exécution isolées avancent en même temps.
Davantage de tâches indépendantes se terminent dans le même temps. Mais le parallélisme seul ne peut pas leur faire échanger des messages ni permettre à une transaction longue d’attendre puis de continuer.
Le parallélisme trouve plusieurs réponses à la fois. Il ne fait pas interagir ces tâches.
Parallèle
Vol, hôtel, transfert et assurance :
des recherches simultanées
- Ce que cela signifie
- L’exécution parallèle signifie que des tâches indépendantes s’exécutent en même temps. Un agent de voyage peut rechercher des vols, des chambres, des transferts et des assurances sans qu’une recherche attende une autre.
- Comment ALUX y parvient
- L’exécution parallèle est native dans le calcul des processus d’ALUX : les transactions ne partagent aucune mémoire et toute interaction est limitée aux canaux de l’espace de tuples. Les transactions indépendantes avancent donc dans des voies TVM distinctes, tandis que Block Merge résout les chevauchements d’état au moment de la validation.
- Ce que cela permet
- Davantage de tâches indépendantes se terminent dans le même temps. Mais le parallélisme seul ne peut pas leur faire échanger des messages ni permettre à une transaction longue d’attendre puis de continuer.
Le parallélisme trouve plusieurs réponses à la fois. Il ne fait pas interagir ces tâches.
Essayez l’environnement d’exécution complet
Modélisez une réservation atomique
Explorez le modèle de composition visé en quatre actions : lancez les vérifications de réservation et de paiement, déposez une attente de disponibilité de chambre, transmettez le message correspondant de l’hôtel, puis modélisez une confirmation conjointe.
Les vérifications de réservation et de paiement avancent indépendamment.
La réservation dépose une condition de disponibilité dans le canal.
Le message correspondant active la continuation de la réservation.
Le blocage de la chambre et l’autorisation de paiement sont validés en un résultat unique.
Lire dans l’ordre
Commencez par l’étape 1. La réservation et le paiement sont gérés séparément dans le même environnement d’exécution.
Les tâches indépendantes n’attendent pas dans une même file globale.
La dépendance réside dans un canal au lieu de bloquer l’environnement d’exécution.
COMM crée la continuation ; ReplayTrie n’enregistre le choix que lorsque l’appariement est non déterministe.
L’objectif est un résultat tout ou rien unique, accompagné de preuves de finalisation reproductibles.
Parcours d’exécution
Ce qui maintient un service en activité
Un service de longue durée reste cohérent parce que chaque étape peut s’exécuter, interagir, porter une autorité explicite, être rejouée de manière déterministe et se finaliser selon un même parcours atomique vérifiable.
Cycle de vie des processus TVM
Un processus peut créer des branches, attendre dans un bloc et reprendre dans un bloc ultérieur sans redémarrer son contexte d’exécution local.
Espace de tuples + COMM
Une opération consume en attente rencontre l’opération produce d’une autre transaction. L’appariement active la continuation pendant que les tâches sans lien poursuivent leur exécution.
Frontières OCAP
Les références de capacité infalsifiables sont transmises explicitement : chaque étape ne reçoit que l’autorité dont elle a besoin ; une identité n’introduit pas automatiquement d’autorité sans lien avec la tâche dans son périmètre.
ReplayTrie
Seuls les choix COMM non déterministes pertinents sont enregistrés, afin que les validateurs puissent reproduire la même exécution.
BlockGit + Block Merge
Les tâches concurrentes rejoignent des franges vérifiées, où les chevauchements sont classés comme acceptés, rejetés ou indécis avant la finalité.
Couche suivante
Un même environnement d’exécution logique dans de multiples environnements
Runtime Lab présente l’exécution parallèle et par messages actuellement disponible, puis illustre le modèle de composition atomique visé. GLVM décrit l’architecture plus large destinée à étendre ce modèle logique aux nœuds blockchain, aux services cloud et aux appareils personnels.
Pourquoi c’est important
Au-delà de blocs plus rapides : des services de longue durée.
Le parallélisme gère l’exécution indépendante. La concurrence gère les interactions par messages et l’attente/reprise. ALUX met en œuvre ces fondations d’exécution dès aujourd’hui et travaille à la composition atomique entre systèmes.
Un débit accru, mais aucune dépendance entre transactions ni aucun appariement de messages.
Les transactions peuvent interagir et attendre, mais les effets entre systèmes peuvent encore se finaliser séparément.
Une frontière atomique existe, mais sans interaction ni attente, elle ne peut pas porter des dépendances de longue durée.