¿Qué permite ALUX que no pueden hacer los contratos inteligentes habituales?
ALUX amplía el modelo de los contratos inteligentes con un motor descentralizado de ejecución duradera para tareas de larga duración. Un flujo de trabajo puede ejecutar procesos concurrentes, suspenderse entre bloques, esperar herramientas externas o personas, reanudarse y unir resultados sin exponer estados a medio completar. Los canales externos mediados por el runtime pueden interactuar con servicios off-chain compatibles sin coordinar por separado oráculos y relayers. La arquitectura está diseñada para extender horizontalmente el mismo modelo atómico, de modo que los efectos entre shards se confirmen o aborten juntos; la ejecución entre shards sigue en la hoja de ruta.
¿Por qué ALUX está diseñada para agentes de IA?
Un agente on-chain es, por naturaleza, una transacción de larga duración. Llamar a un LLM o a una herramienta lleva tiempo; esperar la respuesta de una persona también. No se puede obligar al flujo a ejecutarse como una llamada instantánea de un solo bloque. ALUX le permite conservar el contexto de ejecución, suspenderse, reanudarse cuando llegan datos, coordinar agentes concurrentes y finalizar mediante una ejecución reproducible.
¿ALUX es solo otra L1 más rápida?
No. Las L1 más rápidas aceleran la misma abstracción: actualizaciones de estado de una sola ejecución dentro de un bloque. ALUX es un runtime concurrente descentralizado para transacciones de larga duración que pueden esperar, reanudarse, unirse a través de varios canales o seleccionar el canal que esté listo primero; sus actualizaciones de estado ya no están limitadas por los límites de bloque. Mediante su arquitectura GLVM —abstracción de máquinas virtuales—, la misma transacción lógica está diseñada para extenderse más allá de los límites de bloque, hacia los límites entre shards y sistemas.
Algunas otras cadenas también afirman admitir transacciones entre bloques. ¿En qué se diferencia ALUX?
La clave es la atomicidad.
Compensación / Saga: commit → commit → ✗ fail → run compensating undo
Cada paso se confirma localmente, los estados intermedios son visibles, la compensación también puede fallar y los efectos externos no siempre se pueden revertir. Esto es consistencia eventual. Algunas cadenas asíncronas, incluidas ICP y Rialo, se basan en este modelo. Es más fácil de implementar, pero no sirve para aplicaciones que requieren garantías ACID más sólidas.
ALUX todo o nada: stage → stage → ✗ fail → discard everything
Nada se confirma hasta que se confirma la transacción completa. Si se aborta, se descartan los efectos no confirmados y ningún estado parcial llega a ser observable. Eso es verdadera atomicidad ACID entre alturas de bloque.
¿Cómo mantiene ALUX el determinismo de las transacciones de larga duración?
ReplayTrie registra las decisiones COMM no deterministas que afectan a la ejecución, lo que permite una reproducción determinista bit a bit dentro del runtime de ALUX para que los validadores puedan reproducir el mismo resultado.
¿Qué es Object Capability (OCAP)?
Object Capability (OCAP) es un modelo de seguridad en el que la única forma de que un fragmento de código acceda a un recurso es recibir explícitamente una referencia (una capacidad) a ese recurso. En un sistema OCAP, la misma referencia al objeto identifica un recurso (designación) y concede permiso para usarlo (autorización).
¿Por qué OCAP es un modelo de seguridad más sólido y componible?
Object Capability (OCAP) es un modelo de seguridad más sólido porque la autoridad se representa mediante capacidades explícitas e imposibles de falsificar, en lugar de identidades globales o listas de control de acceso. Sigue el principio de que designar equivale a autorizar: poseer una capacidad identifica un recurso y concede permiso para usarlo, lo que elimina la autoridad ambiental y reduce la superficie de ataque. Como las capacidades se pueden delegar, restringir y revocar de forma segura, las políticas de seguridad quedan localizadas en los objetos implicados en vez de dispersarse por un sistema centralizado de permisos. Esto hace que OCAP sea componible por naturaleza y permite construir aplicaciones complejas, contratos inteligentes y flujos de trabajo de agentes de IA a partir de componentes seguros e independientes, respetando el principio de mínimo privilegio.
¿Qué significa que OCAP tenga soporte nativo en ALUX?
La máquina virtual de espacio de tuplas (TVM) de ALUX implementa el modelo Object Capability (OCAP) directamente en el nivel de bytecode. El conjunto de instrucciones no incluye operaciones para falsificar o construir referencias arbitrarias a objetos, lo que garantiza que las capacidades solo se obtengan mediante delegación explícita. Así, toda autoridad es imposible de falsificar y se transfiere explícitamente.
¿Pueden usarlo los desarrolladores de contratos inteligentes existentes?
TVM ejecuta bytecode EVM dentro de sandboxes aislados, por lo que la mayoría de los contratos EVM pueden migrarse a ALUX con cambios mínimos. ALUX también ofrece una vista compatible con Ethereum mediante un conjunto de métodos JSON-RPC eth_* de uso común.
