Da dies Bedingungen assertentspricht , die niemals eintreten dürfen, wenn der Smart-Contract-Code korrekt ist, sagt mir meine Intuition, dass jemand, der einen Smart-Contract anruft, der eine Bestätigung auslöst, niemals mit Gasausgaben "bestraft" werden darf, da der Anrufer keine Schuld trägt. (Vielleicht sollten Nodes Smart-Contracts, die Asserts erheben, auf eine schwarze Liste setzen und/oder es sollte ein Mechanismus vorhanden sein, der es ermöglicht, neue Versionen/gepatchte Verträge ohne Assertion umzuleiten).
Im Gegensatz dazu requireentspricht die Überprüfung der Eingabedaten den Funktionen , daher sagt mir meine Intuition, dass der Aufruf mit falschen Daten bestraft werden sollte.
Ich glaube, es gibt etwas, das ich NICHT verstehe, oder ich habe die ursprüngliche Absicht von assertvs völlig missverstanden require.
Eine gescheiterte Transaktion kostet den Absender immer Gas. Wenn dies nicht der Fall wäre, könnte jeder einen Denial-of-Service-Angriff gegen das Netzwerk starten, indem er viele fehlgeschlagene Transaktionen kostenlos einreicht.
Der Unterschied zwischen assertund requireliegt darin, wie viel Gas verbraucht wird. assert(oder throw) verbraucht den Rest des in der Transaktion festgelegten Gaslimits, während require(oder revert) nur die bereits verbrauchte Gasmenge verbraucht.
Wann man welchen verwendet: requireist immer gasverbrauchsfreundlicher. Ich habe keinen zwingenden Grund gesehen assert, .
Das (schwache) Argument, das ich gesehen habe, ist, dass es schön ist, zwischen Dingen zu unterscheiden, die erwartet werden, und Dingen, die nicht statisch sind, so dass eine Codeanalyse helfen kann zu beweisen, dass es unmöglich ist, asserts (aber nicht requires) im Code zu erreichen. Und wenn die asserts wirklich unerreichbar sind, gibt es keinen Nachteil für den zusätzlichen Benzinverbrauch.
Benutzer19510
ohrizon