彭鱼宴啊
2.7k Beiträge
彭鱼宴啊
Melden
Nutzer blockieren
推特:彭鱼宴@hongchen1476842，BP-400093E42177
Hochfrequenz-Trader
2.7 Jahre
32 Following
21.1K+ Follower
15.5K+ Like gegeben
Beiträge
Alle
Zitierungen
Live
·
--
31
·
--
#dusk $DUSK @Dusk_Foundation In der Bestrafungsmechanik von Dusk gibt es eine Einstellung, über die ich meine Sichtweise gern separat darlegen möchte: Wenn ein Knoten offline geht und er keinen Block produziert, obwohl er an der Reihe wäre, zählt das nicht als böswilliges Verhalten, bremst das Netzwerk aber aus. Die Behandlung dafür erfolgt erst mit einer Warnung und dann wird ein Teil des Einsatzes in einen vorübergehend nicht wirksamen Status verschoben. Das Kapital wird dabei keinen Cent „verbrannt“, aber es gibt vorerst keine Belohnungen, und man wird für eine gewisse Zeit von der Konsensbildung ausgeschlossen. Wirklich Geld kostet es nur bei eindeutig nachgewiesenem Fehlverhalten wie Doppel-Signaturen oder dem Fälschen von Blöcken.
Ich verstehe die ursprüngliche Absicht dieser Gestaltung: Die minimale Einsatzschwelle liegt bei nur eintausend Coins. Wenn man bei einem einzigen Offline-Vorfall direkt das Kapital abziehen würde, würde das viele Knotenbetreiber abschrecken, die sich ernsthaft beteiligen wollen, aber technisch nur durchschnittliche Voraussetzungen haben. Am Ende würde sich das Netzwerk dann eher auf wenige professionelle Institutionen konzentrieren. Mit einer „sanften“, nicht allzu schmerzhaften Strafe möglichst viele zur Teilnahme zu bewegen – diese Abwägung ist an sich nachvollziehbar.
Meine persönliche Einschätzung ist jedoch, dass dieser Logik ein verborgenes, unausgesprochenes Vorannahme zugrunde liegt: Es wird davon ausgegangen, dass es im Netzwerk genug Menschen gibt, die bereit sind, ihre Knoten wirklich gewissenhaft zu betreiben. Nur dann kann die weiche Strafe die reale Effizienz des Netzwerkbetriebs nicht beeinträchtigen. Wenn eines Tages viele Knoten anfangen, sich auf genau dieselbe Handvoll Cloud-Anbieter oder dasselbe Rechenzentrum zu stützen, und sobald ein Teil dieser Basisinfrastruktur ausfällt, werden in kurzer Zeit sehr viele Knoten gleichzeitig eine weiche Strafe auslösen und gleichzeitig vorübergehend von der Konsensbildung ausgeschlossen. Dann wird das „kein Kapitalabbrennen“ paradox eher zu einem Faktor, der alle dafür „durchwinken“ lässt, sich weniger um die Stabilität ihres Knotens zu kümmern – schließlich tut es ja nicht weh, wenn man offline geht. Wer investiert schon wirklich hart, um eine maximale Online-Rate sicherzustellen? In einem Netzwerk mit „härterer“ Bestrafung würde dieses Gefühl für die Kosten die Betreiber viel ernster dazu zwingen, sich um ihre Infrastruktur zu kümmern. Ob die Toleranz, die durch weiche Strafen entsteht, langfristig heimlich auch die Bedeutung senkt, die das gesamte Netzwerk dem Thema „gewissenhafte Wartung“ beimisst, ist meiner Meinung nach eine Frage, die es kontinuierlich zu beobachten gilt – und nicht etwas, das man mit einem Blick auf die Parameterliste abschließend beurteilen kann.
#dusk $DUSK @Dusk In der Bestrafungsmechanik von Dusk gibt es eine Einstellung, über die ich meine Sichtweise gern separat darlegen möchte: Wenn ein Knoten offline geht und er keinen Block produziert, obwohl er an der Reihe wäre, zählt das nicht als böswilliges Verhalten, bremst das Netzwerk aber aus. Die Behandlung dafür erfolgt erst mit einer Warnung und dann wird ein Teil des Einsatzes in einen vorübergehend nicht wirksamen Status verschoben. Das Kapital wird dabei keinen Cent „verbrannt“, aber es gibt vorerst keine Belohnungen, und man wird für eine gewisse Zeit von der Konsensbildung ausgeschlossen. Wirklich Geld kostet es nur bei eindeutig nachgewiesenem Fehlverhalten wie Doppel-Signaturen oder dem Fälschen von Blöcken.
Ich verstehe die ursprüngliche Absicht dieser Gestaltung: Die minimale Einsatzschwelle liegt bei nur eintausend Coins. Wenn man bei einem einzigen Offline-Vorfall direkt das Kapital abziehen würde, würde das viele Knotenbetreiber abschrecken, die sich ernsthaft beteiligen wollen, aber technisch nur durchschnittliche Voraussetzungen haben. Am Ende würde sich das Netzwerk dann eher auf wenige professionelle Institutionen konzentrieren. Mit einer „sanften“, nicht allzu schmerzhaften Strafe möglichst viele zur Teilnahme zu bewegen – diese Abwägung ist an sich nachvollziehbar.
Meine persönliche Einschätzung ist jedoch, dass dieser Logik ein verborgenes, unausgesprochenes Vorannahme zugrunde liegt: Es wird davon ausgegangen, dass es im Netzwerk genug Menschen gibt, die bereit sind, ihre Knoten wirklich gewissenhaft zu betreiben. Nur dann kann die weiche Strafe die reale Effizienz des Netzwerkbetriebs nicht beeinträchtigen. Wenn eines Tages viele Knoten anfangen, sich auf genau dieselbe Handvoll Cloud-Anbieter oder dasselbe Rechenzentrum zu stützen, und sobald ein Teil dieser Basisinfrastruktur ausfällt, werden in kurzer Zeit sehr viele Knoten gleichzeitig eine weiche Strafe auslösen und gleichzeitig vorübergehend von der Konsensbildung ausgeschlossen. Dann wird das „kein Kapitalabbrennen“ paradox eher zu einem Faktor, der alle dafür „durchwinken“ lässt, sich weniger um die Stabilität ihres Knotens zu kümmern – schließlich tut es ja nicht weh, wenn man offline geht. Wer investiert schon wirklich hart, um eine maximale Online-Rate sicherzustellen? In einem Netzwerk mit „härterer“ Bestrafung würde dieses Gefühl für die Kosten die Betreiber viel ernster dazu zwingen, sich um ihre Infrastruktur zu kümmern. Ob die Toleranz, die durch weiche Strafen entsteht, langfristig heimlich auch die Bedeutung senkt, die das gesamte Netzwerk dem Thema „gewissenhafte Wartung“ beimisst, ist meiner Meinung nach eine Frage, die es kontinuierlich zu beobachten gilt – und nicht etwas, das man mit einem Blick auf die Parameterliste abschließend beurteilen kann.
Ich verstehe die ursprüngliche Absicht dieser Gestaltung: Die minimale Einsatzschwelle liegt bei nur eintausend Coins. Wenn man bei einem einzigen Offline-Vorfall direkt das Kapital abziehen würde, würde das viele Knotenbetreiber abschrecken, die sich ernsthaft beteiligen wollen, aber technisch nur durchschnittliche Voraussetzungen haben. Am Ende würde sich das Netzwerk dann eher auf wenige professionelle Institutionen konzentrieren. Mit einer „sanften“, nicht allzu schmerzhaften Strafe möglichst viele zur Teilnahme zu bewegen – diese Abwägung ist an sich nachvollziehbar.
Meine persönliche Einschätzung ist jedoch, dass dieser Logik ein verborgenes, unausgesprochenes Vorannahme zugrunde liegt: Es wird davon ausgegangen, dass es im Netzwerk genug Menschen gibt, die bereit sind, ihre Knoten wirklich gewissenhaft zu betreiben. Nur dann kann die weiche Strafe die reale Effizienz des Netzwerkbetriebs nicht beeinträchtigen. Wenn eines Tages viele Knoten anfangen, sich auf genau dieselbe Handvoll Cloud-Anbieter oder dasselbe Rechenzentrum zu stützen, und sobald ein Teil dieser Basisinfrastruktur ausfällt, werden in kurzer Zeit sehr viele Knoten gleichzeitig eine weiche Strafe auslösen und gleichzeitig vorübergehend von der Konsensbildung ausgeschlossen. Dann wird das „kein Kapitalabbrennen“ paradox eher zu einem Faktor, der alle dafür „durchwinken“ lässt, sich weniger um die Stabilität ihres Knotens zu kümmern – schließlich tut es ja nicht weh, wenn man offline geht. Wer investiert schon wirklich hart, um eine maximale Online-Rate sicherzustellen? In einem Netzwerk mit „härterer“ Bestrafung würde dieses Gefühl für die Kosten die Betreiber viel ernster dazu zwingen, sich um ihre Infrastruktur zu kümmern. Ob die Toleranz, die durch weiche Strafen entsteht, langfristig heimlich auch die Bedeutung senkt, die das gesamte Netzwerk dem Thema „gewissenhafte Wartung“ beimisst, ist meiner Meinung nach eine Frage, die es kontinuierlich zu beobachten gilt – und nicht etwas, das man mit einem Blick auf die Parameterliste abschließend beurteilen kann.
265
·
--
#dusk $DUSK @Dusk_Foundation Ich habe schon immer neugierig auf ein konkretes Szenario geschaut: Was passiert, wenn jemand an der Reihe ist, einen Block zu erstellen, aber genau dessen Knoten feststeckt oder offline geht? Wartet das Netzwerk dann einfach ab – oder gibt es eine automatische Umschalt- bzw. Ausweichlösung? Ich habe mir deshalb gezielt angesehen, wie dieser Abschnitt im Dusk-Konsensprozess gestaltet ist.
Beim Blockproduzieren in Dusk gibt es drei Schritte: Zuerst schlägt der ausgewählte Knoten einen Block vor. Danach bestätigt eine Reihe von Knoten den Block per Signatur-Voing. Anschließend führt eine andere Gruppe eine zweite Runde der Abstimmung durch, fasst die Ergebnisse der vorherigen Runde zusammen und erreicht offiziell den Konsens. Diese drei Schritte zusammen gelten als eine Runde. Wenn der ausgewählte Knoten den vorgeschlagenen Block nicht innerhalb der vorgegebenen Zeit ordnungsgemäß einreicht oder wenn während der Abstimmung nicht genug Stimmen zusammenkommen, dann schlägt diese Runde wegen Zeitüberschreitung fehl. Es geht dann in die nächste Iteration über: Man wechselt erneut die beteiligten Knoten und versucht es von vorn, und das wird so lange wiederholt, bis tatsächlich ein Konsens erreicht ist.
Ursprünglich dachte ich, dass dieses „nach Timeout neu starten“ starr und unveränderlich ist – also dass nach jedem Timeout immer eine fest definierte Dauer gewartet wird und dann erneut ein Versuch erfolgt. Als ich jedoch in ihre Entwicklungstagebücher geschaut habe, stellte ich fest: dem ist nicht so. Dort gibt es eine Änderung, die explizit mit „adaptive Timeouts implementieren“ beschrieben ist. Zusätzlich gibt es noch eine andere Änderung mit „Blöcke auf eine niedrigere Runde zurücksetzen zulassen“. Das bedeutet: Das System verwendet nicht durchgehend dieselbe feste Wartezeit von Anfang bis Ende, sondern passt das Zeitfenster an die tatsächlichen Bedingungen im Netzwerk an. Außerdem behandelt es Fälle wie diesen: Wenn es bereits akzeptierte Blöcke aus früheren Runden gibt, wird diese spätere Runde nicht mehr unnötig herumprobiert.
Dieser Detailpunkt ist mir erst aufgefallen, weil ich ihn in einem Update der Aufzeichnungen aus einem bestimmten Entwicklungszyklus entdeckt habe. Wenn man nur die Bezeichnung des Protokolls und die Beschreibung der Schritte liest, erkennt man diese Ebene der dynamischen Anpassung überhaupt nicht.
Für mich löst dieses Mechanismus-Design ein ziemlich reales Problem: Je mehr Knoten im Netzwerk sind, desto eher gibt es immer jemanden, der durch Netzwerk-Jitter „zappelt“ oder zwischendurch offline geht. Ohne diese automatische Neuauswahl und die dynamische Timeout-Anpassung könnte das Netzwerk jederzeit an genau einem unglücklichen Knoten festhängen, der einfach nicht rechtzeitig reagiert. Ich habe allerdings keine konkreten historischen Daten gefunden – zum Beispiel wie oft der Hauptnetzbetrieb bisher tatsächlich aufgrund solcher Timeout-Neuauswahlen ausgelöst wurde, und wie lange es im Durchschnitt dauert, bis der Betrieb nach dem Auslösen wieder normal läuft. Dafür habe ich bislang noch keine verwertbaren Zahlen zur Verifizierung gefunden.
#dusk $DUSK @Dusk Ich habe schon immer neugierig auf ein konkretes Szenario geschaut: Was passiert, wenn jemand an der Reihe ist, einen Block zu erstellen, aber genau dessen Knoten feststeckt oder offline geht? Wartet das Netzwerk dann einfach ab – oder gibt es eine automatische Umschalt- bzw. Ausweichlösung? Ich habe mir deshalb gezielt angesehen, wie dieser Abschnitt im Dusk-Konsensprozess gestaltet ist.
Beim Blockproduzieren in Dusk gibt es drei Schritte: Zuerst schlägt der ausgewählte Knoten einen Block vor. Danach bestätigt eine Reihe von Knoten den Block per Signatur-Voing. Anschließend führt eine andere Gruppe eine zweite Runde der Abstimmung durch, fasst die Ergebnisse der vorherigen Runde zusammen und erreicht offiziell den Konsens. Diese drei Schritte zusammen gelten als eine Runde. Wenn der ausgewählte Knoten den vorgeschlagenen Block nicht innerhalb der vorgegebenen Zeit ordnungsgemäß einreicht oder wenn während der Abstimmung nicht genug Stimmen zusammenkommen, dann schlägt diese Runde wegen Zeitüberschreitung fehl. Es geht dann in die nächste Iteration über: Man wechselt erneut die beteiligten Knoten und versucht es von vorn, und das wird so lange wiederholt, bis tatsächlich ein Konsens erreicht ist.
Ursprünglich dachte ich, dass dieses „nach Timeout neu starten“ starr und unveränderlich ist – also dass nach jedem Timeout immer eine fest definierte Dauer gewartet wird und dann erneut ein Versuch erfolgt. Als ich jedoch in ihre Entwicklungstagebücher geschaut habe, stellte ich fest: dem ist nicht so. Dort gibt es eine Änderung, die explizit mit „adaptive Timeouts implementieren“ beschrieben ist. Zusätzlich gibt es noch eine andere Änderung mit „Blöcke auf eine niedrigere Runde zurücksetzen zulassen“. Das bedeutet: Das System verwendet nicht durchgehend dieselbe feste Wartezeit von Anfang bis Ende, sondern passt das Zeitfenster an die tatsächlichen Bedingungen im Netzwerk an. Außerdem behandelt es Fälle wie diesen: Wenn es bereits akzeptierte Blöcke aus früheren Runden gibt, wird diese spätere Runde nicht mehr unnötig herumprobiert.
Dieser Detailpunkt ist mir erst aufgefallen, weil ich ihn in einem Update der Aufzeichnungen aus einem bestimmten Entwicklungszyklus entdeckt habe. Wenn man nur die Bezeichnung des Protokolls und die Beschreibung der Schritte liest, erkennt man diese Ebene der dynamischen Anpassung überhaupt nicht.
Für mich löst dieses Mechanismus-Design ein ziemlich reales Problem: Je mehr Knoten im Netzwerk sind, desto eher gibt es immer jemanden, der durch Netzwerk-Jitter „zappelt“ oder zwischendurch offline geht. Ohne diese automatische Neuauswahl und die dynamische Timeout-Anpassung könnte das Netzwerk jederzeit an genau einem unglücklichen Knoten festhängen, der einfach nicht rechtzeitig reagiert. Ich habe allerdings keine konkreten historischen Daten gefunden – zum Beispiel wie oft der Hauptnetzbetrieb bisher tatsächlich aufgrund solcher Timeout-Neuauswahlen ausgelöst wurde, und wie lange es im Durchschnitt dauert, bis der Betrieb nach dem Auslösen wieder normal läuft. Dafür habe ich bislang noch keine verwertbaren Zahlen zur Verifizierung gefunden.
Beim Blockproduzieren in Dusk gibt es drei Schritte: Zuerst schlägt der ausgewählte Knoten einen Block vor. Danach bestätigt eine Reihe von Knoten den Block per Signatur-Voing. Anschließend führt eine andere Gruppe eine zweite Runde der Abstimmung durch, fasst die Ergebnisse der vorherigen Runde zusammen und erreicht offiziell den Konsens. Diese drei Schritte zusammen gelten als eine Runde. Wenn der ausgewählte Knoten den vorgeschlagenen Block nicht innerhalb der vorgegebenen Zeit ordnungsgemäß einreicht oder wenn während der Abstimmung nicht genug Stimmen zusammenkommen, dann schlägt diese Runde wegen Zeitüberschreitung fehl. Es geht dann in die nächste Iteration über: Man wechselt erneut die beteiligten Knoten und versucht es von vorn, und das wird so lange wiederholt, bis tatsächlich ein Konsens erreicht ist.
Ursprünglich dachte ich, dass dieses „nach Timeout neu starten“ starr und unveränderlich ist – also dass nach jedem Timeout immer eine fest definierte Dauer gewartet wird und dann erneut ein Versuch erfolgt. Als ich jedoch in ihre Entwicklungstagebücher geschaut habe, stellte ich fest: dem ist nicht so. Dort gibt es eine Änderung, die explizit mit „adaptive Timeouts implementieren“ beschrieben ist. Zusätzlich gibt es noch eine andere Änderung mit „Blöcke auf eine niedrigere Runde zurücksetzen zulassen“. Das bedeutet: Das System verwendet nicht durchgehend dieselbe feste Wartezeit von Anfang bis Ende, sondern passt das Zeitfenster an die tatsächlichen Bedingungen im Netzwerk an. Außerdem behandelt es Fälle wie diesen: Wenn es bereits akzeptierte Blöcke aus früheren Runden gibt, wird diese spätere Runde nicht mehr unnötig herumprobiert.
Dieser Detailpunkt ist mir erst aufgefallen, weil ich ihn in einem Update der Aufzeichnungen aus einem bestimmten Entwicklungszyklus entdeckt habe. Wenn man nur die Bezeichnung des Protokolls und die Beschreibung der Schritte liest, erkennt man diese Ebene der dynamischen Anpassung überhaupt nicht.
Für mich löst dieses Mechanismus-Design ein ziemlich reales Problem: Je mehr Knoten im Netzwerk sind, desto eher gibt es immer jemanden, der durch Netzwerk-Jitter „zappelt“ oder zwischendurch offline geht. Ohne diese automatische Neuauswahl und die dynamische Timeout-Anpassung könnte das Netzwerk jederzeit an genau einem unglücklichen Knoten festhängen, der einfach nicht rechtzeitig reagiert. Ich habe allerdings keine konkreten historischen Daten gefunden – zum Beispiel wie oft der Hauptnetzbetrieb bisher tatsächlich aufgrund solcher Timeout-Neuauswahlen ausgelöst wurde, und wie lange es im Durchschnitt dauert, bis der Betrieb nach dem Auslösen wieder normal läuft. Dafür habe ich bislang noch keine verwertbaren Zahlen zur Verifizierung gefunden.
215
·
--
#dusk $DUSK @Dusk_Foundation Dusk 里 gibt es zwei Kontensysteme: eines ist ein öffentlich einsehbares normales Konto, das andere ist ein verschlüsseltes, verstecktes Privacy-Konto. Davor habe ich öfter gehört, dass diese beiden Seiten ineinander umgewandelt werden können. Diesmal habe ich die Umwandlungsfunktion ganz gezielt ausprobiert, um herauszufinden, wie man sie genau bedient—erstmal alles andere beiseite.
Der konkrete Ablauf ist folgender: Auf der Dusk-Ebene gibt es einen speziellen Smart Contract, der für die Logik von Überweisungen zuständig ist. Dasselbe Token kann vom versteckten in den öffentlichen Status wechseln, oder umgekehrt—beides läuft über eine Umwandlungsoperation in genau diesem Contract. Es ist nicht so, dass man die versteckten Gelder einfach erst herauszieht und dann noch einmal separat auf ein öffentliches Konto einzahlt, sondern dass derselbe Vermögenswert in einer einzigen Aktion direkt den Status umschaltet. Dazwischen gibt es keinen Zwischenschritt, der von außen unabhängig beobachtbar wäre.
Ich habe das selbst auf dem Testnetz ausprobiert: Beim ersten Versuch habe ich mich in die falsche Richtung geklickt. Ich wollte eigentlich vom versteckten Konto zum öffentlichen Konto wechseln, habe aber das Gegenteil ausgefüllt—also von öffentlich zu versteckt. Das Geld wurde zwar erfolgreich übertragen, aber es war natürlich nicht das Ergebnis, das ich wollte. Nach ein bisschen Herumprobieren habe ich erst begriffen, dass nicht die Umwandlungsfunktion selbst das Problem ist, sondern dass ich auf der Bedienoberfläche die beiden Richtungen vertauscht hatte.
Nach dem Test war mein Eindruck, dass diese Umwandlungsfunktion sehr reibungslos umgesetzt ist—sie läuft „one-step“ ab, ohne Zwischenstation. Das wirkt anders als bei manchen anderen Konzepten, bei denen man erst über eine Zwischenadresse gehen muss, um so eine Umschaltung zu erreichen. Aber ich habe auch etwas entdeckt, das leicht übersehen wird: Diese Umwandlung kümmert sich nur um den Statuswechsel des Geldes selbst. Wenn es sich dagegen um eine Art von Wertpapier handelt, die an Compliance-Regeln gebunden ist (z. B. Vermögenswerte, bei denen eine Prüfung durch eine Whitelist nötig ist oder die speziellen Übertragungsregeln folgen müssen), dann läuft das Ganze über ein komplett anderes, separates Mechanismus-Design. Man kann dafür nicht einfach diese Umwandlungsfunktion verwenden. Beide sind getrennt entworfen. Anfangs dachte ich aus Gewohnheit instinktiv, dass sich alle Assets so umschalten lassen—bis ich dann bestätigt habe, dass ich mir das falsch vorgestellt hatte.
#dusk $DUSK @Dusk Dusk 里 gibt es zwei Kontensysteme: eines ist ein öffentlich einsehbares normales Konto, das andere ist ein verschlüsseltes, verstecktes Privacy-Konto. Davor habe ich öfter gehört, dass diese beiden Seiten ineinander umgewandelt werden können. Diesmal habe ich die Umwandlungsfunktion ganz gezielt ausprobiert, um herauszufinden, wie man sie genau bedient—erstmal alles andere beiseite.
Der konkrete Ablauf ist folgender: Auf der Dusk-Ebene gibt es einen speziellen Smart Contract, der für die Logik von Überweisungen zuständig ist. Dasselbe Token kann vom versteckten in den öffentlichen Status wechseln, oder umgekehrt—beides läuft über eine Umwandlungsoperation in genau diesem Contract. Es ist nicht so, dass man die versteckten Gelder einfach erst herauszieht und dann noch einmal separat auf ein öffentliches Konto einzahlt, sondern dass derselbe Vermögenswert in einer einzigen Aktion direkt den Status umschaltet. Dazwischen gibt es keinen Zwischenschritt, der von außen unabhängig beobachtbar wäre.
Ich habe das selbst auf dem Testnetz ausprobiert: Beim ersten Versuch habe ich mich in die falsche Richtung geklickt. Ich wollte eigentlich vom versteckten Konto zum öffentlichen Konto wechseln, habe aber das Gegenteil ausgefüllt—also von öffentlich zu versteckt. Das Geld wurde zwar erfolgreich übertragen, aber es war natürlich nicht das Ergebnis, das ich wollte. Nach ein bisschen Herumprobieren habe ich erst begriffen, dass nicht die Umwandlungsfunktion selbst das Problem ist, sondern dass ich auf der Bedienoberfläche die beiden Richtungen vertauscht hatte.
Nach dem Test war mein Eindruck, dass diese Umwandlungsfunktion sehr reibungslos umgesetzt ist—sie läuft „one-step“ ab, ohne Zwischenstation. Das wirkt anders als bei manchen anderen Konzepten, bei denen man erst über eine Zwischenadresse gehen muss, um so eine Umschaltung zu erreichen. Aber ich habe auch etwas entdeckt, das leicht übersehen wird: Diese Umwandlung kümmert sich nur um den Statuswechsel des Geldes selbst. Wenn es sich dagegen um eine Art von Wertpapier handelt, die an Compliance-Regeln gebunden ist (z. B. Vermögenswerte, bei denen eine Prüfung durch eine Whitelist nötig ist oder die speziellen Übertragungsregeln folgen müssen), dann läuft das Ganze über ein komplett anderes, separates Mechanismus-Design. Man kann dafür nicht einfach diese Umwandlungsfunktion verwenden. Beide sind getrennt entworfen. Anfangs dachte ich aus Gewohnheit instinktiv, dass sich alle Assets so umschalten lassen—bis ich dann bestätigt habe, dass ich mir das falsch vorgestellt hatte.
Der konkrete Ablauf ist folgender: Auf der Dusk-Ebene gibt es einen speziellen Smart Contract, der für die Logik von Überweisungen zuständig ist. Dasselbe Token kann vom versteckten in den öffentlichen Status wechseln, oder umgekehrt—beides läuft über eine Umwandlungsoperation in genau diesem Contract. Es ist nicht so, dass man die versteckten Gelder einfach erst herauszieht und dann noch einmal separat auf ein öffentliches Konto einzahlt, sondern dass derselbe Vermögenswert in einer einzigen Aktion direkt den Status umschaltet. Dazwischen gibt es keinen Zwischenschritt, der von außen unabhängig beobachtbar wäre.
Ich habe das selbst auf dem Testnetz ausprobiert: Beim ersten Versuch habe ich mich in die falsche Richtung geklickt. Ich wollte eigentlich vom versteckten Konto zum öffentlichen Konto wechseln, habe aber das Gegenteil ausgefüllt—also von öffentlich zu versteckt. Das Geld wurde zwar erfolgreich übertragen, aber es war natürlich nicht das Ergebnis, das ich wollte. Nach ein bisschen Herumprobieren habe ich erst begriffen, dass nicht die Umwandlungsfunktion selbst das Problem ist, sondern dass ich auf der Bedienoberfläche die beiden Richtungen vertauscht hatte.
Nach dem Test war mein Eindruck, dass diese Umwandlungsfunktion sehr reibungslos umgesetzt ist—sie läuft „one-step“ ab, ohne Zwischenstation. Das wirkt anders als bei manchen anderen Konzepten, bei denen man erst über eine Zwischenadresse gehen muss, um so eine Umschaltung zu erreichen. Aber ich habe auch etwas entdeckt, das leicht übersehen wird: Diese Umwandlung kümmert sich nur um den Statuswechsel des Geldes selbst. Wenn es sich dagegen um eine Art von Wertpapier handelt, die an Compliance-Regeln gebunden ist (z. B. Vermögenswerte, bei denen eine Prüfung durch eine Whitelist nötig ist oder die speziellen Übertragungsregeln folgen müssen), dann läuft das Ganze über ein komplett anderes, separates Mechanismus-Design. Man kann dafür nicht einfach diese Umwandlungsfunktion verwenden. Beide sind getrennt entworfen. Anfangs dachte ich aus Gewohnheit instinktiv, dass sich alle Assets so umschalten lassen—bis ich dann bestätigt habe, dass ich mir das falsch vorgestellt hatte.
199
·
--
#dusk $DUSK @Dusk_Foundation Ich höre Dusk schon lange den Begriff „programmierbarer Datenschutz“ erwähnen, aber jedes Mal, wenn er ihn anspricht, werden mehrere Eigenschaften durcheinandergeworfen. Diesmal möchte ich mir speziell nur „selektive Offenlegung“ herausgreifen, um klarzustellen, was genau damit gemeint ist – der Rest ist erst mal egal.
So wie ich es verstanden habe, löst „selektive Offenlegung“ folgendes Szenario: Bei einer Transaktion ist für Außenstehende normalerweise weder der Betrag noch die Beteiligten sichtbar – das ist der Teil, der unter Datenschutz fällt. Wenn jedoch Aufsichtsbehörden oder Auditoren die Transaktion prüfen müssen, sollten Nutzer oder Institutionen eine Möglichkeit haben, dass eine bestimmte, autorisierte Partei die relevanten Informationen sieht, ohne sie allen öffentlich zu machen. Das ist nicht dieses alte Denkmuster „entweder alles offenlegen oder alles verbergen“, sondern man hat inmitten dieser beiden Extreme einen kontrollierbaren Kanal geschaffen.
Am Anfang dachte ich, dass dieses „selektiv“ durch manuelle Schritte außerhalb der Kette (off-chain) erreicht wird – also wenn etwas passiert, dann über einen Offline-Prozess die Transaktionsprotokolle exportieren, damit die Aufsicht sie sehen kann. Nachdem ich aber erst recherchiert habe, stellte sich heraus, dass es nicht so ist. Die offizielle Darstellung lautet vielmehr, dass diese Fähigkeit direkt über kryptografische Werkzeuge im Protokoll umgesetzt ist: Nutzer oder Institutionen entscheiden selbst, ob sie ein Zertifikat/Attest erzeugen wollen, das nur bestimmten Objekten zur Einsicht bereitsteht. Man muss sich nicht nachträglich bei irgendjemandem anpingen, damit er „im Backend“ eine Datenbankabfrage durchführt. Diese Fehlannahme habe ich erst nach zweimaligem Lesen der Erklärungen korrigiert – am Anfang war sie tatsächlich zu simpel.
Aber ich muss auch offen sagen: In den offiziellen Unterlagen werden die Ausführungsdetails zu „wer die Anfrage für diese Offenlegung stellen darf“ sowie „wie detailliert diese Bescheinigung/der Nachweis eingesehen werden kann“ recht allgemein gehalten. Es gibt keine konkrete Schritt-für-Schritt-Anleitung, der man einfach folgen könnte. Das bedeutet: „Selektive Offenlegung“ ist aktuell eher eine Fähigkeit auf Protokollebene, die zwar vorhanden ist, aber wie man sie in einem konkreten echten Szenario anwendet, wer den Auslöser setzt und wie lange der Genehmigungsprozess dauert – das hängt vermutlich davon ab, wie das später mit Kooperationspartnern wie NPEX in Produkten tatsächlich umgesetzt wird. In dieser Runde konnte ich kein bereits durchgeführtes konkretes Beispiel finden. Ich kann daher erst mal nur bestätigen, dass die Fähigkeit existiert, und nicht beurteilen, ob sie sich in der Praxis gut oder umständlich bedienen lässt.
#dusk $DUSK @Dusk Ich höre Dusk schon lange den Begriff „programmierbarer Datenschutz“ erwähnen, aber jedes Mal, wenn er ihn anspricht, werden mehrere Eigenschaften durcheinandergeworfen. Diesmal möchte ich mir speziell nur „selektive Offenlegung“ herausgreifen, um klarzustellen, was genau damit gemeint ist – der Rest ist erst mal egal.
So wie ich es verstanden habe, löst „selektive Offenlegung“ folgendes Szenario: Bei einer Transaktion ist für Außenstehende normalerweise weder der Betrag noch die Beteiligten sichtbar – das ist der Teil, der unter Datenschutz fällt. Wenn jedoch Aufsichtsbehörden oder Auditoren die Transaktion prüfen müssen, sollten Nutzer oder Institutionen eine Möglichkeit haben, dass eine bestimmte, autorisierte Partei die relevanten Informationen sieht, ohne sie allen öffentlich zu machen. Das ist nicht dieses alte Denkmuster „entweder alles offenlegen oder alles verbergen“, sondern man hat inmitten dieser beiden Extreme einen kontrollierbaren Kanal geschaffen.
Am Anfang dachte ich, dass dieses „selektiv“ durch manuelle Schritte außerhalb der Kette (off-chain) erreicht wird – also wenn etwas passiert, dann über einen Offline-Prozess die Transaktionsprotokolle exportieren, damit die Aufsicht sie sehen kann. Nachdem ich aber erst recherchiert habe, stellte sich heraus, dass es nicht so ist. Die offizielle Darstellung lautet vielmehr, dass diese Fähigkeit direkt über kryptografische Werkzeuge im Protokoll umgesetzt ist: Nutzer oder Institutionen entscheiden selbst, ob sie ein Zertifikat/Attest erzeugen wollen, das nur bestimmten Objekten zur Einsicht bereitsteht. Man muss sich nicht nachträglich bei irgendjemandem anpingen, damit er „im Backend“ eine Datenbankabfrage durchführt. Diese Fehlannahme habe ich erst nach zweimaligem Lesen der Erklärungen korrigiert – am Anfang war sie tatsächlich zu simpel.
Aber ich muss auch offen sagen: In den offiziellen Unterlagen werden die Ausführungsdetails zu „wer die Anfrage für diese Offenlegung stellen darf“ sowie „wie detailliert diese Bescheinigung/der Nachweis eingesehen werden kann“ recht allgemein gehalten. Es gibt keine konkrete Schritt-für-Schritt-Anleitung, der man einfach folgen könnte. Das bedeutet: „Selektive Offenlegung“ ist aktuell eher eine Fähigkeit auf Protokollebene, die zwar vorhanden ist, aber wie man sie in einem konkreten echten Szenario anwendet, wer den Auslöser setzt und wie lange der Genehmigungsprozess dauert – das hängt vermutlich davon ab, wie das später mit Kooperationspartnern wie NPEX in Produkten tatsächlich umgesetzt wird. In dieser Runde konnte ich kein bereits durchgeführtes konkretes Beispiel finden. Ich kann daher erst mal nur bestätigen, dass die Fähigkeit existiert, und nicht beurteilen, ob sie sich in der Praxis gut oder umständlich bedienen lässt.
So wie ich es verstanden habe, löst „selektive Offenlegung“ folgendes Szenario: Bei einer Transaktion ist für Außenstehende normalerweise weder der Betrag noch die Beteiligten sichtbar – das ist der Teil, der unter Datenschutz fällt. Wenn jedoch Aufsichtsbehörden oder Auditoren die Transaktion prüfen müssen, sollten Nutzer oder Institutionen eine Möglichkeit haben, dass eine bestimmte, autorisierte Partei die relevanten Informationen sieht, ohne sie allen öffentlich zu machen. Das ist nicht dieses alte Denkmuster „entweder alles offenlegen oder alles verbergen“, sondern man hat inmitten dieser beiden Extreme einen kontrollierbaren Kanal geschaffen.
Am Anfang dachte ich, dass dieses „selektiv“ durch manuelle Schritte außerhalb der Kette (off-chain) erreicht wird – also wenn etwas passiert, dann über einen Offline-Prozess die Transaktionsprotokolle exportieren, damit die Aufsicht sie sehen kann. Nachdem ich aber erst recherchiert habe, stellte sich heraus, dass es nicht so ist. Die offizielle Darstellung lautet vielmehr, dass diese Fähigkeit direkt über kryptografische Werkzeuge im Protokoll umgesetzt ist: Nutzer oder Institutionen entscheiden selbst, ob sie ein Zertifikat/Attest erzeugen wollen, das nur bestimmten Objekten zur Einsicht bereitsteht. Man muss sich nicht nachträglich bei irgendjemandem anpingen, damit er „im Backend“ eine Datenbankabfrage durchführt. Diese Fehlannahme habe ich erst nach zweimaligem Lesen der Erklärungen korrigiert – am Anfang war sie tatsächlich zu simpel.
Aber ich muss auch offen sagen: In den offiziellen Unterlagen werden die Ausführungsdetails zu „wer die Anfrage für diese Offenlegung stellen darf“ sowie „wie detailliert diese Bescheinigung/der Nachweis eingesehen werden kann“ recht allgemein gehalten. Es gibt keine konkrete Schritt-für-Schritt-Anleitung, der man einfach folgen könnte. Das bedeutet: „Selektive Offenlegung“ ist aktuell eher eine Fähigkeit auf Protokollebene, die zwar vorhanden ist, aber wie man sie in einem konkreten echten Szenario anwendet, wer den Auslöser setzt und wie lange der Genehmigungsprozess dauert – das hängt vermutlich davon ab, wie das später mit Kooperationspartnern wie NPEX in Produkten tatsächlich umgesetzt wird. In dieser Runde konnte ich kein bereits durchgeführtes konkretes Beispiel finden. Ich kann daher erst mal nur bestätigen, dass die Fähigkeit existiert, und nicht beurteilen, ob sie sich in der Praxis gut oder umständlich bedienen lässt.
191
·
--
#dusk $DUSK @Dusk_Foundation Ich war schon immer neugierig, wie der Entwicklungsfonds im Dusk-Ökosystem konkret funktioniert – entscheiden die Teams selbst, oder gibt es einen Prozess, mit dem auch externe Personen diese Mittel beantragen können? Nachdem ich mir die Erklärungen zur Governance genauer angesehen hatte, stellte ich fest: Dieser Prozess ist formeller, als ich ursprünglich gedacht hatte.
Die Mittelherkunft ist recht direkt: Für jeden produzierten Block im Mainnet wird ein fester Anteil aus der Belohnung herausgeschnitten und über die Zeit in diesem Fonds-Pool angesammelt. Er ist speziell dafür da, die anschließende Ökosystem-Entwicklung und Forschungsarbeiten zu unterstützen – nicht über kurzfristige Spendenaktionen oder weil ein Team „aus eigener Tasche“ zahlt.
Die eigentliche Dezentralisierung liegt im Genehmigungsprozess: Änderungen, die direkt mit dem Protokoll selbst zusammenhängen – etwa zu einem konkreten technischen Verbesserungsvorschlag – laufen über eine Linie aus Einreichung, Begutachtung und Entscheidung, ob diese Maßnahme übernommen wird. Dabei werden an das Format relativ strenge Anforderungen gestellt; es muss wie ein formelles technisches Vorschlagsdokument ausgearbeitet sein – nicht einfach nur ein Beitrag posten und es gilt dann als entschieden. Ausgaben, die keinen direkten Bezug zum Protokollcode haben – zum Beispiel die Entwicklung eines Wallet-Tools oder zweckgebundene Forschungsmittel für ein bestimmtes Forschungsthema – laufen über eine andere Genehmigungslinie. Dafür wird von einer Governance-Gruppe, die speziell für die Zuteilung dieser Gelder zuständig ist, bewertet und entschieden. Theoretisch können auch Mitglieder der externen Community über den Prozess der Wahlen in diese Gruppe einbezogen werden und so am Genehmigungsprozess partizipieren.
Ich hatte ursprünglich gedacht, dass das im Kern ein „Black-Box-Prozess der internen Team-Genehmigung“ ist. Aber nachdem ich die Unterlagen gelesen hatte, sah ich: Zumindest auf Dokumentenebene sind diese beiden Linien ziemlich klar getrennt. Außerdem gibt es jeweils Einstiegspunkte, über die externe Personen Anträge einreichen und sogar an der Begutachtung teilnehmen können – nicht völlig verschlossen. Allerdings sind Dokumentenbeschreibung und tatsächliche Ausführung zwei verschiedene Dinge. Welche Projekte in den letzten Jahren genehmigt wurden, wie hoch die Genehmigungsquote ungefähr war und welcher Anteil auf von extern eingereichte Anträge entfällt – konkrete Ausführungsdaten dazu habe ich derzeit in der Hand nicht gefunden. Man kann also sagen: Vom Prozessdesign her ist das System offen, aber ob und wie transparent die tatsächliche Umsetzung ist, ist noch nicht klar genug; dafür bräuchte es mehr historische Aufzeichnungen zur Überprüfung. Im Moment kann ich keine endgültige, belastbare Einschätzung abgeben.
#dusk $DUSK @Dusk Ich war schon immer neugierig, wie der Entwicklungsfonds im Dusk-Ökosystem konkret funktioniert – entscheiden die Teams selbst, oder gibt es einen Prozess, mit dem auch externe Personen diese Mittel beantragen können? Nachdem ich mir die Erklärungen zur Governance genauer angesehen hatte, stellte ich fest: Dieser Prozess ist formeller, als ich ursprünglich gedacht hatte.
Die Mittelherkunft ist recht direkt: Für jeden produzierten Block im Mainnet wird ein fester Anteil aus der Belohnung herausgeschnitten und über die Zeit in diesem Fonds-Pool angesammelt. Er ist speziell dafür da, die anschließende Ökosystem-Entwicklung und Forschungsarbeiten zu unterstützen – nicht über kurzfristige Spendenaktionen oder weil ein Team „aus eigener Tasche“ zahlt.
Die eigentliche Dezentralisierung liegt im Genehmigungsprozess: Änderungen, die direkt mit dem Protokoll selbst zusammenhängen – etwa zu einem konkreten technischen Verbesserungsvorschlag – laufen über eine Linie aus Einreichung, Begutachtung und Entscheidung, ob diese Maßnahme übernommen wird. Dabei werden an das Format relativ strenge Anforderungen gestellt; es muss wie ein formelles technisches Vorschlagsdokument ausgearbeitet sein – nicht einfach nur ein Beitrag posten und es gilt dann als entschieden. Ausgaben, die keinen direkten Bezug zum Protokollcode haben – zum Beispiel die Entwicklung eines Wallet-Tools oder zweckgebundene Forschungsmittel für ein bestimmtes Forschungsthema – laufen über eine andere Genehmigungslinie. Dafür wird von einer Governance-Gruppe, die speziell für die Zuteilung dieser Gelder zuständig ist, bewertet und entschieden. Theoretisch können auch Mitglieder der externen Community über den Prozess der Wahlen in diese Gruppe einbezogen werden und so am Genehmigungsprozess partizipieren.
Ich hatte ursprünglich gedacht, dass das im Kern ein „Black-Box-Prozess der internen Team-Genehmigung“ ist. Aber nachdem ich die Unterlagen gelesen hatte, sah ich: Zumindest auf Dokumentenebene sind diese beiden Linien ziemlich klar getrennt. Außerdem gibt es jeweils Einstiegspunkte, über die externe Personen Anträge einreichen und sogar an der Begutachtung teilnehmen können – nicht völlig verschlossen. Allerdings sind Dokumentenbeschreibung und tatsächliche Ausführung zwei verschiedene Dinge. Welche Projekte in den letzten Jahren genehmigt wurden, wie hoch die Genehmigungsquote ungefähr war und welcher Anteil auf von extern eingereichte Anträge entfällt – konkrete Ausführungsdaten dazu habe ich derzeit in der Hand nicht gefunden. Man kann also sagen: Vom Prozessdesign her ist das System offen, aber ob und wie transparent die tatsächliche Umsetzung ist, ist noch nicht klar genug; dafür bräuchte es mehr historische Aufzeichnungen zur Überprüfung. Im Moment kann ich keine endgültige, belastbare Einschätzung abgeben.
Die Mittelherkunft ist recht direkt: Für jeden produzierten Block im Mainnet wird ein fester Anteil aus der Belohnung herausgeschnitten und über die Zeit in diesem Fonds-Pool angesammelt. Er ist speziell dafür da, die anschließende Ökosystem-Entwicklung und Forschungsarbeiten zu unterstützen – nicht über kurzfristige Spendenaktionen oder weil ein Team „aus eigener Tasche“ zahlt.
Die eigentliche Dezentralisierung liegt im Genehmigungsprozess: Änderungen, die direkt mit dem Protokoll selbst zusammenhängen – etwa zu einem konkreten technischen Verbesserungsvorschlag – laufen über eine Linie aus Einreichung, Begutachtung und Entscheidung, ob diese Maßnahme übernommen wird. Dabei werden an das Format relativ strenge Anforderungen gestellt; es muss wie ein formelles technisches Vorschlagsdokument ausgearbeitet sein – nicht einfach nur ein Beitrag posten und es gilt dann als entschieden. Ausgaben, die keinen direkten Bezug zum Protokollcode haben – zum Beispiel die Entwicklung eines Wallet-Tools oder zweckgebundene Forschungsmittel für ein bestimmtes Forschungsthema – laufen über eine andere Genehmigungslinie. Dafür wird von einer Governance-Gruppe, die speziell für die Zuteilung dieser Gelder zuständig ist, bewertet und entschieden. Theoretisch können auch Mitglieder der externen Community über den Prozess der Wahlen in diese Gruppe einbezogen werden und so am Genehmigungsprozess partizipieren.
Ich hatte ursprünglich gedacht, dass das im Kern ein „Black-Box-Prozess der internen Team-Genehmigung“ ist. Aber nachdem ich die Unterlagen gelesen hatte, sah ich: Zumindest auf Dokumentenebene sind diese beiden Linien ziemlich klar getrennt. Außerdem gibt es jeweils Einstiegspunkte, über die externe Personen Anträge einreichen und sogar an der Begutachtung teilnehmen können – nicht völlig verschlossen. Allerdings sind Dokumentenbeschreibung und tatsächliche Ausführung zwei verschiedene Dinge. Welche Projekte in den letzten Jahren genehmigt wurden, wie hoch die Genehmigungsquote ungefähr war und welcher Anteil auf von extern eingereichte Anträge entfällt – konkrete Ausführungsdaten dazu habe ich derzeit in der Hand nicht gefunden. Man kann also sagen: Vom Prozessdesign her ist das System offen, aber ob und wie transparent die tatsächliche Umsetzung ist, ist noch nicht klar genug; dafür bräuchte es mehr historische Aufzeichnungen zur Überprüfung. Im Moment kann ich keine endgültige, belastbare Einschätzung abgeben.
210
·
--
#dusk $DUSK @Dusk_Foundation Am Anfang war meine Vorstellung von dem Thema „DUSK staken als Provisioner“ ziemlich simpel: Coins rüber schicken, einen Knoten laufen lassen und auf die Belohnungen warten. Erst als ich mir die offizielle Anleitung zu sicheren Betriebsabläufen wirklich gründlich angesehen und den Prozess Schritt für Schritt selbst durchgespielt habe, wurde mir klar, dass die Hürden deutlich höher sind, als ich dachte.
Die empfohlene Vorgehensweise in der Anleitung ist, den Owner-Key, der die Staking-Berechtigungen hält, direkt in einem per LUKS verschlüsselten USB-Gerät zu erzeugen, statt ihn auf der regelmäßig mit dem Internet verbundenen Festplatte im Alltag liegen zu lassen. Konkret: erst mit cryptsetup den USB-Stick als LUKS-Vollverschlüsselung einrichten, ein starkes Passwort festlegen und den privaten Schlüssel des Wallet-Inhabers direkt in dieser verschlüsselten Partition erzeugen. Im Alltag wird das Gerät dann gar nicht eingesteckt; nur wenn du wirklich das Staking auflösen oder Belohnungen abziehen möchtest, steckst du es kurz ein und nutzt es einmal.
Die Logik dahinter: Selbst wenn der USB-Stick verloren geht oder gestohlen wird, kann man ohne Passwort nicht auf irgendetwas zugreifen. Die normalen Knotenoperationen laufen stattdessen mit einem anderen Satz, mit geringeren Berechtigungen. Dieser unterscheidet sich von dem Owner-Key, mit dem man das Staking-Grundkapital tatsächlich bewegen kann.
Ich habe diesen Ablauf einmal genauso durchgezogen und der größte Eindruck war: Das ist längst keine „ein paar Buttons drücken“-Aktion mehr, sondern verlangt, dass du die Betriebsebene verstehst – also Festplattenverschlüsselung und Offline-Key-Management. Für Leute wie mich, die sonst eher Code schreiben, aber nicht wirklich Profi im Betrieb sind, hat allein das Klären gekostet, welches /dev/sdX man nehmen muss, und darauf zu achten, nicht aus Versehen die falsche Partition zu formatieren – ich musste das mehrfach und wiederholt bestätigen.
Das hat mich dann wieder über die Beteiligung am Dusk-Staking nachdenken lassen: Die niedrigste Staking-Schwelle liegt zwar nur bei 1000 DUSK, klingt also nach geringer Einstiegshürde. Aber wenn man es wirklich nach dem offiziellen Sicherheitsstandard umsetzt, ist die praktische Hürde viel mehr als nur „1000 Coins haben“. Es braucht zusätzlich technisches Know-how und Geduld, um den Sicherheitsprozess vollständig korrekt durchzuführen. Das wird sehr wahrscheinlich automatisch eine Gruppe von normalen Nutzern aussortieren, die im Grunde nur „einfach schnell staken“ wollen. Übrig bleiben eher diejenigen, die Knoten-Sicherheit ernst nehmen. Für die Netzwerksicherheit ist das gut – aber in Bezug auf das Ziel „genug zur Dezentralisierung beitragen“ könnte die eigentliche operative Hürde selbst auch ein leicht übersehener Filter sein.
#dusk $DUSK @Dusk Am Anfang war meine Vorstellung von dem Thema „DUSK staken als Provisioner“ ziemlich simpel: Coins rüber schicken, einen Knoten laufen lassen und auf die Belohnungen warten. Erst als ich mir die offizielle Anleitung zu sicheren Betriebsabläufen wirklich gründlich angesehen und den Prozess Schritt für Schritt selbst durchgespielt habe, wurde mir klar, dass die Hürden deutlich höher sind, als ich dachte.
Die empfohlene Vorgehensweise in der Anleitung ist, den Owner-Key, der die Staking-Berechtigungen hält, direkt in einem per LUKS verschlüsselten USB-Gerät zu erzeugen, statt ihn auf der regelmäßig mit dem Internet verbundenen Festplatte im Alltag liegen zu lassen. Konkret: erst mit cryptsetup den USB-Stick als LUKS-Vollverschlüsselung einrichten, ein starkes Passwort festlegen und den privaten Schlüssel des Wallet-Inhabers direkt in dieser verschlüsselten Partition erzeugen. Im Alltag wird das Gerät dann gar nicht eingesteckt; nur wenn du wirklich das Staking auflösen oder Belohnungen abziehen möchtest, steckst du es kurz ein und nutzt es einmal.
Die Logik dahinter: Selbst wenn der USB-Stick verloren geht oder gestohlen wird, kann man ohne Passwort nicht auf irgendetwas zugreifen. Die normalen Knotenoperationen laufen stattdessen mit einem anderen Satz, mit geringeren Berechtigungen. Dieser unterscheidet sich von dem Owner-Key, mit dem man das Staking-Grundkapital tatsächlich bewegen kann.
Ich habe diesen Ablauf einmal genauso durchgezogen und der größte Eindruck war: Das ist längst keine „ein paar Buttons drücken“-Aktion mehr, sondern verlangt, dass du die Betriebsebene verstehst – also Festplattenverschlüsselung und Offline-Key-Management. Für Leute wie mich, die sonst eher Code schreiben, aber nicht wirklich Profi im Betrieb sind, hat allein das Klären gekostet, welches /dev/sdX man nehmen muss, und darauf zu achten, nicht aus Versehen die falsche Partition zu formatieren – ich musste das mehrfach und wiederholt bestätigen.
Das hat mich dann wieder über die Beteiligung am Dusk-Staking nachdenken lassen: Die niedrigste Staking-Schwelle liegt zwar nur bei 1000 DUSK, klingt also nach geringer Einstiegshürde. Aber wenn man es wirklich nach dem offiziellen Sicherheitsstandard umsetzt, ist die praktische Hürde viel mehr als nur „1000 Coins haben“. Es braucht zusätzlich technisches Know-how und Geduld, um den Sicherheitsprozess vollständig korrekt durchzuführen. Das wird sehr wahrscheinlich automatisch eine Gruppe von normalen Nutzern aussortieren, die im Grunde nur „einfach schnell staken“ wollen. Übrig bleiben eher diejenigen, die Knoten-Sicherheit ernst nehmen. Für die Netzwerksicherheit ist das gut – aber in Bezug auf das Ziel „genug zur Dezentralisierung beitragen“ könnte die eigentliche operative Hürde selbst auch ein leicht übersehener Filter sein.
Die empfohlene Vorgehensweise in der Anleitung ist, den Owner-Key, der die Staking-Berechtigungen hält, direkt in einem per LUKS verschlüsselten USB-Gerät zu erzeugen, statt ihn auf der regelmäßig mit dem Internet verbundenen Festplatte im Alltag liegen zu lassen. Konkret: erst mit cryptsetup den USB-Stick als LUKS-Vollverschlüsselung einrichten, ein starkes Passwort festlegen und den privaten Schlüssel des Wallet-Inhabers direkt in dieser verschlüsselten Partition erzeugen. Im Alltag wird das Gerät dann gar nicht eingesteckt; nur wenn du wirklich das Staking auflösen oder Belohnungen abziehen möchtest, steckst du es kurz ein und nutzt es einmal.
Die Logik dahinter: Selbst wenn der USB-Stick verloren geht oder gestohlen wird, kann man ohne Passwort nicht auf irgendetwas zugreifen. Die normalen Knotenoperationen laufen stattdessen mit einem anderen Satz, mit geringeren Berechtigungen. Dieser unterscheidet sich von dem Owner-Key, mit dem man das Staking-Grundkapital tatsächlich bewegen kann.
Ich habe diesen Ablauf einmal genauso durchgezogen und der größte Eindruck war: Das ist längst keine „ein paar Buttons drücken“-Aktion mehr, sondern verlangt, dass du die Betriebsebene verstehst – also Festplattenverschlüsselung und Offline-Key-Management. Für Leute wie mich, die sonst eher Code schreiben, aber nicht wirklich Profi im Betrieb sind, hat allein das Klären gekostet, welches /dev/sdX man nehmen muss, und darauf zu achten, nicht aus Versehen die falsche Partition zu formatieren – ich musste das mehrfach und wiederholt bestätigen.
Das hat mich dann wieder über die Beteiligung am Dusk-Staking nachdenken lassen: Die niedrigste Staking-Schwelle liegt zwar nur bei 1000 DUSK, klingt also nach geringer Einstiegshürde. Aber wenn man es wirklich nach dem offiziellen Sicherheitsstandard umsetzt, ist die praktische Hürde viel mehr als nur „1000 Coins haben“. Es braucht zusätzlich technisches Know-how und Geduld, um den Sicherheitsprozess vollständig korrekt durchzuführen. Das wird sehr wahrscheinlich automatisch eine Gruppe von normalen Nutzern aussortieren, die im Grunde nur „einfach schnell staken“ wollen. Übrig bleiben eher diejenigen, die Knoten-Sicherheit ernst nehmen. Für die Netzwerksicherheit ist das gut – aber in Bezug auf das Ziel „genug zur Dezentralisierung beitragen“ könnte die eigentliche operative Hürde selbst auch ein leicht übersehener Filter sein.
192
·
--
#termmax @termmax Eigentlich wollte ich in TermMax’ Whitepaper wegen der Kredit-/Leih-Zinsen schauen – als ich dann bei dem Abschnitt über die Vision gelandet bin, wäre ich fast einfach weitergescrollt: „Für jedes Tokenpaar wird ein vollständiger Kreditmarkt aufgebaut – wie in der realen Welt“. So etwas steht in Whitepapern viel zu oft, also habe ich es zunächst nicht weiter ernst genommen. Aber dann habe ich zwei Zeilen weitergelesen und gemerkt, dass in derselben Liste sogar „Long und Short auf Spot-Assets“ mit aufgeführt ist. Da bin ich stehen geblieben und habe es noch einmal von vorn gelesen.
Meine erste Reaktion war: Diese beiden Dinge zusammen wirken ein bisschen merkwürdig. Fixzins-Kredit/Leihe ist ein Finanzinstrument, „Long/Short auf Spot“ ist etwas anderes – warum sollte das in derselben Produkt-„Vision“ auftauchen? Erst als ich diesen Abschnitt einmal zusammen mit den Mechanismen von GTs One-Click-Hebel und dem Kreis-/Loop-Kredit durchdacht habe, wurde mir klar: Fixzinsen sind hier gar nicht das Ziel, sondern die Basis. Wenn man statt „A leihen und zu B wechseln, um B long zu gehen“ einfach die Richtung tauscht und entsprechend shortet – solange die Finanzierungskosten vorher fest einkalkuliert werden können – dann wird der Ertrag dieser Strategie nicht still und leise von den Schwankungen der variablen Zinsen aufgefressen. Ursprünglich ist die Fixzins-Leihe also dazu da, die nächste Schicht der darüberliegenden Handelsstrategie zu fundieren.
Als ich das erkannt hatte, fing ich wieder an zu zweifeln, ob ich mir da vielleicht zu viel einrede. Also bin ich zurückgegangen und habe nachgeschaut, wie es heute mit der Tiefe bei Range Orders und Limit Orders aussieht. Dabei schien es tatsächlich so, als lägen die meisten Orders primär in den ersten (wenigen) Märkten. Das macht mich ein bisschen zögerlich: Wenn die Strategie „A leihen und B long gehen“ funktionieren soll, müssen sowohl auf der Seite der Sicherheiten als auch auf der Seite der Schuldassets genug „Tiefe“ in den Kursen vorhanden sein – bei Rand-Asset-Paaren könnten die Kurven sich möglicherweise gar nicht stabil genug aufbauen. Mit anderen Worten: „wie in der realen Welt einen vollständigen Kreditmarkt aufbauen“ klingt für mich inzwischen eher so, als sei das architektonisch als Schnittstelle vorgesehen, aber noch nicht in der echten Umsetzung angekommen.
Als Nächstes werde ich nicht mehr darauf starren, wie viele Lending-/Borrowing-Märkte unterstützt werden, sondern darauf, ob wirklich jemand „A leihen und B long“ in Form von rein richtungsbasierten Trades nutzt – und nicht wieder zurück in dieses alte Loop-Spiel um One-Click-Hebel gerät. Die Lücke zwischen Vision und Produkt ist der entscheidende Punkt, um zu beurteilen, in welchem Stadium diese Story gerade wirklich ist.
#termmax @TermMax Eigentlich wollte ich in TermMax’ Whitepaper wegen der Kredit-/Leih-Zinsen schauen – als ich dann bei dem Abschnitt über die Vision gelandet bin, wäre ich fast einfach weitergescrollt: „Für jedes Tokenpaar wird ein vollständiger Kreditmarkt aufgebaut – wie in der realen Welt“. So etwas steht in Whitepapern viel zu oft, also habe ich es zunächst nicht weiter ernst genommen. Aber dann habe ich zwei Zeilen weitergelesen und gemerkt, dass in derselben Liste sogar „Long und Short auf Spot-Assets“ mit aufgeführt ist. Da bin ich stehen geblieben und habe es noch einmal von vorn gelesen.
Meine erste Reaktion war: Diese beiden Dinge zusammen wirken ein bisschen merkwürdig. Fixzins-Kredit/Leihe ist ein Finanzinstrument, „Long/Short auf Spot“ ist etwas anderes – warum sollte das in derselben Produkt-„Vision“ auftauchen? Erst als ich diesen Abschnitt einmal zusammen mit den Mechanismen von GTs One-Click-Hebel und dem Kreis-/Loop-Kredit durchdacht habe, wurde mir klar: Fixzinsen sind hier gar nicht das Ziel, sondern die Basis. Wenn man statt „A leihen und zu B wechseln, um B long zu gehen“ einfach die Richtung tauscht und entsprechend shortet – solange die Finanzierungskosten vorher fest einkalkuliert werden können – dann wird der Ertrag dieser Strategie nicht still und leise von den Schwankungen der variablen Zinsen aufgefressen. Ursprünglich ist die Fixzins-Leihe also dazu da, die nächste Schicht der darüberliegenden Handelsstrategie zu fundieren.
Als ich das erkannt hatte, fing ich wieder an zu zweifeln, ob ich mir da vielleicht zu viel einrede. Also bin ich zurückgegangen und habe nachgeschaut, wie es heute mit der Tiefe bei Range Orders und Limit Orders aussieht. Dabei schien es tatsächlich so, als lägen die meisten Orders primär in den ersten (wenigen) Märkten. Das macht mich ein bisschen zögerlich: Wenn die Strategie „A leihen und B long gehen“ funktionieren soll, müssen sowohl auf der Seite der Sicherheiten als auch auf der Seite der Schuldassets genug „Tiefe“ in den Kursen vorhanden sein – bei Rand-Asset-Paaren könnten die Kurven sich möglicherweise gar nicht stabil genug aufbauen. Mit anderen Worten: „wie in der realen Welt einen vollständigen Kreditmarkt aufbauen“ klingt für mich inzwischen eher so, als sei das architektonisch als Schnittstelle vorgesehen, aber noch nicht in der echten Umsetzung angekommen.
Als Nächstes werde ich nicht mehr darauf starren, wie viele Lending-/Borrowing-Märkte unterstützt werden, sondern darauf, ob wirklich jemand „A leihen und B long“ in Form von rein richtungsbasierten Trades nutzt – und nicht wieder zurück in dieses alte Loop-Spiel um One-Click-Hebel gerät. Die Lücke zwischen Vision und Produkt ist der entscheidende Punkt, um zu beurteilen, in welchem Stadium diese Story gerade wirklich ist.
Meine erste Reaktion war: Diese beiden Dinge zusammen wirken ein bisschen merkwürdig. Fixzins-Kredit/Leihe ist ein Finanzinstrument, „Long/Short auf Spot“ ist etwas anderes – warum sollte das in derselben Produkt-„Vision“ auftauchen? Erst als ich diesen Abschnitt einmal zusammen mit den Mechanismen von GTs One-Click-Hebel und dem Kreis-/Loop-Kredit durchdacht habe, wurde mir klar: Fixzinsen sind hier gar nicht das Ziel, sondern die Basis. Wenn man statt „A leihen und zu B wechseln, um B long zu gehen“ einfach die Richtung tauscht und entsprechend shortet – solange die Finanzierungskosten vorher fest einkalkuliert werden können – dann wird der Ertrag dieser Strategie nicht still und leise von den Schwankungen der variablen Zinsen aufgefressen. Ursprünglich ist die Fixzins-Leihe also dazu da, die nächste Schicht der darüberliegenden Handelsstrategie zu fundieren.
Als ich das erkannt hatte, fing ich wieder an zu zweifeln, ob ich mir da vielleicht zu viel einrede. Also bin ich zurückgegangen und habe nachgeschaut, wie es heute mit der Tiefe bei Range Orders und Limit Orders aussieht. Dabei schien es tatsächlich so, als lägen die meisten Orders primär in den ersten (wenigen) Märkten. Das macht mich ein bisschen zögerlich: Wenn die Strategie „A leihen und B long gehen“ funktionieren soll, müssen sowohl auf der Seite der Sicherheiten als auch auf der Seite der Schuldassets genug „Tiefe“ in den Kursen vorhanden sein – bei Rand-Asset-Paaren könnten die Kurven sich möglicherweise gar nicht stabil genug aufbauen. Mit anderen Worten: „wie in der realen Welt einen vollständigen Kreditmarkt aufbauen“ klingt für mich inzwischen eher so, als sei das architektonisch als Schnittstelle vorgesehen, aber noch nicht in der echten Umsetzung angekommen.
Als Nächstes werde ich nicht mehr darauf starren, wie viele Lending-/Borrowing-Märkte unterstützt werden, sondern darauf, ob wirklich jemand „A leihen und B long“ in Form von rein richtungsbasierten Trades nutzt – und nicht wieder zurück in dieses alte Loop-Spiel um One-Click-Hebel gerät. Die Lücke zwischen Vision und Produkt ist der entscheidende Punkt, um zu beurteilen, in welchem Stadium diese Story gerade wirklich ist.
153
·
--
#dusk $DUSK @Dusk_Foundation Neulich habe ich einem Freund erklärt, wie der Konsensmechanismus von Dusk funktioniert – und ganz automatisch habe ich eine ältere Darstellung hervorgeholt: Dusk nutze Proof of Blind Bid, der Identität des Block-Erstellers sei anonym, und über Zero-Knowledge-Beweise werde die eigene Einsatzsumme verborgen, um ein Recht zum Block-Erstellen zu erwirken. Nachdem ich fertig war, kam mir aber ein Zweifel: Nutzt Dusk dieses Modell heute überhaupt noch – oder habe ich mich mit einer veralteten Quelle vertan? Ich habe dann nachgeschaut und festgestellt, dass ich tatsächlich falsch lag.
In den frühen Versionen des Dusk-Whitepapers ist Proof of Blind Bid tatsächlich ein durchdachtes Design: Block-Erstellungskandidaten (Block Generator) reichen eine „Bid Transaction“ ein, in der sie ihre Einsatzsumme in einen Poseidon-Baum speichern und einen passenden Zero-Knowledge-Beweis generieren. Der gesamte Auswahlprozess bleibt nach außen hin unsichtbar: Niemand kann sehen, wer teilnimmt oder wie viel eingesetzt wird. Die Intention dahinter war sehr praxisnah – wenn Identität und Einsatzsumme öffentlich wären, bekämen Angreifer im Grunde eine „Liste der bevorzugten Ziele“, um gezielte Angriffe auf bekannte, große Block-Ersteller zu starten. Anonyme Teilnahme war in der Frühphase von Dusk also ein kryptografisches Gegenmittel gegen solche gezielten Angriffe.
Doch heute beschreibt die offizielle Dusk-Dokumentation für den Mainnet-Konsens Succinct Attestation: ein Proof-of-Stake-Design auf Basis eines Komitees. Dabei werden über ein deterministisches Auswahlverfahren Kandidaten und das Abstimmungs-Komitee durch einen „provisioner“ bestimmt – im gesamten Ablauf wird nicht mehr das Konzept „anonyme Teilnahme“ erwähnt. Anders gesagt: Im Übergang vom frühen Design hin zur Mainnet-Implementierung hat Dusk stillschweigend das Merkmal „Anonymität der Block-Ersteller-Identität“ ersetzt – hin zu einem stärker effizienz- und determinismusorientierten Komitee-Mechanismus.
Diese Änderung wurde nicht groß angekündigt, hat aber dennoch erhebliche Bedeutung: Das Problem, das Proof of Blind Bid in der Frühphase lösen wollte („gezielte Angriffe verhindern“), wird bei Succinct Attestation mit einem anderen Ansatz angegangen – es wird stärker auf die Größe des Komitees und die Unvorhersehbarkeit der Wahlen gesetzt, statt die Identität komplett im Verborgenen zu halten. Für mich ist das eine Erinnerung: Bei der Bewertung eines Projekts darf man sich nicht allein auf ein paar Jahre alte Artikel als Grundlage stützen. Auch bei Dusk iteriert der Kernmechanismus kontinuierlich. Das anonyme Kandidaten-Konzept, das sich damals so cool anhörte, könnte in der Praxis heute schlicht nicht mehr so umgesetzt sein.
#dusk $DUSK @Dusk Neulich habe ich einem Freund erklärt, wie der Konsensmechanismus von Dusk funktioniert – und ganz automatisch habe ich eine ältere Darstellung hervorgeholt: Dusk nutze Proof of Blind Bid, der Identität des Block-Erstellers sei anonym, und über Zero-Knowledge-Beweise werde die eigene Einsatzsumme verborgen, um ein Recht zum Block-Erstellen zu erwirken. Nachdem ich fertig war, kam mir aber ein Zweifel: Nutzt Dusk dieses Modell heute überhaupt noch – oder habe ich mich mit einer veralteten Quelle vertan? Ich habe dann nachgeschaut und festgestellt, dass ich tatsächlich falsch lag.
In den frühen Versionen des Dusk-Whitepapers ist Proof of Blind Bid tatsächlich ein durchdachtes Design: Block-Erstellungskandidaten (Block Generator) reichen eine „Bid Transaction“ ein, in der sie ihre Einsatzsumme in einen Poseidon-Baum speichern und einen passenden Zero-Knowledge-Beweis generieren. Der gesamte Auswahlprozess bleibt nach außen hin unsichtbar: Niemand kann sehen, wer teilnimmt oder wie viel eingesetzt wird. Die Intention dahinter war sehr praxisnah – wenn Identität und Einsatzsumme öffentlich wären, bekämen Angreifer im Grunde eine „Liste der bevorzugten Ziele“, um gezielte Angriffe auf bekannte, große Block-Ersteller zu starten. Anonyme Teilnahme war in der Frühphase von Dusk also ein kryptografisches Gegenmittel gegen solche gezielten Angriffe.
Doch heute beschreibt die offizielle Dusk-Dokumentation für den Mainnet-Konsens Succinct Attestation: ein Proof-of-Stake-Design auf Basis eines Komitees. Dabei werden über ein deterministisches Auswahlverfahren Kandidaten und das Abstimmungs-Komitee durch einen „provisioner“ bestimmt – im gesamten Ablauf wird nicht mehr das Konzept „anonyme Teilnahme“ erwähnt. Anders gesagt: Im Übergang vom frühen Design hin zur Mainnet-Implementierung hat Dusk stillschweigend das Merkmal „Anonymität der Block-Ersteller-Identität“ ersetzt – hin zu einem stärker effizienz- und determinismusorientierten Komitee-Mechanismus.
Diese Änderung wurde nicht groß angekündigt, hat aber dennoch erhebliche Bedeutung: Das Problem, das Proof of Blind Bid in der Frühphase lösen wollte („gezielte Angriffe verhindern“), wird bei Succinct Attestation mit einem anderen Ansatz angegangen – es wird stärker auf die Größe des Komitees und die Unvorhersehbarkeit der Wahlen gesetzt, statt die Identität komplett im Verborgenen zu halten. Für mich ist das eine Erinnerung: Bei der Bewertung eines Projekts darf man sich nicht allein auf ein paar Jahre alte Artikel als Grundlage stützen. Auch bei Dusk iteriert der Kernmechanismus kontinuierlich. Das anonyme Kandidaten-Konzept, das sich damals so cool anhörte, könnte in der Praxis heute schlicht nicht mehr so umgesetzt sein.
In den frühen Versionen des Dusk-Whitepapers ist Proof of Blind Bid tatsächlich ein durchdachtes Design: Block-Erstellungskandidaten (Block Generator) reichen eine „Bid Transaction“ ein, in der sie ihre Einsatzsumme in einen Poseidon-Baum speichern und einen passenden Zero-Knowledge-Beweis generieren. Der gesamte Auswahlprozess bleibt nach außen hin unsichtbar: Niemand kann sehen, wer teilnimmt oder wie viel eingesetzt wird. Die Intention dahinter war sehr praxisnah – wenn Identität und Einsatzsumme öffentlich wären, bekämen Angreifer im Grunde eine „Liste der bevorzugten Ziele“, um gezielte Angriffe auf bekannte, große Block-Ersteller zu starten. Anonyme Teilnahme war in der Frühphase von Dusk also ein kryptografisches Gegenmittel gegen solche gezielten Angriffe.
Doch heute beschreibt die offizielle Dusk-Dokumentation für den Mainnet-Konsens Succinct Attestation: ein Proof-of-Stake-Design auf Basis eines Komitees. Dabei werden über ein deterministisches Auswahlverfahren Kandidaten und das Abstimmungs-Komitee durch einen „provisioner“ bestimmt – im gesamten Ablauf wird nicht mehr das Konzept „anonyme Teilnahme“ erwähnt. Anders gesagt: Im Übergang vom frühen Design hin zur Mainnet-Implementierung hat Dusk stillschweigend das Merkmal „Anonymität der Block-Ersteller-Identität“ ersetzt – hin zu einem stärker effizienz- und determinismusorientierten Komitee-Mechanismus.
Diese Änderung wurde nicht groß angekündigt, hat aber dennoch erhebliche Bedeutung: Das Problem, das Proof of Blind Bid in der Frühphase lösen wollte („gezielte Angriffe verhindern“), wird bei Succinct Attestation mit einem anderen Ansatz angegangen – es wird stärker auf die Größe des Komitees und die Unvorhersehbarkeit der Wahlen gesetzt, statt die Identität komplett im Verborgenen zu halten. Für mich ist das eine Erinnerung: Bei der Bewertung eines Projekts darf man sich nicht allein auf ein paar Jahre alte Artikel als Grundlage stützen. Auch bei Dusk iteriert der Kernmechanismus kontinuierlich. Das anonyme Kandidaten-Konzept, das sich damals so cool anhörte, könnte in der Praxis heute schlicht nicht mehr so umgesetzt sein.
2
1
141
·
--
Endlich ist es soweit: $ALIGN TGE
Heute um 23:00 Uhr Pekinger Zeit startet Aligned sein TGE.
Als Projekt, das sich auf ZK- Proof-Verifizierung und eine Ethereum-wertifizierbare Recheninfrastruktur spezialisiert hat, sind die Produktaufbauten von Aligned bisher recht solide.
Wir freuen uns auf die heutige Performance und darauf, dass sich das Aligned-Ökosystem weiter ausdehnt.
Und mit den geplanten Listings bei Börsen wie Coinbase hoffe ich, dass wir auch etwas vom Kuchen abbekommen
$ALIGN 🚀
Endlich ist es soweit: $ALIGN TGE
Heute um 23:00 Uhr Pekinger Zeit startet Aligned sein TGE.
Als Projekt, das sich auf ZK- Proof-Verifizierung und eine Ethereum-wertifizierbare Recheninfrastruktur spezialisiert hat, sind die Produktaufbauten von Aligned bisher recht solide.
Wir freuen uns auf die heutige Performance und darauf, dass sich das Aligned-Ökosystem weiter ausdehnt.
Und mit den geplanten Listings bei Börsen wie Coinbase hoffe ich, dass wir auch etwas vom Kuchen abbekommen
$ALIGN 🚀
Heute um 23:00 Uhr Pekinger Zeit startet Aligned sein TGE.
Als Projekt, das sich auf ZK- Proof-Verifizierung und eine Ethereum-wertifizierbare Recheninfrastruktur spezialisiert hat, sind die Produktaufbauten von Aligned bisher recht solide.
Wir freuen uns auf die heutige Performance und darauf, dass sich das Aligned-Ökosystem weiter ausdehnt.
Und mit den geplanten Listings bei Börsen wie Coinbase hoffe ich, dass wir auch etwas vom Kuchen abbekommen
$ALIGN 🚀
1
1.3k
·
--
#dusk $DUSK @Dusk_Foundation Seit jeher war mein Verständnis von Phoenix: „Das ist die Dusk-Version von Zcash/Monero“ – ein Modell für Privacy-Transaktionen mit dem Ziel vollständiger Anonymität, bei dem beide Übertragungsparteien einander nicht sehen können. Erst als ich die offiziellen Hinweise im aktualisierten Whitepaper von 2024 im Abgleich dazu gelesen habe, wurde mir klar, dass dieses Verständnis längst veraltet ist.
In den Aktualisierungsnotizen steht das sehr deutlich: Sie haben Phoenix um die Fähigkeit erweitert, „dass der Empfänger die Identität des Absenders erkennen kann“, und ausdrücklich gesagt, dass sie Phoenix damit von einem Anonymity-Protocol (anonymes Protokoll) zu einem Privacy-Preserving-Protocol (datenschutzfreundliches Protokoll) umgebaut haben – mit dem Ziel, die aktuellen europäischen regulatorischen Anforderungen zu erfüllen. In derselben Mitteilung wird auch erwähnt, dass der direkte Anstoß für die Integration von Moonlight (dem transparenten Kontomodell) ebenfalls daher kam, dass das Team erkannte: Wenn man eine reibungslose Anbindung an Börsen und Institutionen schaffen will, reicht ein rein anonymes Kontomodell nicht aus – sie schreiben sogar ganz offen, dass der Zweck darin besteht, „die Einhaltung zu gewährleisten und das Risiko der Entfernung von Plattformen zu eliminieren“.
Dieser Umschwung ist meiner Meinung nach größer, als die meisten denken. „Anonymität“ und „Privatsphäre“ sind in der Kryptografie-Community keine Synonyme: Anonyme Protokolle wollen sicherstellen, dass kein Dritter (einschließlich des Empfängers) bestimmen kann, wer der Absender ist; Privacy-Preserving-Protokolle garantieren dagegen nur, dass Außenstehende die Details nicht sehen können – die Erkennbarkeit zwischen den Transaktionsparteien kann erhalten bleiben und sogar bewusst so gestaltet werden. Dusk gibt das Erstere aktiv auf und wählt das Letztere. Das ist keine technische Kompromisslösung, sondern eine sehr klare Anpassung der Produktpositionierung: In den frühen Whitepapern war die Ambition von Phoenix näher an einer reinen Privacy-Coin-Vorstellung – später wurde sie dann direkt von der Realität der Compliance in eine andere Richtung gezogen.
Früher dachte ich, „Anonymität“ sei der wichtigste Verkaufsargument von Phoenix. Wenn ich jetzt zurückblicke, war dieses Verständnis selbst genau dadurch falsch, dass ich ein veraltetes altes Whitepaper benutzt habe, um ein bereits weiterentwickeltes Protokoll zu bewerten. Für diejenigen, die es weiterhin unter dem Rahmen „Ist Dusk eine anonyme Coin?“ beurteilen, könnte die Frage selbst bereits an der falschen Stelle ansetzen – die eigentliche Frage lautet vielmehr: Unter der Prämisse „Der Empfänger kann den Absender identifizieren“ – wo genau liegt die verbleibende Privacy-Grenze bei Phoenix, und trägt diese Grenze aus, was es für die Compliance-Szenarien leisten will, die es bedienen möchte.
#dusk $DUSK @Dusk Seit jeher war mein Verständnis von Phoenix: „Das ist die Dusk-Version von Zcash/Monero“ – ein Modell für Privacy-Transaktionen mit dem Ziel vollständiger Anonymität, bei dem beide Übertragungsparteien einander nicht sehen können. Erst als ich die offiziellen Hinweise im aktualisierten Whitepaper von 2024 im Abgleich dazu gelesen habe, wurde mir klar, dass dieses Verständnis längst veraltet ist.
In den Aktualisierungsnotizen steht das sehr deutlich: Sie haben Phoenix um die Fähigkeit erweitert, „dass der Empfänger die Identität des Absenders erkennen kann“, und ausdrücklich gesagt, dass sie Phoenix damit von einem Anonymity-Protocol (anonymes Protokoll) zu einem Privacy-Preserving-Protocol (datenschutzfreundliches Protokoll) umgebaut haben – mit dem Ziel, die aktuellen europäischen regulatorischen Anforderungen zu erfüllen. In derselben Mitteilung wird auch erwähnt, dass der direkte Anstoß für die Integration von Moonlight (dem transparenten Kontomodell) ebenfalls daher kam, dass das Team erkannte: Wenn man eine reibungslose Anbindung an Börsen und Institutionen schaffen will, reicht ein rein anonymes Kontomodell nicht aus – sie schreiben sogar ganz offen, dass der Zweck darin besteht, „die Einhaltung zu gewährleisten und das Risiko der Entfernung von Plattformen zu eliminieren“.
Dieser Umschwung ist meiner Meinung nach größer, als die meisten denken. „Anonymität“ und „Privatsphäre“ sind in der Kryptografie-Community keine Synonyme: Anonyme Protokolle wollen sicherstellen, dass kein Dritter (einschließlich des Empfängers) bestimmen kann, wer der Absender ist; Privacy-Preserving-Protokolle garantieren dagegen nur, dass Außenstehende die Details nicht sehen können – die Erkennbarkeit zwischen den Transaktionsparteien kann erhalten bleiben und sogar bewusst so gestaltet werden. Dusk gibt das Erstere aktiv auf und wählt das Letztere. Das ist keine technische Kompromisslösung, sondern eine sehr klare Anpassung der Produktpositionierung: In den frühen Whitepapern war die Ambition von Phoenix näher an einer reinen Privacy-Coin-Vorstellung – später wurde sie dann direkt von der Realität der Compliance in eine andere Richtung gezogen.
Früher dachte ich, „Anonymität“ sei der wichtigste Verkaufsargument von Phoenix. Wenn ich jetzt zurückblicke, war dieses Verständnis selbst genau dadurch falsch, dass ich ein veraltetes altes Whitepaper benutzt habe, um ein bereits weiterentwickeltes Protokoll zu bewerten. Für diejenigen, die es weiterhin unter dem Rahmen „Ist Dusk eine anonyme Coin?“ beurteilen, könnte die Frage selbst bereits an der falschen Stelle ansetzen – die eigentliche Frage lautet vielmehr: Unter der Prämisse „Der Empfänger kann den Absender identifizieren“ – wo genau liegt die verbleibende Privacy-Grenze bei Phoenix, und trägt diese Grenze aus, was es für die Compliance-Szenarien leisten will, die es bedienen möchte.
In den Aktualisierungsnotizen steht das sehr deutlich: Sie haben Phoenix um die Fähigkeit erweitert, „dass der Empfänger die Identität des Absenders erkennen kann“, und ausdrücklich gesagt, dass sie Phoenix damit von einem Anonymity-Protocol (anonymes Protokoll) zu einem Privacy-Preserving-Protocol (datenschutzfreundliches Protokoll) umgebaut haben – mit dem Ziel, die aktuellen europäischen regulatorischen Anforderungen zu erfüllen. In derselben Mitteilung wird auch erwähnt, dass der direkte Anstoß für die Integration von Moonlight (dem transparenten Kontomodell) ebenfalls daher kam, dass das Team erkannte: Wenn man eine reibungslose Anbindung an Börsen und Institutionen schaffen will, reicht ein rein anonymes Kontomodell nicht aus – sie schreiben sogar ganz offen, dass der Zweck darin besteht, „die Einhaltung zu gewährleisten und das Risiko der Entfernung von Plattformen zu eliminieren“.
Dieser Umschwung ist meiner Meinung nach größer, als die meisten denken. „Anonymität“ und „Privatsphäre“ sind in der Kryptografie-Community keine Synonyme: Anonyme Protokolle wollen sicherstellen, dass kein Dritter (einschließlich des Empfängers) bestimmen kann, wer der Absender ist; Privacy-Preserving-Protokolle garantieren dagegen nur, dass Außenstehende die Details nicht sehen können – die Erkennbarkeit zwischen den Transaktionsparteien kann erhalten bleiben und sogar bewusst so gestaltet werden. Dusk gibt das Erstere aktiv auf und wählt das Letztere. Das ist keine technische Kompromisslösung, sondern eine sehr klare Anpassung der Produktpositionierung: In den frühen Whitepapern war die Ambition von Phoenix näher an einer reinen Privacy-Coin-Vorstellung – später wurde sie dann direkt von der Realität der Compliance in eine andere Richtung gezogen.
Früher dachte ich, „Anonymität“ sei der wichtigste Verkaufsargument von Phoenix. Wenn ich jetzt zurückblicke, war dieses Verständnis selbst genau dadurch falsch, dass ich ein veraltetes altes Whitepaper benutzt habe, um ein bereits weiterentwickeltes Protokoll zu bewerten. Für diejenigen, die es weiterhin unter dem Rahmen „Ist Dusk eine anonyme Coin?“ beurteilen, könnte die Frage selbst bereits an der falschen Stelle ansetzen – die eigentliche Frage lautet vielmehr: Unter der Prämisse „Der Empfänger kann den Absender identifizieren“ – wo genau liegt die verbleibende Privacy-Grenze bei Phoenix, und trägt diese Grenze aus, was es für die Compliance-Szenarien leisten will, die es bedienen möchte.
2
1
436
·
--
#termmax @termmax TermMax verwandelt jede Hebel-Position in ein GT – also in einen ERC-721. Als ich dieses Design das erste Mal gesehen habe, habe ich mir nicht viel dabei gedacht, bis mir klar wurde: NFTs sind übertragbar. Das bedeutet eine „Position mit Schulden“, die theoretisch an eine andere Person verkauft werden kann.
Bei einer normalen Hebel-Position sind Risiko und Rendite direkt an die Person gebunden, die die Position eröffnet hat: Wenn es schiefgeht, trägt es der Eröffner selbst; wenn es gut läuft, bekommt er selbst die Gewinne. GT trennt das voneinander. Wenn ein GT auf dem Sekundärmarkt gehandelt werden kann, kauft der Käufer nicht eine „fest definierte Vermögensposition“, sondern eine „zum aktuellen Zeitpunkt bestehende Beleihungsquote + das zukünftige Liquidationsrisiko“. Wer bereit ist, den Posten „zu übernehmen“, bewertet im Grunde genommen den aktuellen Gesundheitszustand dieser Position – das ist im Wesen nicht anders als der Kauf einer rabattierten Schuldverschreibung, nur dass Sicherheiten und Hebelstruktur bei GT deutlich komplexer sind.
Wenn das TermMax-Design tatsächlich funktioniert, würde es eine neue Art des Handels schaffen: Jemand kauft gezielt GTs zu niedrigeren Preisen, deren LTV bereits zu hoch ist, aber die LLTV-Grenze noch nicht ausgelöst haben – mit der Wette, vor der Liquidationslinie einen neuen Käufer zu finden; oder mit der Wette, dass er die Position besser managen kann als der ursprüngliche Inhaber. Das klingt so, als würde man das Risiko an professionellere Übernehmer delegieren, kann aber auch einfach nur bedeuten, dass das Liquidationsrisiko von einer unprofessionellen Person auf eine andere unprofessionelle Person übertragen wird – nur eben auf jemanden, der eher wagt. Das Protokoll selbst wird nicht automatisch sicherer, nur weil das GT einen neuen Eigentümer hat.
Was ich eigentlich herausfinden möchte, ist: Gibt es auf dem Sekundärmarkt von GTs bereits echte Umschlag- bzw. Weiterverkaufsaufzeichnungen? Ist die Information über den aktuellen Beleihungsstatus zwischen Käufer und Verkäufer beim Weiterverkauf symmetrisch, oder bleibt diese „Übertragbarkeit“ bisher nur auf der Ebene des Vertrags bestehen und wird in der Praxis tatsächlich nicht so genutzt. Ob eine TermMax-Position gehandelt werden kann, und ob sie tatsächlich gehandelt wird, sind zwei völlig unterschiedliche Dinge.
#termmax @TermMax TermMax verwandelt jede Hebel-Position in ein GT – also in einen ERC-721. Als ich dieses Design das erste Mal gesehen habe, habe ich mir nicht viel dabei gedacht, bis mir klar wurde: NFTs sind übertragbar. Das bedeutet eine „Position mit Schulden“, die theoretisch an eine andere Person verkauft werden kann.
Bei einer normalen Hebel-Position sind Risiko und Rendite direkt an die Person gebunden, die die Position eröffnet hat: Wenn es schiefgeht, trägt es der Eröffner selbst; wenn es gut läuft, bekommt er selbst die Gewinne. GT trennt das voneinander. Wenn ein GT auf dem Sekundärmarkt gehandelt werden kann, kauft der Käufer nicht eine „fest definierte Vermögensposition“, sondern eine „zum aktuellen Zeitpunkt bestehende Beleihungsquote + das zukünftige Liquidationsrisiko“. Wer bereit ist, den Posten „zu übernehmen“, bewertet im Grunde genommen den aktuellen Gesundheitszustand dieser Position – das ist im Wesen nicht anders als der Kauf einer rabattierten Schuldverschreibung, nur dass Sicherheiten und Hebelstruktur bei GT deutlich komplexer sind.
Wenn das TermMax-Design tatsächlich funktioniert, würde es eine neue Art des Handels schaffen: Jemand kauft gezielt GTs zu niedrigeren Preisen, deren LTV bereits zu hoch ist, aber die LLTV-Grenze noch nicht ausgelöst haben – mit der Wette, vor der Liquidationslinie einen neuen Käufer zu finden; oder mit der Wette, dass er die Position besser managen kann als der ursprüngliche Inhaber. Das klingt so, als würde man das Risiko an professionellere Übernehmer delegieren, kann aber auch einfach nur bedeuten, dass das Liquidationsrisiko von einer unprofessionellen Person auf eine andere unprofessionelle Person übertragen wird – nur eben auf jemanden, der eher wagt. Das Protokoll selbst wird nicht automatisch sicherer, nur weil das GT einen neuen Eigentümer hat.
Was ich eigentlich herausfinden möchte, ist: Gibt es auf dem Sekundärmarkt von GTs bereits echte Umschlag- bzw. Weiterverkaufsaufzeichnungen? Ist die Information über den aktuellen Beleihungsstatus zwischen Käufer und Verkäufer beim Weiterverkauf symmetrisch, oder bleibt diese „Übertragbarkeit“ bisher nur auf der Ebene des Vertrags bestehen und wird in der Praxis tatsächlich nicht so genutzt. Ob eine TermMax-Position gehandelt werden kann, und ob sie tatsächlich gehandelt wird, sind zwei völlig unterschiedliche Dinge.
Bei einer normalen Hebel-Position sind Risiko und Rendite direkt an die Person gebunden, die die Position eröffnet hat: Wenn es schiefgeht, trägt es der Eröffner selbst; wenn es gut läuft, bekommt er selbst die Gewinne. GT trennt das voneinander. Wenn ein GT auf dem Sekundärmarkt gehandelt werden kann, kauft der Käufer nicht eine „fest definierte Vermögensposition“, sondern eine „zum aktuellen Zeitpunkt bestehende Beleihungsquote + das zukünftige Liquidationsrisiko“. Wer bereit ist, den Posten „zu übernehmen“, bewertet im Grunde genommen den aktuellen Gesundheitszustand dieser Position – das ist im Wesen nicht anders als der Kauf einer rabattierten Schuldverschreibung, nur dass Sicherheiten und Hebelstruktur bei GT deutlich komplexer sind.
Wenn das TermMax-Design tatsächlich funktioniert, würde es eine neue Art des Handels schaffen: Jemand kauft gezielt GTs zu niedrigeren Preisen, deren LTV bereits zu hoch ist, aber die LLTV-Grenze noch nicht ausgelöst haben – mit der Wette, vor der Liquidationslinie einen neuen Käufer zu finden; oder mit der Wette, dass er die Position besser managen kann als der ursprüngliche Inhaber. Das klingt so, als würde man das Risiko an professionellere Übernehmer delegieren, kann aber auch einfach nur bedeuten, dass das Liquidationsrisiko von einer unprofessionellen Person auf eine andere unprofessionelle Person übertragen wird – nur eben auf jemanden, der eher wagt. Das Protokoll selbst wird nicht automatisch sicherer, nur weil das GT einen neuen Eigentümer hat.
Was ich eigentlich herausfinden möchte, ist: Gibt es auf dem Sekundärmarkt von GTs bereits echte Umschlag- bzw. Weiterverkaufsaufzeichnungen? Ist die Information über den aktuellen Beleihungsstatus zwischen Käufer und Verkäufer beim Weiterverkauf symmetrisch, oder bleibt diese „Übertragbarkeit“ bisher nur auf der Ebene des Vertrags bestehen und wird in der Praxis tatsächlich nicht so genutzt. Ob eine TermMax-Position gehandelt werden kann, und ob sie tatsächlich gehandelt wird, sind zwei völlig unterschiedliche Dinge.
2
1
1.1k
·
--
#dusk $DUSK @Dusk_Foundation Seit langem sehe ich mir die Erklärung zur Token-Ökonomie von Dusk an, und immer wieder taucht ein Satz auf: „500 Mio. DUSK werden über 36 Jahre schrittweise an Staker freigegeben.“ Dieser Satz klingt so, als würde er eine extrem gleichmäßige, beinahe nicht spürbare Entlastungskurve in Bezug auf Inflationsdruck beschreiben. Ich habe es früher genauso verstanden – bis ich es selbst anhand der Parameter aus den offiziellen Dokumenten einmal ausgerechnet habe und gemerkt habe: Es ist nicht ganz so einfach.
Die maximale Gesamtmenge von Dusk beträgt 1 Milliarde Coins. Davon sind 500 Mio. bereits vor dem Mainnet-Launch in den Umlauf gelangt. Die verbleibenden 500 Mio. werden dann nach einem geometrischen Abklingmodell über 36 Jahre an Staker freigegeben, wobei die Abklingrate alle 4 Jahre halbiert wird. Dieses „alle 4 Jahre halbieren“ ist die entscheidende Information – wenn man die gesamte Abklingsequenz als geometrische Reihe entfaltet, entspricht das in etwa dem, was im ersten 4-Jahres-Zyklus freigegeben wird: grob so viel wie die Hälfte der verbleibenden 500 Mio., also ungefähr 250 Mio. Grob umgerechnet liegt die durchschnittliche jährliche Freigabemenge in den ersten 4 Jahren bei mehr als dem Vierfachen der „durchschnittlichen Inflationsrate“, die man erhielte, wenn man einfach 500 Mio. gleichmäßig auf 36 Jahre verteilen würde.
Das heißt: „36 Jahre langsame Freigabe“ sagt für sich genommen nicht die Unwahrheit, aber es verleitet leicht zu der stillen Annahme, „die Emissionsgeschwindigkeit pro Jahr ist ungefähr gleich und sehr glatt“. In Wahrheit ist der Emissionsdruck in den ersten Jahren deutlich stärker gebündelt: Nach jedem weiteren 4-Jahres-Zyklus wird die Freigabegeschwindigkeit jeweils halbiert, also fällt die Kurve steil ab – keine gerade, flache Linie. Für die realistische Erwartung an die Staking-Rendite ist dieser Unterschied kein unwichtiges Detail: Wer früh am Staking teilnimmt, bekommt den Belohnungstopf der Phase mit der schnellsten Freigabegeschwindigkeit. Je weiter man später einsteigt, desto dünner wird der Anteil an neu ausgegebenen Beträgen, die man noch abgreifen kann.
Ich halte das nicht für einen Designfehler. Geometrisches Abklingen ist ein gängiges Vorgehen in vielen PoS-Netzwerken, um in der frühen Phase genug Anreize zu geben und das Validator-Netzwerk hochzuziehen, bevor man die Inflation im Verlauf schrittweise wieder begrenzt. Aber wenn man nur die Zahl „36 Jahre“ betrachtet und davon ausgeht, dass der Inflationsdruck gleichmäßig verteilt ist, übersieht man die Realität. Mein nächster Beobachtungspunkt ist daher: ab 2026 bis in die Nähe des ersten 4-Jahres-Abkling-Knotens zählen und die tatsächlichen On-Chain-Daten zur Ausschüttung von Staking-Belohnungen prüfen – ob sie mit der theoretischen Kurve dieses geometrischen Modells übereinstimmen. Wenn ja, spricht das dafür, dass das Team das wirtschaftliche Modell aus dem Whitepaper stabil umsetzt. Wenn es Abweichungen gibt, ist das ein anderes Signal, das neu bewertet werden muss.
#dusk $DUSK @Dusk Seit langem sehe ich mir die Erklärung zur Token-Ökonomie von Dusk an, und immer wieder taucht ein Satz auf: „500 Mio. DUSK werden über 36 Jahre schrittweise an Staker freigegeben.“ Dieser Satz klingt so, als würde er eine extrem gleichmäßige, beinahe nicht spürbare Entlastungskurve in Bezug auf Inflationsdruck beschreiben. Ich habe es früher genauso verstanden – bis ich es selbst anhand der Parameter aus den offiziellen Dokumenten einmal ausgerechnet habe und gemerkt habe: Es ist nicht ganz so einfach.
Die maximale Gesamtmenge von Dusk beträgt 1 Milliarde Coins. Davon sind 500 Mio. bereits vor dem Mainnet-Launch in den Umlauf gelangt. Die verbleibenden 500 Mio. werden dann nach einem geometrischen Abklingmodell über 36 Jahre an Staker freigegeben, wobei die Abklingrate alle 4 Jahre halbiert wird. Dieses „alle 4 Jahre halbieren“ ist die entscheidende Information – wenn man die gesamte Abklingsequenz als geometrische Reihe entfaltet, entspricht das in etwa dem, was im ersten 4-Jahres-Zyklus freigegeben wird: grob so viel wie die Hälfte der verbleibenden 500 Mio., also ungefähr 250 Mio. Grob umgerechnet liegt die durchschnittliche jährliche Freigabemenge in den ersten 4 Jahren bei mehr als dem Vierfachen der „durchschnittlichen Inflationsrate“, die man erhielte, wenn man einfach 500 Mio. gleichmäßig auf 36 Jahre verteilen würde.
Das heißt: „36 Jahre langsame Freigabe“ sagt für sich genommen nicht die Unwahrheit, aber es verleitet leicht zu der stillen Annahme, „die Emissionsgeschwindigkeit pro Jahr ist ungefähr gleich und sehr glatt“. In Wahrheit ist der Emissionsdruck in den ersten Jahren deutlich stärker gebündelt: Nach jedem weiteren 4-Jahres-Zyklus wird die Freigabegeschwindigkeit jeweils halbiert, also fällt die Kurve steil ab – keine gerade, flache Linie. Für die realistische Erwartung an die Staking-Rendite ist dieser Unterschied kein unwichtiges Detail: Wer früh am Staking teilnimmt, bekommt den Belohnungstopf der Phase mit der schnellsten Freigabegeschwindigkeit. Je weiter man später einsteigt, desto dünner wird der Anteil an neu ausgegebenen Beträgen, die man noch abgreifen kann.
Ich halte das nicht für einen Designfehler. Geometrisches Abklingen ist ein gängiges Vorgehen in vielen PoS-Netzwerken, um in der frühen Phase genug Anreize zu geben und das Validator-Netzwerk hochzuziehen, bevor man die Inflation im Verlauf schrittweise wieder begrenzt. Aber wenn man nur die Zahl „36 Jahre“ betrachtet und davon ausgeht, dass der Inflationsdruck gleichmäßig verteilt ist, übersieht man die Realität. Mein nächster Beobachtungspunkt ist daher: ab 2026 bis in die Nähe des ersten 4-Jahres-Abkling-Knotens zählen und die tatsächlichen On-Chain-Daten zur Ausschüttung von Staking-Belohnungen prüfen – ob sie mit der theoretischen Kurve dieses geometrischen Modells übereinstimmen. Wenn ja, spricht das dafür, dass das Team das wirtschaftliche Modell aus dem Whitepaper stabil umsetzt. Wenn es Abweichungen gibt, ist das ein anderes Signal, das neu bewertet werden muss.
Die maximale Gesamtmenge von Dusk beträgt 1 Milliarde Coins. Davon sind 500 Mio. bereits vor dem Mainnet-Launch in den Umlauf gelangt. Die verbleibenden 500 Mio. werden dann nach einem geometrischen Abklingmodell über 36 Jahre an Staker freigegeben, wobei die Abklingrate alle 4 Jahre halbiert wird. Dieses „alle 4 Jahre halbieren“ ist die entscheidende Information – wenn man die gesamte Abklingsequenz als geometrische Reihe entfaltet, entspricht das in etwa dem, was im ersten 4-Jahres-Zyklus freigegeben wird: grob so viel wie die Hälfte der verbleibenden 500 Mio., also ungefähr 250 Mio. Grob umgerechnet liegt die durchschnittliche jährliche Freigabemenge in den ersten 4 Jahren bei mehr als dem Vierfachen der „durchschnittlichen Inflationsrate“, die man erhielte, wenn man einfach 500 Mio. gleichmäßig auf 36 Jahre verteilen würde.
Das heißt: „36 Jahre langsame Freigabe“ sagt für sich genommen nicht die Unwahrheit, aber es verleitet leicht zu der stillen Annahme, „die Emissionsgeschwindigkeit pro Jahr ist ungefähr gleich und sehr glatt“. In Wahrheit ist der Emissionsdruck in den ersten Jahren deutlich stärker gebündelt: Nach jedem weiteren 4-Jahres-Zyklus wird die Freigabegeschwindigkeit jeweils halbiert, also fällt die Kurve steil ab – keine gerade, flache Linie. Für die realistische Erwartung an die Staking-Rendite ist dieser Unterschied kein unwichtiges Detail: Wer früh am Staking teilnimmt, bekommt den Belohnungstopf der Phase mit der schnellsten Freigabegeschwindigkeit. Je weiter man später einsteigt, desto dünner wird der Anteil an neu ausgegebenen Beträgen, die man noch abgreifen kann.
Ich halte das nicht für einen Designfehler. Geometrisches Abklingen ist ein gängiges Vorgehen in vielen PoS-Netzwerken, um in der frühen Phase genug Anreize zu geben und das Validator-Netzwerk hochzuziehen, bevor man die Inflation im Verlauf schrittweise wieder begrenzt. Aber wenn man nur die Zahl „36 Jahre“ betrachtet und davon ausgeht, dass der Inflationsdruck gleichmäßig verteilt ist, übersieht man die Realität. Mein nächster Beobachtungspunkt ist daher: ab 2026 bis in die Nähe des ersten 4-Jahres-Abkling-Knotens zählen und die tatsächlichen On-Chain-Daten zur Ausschüttung von Staking-Belohnungen prüfen – ob sie mit der theoretischen Kurve dieses geometrischen Modells übereinstimmen. Wenn ja, spricht das dafür, dass das Team das wirtschaftliche Modell aus dem Whitepaper stabil umsetzt. Wenn es Abweichungen gibt, ist das ein anderes Signal, das neu bewertet werden muss.
2
130
Anmelden und weiter Inhalte entdecken
Krypto-Nutzer weltweit auf Binance Square kennenlernen
⚡️ Bleib in Sachen Krypto stets am Puls.
💬 Die weltgrößte Kryptobörse vertraut darauf.
👍 Erhalte verlässliche Einblicke von verifizierten Creators.
E-Mail-Adresse/Telefonnummer
Trendthemen
CanMicrosoftDeliverOnAI
499,742 Aufrufe
3,436 Kommentare
Berichtssaison, Session 3: Übertreffen Google und Microsoft die Gewinnerwartungen?
Binance Square Official
·150 Likes
·83.3k Aufrufe
CanGoogleDefindItsCore
305,144 Aufrufe
2,427 Kommentare
EarningsSeason
6M Aufrufe
29,578 Kommentare