Ich habe die 12 Zeilen des offiziellen Dusk-Audit-Index neu sortiert: erst nach Komponenten gruppiert, dann die Daten daneben gesetzt. Nachdem die Tabelle fertig war, ließ sich der ursprüngliche, so eingängige Satz „Dusk wurde bereits geprüft“ nicht mehr unverändert weiterverwenden. Jede Berichtsdatei hat ihren eigenen Gegenstand und ihre eigene Zeit; keine Zeile heißt „aktueller vollständiger Code-Stack mit Gesamtnachweis-Zertifikat“.
Die letzten beiden Punkte betreffen die Sicherheitsbewertung für ERC20 und BEP20 im April 2026. Die Berichte zu Kernprotokoll, Konsens, Knoten, Phoenix usw. liegen überwiegend in den Jahren 2023–2024. Hier geht es nicht darum, ob das Neue oder das Alte wichtiger ist, sondern darum, dass Berichte nur für die Komponenten sprechen können, die sie tatsächlich geprüft haben. Später hinzugefügte Module oder Versionen mit größeren Änderungen dürfen nicht allein deshalb die Schlussfolgerungen alter Berichte erben, weil die Projektnamen gleich sind.
Diese Tabelle hat meine Prüfhandlung wirklich verändert. Wenn ich künftig Sicherheitswerbung sehe, streite ich nicht zuerst darüber, „ob Audits etwas bringen“. Zuerst brauche ich vier Dinge: den Namen des Berichts, die geprüfte Komponente, das Audit-Datum und die zugehörige Version. Wenn alle vier zueinander passen, gehe ich weiter, um die Findings und die Reparaturbestätigungen zu lesen; nur mit dem Projektlogo oder dem Logo der Audit-Organisation bleibt die Information bei der Werbeebene stehen.
Für $DUSK ist diese Einschränkung kein bewusstes Gegenargument. Dass das Audit-Repository öffentlich ist und Berichte nachverfolgbar sind, ist an sich schon eine gute Sache. Indem man den Umfang präzise angibt, erkennt man, welcher Bereich bereits mit Belegen abgedeckt ist und welcher wegen Versionsänderungen nachgewiesen werden muss. Auch alte Berichte sollten nicht einfach pauschal als ungültig abgetan werden; sie garantieren nur nicht automatisch die Objekte, die nicht abgedeckt sind.
Es gibt außerdem zwei Dinge, die sich aus diesen 12 Zeilen nicht ableiten lassen. Erstens: Ich bewerte hier nicht die Qualität jedes einzelnen Berichts, und zweitens: Ich überprüfe auch nicht im Detail, ob alle Probleme vollständig behoben wurden. Wenn ein öffentlicher Index eine bestimmte Unterlage nicht aufführt, kann das nicht beweisen, dass sie an anderer Stelle absolut nicht existiert. Der Index, den @Dusk bereitgestellt hat, eignet sich als Einstieg, nicht als Endpunkt der Schlussfolgerungen.
Ein Satz wie „bereits auditiert“ spart zwar viele Worte, aber er spart auch die wichtigste Grenze. Nachdem ich die 12 Zeilen aufgedröselt habe, hat die Sicherheitsbeurteilung endlich überprüfbare Subjekte, Zeiten und Versionen. Beim nächsten Mal, wenn jemand mit einer Schlussfolgerung auf Basis eines ganzen Projekt-Schemas argumentiert, werde ich ihn bitten, zuerst genau zu zeigen, welche Zeile gemeint ist. #dusk
Die letzten beiden Punkte betreffen die Sicherheitsbewertung für ERC20 und BEP20 im April 2026. Die Berichte zu Kernprotokoll, Konsens, Knoten, Phoenix usw. liegen überwiegend in den Jahren 2023–2024. Hier geht es nicht darum, ob das Neue oder das Alte wichtiger ist, sondern darum, dass Berichte nur für die Komponenten sprechen können, die sie tatsächlich geprüft haben. Später hinzugefügte Module oder Versionen mit größeren Änderungen dürfen nicht allein deshalb die Schlussfolgerungen alter Berichte erben, weil die Projektnamen gleich sind.
Diese Tabelle hat meine Prüfhandlung wirklich verändert. Wenn ich künftig Sicherheitswerbung sehe, streite ich nicht zuerst darüber, „ob Audits etwas bringen“. Zuerst brauche ich vier Dinge: den Namen des Berichts, die geprüfte Komponente, das Audit-Datum und die zugehörige Version. Wenn alle vier zueinander passen, gehe ich weiter, um die Findings und die Reparaturbestätigungen zu lesen; nur mit dem Projektlogo oder dem Logo der Audit-Organisation bleibt die Information bei der Werbeebene stehen.
Für $DUSK ist diese Einschränkung kein bewusstes Gegenargument. Dass das Audit-Repository öffentlich ist und Berichte nachverfolgbar sind, ist an sich schon eine gute Sache. Indem man den Umfang präzise angibt, erkennt man, welcher Bereich bereits mit Belegen abgedeckt ist und welcher wegen Versionsänderungen nachgewiesen werden muss. Auch alte Berichte sollten nicht einfach pauschal als ungültig abgetan werden; sie garantieren nur nicht automatisch die Objekte, die nicht abgedeckt sind.
Es gibt außerdem zwei Dinge, die sich aus diesen 12 Zeilen nicht ableiten lassen. Erstens: Ich bewerte hier nicht die Qualität jedes einzelnen Berichts, und zweitens: Ich überprüfe auch nicht im Detail, ob alle Probleme vollständig behoben wurden. Wenn ein öffentlicher Index eine bestimmte Unterlage nicht aufführt, kann das nicht beweisen, dass sie an anderer Stelle absolut nicht existiert. Der Index, den @Dusk bereitgestellt hat, eignet sich als Einstieg, nicht als Endpunkt der Schlussfolgerungen.
Ein Satz wie „bereits auditiert“ spart zwar viele Worte, aber er spart auch die wichtigste Grenze. Nachdem ich die 12 Zeilen aufgedröselt habe, hat die Sicherheitsbeurteilung endlich überprüfbare Subjekte, Zeiten und Versionen. Beim nächsten Mal, wenn jemand mit einer Schlussfolgerung auf Basis eines ganzen Projekt-Schemas argumentiert, werde ich ihn bitten, zuerst genau zu zeigen, welche Zeile gemeint ist. #dusk