Que permet ALUX que les contrats intelligents ordinaires ne peuvent pas faire ?
ALUX étend le modèle des contrats intelligents en un moteur décentralisé d’exécution durable pour les tâches de longue durée. Un workflow peut exécuter des processus concurrents, se suspendre d’un bloc à l’autre, attendre des outils externes ou des personnes, reprendre et joindre les résultats sans exposer un état à moitié achevé. Des canaux externes gérés par l’environnement d’exécution peuvent interagir avec les services hors chaîne pris en charge sans orchestration distincte d’oracles et de relais. L’architecture est conçue pour étendre horizontalement ce même modèle atomique, afin que les effets entre shards soient validés ou abandonnés ensemble ; l’exécution entre shards reste inscrite à la feuille de route.
Pourquoi ALUX est-il conçu pour les agents IA ?
Un agent sur la blockchain est naturellement une transaction longue. Appeler un LLM ou un outil prend du temps ; attendre une réponse humaine aussi. Le workflow ne peut pas être contraint à un appel instantané dans un seul bloc. ALUX lui permet de conserver son contexte d’exécution, de se suspendre, de reprendre à l’arrivée des entrées, de coordonner des agents concurrents et de se finaliser au moyen d’une exécution rejouable.
ALUX est-il simplement une L1 plus rapide de plus ?
Non. Les L1 plus rapides accélèrent la même abstraction : des mises à jour d’état ponctuelles réalisées dans un seul bloc. ALUX est un environnement d’exécution concurrent décentralisé pour des transactions longues qui peuvent attendre, reprendre, effectuer une jonction sur plusieurs canaux ou sélectionner le premier canal prêt ; leurs mises à jour d’état ne sont plus limitées par les frontières d’un bloc. Son architecture GLVM — abstraction de machine virtuelle — est conçue pour étendre une même transaction logique au-delà des blocs, vers les frontières entre shards et entre systèmes.
D’autres blockchains affirment aussi prendre en charge les transactions sur plusieurs blocs. En quoi ALUX est-il différent ?
Le mot clé est l’atomicité.
Compensation / Saga : commit → commit → ✗ fail → run compensating undo
Chaque étape est validée localement, les états intermédiaires sont visibles, la compensation peut elle aussi échouer et les effets externes ne peuvent pas toujours être annulés. C’est de la cohérence à terme. Certaines blockchains asynchrones, dont ICP et Rialo, s’appuient sur ce modèle. Il est plus simple à mettre en œuvre, mais ne convient pas aux applications qui exigent des garanties ACID plus fortes.
Le tout ou rien d’ALUX : stage → stage → ✗ fail → discard everything
Rien n’est validé tant que la transaction entière ne l’est pas. En cas d’abandon, les effets non validés sont écartés et aucun état partiel ne devient observable. Il s’agit d’une véritable atomicité ACID entre hauteurs de blocs.
Comment ALUX garantit-il le déterminisme des transactions longues ?
ReplayTrie enregistre les choix COMM non déterministes qui influencent l’exécution, ce qui permet un rejeu déterministe exact bit à bit dans l’environnement d’exécution d’ALUX, afin que les validateurs puissent reproduire le même résultat d’exécution.
Qu’est-ce que le modèle de capacités objet (OCAP) ?
Le modèle de capacités objet (OCAP) est un modèle de sécurité dans lequel un code ne peut accéder à une ressource que si une référence à cette ressource — une capacité — lui est explicitement fournie. Dans un système OCAP, la même référence d’objet identifie une ressource (désignation) et accorde le droit de l’utiliser (autorisation).
Pourquoi OCAP est-il un modèle de sécurité plus fort et composable ?
Le modèle de capacités objet (OCAP) est un modèle de sécurité plus fort, car l’autorité est représentée par des capacités explicites et infalsifiables, plutôt que par des identités globales ou des listes de contrôle d’accès. Il suit le principe selon lequel la désignation vaut autorisation : posséder une capacité identifie une ressource et accorde le droit de l’utiliser, éliminant ainsi l’autorité ambiante et réduisant la surface d’attaque. Puisque les capacités peuvent être déléguées, restreintes et révoquées de façon sûre, les politiques de sécurité restent locales aux objets concernés au lieu d’être dispersées dans un système centralisé de permissions. OCAP est ainsi naturellement composable : des applications complexes, des contrats intelligents et des workflows d’agents IA peuvent être construits à partir de composants sécurisés indépendamment, tout en préservant le principe du moindre privilège.
Que signifie la prise en charge native d’OCAP dans ALUX ?
La machine virtuelle à espace de tuples (TVM) d’ALUX met en œuvre le modèle de capacités objet (OCAP) directement au niveau du bytecode. Le jeu d’instructions ne contient aucune opération permettant de falsifier ou de construire des références d’objet arbitraires, ce qui garantit que les capacités ne peuvent être acquises que par délégation explicite. Toute autorité est ainsi à la fois infalsifiable et transférée explicitement.
Les développeurs actuels de contrats intelligents peuvent-ils l’utiliser ?
TVM exécute le bytecode EVM dans des bacs à sable isolés ; la plupart des contrats EVM peuvent donc être migrés vers ALUX avec un minimum de modifications. ALUX propose également une interface compatible avec Ethereum grâce à un ensemble de méthodes JSON-RPC eth_* couramment utilisées.
