Dass init während der Bereitstellung aufgerufen wurde, bedeutet nicht, dass die Funktion danach ihre Berechtigungen verliert. Die DuskVM Reference hält ausdrücklich fest, dass init auch nach der Bereitstellung ein exportierter Einstiegspunkt bleibt. Dieses Detail verlagert die einmalige Initialisierung von einer Garantie der Plattform in die Zugriffskontrolle des Vertrags selbst. Wenn der Code keine Zustandssperre vorsieht, ist der Zeitpunkt der Bereitstellung nur ein vergangenes Ereignis und kein dauerhaftes Siegel.
Ich teile die Verantwortung in zwei Spalten auf. Die Plattform erstellt den Anfangszustand und ruft bei der Bereitstellung gemäß den Parametern pub fn init auf. @Dusk Der Vertrag selbst ist dafür verantwortlich, festzuhalten, ob er bereits initialisiert wurde, spätere Aufrufe abzulehnen und zu prüfen, ob der Caller über die nötigen Berechtigungen verfügt. Die erste Spalte stellt sicher, dass die Funktion aufgerufen wird. Erst die zweite legt fest, wer sie erneut aufrufen darf und wie oft. Diese beiden Spalten können einander nicht vertreten.
Das Risiko liegt nicht im Namen init, sondern darin, was die Funktion möglicherweise schreibt. Wenn sich eine Administratoradresse, eine Zuordnung von Vermögenswerten, Gebührenparameter oder die Adresse eines externen Vertrags ein zweites Mal überschreiben lassen, werden die Vertrauensbedingungen zurückgesetzt, die bei der ersten Bereitstellung geschaffen wurden. Aus dem Funktionsnamen allein lässt sich hier keine Schwachstelle ableiten: Entscheidend sind die Fakten. Eine erneute Initialisierung wird nur dann zu einer tatsächlichen Angriffsfläche, wenn dem konkreten Code ein Statusfeld oder eine Prüfung des Aufrufers fehlt.
$DUSK Wenn ich die Anfangskonfiguration eines Vertrags prüfe, suche ich nach drei Belegen. Gibt es im persistenten Zustand ein initialized-Flag? Schlägt ein zweiter Aufruf ausdrücklich fehl? Wird der Caller geprüft, bevor wichtige Felder geändert werden? Die Bereitstellungstransaktion kann nur belegen, dass die Funktion damals ausgeführt wurde – nicht, wer sie später noch ausführen darf. Wenn ein Auditbericht nur den erfolgreichen Beleg des ersten Aufrufs zeigt, bleibt die Berechtigungsfrage zur Hälfte offen.
Diese Zweiteilung gibt auch normalen Nutzern eine praktische Möglichkeit zur Einschätzung. Wenn ein Projektteam sagt, die Parameter seien bei der Bereitstellung gesperrt worden, kann man nachfragen, ob die Sperre von der virtuellen Maschine oder vom Vertragscode umgesetzt wird. Ersteres widerspricht der Dokumentation; Letzteres sollte sich im Quellcode und in Tests mit wiederholten Aufrufen nachweisen lassen. init ist der Einstiegspunkt bei der Bereitstellung und bleibt auch danach öffentlich zugänglich. Dass etwas wirklich einmalig ist, ergibt sich nicht aus der zeitlichen Abfolge, sondern aus der Ablehnung durch den Zustand und der Autorisierung des Aufrufers. #dusk
Ich teile die Verantwortung in zwei Spalten auf. Die Plattform erstellt den Anfangszustand und ruft bei der Bereitstellung gemäß den Parametern pub fn init auf. @Dusk Der Vertrag selbst ist dafür verantwortlich, festzuhalten, ob er bereits initialisiert wurde, spätere Aufrufe abzulehnen und zu prüfen, ob der Caller über die nötigen Berechtigungen verfügt. Die erste Spalte stellt sicher, dass die Funktion aufgerufen wird. Erst die zweite legt fest, wer sie erneut aufrufen darf und wie oft. Diese beiden Spalten können einander nicht vertreten.
Das Risiko liegt nicht im Namen init, sondern darin, was die Funktion möglicherweise schreibt. Wenn sich eine Administratoradresse, eine Zuordnung von Vermögenswerten, Gebührenparameter oder die Adresse eines externen Vertrags ein zweites Mal überschreiben lassen, werden die Vertrauensbedingungen zurückgesetzt, die bei der ersten Bereitstellung geschaffen wurden. Aus dem Funktionsnamen allein lässt sich hier keine Schwachstelle ableiten: Entscheidend sind die Fakten. Eine erneute Initialisierung wird nur dann zu einer tatsächlichen Angriffsfläche, wenn dem konkreten Code ein Statusfeld oder eine Prüfung des Aufrufers fehlt.
$DUSK Wenn ich die Anfangskonfiguration eines Vertrags prüfe, suche ich nach drei Belegen. Gibt es im persistenten Zustand ein initialized-Flag? Schlägt ein zweiter Aufruf ausdrücklich fehl? Wird der Caller geprüft, bevor wichtige Felder geändert werden? Die Bereitstellungstransaktion kann nur belegen, dass die Funktion damals ausgeführt wurde – nicht, wer sie später noch ausführen darf. Wenn ein Auditbericht nur den erfolgreichen Beleg des ersten Aufrufs zeigt, bleibt die Berechtigungsfrage zur Hälfte offen.
Diese Zweiteilung gibt auch normalen Nutzern eine praktische Möglichkeit zur Einschätzung. Wenn ein Projektteam sagt, die Parameter seien bei der Bereitstellung gesperrt worden, kann man nachfragen, ob die Sperre von der virtuellen Maschine oder vom Vertragscode umgesetzt wird. Ersteres widerspricht der Dokumentation; Letzteres sollte sich im Quellcode und in Tests mit wiederholten Aufrufen nachweisen lassen. init ist der Einstiegspunkt bei der Bereitstellung und bleibt auch danach öffentlich zugänglich. Dass etwas wirklich einmalig ist, ergibt sich nicht aus der zeitlichen Abfolge, sondern aus der Ablehnung durch den Zustand und der Autorisierung des Aufrufers. #dusk