Ich habe die „Economic Protocol“-Erklärung zu @Dusk zurückverfolgt und erst dann verstanden: „Der Vertrag zahlt Gas für den Nutzer“ spart nicht nur einen einzelnen Schritt beim Kauf von Coins. Es überträgt dem Vertrag drei Dinge, die man auf traditionellen Chains selten zusammenbringt: Der Vertrag kann vom Nutzer eine Servicegebühr erheben, kann das Ausführungs-Gas selbst übernehmen und kann nach Regeln auch dann automatisch laufen, wenn kein externes Konto manuell getriggert wird – autocontract. $DUSK wird weiterhin für Blockspace und Validator-Anreize genutzt, aber der Zahler muss nicht immer der endgültige Nutzer sein.
Das ist entscheidend für Anwendungen, die sich an Web2-Nutzer richten. Wenn Nutzer Anleihen kaufen, Kupons einlösen oder eine Identität verifizieren, kann das Frontend Gebühren in die Geschäftspreise einkalkulieren, ohne sie erst anzuweisen, im Exchange erst etwas native Coin zu kaufen. Entwickler können außerdem „pro Aufruf wird abgerechnet“, „kostenlose Kontingente“ oder „vom Emittenten gesponsert“ als Teil des Produktmodells abbilden. Es löst nicht das „Verschwinden von Gas“, sondern verlagert Gas von einer vorgelagerten Nutzeraktion in die Backend-Kosten der Anwendung.
Umgekehrt verlagert die Gebührenübernahme auch Risiken vom Nutzer auf den Vertrag. Wer die Gebührenparameter ändern kann, wie die Transaktion fehlschlägt, wenn das Vertragsguthaben nicht ausreicht, und ob automatische Aktionen durch „Spam“-Calls geleert werden können – all das muss vorher entworfen werden. Wenn das Projekt Gas subventioniert, wirkt das kurzfristig glatt, langfristig kann es aber zu einem zentralisierten Betriebsbudget werden. Und wenn die Servicegebühren nicht transparent sind, wird aus Kettengebühren nur ein anderes, schwerer vergleichbares Preisschild.
Das ist auch mein Maßstab, um das Economic Protocol von #dusk zu bewerten: nicht die vier Worte „gas ohne Gefühl“, sondern die Frage, wer das Abrechnungsrecht hat, wie hoch das finanzielle Limit ist und welche Schutzmechanismen es bei Fehlschlägen gibt. Du weißt genau, welche Kettengebühr du selbst klar und transparent zahlst – oder akzeptierst du eher, dass die Anwendung übernimmt und die Kosten dann in den Servicepreisen versteckt?
Das ist entscheidend für Anwendungen, die sich an Web2-Nutzer richten. Wenn Nutzer Anleihen kaufen, Kupons einlösen oder eine Identität verifizieren, kann das Frontend Gebühren in die Geschäftspreise einkalkulieren, ohne sie erst anzuweisen, im Exchange erst etwas native Coin zu kaufen. Entwickler können außerdem „pro Aufruf wird abgerechnet“, „kostenlose Kontingente“ oder „vom Emittenten gesponsert“ als Teil des Produktmodells abbilden. Es löst nicht das „Verschwinden von Gas“, sondern verlagert Gas von einer vorgelagerten Nutzeraktion in die Backend-Kosten der Anwendung.
Umgekehrt verlagert die Gebührenübernahme auch Risiken vom Nutzer auf den Vertrag. Wer die Gebührenparameter ändern kann, wie die Transaktion fehlschlägt, wenn das Vertragsguthaben nicht ausreicht, und ob automatische Aktionen durch „Spam“-Calls geleert werden können – all das muss vorher entworfen werden. Wenn das Projekt Gas subventioniert, wirkt das kurzfristig glatt, langfristig kann es aber zu einem zentralisierten Betriebsbudget werden. Und wenn die Servicegebühren nicht transparent sind, wird aus Kettengebühren nur ein anderes, schwerer vergleichbares Preisschild.
Das ist auch mein Maßstab, um das Economic Protocol von #dusk zu bewerten: nicht die vier Worte „gas ohne Gefühl“, sondern die Frage, wer das Abrechnungsrecht hat, wie hoch das finanzielle Limit ist und welche Schutzmechanismen es bei Fehlschlägen gibt. Du weißt genau, welche Kettengebühr du selbst klar und transparent zahlst – oder akzeptierst du eher, dass die Anwendung übernimmt und die Kosten dann in den Servicepreisen versteckt?