Skip to main content
Diese Seite ist die maßgebliche Übersicht über externe Sicherheitsprüfungen an den Komponenten von Intention. Sie benennt, was auditiert wurde, was gerade geprüft wird und – ebenso wichtig – was noch nicht auditiert wurde.

​
Aktueller Stand

Die Cross-Chain-Bridge ist die Komponente, die extern sicherheitsgeprüft wird. Der Umfang deckt die Verträge auf der externen Chain und die Signer-Infrastruktur dahinter ab: Verwahrung, Signaturprüfung, den zweistufigen Auszahlungspfad samt Einspruchsfrist und die Weitergabe des Validatorensets über die Chain-Grenze hinweg. Die Bridge wurde bewusst priorisiert. Sie ist die eine Komponente, deren Sicherheitsmodell nicht das des Netzwerks ist – die Hälfte davon läuft auf einer anderen Chain, mit eigenen Validatoren und eigenen Fehlermodi, und dort schlägt eine Kompromittierung am unmittelbarsten in verlorenes Geld um. Der Rest des Protokolls lässt sich durch erneutes Ausführen von Blöcken verifizieren; ein Bridge-Vertrag auf einer externen Chain nicht. Prüfer und Bericht werden nach Abschluss hier veröffentlicht, mit Umfang und Feststellungen.
Dies ist derzeit das einzige vorgesehene externe Audit. Andere Komponenten – der Ausführungskernel, der Konsens und die Clearingstelle – sind durch die unten beschriebenen internen Kontrollen abgedeckt, nicht durch eine externe Prüfung. Dass kein Audit veröffentlicht ist, ist kein Beleg dafür, dass es keine Mängel gibt. Beurteilen Sie das entsprechend, insbesondere vor dem Mainnet.

​
Wie ein Bericht zu lesen ist, wenn er erscheint

Ein nützliches Audit beantwortet drei Fragen: was zum Umfang gehörte, was die Prüfer tatsächlich untersucht haben und was bei Veröffentlichung offen bleibt. Jeder hier veröffentlichte Bericht wird alle drei ausdrücklich beantworten.
  • Umfang ist ein Commit-Hash plus eine aufgezählte Komponentenliste. Dateien und Verträge, die nicht aufgeführt sind, wurden nicht auditiert.
  • Feststellungen sind nach Schweregrad kategorisiert. Bei Feststellungen mit akzeptiertem Risiko stehen die Begründung und etwaige mildernde Kontrollen dabei, statt weggelassen zu werden.
  • Diff seit dem Audit wird separat verfolgt. Jede Änderung nach dem Audit, die auditierten Code berührt, wird markiert, damit erkennbar ist, ob der veröffentlichte Bericht noch das laufende System beschreibt.
Der letzte Punkt fehlt anderswo am häufigsten. Ein Audit beschreibt einen bestimmten Commit. Code, der sich seitdem bewegt hat, ist Code, den niemand geprüft hat, und ein Bericht, der das nicht sagt, überzeichnet seine Reichweite.

​
Laufende Prüfung

Stichtagsbezogene Audits setzen auf Kontrollen auf, die ununterbrochen laufen:
  • Review-Gates bei jeder Änderung an Kernel, Konsens und Bridge.
  • Fuzzing und eigenschaftsbasiertes Testen gegen die Zustandsmaschinen für Matching, Risiko und Abrechnung, einschließlich Determinismusprüfungen, die festgeschriebene Blöcke erneut ausführen und die Ergebnisse Byte für Byte vergleichen.
  • Differenzielles Testen über unabhängige Engine-Builds hinweg – eine Divergenz gilt als Konsensfehler, nicht als fehlgeschlagener Test.
  • Öffentliches Bug-Bounty-Programm für dauerhafte externe Abdeckung.

​
Wie es weitergeht

Bug Bounty

Umfang, Schweregrade und wie man eine Schwachstelle meldet.

Risikohinweise

Was ungeschützt bleibt, klar benannt.

Bridge

Die geprüfte Komponente und wo ihre Vertrauensannahmen liegen.

Meilensteine

Was geliefert ist und was an den kommenden Terminen hängt.
Fragen zum Audit-Umfang oder zu einer bestimmten Feststellung gehen an contact@intention.xyz. Meldungen von Schwachstellen folgen dem Prozess auf der Seite Bug Bounty und werden nicht hier vorgebracht.