Gestern hatte ich eigentlich vor, aufzugeben, aber ich habe es trotzdem versucht, die Knoten-Konfiguration für @Dusk in einer lokalen Umgebung zum Laufen zu bringen. Beim Kompilieren des rusk`-Kern-Repository für das Testnetz blieb ich jedoch bei einem Vergleichs-Log in einem Konsens-Status hängen.
Dann bin ich in das Node-Staking-Handling im consensus/staking-Modul eingetaucht und habe dabei einen ziemlich interessanten Variablennamen entdeckt: AttestationCapacity. Sofort war ich neugierig.
Ich dachte zuerst, das sei nur ein normales Feld, das die Menge der gesperrten Tokens des Knotens protokolliert. Aber als ich der Aufrufkette weiter in rewards_emission.rs folgte, stellte sich heraus, dass Dusk im Kern eine ziemlich harte Strategie zur Bindung von Rechenleistung fährt.
Auf den meisten PoS-Ketten in der Vergangenheit sind die Node-Erträge komplett ein „Kapitalspiel“. Was heißt das? Du kaufst viele Coins, sperrst sie lange, und bekommst entsprechend mehr Inflationsbelohnungen. Selbst wenn der Knoten-Server nur mit einem Raspberry Pi läuft, interessiert sich niemand dafür. Aber bei Dusk bindet der Code die Staking-Erträge des Knotens direkt an die Antwortlatenz der ZK-Berechnung der Piecrust-VM.
Wenn ein Knoten nur viel Guthaben hat, aber in der vorherigen SA-Konsensrunde beim Verarbeiten von Poseidon-Hashes oder beim Validieren von Plonk-Proofs um eine halbe „Taktlücke“ hinterherhinkt, dann reduziert der Dämpfungsalgorithmus im System direkt die dynamische Gewichtung seiner AttestationCapacity. Mit anderen Worten: Wer „hängt“ und die Rechenleistung nicht bringt, dem zieht das System die Rendite zwangsweise ab.
Eine weitere sehr interessante Gestaltung ist die Logik zum Gas-Burn. Im Transaktionsgebühren-Modul fee_collector ist die Base Fee jeder konformen Transaktion auf Protokollebene fest verankert und wird verbrannt; nur die Priority Fee wird nach Gewicht an die tatsächlich an der ZK-Verifikation beteiligten Knoten mit Rechenleistung verteilt.
Ich habe die Rechenleistungs-Logs aus dem Testnetz herangezogen und grob abgeschätzt: Wenn das Layer-übergreifende RWA-Asset-Settlement eine bestimmte Transaktionsfrequenz erreicht, dann kann die Burn-Rate des Basis-Gas die System-Blockbelohnung durch Inflationsausschüttungen schnell überholen.
Es wird nicht mit irgendeinem „Super-Deflations-Konzept“ spekuliert, sondern ganz unten im Code werden „Rechenleistungsbeitrag“, „Staking-Verteilung“ und „Gas-Burn“ als ein dreieckiges Modell umgesetzt, das sich gegenseitig einschränkt. An Konsens teilzunehmen heißt nicht, einfach Wasser abzuzapfen, sondern die echte Hardware-Rechenleistung muss auf die Kette gebracht werden. Und all diese Erträge sind vollständig an $DUSK verankert.
#dusk
Dann bin ich in das Node-Staking-Handling im consensus/staking-Modul eingetaucht und habe dabei einen ziemlich interessanten Variablennamen entdeckt: AttestationCapacity. Sofort war ich neugierig.
Ich dachte zuerst, das sei nur ein normales Feld, das die Menge der gesperrten Tokens des Knotens protokolliert. Aber als ich der Aufrufkette weiter in rewards_emission.rs folgte, stellte sich heraus, dass Dusk im Kern eine ziemlich harte Strategie zur Bindung von Rechenleistung fährt.
Auf den meisten PoS-Ketten in der Vergangenheit sind die Node-Erträge komplett ein „Kapitalspiel“. Was heißt das? Du kaufst viele Coins, sperrst sie lange, und bekommst entsprechend mehr Inflationsbelohnungen. Selbst wenn der Knoten-Server nur mit einem Raspberry Pi läuft, interessiert sich niemand dafür. Aber bei Dusk bindet der Code die Staking-Erträge des Knotens direkt an die Antwortlatenz der ZK-Berechnung der Piecrust-VM.
Wenn ein Knoten nur viel Guthaben hat, aber in der vorherigen SA-Konsensrunde beim Verarbeiten von Poseidon-Hashes oder beim Validieren von Plonk-Proofs um eine halbe „Taktlücke“ hinterherhinkt, dann reduziert der Dämpfungsalgorithmus im System direkt die dynamische Gewichtung seiner AttestationCapacity. Mit anderen Worten: Wer „hängt“ und die Rechenleistung nicht bringt, dem zieht das System die Rendite zwangsweise ab.
Eine weitere sehr interessante Gestaltung ist die Logik zum Gas-Burn. Im Transaktionsgebühren-Modul fee_collector ist die Base Fee jeder konformen Transaktion auf Protokollebene fest verankert und wird verbrannt; nur die Priority Fee wird nach Gewicht an die tatsächlich an der ZK-Verifikation beteiligten Knoten mit Rechenleistung verteilt.
Ich habe die Rechenleistungs-Logs aus dem Testnetz herangezogen und grob abgeschätzt: Wenn das Layer-übergreifende RWA-Asset-Settlement eine bestimmte Transaktionsfrequenz erreicht, dann kann die Burn-Rate des Basis-Gas die System-Blockbelohnung durch Inflationsausschüttungen schnell überholen.
Es wird nicht mit irgendeinem „Super-Deflations-Konzept“ spekuliert, sondern ganz unten im Code werden „Rechenleistungsbeitrag“, „Staking-Verteilung“ und „Gas-Burn“ als ein dreieckiges Modell umgesetzt, das sich gegenseitig einschränkt. An Konsens teilzunehmen heißt nicht, einfach Wasser abzuzapfen, sondern die echte Hardware-Rechenleistung muss auf die Kette gebracht werden. Und all diese Erträge sind vollständig an $DUSK verankert.
#dusk