Lernen / Runtime Lab
Runtime Lab
Parallel / Nebenläufig / Kombinierbar
ALUX unterstützt wiederholbare Langtransaktionen: Unabhängige Aufgaben laufen gleichzeitig, und Transaktionen koordinieren sich über Nachrichten. Das Buchungsszenario veranschaulicht das Zielmodell, bei dem zusammengehörige systemübergreifende Effekte als ein atomares Ergebnis abgeschlossen werden.
Eine hochwertige technische Illustration der ALUX-Runtime, die Nodes, Cloud-Dienste, Geräte, Agenten, Capability-Tokens und Commit-Schienen verbindet.
Der einfache Unterschied
Drei Begriffe, drei ganz unterschiedliche Aufgaben der Runtime
Parallelität führt unabhängige Transaktionen gleichzeitig aus. Nebenläufigkeit ermöglicht Interaktion über Kanäle: Eine Transaktion kann auf eine passende Nachricht einer anderen warten und anschließend fortfahren. Komponierbarkeit verbindet Zustandsübergänge verschiedener Systeme zu einem überprüfbaren atomaren Übergang.
In der aktuellen ALUX-Runtime kann unabhängige Arbeit parallel laufen, Transaktionen koordinieren sich über Nachrichten und Ausführungen können blockübergreifend fortgesetzt werden. Atomare Komposition über unabhängige Systeme hinweg bleibt ein Architekturziel.
Mehrere isolierte Ausführungsspuren schreiten gleichzeitig voran.
Mehr unabhängige Arbeit wird in derselben Zeit erledigt. Parallelität allein ermöglicht diesen Aufgaben jedoch weder den Nachrichtenaustausch noch das Warten und Fortsetzen einer Langtransaktion.
Parallelität findet mehrere Antworten zugleich. Sie lässt diese Aufgaben nicht miteinander interagieren.
Parallel
Flug, Hotel, Transfer und Versicherung
gleichzeitig suchen
- Was es bedeutet
- Parallele Ausführung bedeutet, dass unabhängige Aufgaben gleichzeitig laufen. Ein Reise-Agent kann Flüge, Zimmer, Transfers und Versicherungen suchen, ohne eine Suche hinter einer anderen warten zu lassen.
- Wie ALUX es umsetzt
- Parallele Ausführung ist Teil des nativen Prozesskalküls von ALUX: Transaktionen teilen keinen Speicher, und jede Interaktion ist auf Tuple-Space-Kanäle beschränkt. Daher schreiten unabhängige Transaktionen auf getrennten TVM-Spuren voran; Block Merge löst Zustandsüberschneidungen beim Commit auf.
- Was es ermöglicht
- Mehr unabhängige Arbeit wird in derselben Zeit erledigt. Parallelität allein ermöglicht diesen Aufgaben jedoch weder den Nachrichtenaustausch noch das Warten und Fortsetzen einer Langtransaktion.
Parallelität findet mehrere Antworten zugleich. Sie lässt diese Aufgaben nicht miteinander interagieren.
Die gesamte Runtime ausprobieren
Eine Buchung atomar modellieren
Mit vier Aktionen können Sie das Zielmodell für Komposition erkunden: Starten Sie die Reservierungs- und Zahlungsprüfung, warten Sie auf die Zimmerverfügbarkeit, stellen Sie die passende Nachricht des Hotels zu und modellieren Sie anschließend eine gemeinsame Bestätigung.
Reservierungs- und Zahlungsprüfungen laufen unabhängig voneinander.
Die Reservierung hinterlegt im Kanal eine Verfügbarkeitsbedingung.
Die passende Nachricht aktiviert die Buchungsfortsetzung.
Zimmerreservierung und Zahlungsautorisierung werden als ein Ergebnis übernommen.
Schrittweise abspielen
Beginnen Sie mit Schritt 1. Reservierung und Zahlung werden innerhalb derselben Runtime getrennt verwaltet.
Unabhängige Arbeit muss nicht hinter einer globalen Warteschlange warten.
Die Abhängigkeit liegt in einem Kanal, statt die Runtime zu blockieren.
COMM erzeugt die Fortsetzung; ReplayTrie zeichnet die Auswahl nur dann auf, wenn der Abgleich nichtdeterministisch ist.
Ziel ist ein Alles-oder-nichts-Ergebnis mit reproduzierbaren Nachweisen für die Abwicklung.
Runtime-Pfad
Was einen Dienst am Laufen hält
Ein lang laufender Dienst bleibt konsistent, weil jeder Schritt ausgeführt werden, interagieren, explizite Berechtigungen übertragen, deterministisch wiederholt und über einen überprüfbaren atomaren Pfad abgeschlossen werden kann.
Lebenszyklus eines TVM-Prozesses
Ein Prozess kann sich verzweigen, in einem Block warten und in einem späteren Block fortgesetzt werden, ohne seinen lokalen Ausführungskontext neu aufzubauen.
Tuple Space + COMM
Ein wartender Consume trifft auf das Produce einer anderen Transaktion. Der Abgleich aktiviert die Fortsetzung, während unabhängige Arbeit weiterläuft.
OCAP-Grenzen
Fälschungssichere Capability-Referenzen werden explizit übergeben, sodass jeder Schritt nur die nötigen Berechtigungen erhält; eine Identität bringt nicht automatisch sachfremde Rechte in den Geltungsbereich.
ReplayTrie
Nur die relevanten nichtdeterministischen COMM-Entscheidungen werden aufgezeichnet, sodass Validatoren dieselbe Ausführung reproduzieren können.
BlockGit + Block Merge
Nebenläufige Arbeit gelangt in überprüfte Fringes. Dort werden Überschneidungen vor der Finalisierung als akzeptiert, abgelehnt oder unentschieden eingestuft.
Nächste Ebene
Eine logische Runtime über viele Umgebungen hinweg
Runtime Lab zeigt die aktuelle parallele und nachrichtenbasierte Ausführung und veranschaulicht anschließend das Zielmodell atomarer Komposition. GLVM beschreibt die umfassendere Architektur, mit der sich dieses logische Modell über Blockchain-Nodes, Cloud-Dienste und persönliche Geräte hinweg erweitern lässt.
Warum es wichtig ist
Keine schnelleren Blöcke. Lang laufende Dienste.
Parallelität übernimmt unabhängige Ausführung. Nebenläufigkeit ermöglicht nachrichtenbasierte Interaktion sowie Warten und Fortsetzen. ALUX implementiert diese Runtime-Grundlagen bereits heute und arbeitet auf atomare Komposition über Systemgrenzen hinweg hin.
Mehr Durchsatz, aber keine Transaktionsabhängigkeiten oder Nachrichtenabgleiche.
Transaktionen können miteinander interagieren und warten, aber systemübergreifende Effekte werden möglicherweise weiterhin getrennt abgeschlossen.
Es gibt eine atomare Grenze, doch ohne Interaktion und Warten lassen sich darin keine lang laufenden Abhängigkeiten abbilden.