#dusk enttäuscht, meine Platzierung verbessert sich nicht, habe alles versucht, was es gibt, jetzt bin ich fertig $TREE n $HEMI sind die aufstrebenden Stars von heute

Ich habe die Dusk-Aufgabe „The Dusk task“ verbracht, indem ich in ein Engineering-Update eingetaucht bin, und bin an einem Transfer-Mechanismus hängen geblieben, an den ich wirklich nicht gedacht hatte: Ein Smart Contract muss DUSK nicht akzeptieren, nur weil ein anderer Contract es sendet.
Dusk hat transfer_to_contract hinzugefügt, bei dem ein Contract DUSK an einen anderen übertragen und dabei beliebige Daten an den Aufruf anhängen kann. Der empfangende Contract darf diese Daten prüfen und entweder die Übertragung akzeptieren oder ablehnen.
Klingt nach Kleinkram. Ist es nicht.
Ein normales Transfer-Modell behandelt das Empfangen von Geld im Grunde als passiv. Wenn jemand einen Wert an eine Adresse sendet, kommt der Wert an. Hier kann das Empfangen selbst Teil der Anwendungslogik werden. Ein Contract kann effektiv sagen: „Ich akzeptiere diese Zahlung nur, wenn die daran geknüpften Informationen meine Regeln erfüllen.“
Ich bin immer wieder darauf zurückgekommen, was das für finanzielle Workflows bedeutet. Eine Zahlung muss möglicherweise zu einer bestimmten Anweisung, einem Status oder einer Bedingung passen, bevor die empfangende Anwendung sie als gültig behandeln sollte. Statt zunächst Gelder zu akzeptieren und danach herauszufinden, wofür sie gedacht waren, kann der Empfänger die Akzeptanz direkt als Teil der Ausführung einbauen.
Das ist sauberer, aber es bedeutet auch, dass Zahlungen nicht mehr universell neutral sind. Der Ziel-Contract hat Einfluss darüber, ob die Übertragung abgeschlossen wird, und eine schlecht entworfene Logik zur Akzeptanz kann völlig legitime Abläufe ablehnen.
Seltsamerweise ist der interessante Teil nicht, dass Contracts Geld senden können. Das ist zu erwarten. Interessant ist, dass die Empfangsseite abstimmt.
Ist eine explizite Annahme durch den Empfänger also die richtige Grundeinheit für finanzielle Contracts, die bedingte Zahlungen brauchen, oder macht es das Hinzufügen, dass Contracts eingehende Werte ablehnen können, komplexer, als es Transfervorgänge eigentlich sein sollten, die doch einfach bleiben sollten??
#dusk $DUSK @Dusk

Bedingte DUSK-Zahlungen: bessere Grundeinheit oder zusätzliche Komplexität?