Ich habe das aufschlussreichste AEGIS-Problem außerhalb des Zero-Knowledge-Beweises selbst gefunden. Ein Wert daneben war nicht vollständig kontrolliert.
Im Phoenix-Transaktionspfad von Dusk Network konnte ein Nutzer sich auf eine legitime max_fee festlegen, während die Ausführung dennoch Gebührenfelder verbrauchte, die nicht in dieselbe Sicherheitsgeschichte eingebunden waren. Feindliche Gas-Parameter konnten eine Rückerstattungsinflation auslösen oder Überläufe verursachen. Eine mutable Rückerstattungsadresse konnte den Wert umleiten.
Der Beweis war gültig. Die Transaktionssemantik war nicht vollständig damit verbunden.
Eine Gebühr ist nicht harmlose Metadaten, wenn der Rückerstattungspfad Werte erzeugen oder umleiten kann.
Das ist eine nützliche Warnung für jedes Privacy-Protokoll. Einen einzigen Satz perfekt zu beweisen sichert nicht automatisch benachbarte Felder ab, denen die Ausführung später vertraut. Das System muss den Beweis, die Signatur, die Gebührenberechnung, das Ziel und den Rückerstattungspfad zu einer einzigen Invariante binden.
AEGIS fügte geprüfte Multiplikation für gas_limit mal gas_price hinzu und verlangte, dass das Ergebnis dem bewiesenen max_fee entspricht. Dusk erzwang diese Prüfung zweimal: bei der Aufnahme in den Mempool und erneut innerhalb der VM-Ausführung. Außerdem band es die Rückerstattungs-Stealth-Adresse so ein, dass Manipulation die Transaktion ungültig machen würde.
Die zweite Prüfung ist das Detail, um das es mir geht. Ein böswilliger Block-Producer muss die Annahmen eines ehrlichen Mempools nicht respektieren. Wenn die Invariante nur am Netzwerk-Rand existiert, kann der Konsens dennoch eine Transaktion ausführen, die diese Randbedingung umgangen hat.
Ich würde nun nach demselben Verteidigungsmuster in Dusk suchen: günstige Ablehnung vor der Aufnahme, autoritative Validierung bei der Ausführung und Regressionstests, die jedes Feld rund um einen Beweis mutieren.
AEGIS hat die bekannten kritischen Pfade geschlossen. Die größere Frage ist, ob andere Dusk-Verträge Werte enthalten, die in einer Ebene „geprüft“ werden und in der nächsten nur vertraut.
Kryptografie kann genau das beweisen, was sie beweisen soll. Sicherheit hängt davon ab, dass Dusk nach der vollständigen Aussage fragt.
#dusk $DUSK @Dusk
Im Phoenix-Transaktionspfad von Dusk Network konnte ein Nutzer sich auf eine legitime max_fee festlegen, während die Ausführung dennoch Gebührenfelder verbrauchte, die nicht in dieselbe Sicherheitsgeschichte eingebunden waren. Feindliche Gas-Parameter konnten eine Rückerstattungsinflation auslösen oder Überläufe verursachen. Eine mutable Rückerstattungsadresse konnte den Wert umleiten.
Der Beweis war gültig. Die Transaktionssemantik war nicht vollständig damit verbunden.
Eine Gebühr ist nicht harmlose Metadaten, wenn der Rückerstattungspfad Werte erzeugen oder umleiten kann.
Das ist eine nützliche Warnung für jedes Privacy-Protokoll. Einen einzigen Satz perfekt zu beweisen sichert nicht automatisch benachbarte Felder ab, denen die Ausführung später vertraut. Das System muss den Beweis, die Signatur, die Gebührenberechnung, das Ziel und den Rückerstattungspfad zu einer einzigen Invariante binden.
AEGIS fügte geprüfte Multiplikation für gas_limit mal gas_price hinzu und verlangte, dass das Ergebnis dem bewiesenen max_fee entspricht. Dusk erzwang diese Prüfung zweimal: bei der Aufnahme in den Mempool und erneut innerhalb der VM-Ausführung. Außerdem band es die Rückerstattungs-Stealth-Adresse so ein, dass Manipulation die Transaktion ungültig machen würde.
Die zweite Prüfung ist das Detail, um das es mir geht. Ein böswilliger Block-Producer muss die Annahmen eines ehrlichen Mempools nicht respektieren. Wenn die Invariante nur am Netzwerk-Rand existiert, kann der Konsens dennoch eine Transaktion ausführen, die diese Randbedingung umgangen hat.
Ich würde nun nach demselben Verteidigungsmuster in Dusk suchen: günstige Ablehnung vor der Aufnahme, autoritative Validierung bei der Ausführung und Regressionstests, die jedes Feld rund um einen Beweis mutieren.
AEGIS hat die bekannten kritischen Pfade geschlossen. Die größere Frage ist, ob andere Dusk-Verträge Werte enthalten, die in einer Ebene „geprüft“ werden und in der nächsten nur vertraut.
Kryptografie kann genau das beweisen, was sie beweisen soll. Sicherheit hängt davon ab, dass Dusk nach der vollständigen Aussage fragt.
#dusk $DUSK @Dusk
