Ich habe etwas Bemerkenswertes bemerkt, wenn man über die Rolle von Zilch auf @Dusk nachdenkt: Es wirkt wie eine Art „Übersetzung“ zwischen zwei unterschiedlichen Sprachen — der Sprache von Werten, die im UTXO-ähnlichen Modell als anonyme, geschützte Einträge geschützt sind, und der Sprache von Vertragszuständen im account-basierten Modell, die die meisten Smart-Contract-Logiken zum Betrieb benötigen.
Phoenix funktioniert ähnlich wie ein privates UTXO-Modell — der Wert existiert als eigenständige Notizen, wobei jede Notiz ihre Gültigkeit selbst beweist, ohne dass man den globalen Zustand kennen muss. Doch die meiste Vertragslogik, auch auf der Rusk VM, braucht typischerweise ein stärker zustandsorientiertes Modell — in dem eine Variable gelesen, geändert und in einer nachvollziehbaren Reihenfolge wieder aufgezeichnet wird. Das ist die architektonische Lücke zwischen zwei verschiedenen Datenmodellen, und das ist nicht nur ein Thema der Privatsphäre.
Wenn das stimmt, besteht die Rolle von Zilch nicht nur darin, „Informationen vor Außenstehenden zu verstecken“, sondern auch als Brücke, um einen Wert in Form einer losen Notiz in eine Eingabe zu übersetzen, die das Zustandsmodell des Vertrags verarbeiten kann — eine Datenkompatibilitätsaufgabe, nicht nur eine Sicherheitsfrage. PLONK beweist anschließend, dass dieser Übersetzungsprozess den Regeln entspricht, ohne dabei den Inhalt der ursprünglichen Notiz offenzulegen.
Selbstkritik: Das ist eine Schlussfolgerung, die auf allgemeinem Verständnis der Unterschiede zwischen UTXO- und account-basierten Modellen beruht; sie spiegelt möglicherweise nicht genau die technischen Implementierungsdetails von Dusk wider — es braucht detailliertere Fachdokumentation, um das zu bestätigen.
Ich warte darauf zu sehen, ob $DUSK weitere detaillierte technische Unterlagen veröffentlicht hat, wie Zilch zwischen diesen beiden Datenmodellen umwandelt, um zu bestätigen, ob das wirklich genau die UTXO-to-account-Kompatibilitätsaufgabe ist, wie ich sie mir vorstelle.
#dusk $BTC $ETH
Phoenix funktioniert ähnlich wie ein privates UTXO-Modell — der Wert existiert als eigenständige Notizen, wobei jede Notiz ihre Gültigkeit selbst beweist, ohne dass man den globalen Zustand kennen muss. Doch die meiste Vertragslogik, auch auf der Rusk VM, braucht typischerweise ein stärker zustandsorientiertes Modell — in dem eine Variable gelesen, geändert und in einer nachvollziehbaren Reihenfolge wieder aufgezeichnet wird. Das ist die architektonische Lücke zwischen zwei verschiedenen Datenmodellen, und das ist nicht nur ein Thema der Privatsphäre.
Wenn das stimmt, besteht die Rolle von Zilch nicht nur darin, „Informationen vor Außenstehenden zu verstecken“, sondern auch als Brücke, um einen Wert in Form einer losen Notiz in eine Eingabe zu übersetzen, die das Zustandsmodell des Vertrags verarbeiten kann — eine Datenkompatibilitätsaufgabe, nicht nur eine Sicherheitsfrage. PLONK beweist anschließend, dass dieser Übersetzungsprozess den Regeln entspricht, ohne dabei den Inhalt der ursprünglichen Notiz offenzulegen.
Selbstkritik: Das ist eine Schlussfolgerung, die auf allgemeinem Verständnis der Unterschiede zwischen UTXO- und account-basierten Modellen beruht; sie spiegelt möglicherweise nicht genau die technischen Implementierungsdetails von Dusk wider — es braucht detailliertere Fachdokumentation, um das zu bestätigen.
Ich warte darauf zu sehen, ob $DUSK weitere detaillierte technische Unterlagen veröffentlicht hat, wie Zilch zwischen diesen beiden Datenmodellen umwandelt, um zu bestätigen, ob das wirklich genau die UTXO-to-account-Kompatibilitätsaufgabe ist, wie ich sie mir vorstelle.
#dusk $BTC $ETH
