Ich habe gestern Abend die @Dusk -Whitepaper durchgeblättert und bin bis ins 7. Kapitel vorgedrungen. Eigentlich wollte ich nur das Ende einer Übereinstimmungspassage finden, aber ich bin direkt in diese Kapitel auf der Ausführungsebene geraten. Rusk VM plus vier Genesis-Verträge.
Zuerst: Was ist die Rusk VM?
Eine virtuelle Maschine mit WebAssembly als Basis, aber das Whitepaper gibt ihr eine sehr zurückhaltende Identität: sie ist quasi-turingvollständig. Sie versieht jede Funktion mit einem Preis. Für eine interne Abrechnungseinheit namens „gas“. Und jede Rechenmenge für Zustandsübergänge wird auf ein zugewiesenes Gas-Limit gedeckelt. Warum macht man das so?
Man kann nicht garantieren, dass eine vollständig turingvollständige Maschine immer anhält.
Darum umgeht sie dieses Problem über rechnerische Obergrenzen.
Diese virtuelle Maschine läuft nicht „nackt“ mit nur kryptografischen Host-Funktionen als Beiwerk: Hashing, elliptische Kurven-Skalarmultiplikation, Signaturüberprüfung, Zero-Knowledge-Proof-Verifikation—alles als native Calls. Außerdem bietet sie Zugriff auf Protokollzustände wie Vertrags-Speicherlese-/schreibvorgänge, die aktuelle Blockhöhe und den Zeitstempel.
Am meisten hat mich der Abschnitt zu den Zustandsübergabefunktionen getroffen: Er listet gleich neun globale Statusfelder auf und speist sie in die VM—Zustandsbaum, Zeitstempel, Blockhöhe, Seed, Gas-Limit und so weiter.
Mich hat dann aber vor allem das Thema der vier Genesis-Verträge zum Stoppen gebracht. Das sind keine gewöhnlichen Verträge. Sie sind in den Genesis-Block geschrieben—jeder Protokollknoten bringt sie von Natur aus mit. Man kommt nicht daran vorbei.
Der DUSK-Vertrag ist das Gerüst: Er kümmert sich um das native Asset-Buchhaltungswerk. Ich habe gezählt: Er hat insgesamt neun Funktionen. Allein die Assets müssen zwischen zwei Formen wechseln—„transparent“ und „verwischt“ (confused)—und je nach Richtung geht es rein und raus. Daraus ergibt sich eine ganze Reihe von Funktionen.
Vom Nutzer, der den Vertrag aufruft, bis dahin, dass der Vertrag den Nutzer oder einen anderen Vertrag wieder „entlässt“: transparent rein, verwischt raus; verwischt rein, transparent raus. Jede Richtung hat ihre eigene Funktion. Es gibt keinen einzigen mehrdeutigen Universal-Endpoint.
Der Bid-Vertrag kümmert sich um die Auktionen durch Blockproduzenten: Es gibt drei Aktionen—einreichen, verlängern und bei Ablauf zurückziehen.
Der Stake-Vertrag verwaltet die Verifizierung durch Validatoren—ebenfalls ein Set aus drei Bausteinen. Aber er hat noch einen vierten: FSlash. Jede Person kann einen Validator melden, der einen Fehler gemacht hat. Der Meldende kann dann eine Prämie aus dem bestraften Einsatz (Staking) erhalten.
Das entspricht übrigens dem, was ich zuvor besprochen hatte.
Der Reward-Vertrag ist für die Ausschüttung zuständig: Er verteilt Gewinne an die Validatoren für die finalisierten Blöcke und an die Blockproduzenten fürs Erzeugen von Blöcken. Die Blockproduzenten nehmen ihren Anteil selbst in Empfang.
Die vier Verträge kontrollieren damit die Ein- und Ausgänge der Assets. Wer DUSK bewegen will, muss durch genau diese Funktionen. Voraussetzung bleibt dabei unverändert: Oben muss wirklich Security-Token im Umlauf sein. So präzise die Ausführungsebene auch ist—wenn es keine Business-Logik gibt, die sie füttert, ist es im Grunde nur eine Maschine, die leer läuft. #dusk $DUSK
Zuerst: Was ist die Rusk VM?
Eine virtuelle Maschine mit WebAssembly als Basis, aber das Whitepaper gibt ihr eine sehr zurückhaltende Identität: sie ist quasi-turingvollständig. Sie versieht jede Funktion mit einem Preis. Für eine interne Abrechnungseinheit namens „gas“. Und jede Rechenmenge für Zustandsübergänge wird auf ein zugewiesenes Gas-Limit gedeckelt. Warum macht man das so?
Man kann nicht garantieren, dass eine vollständig turingvollständige Maschine immer anhält.
Darum umgeht sie dieses Problem über rechnerische Obergrenzen.
Diese virtuelle Maschine läuft nicht „nackt“ mit nur kryptografischen Host-Funktionen als Beiwerk: Hashing, elliptische Kurven-Skalarmultiplikation, Signaturüberprüfung, Zero-Knowledge-Proof-Verifikation—alles als native Calls. Außerdem bietet sie Zugriff auf Protokollzustände wie Vertrags-Speicherlese-/schreibvorgänge, die aktuelle Blockhöhe und den Zeitstempel.
Am meisten hat mich der Abschnitt zu den Zustandsübergabefunktionen getroffen: Er listet gleich neun globale Statusfelder auf und speist sie in die VM—Zustandsbaum, Zeitstempel, Blockhöhe, Seed, Gas-Limit und so weiter.
Mich hat dann aber vor allem das Thema der vier Genesis-Verträge zum Stoppen gebracht. Das sind keine gewöhnlichen Verträge. Sie sind in den Genesis-Block geschrieben—jeder Protokollknoten bringt sie von Natur aus mit. Man kommt nicht daran vorbei.
Der DUSK-Vertrag ist das Gerüst: Er kümmert sich um das native Asset-Buchhaltungswerk. Ich habe gezählt: Er hat insgesamt neun Funktionen. Allein die Assets müssen zwischen zwei Formen wechseln—„transparent“ und „verwischt“ (confused)—und je nach Richtung geht es rein und raus. Daraus ergibt sich eine ganze Reihe von Funktionen.
Vom Nutzer, der den Vertrag aufruft, bis dahin, dass der Vertrag den Nutzer oder einen anderen Vertrag wieder „entlässt“: transparent rein, verwischt raus; verwischt rein, transparent raus. Jede Richtung hat ihre eigene Funktion. Es gibt keinen einzigen mehrdeutigen Universal-Endpoint.
Der Bid-Vertrag kümmert sich um die Auktionen durch Blockproduzenten: Es gibt drei Aktionen—einreichen, verlängern und bei Ablauf zurückziehen.
Der Stake-Vertrag verwaltet die Verifizierung durch Validatoren—ebenfalls ein Set aus drei Bausteinen. Aber er hat noch einen vierten: FSlash. Jede Person kann einen Validator melden, der einen Fehler gemacht hat. Der Meldende kann dann eine Prämie aus dem bestraften Einsatz (Staking) erhalten.
Das entspricht übrigens dem, was ich zuvor besprochen hatte.
Der Reward-Vertrag ist für die Ausschüttung zuständig: Er verteilt Gewinne an die Validatoren für die finalisierten Blöcke und an die Blockproduzenten fürs Erzeugen von Blöcken. Die Blockproduzenten nehmen ihren Anteil selbst in Empfang.
Die vier Verträge kontrollieren damit die Ein- und Ausgänge der Assets. Wer DUSK bewegen will, muss durch genau diese Funktionen. Voraussetzung bleibt dabei unverändert: Oben muss wirklich Security-Token im Umlauf sein. So präzise die Ausführungsebene auch ist—wenn es keine Business-Logik gibt, die sie füttert, ist es im Grunde nur eine Maschine, die leer läuft. #dusk $DUSK