Du kennst das, wenn man ein Rezept testet, bevor man es für Gäste kocht? Du brätst einen kleinen Pfannkuchen, probierst ihn, passt das Salz an. Wenn er schrecklich ist, verschwendest du nicht den ganzen Teig. Du hast eine Minute verloren, nicht die Dinner-Party.
Ich habe die Newton-SDK-Dokumentation gelesen und die „simulate“-Task-Funktion funktioniert genau wie dieser Probepfannkuchen. Eine dApp kann einen Intent annehmen, die Transaktion, die der Nutzer ausführen will, und sie an einen Operator senden, der eine trockene Bewertung durchführt, bevor irgendetwas auf die Chain geht. Der Operator führt die Rego-Richtlinie dagegen aus, holt alle externen Daten, die die WASM-Orakel benötigen, und gibt ein Allow oder Deny zurück. In den Docs steht, dass das nur Millisekunden dauert. Kein Gas wird verbraucht, keine Attestation wird erzeugt, und nichts wird Onchain geschrieben.
Die Frontend-Seite kann den Nutzer dann direkt in der UI warnen. Etwa so: Diese Überweisung wird fehlschlagen, weil du das tägliche Limit überschritten hast, oder diese Adresse ist nicht auf deiner Allowlist. Der Nutzer hat noch nichts unterschrieben. Er hat noch keinen Cent bezahlt. Die Feedback-Schleife ist fast augenblicklich.
Aber hier ist das, worüber ich immer wieder nachdenke. Die Simulation ist ein Snapshot. Sie verwendet alle Daten, die das Orakel zu genau diesem Zeitpunkt zurückliefert. Ein Kursfeed könnte zwei Sekunden später umschalten. Ein KYC-Status könnte sich ändern. Die echte Bewertung, die eine Attestation Onchain erzeugt, könnte also vom Vorschau-Ergebnis abweichen. Das ist kein Bug, sondern so funktioniert jeder Pre-Flight-Check. Die Warnung ist eine Prognose, kein Versprechen.
Ich frage mich, wie viele dApps mit dieser Abweichung wohl souverän umgehen werden. Ein grünes Licht in der UI, gefolgt von einer Onchain-Ablehnung, fühlt sich schlimmer an als gar keine Warnung. Vielleicht bauen Teams eine Toleranzspanne ein oder akzeptieren einfach gelegentliche Fehleinschätzungen. Frühes Feedback mit einer kleinen Fehlerquote ist wahrscheinlich besser als Schweigen. Aber ich bin nicht sicher, ob die meisten Nutzer den Unterschied zwischen einer Vermutung und einer Garantie verstehen, und diese Verwirrung könnte sich an Stellen zeigen, die die Entwickler nicht beobachten.
#newt $NEWT @NewtonProtocol
Ich habe die Newton-SDK-Dokumentation gelesen und die „simulate“-Task-Funktion funktioniert genau wie dieser Probepfannkuchen. Eine dApp kann einen Intent annehmen, die Transaktion, die der Nutzer ausführen will, und sie an einen Operator senden, der eine trockene Bewertung durchführt, bevor irgendetwas auf die Chain geht. Der Operator führt die Rego-Richtlinie dagegen aus, holt alle externen Daten, die die WASM-Orakel benötigen, und gibt ein Allow oder Deny zurück. In den Docs steht, dass das nur Millisekunden dauert. Kein Gas wird verbraucht, keine Attestation wird erzeugt, und nichts wird Onchain geschrieben.
Die Frontend-Seite kann den Nutzer dann direkt in der UI warnen. Etwa so: Diese Überweisung wird fehlschlagen, weil du das tägliche Limit überschritten hast, oder diese Adresse ist nicht auf deiner Allowlist. Der Nutzer hat noch nichts unterschrieben. Er hat noch keinen Cent bezahlt. Die Feedback-Schleife ist fast augenblicklich.
Aber hier ist das, worüber ich immer wieder nachdenke. Die Simulation ist ein Snapshot. Sie verwendet alle Daten, die das Orakel zu genau diesem Zeitpunkt zurückliefert. Ein Kursfeed könnte zwei Sekunden später umschalten. Ein KYC-Status könnte sich ändern. Die echte Bewertung, die eine Attestation Onchain erzeugt, könnte also vom Vorschau-Ergebnis abweichen. Das ist kein Bug, sondern so funktioniert jeder Pre-Flight-Check. Die Warnung ist eine Prognose, kein Versprechen.
Ich frage mich, wie viele dApps mit dieser Abweichung wohl souverän umgehen werden. Ein grünes Licht in der UI, gefolgt von einer Onchain-Ablehnung, fühlt sich schlimmer an als gar keine Warnung. Vielleicht bauen Teams eine Toleranzspanne ein oder akzeptieren einfach gelegentliche Fehleinschätzungen. Frühes Feedback mit einer kleinen Fehlerquote ist wahrscheinlich besser als Schweigen. Aber ich bin nicht sicher, ob die meisten Nutzer den Unterschied zwischen einer Vermutung und einer Garantie verstehen, und diese Verwirrung könnte sich an Stellen zeigen, die die Entwickler nicht beobachten.
#newt $NEWT @NewtonProtocol