Was wird mit ALUX möglich, was gewöhnliche Smart Contracts nicht können?
ALUX erweitert das Smart-Contract-Modell zu einer dezentralen Engine für dauerhafte Ausführung lang laufender Aufgaben. Ein Ablauf kann nebenläufige Prozesse ausführen, blockübergreifend angehalten werden, auf externe Tools oder Menschen warten, fortgesetzt werden und Ergebnisse zusammenführen, ohne einen halbfertigen Zustand offenzulegen. Über die Runtime vermittelte externe Kanäle können mit unterstützten Off-Chain-Diensten interagieren, ohne separate Oracle- und Relayer-Abläufe. Die Architektur soll dasselbe atomare Modell horizontal erweitern, sodass Cross-Shard-Effekte gemeinsam übernommen oder abgebrochen werden; Cross-Shard-Ausführung steht weiterhin auf der Roadmap.
Warum wurde ALUX für KI-Agenten entwickelt?
Ein On-Chain-Agent ist von Natur aus eine Langtransaktion. Ein Aufruf eines LLM oder Tools dauert; auch das Warten auf eine menschliche Antwort braucht Zeit. Der Ablauf lässt sich nicht in einen sofortigen Aufruf innerhalb eines Blocks zwingen. ALUX bewahrt den Ausführungskontext, hält den Ablauf an, setzt ihn bei eingehenden Eingaben fort, koordiniert nebenläufige Agenten und finalisiert über wiederholbare Ausführung.
Ist ALUX nur eine weitere, schnellere L1?
Nein. Schnellere L1s beschleunigen dieselbe Abstraktion: einmalige Zustandsaktualisierungen innerhalb eines Blocks. ALUX ist eine dezentrale nebenläufige Runtime für Langtransaktionen, die warten, fortgesetzt werden, Ergebnisse über mehrere Kanäle zusammenführen oder den zuerst verfügbaren Kanal auswählen können; ihre Zustandsaktualisierungen sind nicht mehr an eine Blockgrenze gebunden. Mit seiner GLVM-Architektur – Abstraktion virtueller Maschinen – ist ALUX darauf ausgelegt, dieselbe logische Transaktion über Blockgrenzen hinaus auf Shard- und Systemgrenzen auszuweiten.
Einige andere Chains behaupten ebenfalls, Cross-Block-Transaktionen zu unterstützen. Was unterscheidet ALUX?
Entscheidend ist die Atomarität.
Kompensation / Saga: commit → commit → ✗ fail → run compensating undo
Jeder Schritt wird lokal übernommen, Zwischenzustände sind sichtbar, Kompensationen können ebenfalls scheitern und externe Effekte lassen sich nicht immer rückgängig machen. Das ist letztliche Konsistenz. Einige asynchrone Chains, darunter ICP und Rialo, setzen stark auf dieses Modell. Es ist einfacher umzusetzen, aber ungeeignet für Anwendungen, die stärkere ACID-Garantien benötigen.
ALUX: Alles oder nichts: stage → stage → ✗ fail → discard everything
Nichts wird übernommen, bevor die gesamte Transaktion erfolgreich abgeschlossen ist. Bei einem Abbruch werden nicht übernommene Effekte verworfen und kein Teilzustand wird sichtbar. Das ist echte ACID-Atomarität über Blockhöhen hinweg.
Wie hält ALUX Langtransaktionen deterministisch?
ReplayTrie zeichnet nichtdeterministische COMM-Entscheidungen auf, die sich auf die Ausführung auswirken. So ermöglicht es eine bitgenaue deterministische Wiederholung innerhalb der ALUX-Runtime, damit Validatoren dasselbe Ausführungsergebnis reproduzieren können.
Was sind Object Capabilities (OCAP)?
Object Capability (OCAP) ist ein Sicherheitsmodell, in dem ein Stück Code nur dann auf eine Ressource zugreifen kann, wenn ihm ausdrücklich eine Referenz (eine Capability) auf diese Ressource übergeben wurde. In einem OCAP-System identifiziert dieselbe Objektreferenz eine Ressource (Bezeichnung) und erteilt zugleich die Berechtigung, sie zu verwenden (Autorisierung).
Warum ist OCAP ein stärkeres und kombinierbares Sicherheitsmodell?
Object Capability (OCAP) ist ein stärkeres Sicherheitsmodell, weil Berechtigungen durch explizite, fälschungssichere Capabilities statt durch globale Identitäten oder Zugriffskontrolllisten dargestellt werden. Es folgt dem Prinzip, dass Bezeichnung zugleich Berechtigung ist: Wer eine Capability besitzt, bezeichnet damit eine Ressource und erhält die Erlaubnis, sie zu verwenden. So entfallen implizite Umgebungsberechtigungen und die Angriffsfläche wird kleiner. Da Capabilities sicher delegiert, eingeschränkt und widerrufen werden können, gelten Sicherheitsrichtlinien lokal für die beteiligten Objekte, statt über ein zentrales Berechtigungssystem verstreut zu sein. Dadurch lässt sich OCAP auf natürliche Weise kombinieren: Komplexe Anwendungen, Smart Contracts und KI-Agenten-Abläufe können aus unabhängig abgesicherten Komponenten aufgebaut werden, während das Prinzip der geringsten Berechtigung erhalten bleibt.
Was bedeutet native OCAP-Unterstützung in ALUX?
Die tupelraumbasierte virtuelle Maschine (TVM) von ALUX implementiert das Object-Capability-Modell (OCAP) direkt auf Bytecode-Ebene. Der Befehlssatz enthält keine Operationen zum Fälschen oder Erzeugen beliebiger Objektreferenzen. Dadurch können Capabilities nur durch explizite Delegation erworben werden. So wird sichergestellt, dass alle Berechtigungen fälschungssicher und ausdrücklich übertragen sind.
Können Entwickler bestehender Smart Contracts ALUX nutzen?
Die TVM führt EVM-Bytecode in isolierten Sandboxes aus, sodass sich die meisten EVM-Verträge mit minimalen Änderungen zu ALUX migrieren lassen. Außerdem bietet ALUX über eine Auswahl häufig verwendeter eth_* JSON-RPC-Methoden eine Ethereum-kompatible Sicht.
