Kontakt

Lernen / GLVM

GLVM

Globale logische virtuelle Maschine

Eine logische Ausführungsschicht, koordiniert über viele Maschinen hinweg.

GLVM ist die entwicklerorientierte Ausführungsabstraktion, die ALUX auf Basis seiner nebenläufigen Runtime entwickelt. Eine TVM stellt auf jeder beteiligten Maschine die konkrete Engine bereit; das GLVM-Modell führt Ausführungszustand, Prozesse, Wiederholung, Replikation und Konsens in einer logischen Schicht zusammen.

Physisches ModellEine TVM pro Maschine
Logisches ModellEine GLVM über ihnen
RichtungVon der Chain über die Cloud bis zum Gerät

Die Kerndefinition

Eine TVM pro Maschine, koordiniert über ein gemeinsames logisches Ausführungsmodell

TVM ist die Bytecode-Ausführungsengine auf einer Maschine. GLVM definiert die systemweite Ausführungsabstraktion über die beteiligten TVMs hinweg. GLVM ist keine weitere Bytecode-VM: Entwickler arbeiten mit einem logischen Modell, während deterministische Wiederholung, Ausführungskontinuität, Replikation, Finalisierung und Konsens unterhalb dieser Abstraktion koordiniert werden.

TVM

Tupelraumbasierte virtuelle Maschine

Die konkrete ALUX-Ausführungsengine. Sie führt Tolang-Bytecode aus, koordiniert unabhängige Prozesse über Kanäle und COMM-Ereignisse und zeichnet die nichtdeterministischen Entscheidungen auf, die für eine deterministische Wiederholung erforderlich sind.

Eine konkrete Engine innerhalb einer Maschine
GLVM

Globale logische virtuelle Maschine

GLVM definiert das entwicklerorientierte logische Modell über die beteiligten TVMs hinweg. Es bietet eine gemeinsame Grenze für Ausführungszustand und Prozesse; Wiederholung, Replikation, Finalisierung und Konsens bleiben unterhalb dieser Abstraktion.

Ein logisches System über vielen Maschinen
VM-AbstraktionWird erweitert
Vertikale AtomaritätCore-Runtime
Horizontale AtomaritätRoadmap
Komponierbare SicherheitCore-Runtime

Architektur mit drei Schichten

Drei Schichten, ein entwicklerorientiertes Ausführungsmodell

Physische Maschinen führen TVMs aus. In der GLVM-Architektur wirken diese Engines an einem gemeinsamen logischen Ausführungsmodell mit. Ein künftiges World OS wird diese Ebene als auffindbare, orchestrierte Dienste organisieren, deren Regeln durch explizite Capabilities festgelegt sind.

Wählen Sie eine beliebige Schicht aus, um das Detailfeld zu aktualisieren.

Ausführung und Atomarität

Eine Transaktion kann über Blöcke hinweg warten und anschließend als Ganzes abgeschlossen werden

Die Ausführung entwickelt sich von sequenzieller und paralleler Arbeit hin zu nebenläufigen Prozessen, die kommunizieren, warten und fortgesetzt werden. Zusammengesetzte Ausführung erweitert das Modell, sodass mehrere nebenläufige Transaktionen eine übergeordnete Abwicklungsgrenze teilen können; blockübergreifende Kontinuität bildet die vertikale Grundlage dafür.

Core-Runtime

Nebenläufig

Prozesse kommunizieren über Kanäle, warten und werden fortgesetzt.

Vertikale Atomarität · Core-RuntimeBlockübergreifende Ausführung erhält einen gemeinsamen Transaktionskontext.
  1. 01 · Start Einmal beginnen

    Eine Transaktion mit einem begrenzten Satz an Capabilities starten.

  2. 02 · Anhalten Warten ohne Teilabwicklung

    Fehlt eine Antwort oder ein passendes Kanalereignis, bleibt die Fortsetzung erhalten, statt die Transaktion vorzeitig abzuschließen.

  3. 03 · Aufzeichnen Die Auswahl festhalten

    ReplayTrie zeichnet die nichtdeterministische Auswahl oder authentifizierte Antwort auf, die zur Reproduktion des Ausführungspfads benötigt wird.

  4. 04 · Fortsetzen Dieselbe Transaktion fortführen

    Ein passendes COMM-Ereignis oder eine aufgezeichnete Antwort setzt die erhaltene Fortsetzung in einem späteren Block fort.

  5. 05 · Finalisieren Übernehmen oder verwerfen

    An der Finalisierungsgrenze wird der zulässige Zustand übernommen; abgelehnter vorläufiger Zustand wird verworfen.

Zentraler Ausführungspfad

Nebenläufige TVM-Ausführung · COMM-Warten und Fortsetzen · ReplayTrie · blockübergreifende Fortsetzung und Finalisierung

Atomaritätsmodell

Ein vorläufiger Zwischenzustand wird erst bei der Finalisierung zum bestätigten Zustand. Ein fehlgeschlagener Pfad wird verworfen, statt später durch kompensierende Transaktionen repariert zu werden.

Native Off-Chain-Leseoperation

Ein authentifizierter HTTPS-GET kann die Ausführung anhalten, die Antwort aufzeichnen, die Wiederholung ermöglichen und sie fortsetzen. Die Datenquelle bestimmt weiterhin die Wahrheit; irreversible Off-Chain-Nebenwirkungen liegen außerhalb des Rollbacks.

Horizontale Atomarität

Atomare Cross-Shard-Ausführung und die Komposition mit unabhängigen externen Systemen bilden die nächste Erweiterung des Modells.

Sicherheit durch Objekt-Capabilities

Geben Sie der Aufgabe einen einzelnen Schlüssel statt des Nutzer-Badges

Im Beispiel mit dem CEO und Bob kann identitätsbasierter Zugriff die durch das CEO-Badge dargestellten umfassenden Rechte in die Aufgabe einbringen. Bei Objekt-Capabilities erhält die Aufgabe nur einen Schlüssel, der Bobs Datensatz bezeichnet. Die TVM setzt die erreichbare Grenze zur Laufzeit durch. Ohne eine Capability-Referenz zu einem anderen bereits vorhandenen Objekt kann die Aufgabe dieses weder benennen noch erreichen.

Umfassende identitätsbasierte Berechtigung

Das Badge bringt sachfremde Zugriffsrechte in die Aufgabe ein

Auch wenn die Aufgabe nur Bob betrifft, kann die durch das Badge des CEO dargestellte Identitätsberechtigung weiterhin Finanzdaten und die Datensätze von Alice, Carol und Bob umfassen.

Explizite Objekt-Capability

Die Aufgabe erhält einen Schlüssel, der Bobs Datensatz bezeichnet

Dieser Schlüssel steht für einen fälschungssicheren Namen, der Bobs Datensatz bezeichnet. Ohne eine Capability-Referenz zu einem anderen bereits vorhandenen Objekt kann die Aufgabe dieses weder benennen noch erreichen. Die TVM prüft diese Grenze zur Laufzeit.

Begriffsklärung

Hier steht „Schlüssel“ visuell für einen fälschungssicheren Namen nach OCAP – eine Capability-Referenz. Es handelt sich nicht um einen kryptografischen Schlüssel. Diese Garantie gilt für TVM-native, durch Capabilities vermittelte Interaktionen; Berechtigungen in gehosteten EVM-Umgebungen und bei externen Diensten benötigen eigene Kontrollen.

Ablauf-Explorer

Wählen Sie die Ausführungsumgebung nach Vertrauen, Reaktionszeit und Datenlokalität

Ein unternehmensübergreifender Gerätereparaturprozess veranschaulicht das Modell: Das Escrow benötigt unabhängige Prüfung, Diagnosen brauchen elastische Rechenleistung und der Geräteeigentümer soll den lokalen Zugriff genehmigen. Im GLVM-Modell wird jede Aufgabe der Ausführungsumgebung zugeordnet, die zu ihren Anforderungen an Vertrauen, Latenz und Datengrenzen passt; Berechtigungen bleiben explizit.

Anforderung auswählen
Core-Runtime

TVM einer Public Chain + EVM-Host

Das Gewährleistungs-Escrow halten und den Freigabepfad so aufzeichnen, dass unabhängige Validatoren den Übergang prüfen können.

Dem angestrebten Ablauf folgen0 / 6

Bereit. Starten Sie die Simulation, um den angestrebten logischen Ablauf zu sehen.

01

Begrenzte Capability

Der Reparatur-Agent erhält nur die für diesen Auftrag erforderlichen Rechte.

02

Verteilung planen

Der Ablauf ordnet begrenzte Teilaufgaben TVMs auf der Chain, in privaten Umgebungen oder in der Cloud sowie auf Client-Geräten zu.

03

Warten / anhalten

Fehlt in der Chain-Runtime eine Antwort, bleibt die Fortsetzung erhalten, statt die Transaktion vorzeitig abzuschließen.

04

COMM-Abgleich

Ein erzeugtes Ergebnis trifft über einen Kanal auf die wartende Fortsetzung; der Ablauf wird fortgesetzt.

05

Wiederholungsnachweis

ReplayTrie zeichnet die nötigen Entscheidungen auf, damit ein anderer Validator den Ablauf reproduzieren kann.

06

Finalisierungsgrenze

BlockGit und Block Merge führen überprüfbare Ergebnisse auf der Chain zusammen. Ein einzelner atomarer Commit über alle Ausführungsumgebungen hinweg ist das Zielbild der GLVM.

Aufbau der Runtime

Neun Capability-Bereiche hinter der GLVM-Abstraktion

GLVM ist keine zweite Bytecode-VM. Diese neun Architekturansichten – von TVM-Ausführung, Objekt-Capabilities und Wiederholung bis zu BlockGit, Guest-VMs und Entwickler-Tooling – zeigen das Capability-System hinter dem logischen Ausführungsmodell.

  1. 01
    Bytecode-VMCore-Runtime

    TVM · Tuple Space · COMM

    Die konkrete nebenläufige Engine führt Bytecode aus und ermöglicht unabhängigen Prozessen, über Kanäle Daten und Fortsetzungen auszutauschen.

  2. 02
    SicherheitCore-Runtime

    Native Objekt-Capabilities

    Fälschungssichere Referenzen machen erreichbare Berechtigungen explizit und ermöglichen der Runtime, Grenzen nach dem Prinzip der geringsten Berechtigung durchzusetzen.

  3. 03
    AtomaritätCore-Runtime

    Atomare Ausführung über Blockgrenzen hinweg

    Ausführungskontexte können blockübergreifend angehalten, anhand gespeicherter Fortsetzungen wieder aufgenommen und bis zu einer aufgeschobenen Finalisierungsgrenze ausgeführt werden.

  4. 04
    FinalitätCore-Runtime

    BlockGit · Fringe · Merge

    Ein Block-DAG, deterministische Rotation der Leader und Merge-Regeln führen nebenläufige Arbeit auf der Chain zusammen – ohne permanenten Leader.

  5. 05
    WiederholungCore-Runtime

    ReplayTrie · Trace

    Aufgezeichnete nichtdeterministische Entscheidungen und Ausführungsspuren ermöglichen Validatoren, den akzeptierten Pfad zu reproduzieren.

  6. 06
    NetzwerkCore-Runtime

    Peer- und Validator-Netzwerk

    Die Node-Schicht transportiert Vorschläge, Blöcke, Zustandsnachweise und Validator-Koordination unterhalb der Ausführungsabstraktion.

  7. 07
    SpracheCore-Runtime

    Tolang → tolangc → .tox

    Tolang beschreibt nebenläufige Prozesse; der Compiler übersetzt den Quelltext in TVM-ausführbaren Bytecode.

  8. 08
    Guest-VMsEVM Core · WASM-Roadmap

    EVM-Host · WASM-Roadmap

    Die EVM läuft mit Koordination nach Art von TSAC als zustandsbehaftete Gast-VM. WASM erweitert die Ausrichtung auf heterogene VMs.

  9. 09
    ToolingEntwicklerumgebung

    Compiler · LSP · Playground

    Compiler, LSP, Playground, Testsuite und Diagnosen integrieren das Ausführungsmodell in Entwicklerabläufe.

Ausbauplan

Die Core-Runtime nimmt Gestalt an, während GLVM auf weitere Umgebungen ausgeweitet wird

GLVM entwickelt sich aus der nebenläufigen Chain-Runtime von ALUX heraus. Eine private Cloud ist die nächste Integrationsfläche; Ausführung auf Client-Geräten und Cross-Shard-Ausführung stehen weiterhin auf der Roadmap. Die folgende Übersicht unterscheidet zwischen der Core-Runtime, den derzeit ausgebauten Umgebungen und dem nächsten Architekturhorizont.

Core-Runtime

  • Nebenläufige TVM und COMM
  • ReplayTrie und Ausführungsspuren
  • Blockübergreifende Anhalte- und Fortsetzungspfade
  • Native OCAP-Grundlagen
  • EVM-Host-Pfad
  • BlockGit-DAG, Fringe und Merge

System wird erweitert

  • Bereitstellung einer Engine in privaten Umgebungen oder in der Cloud
  • GLVM-Abstraktion über verschiedene Bereitstellungsumgebungen hinweg
  • Härtung für den Produktionseinsatz
  • Umfangreichere Richtlinien- und abgesicherte Kanalsteuerung
  • Runtime-Observability und Operator-Tooling

Roadmap

  • Horizontale Cross-Shard-Atomarität
  • WASM-Gast-VM
  • Bereitstellung von TVM auf Client-Geräten
  • Account-Abstraktion und Capability-Registry
  • Peer-Neusynchronisierung nach Ausfällen und dynamische Änderungen am Validator-Set
  • Programmierbare World-OS-Schicht

Weiterlernen

Runtime, Agenten-Workloads und Systemvergleiche entdecken

Runtime Lab erläutert das Ausführungsmodell. „Für KI-Agenten“ zeigt das Workload-Muster. „ALUX im Vergleich“ stellt Architektur und Capabilities verschiedener Systeme gegenüber.