Ich habe heute dieselbe Gleichung zweimal überprüft gesehen und wäre fast darüber hinweggegangen, warum.
Beim Lesen eines Dusk-Security-Writeups, einer Gebührenformel, Gaslimit mal Gaspreis ergibt maximale Gebühr – das wird zweimal erzwungen: einmal beim Eintritt in den Mempool, nochmal bei der VM-Ausführung.
Beim ersten Lesen dachte ich, das sei Redundanz. Gürtel und Hosenträger, nichts weiter zu vertiefen.
Der nächste Absatz hat das nicht überstanden. Mempool-alleiniger Zwang reicht nicht: Ein böswilliger Proposer muss nicht darauf beschränkt sein, nur die mempool-redliche Version der Felder einer Transaktion einzuschließen.
Das ist die eigentliche Lücke. Ein Wert, der in einem Teil einer Transaktion nachgewiesen oder signiert wurde, bindet nicht jede Ebene, die ihn später verbraucht. Jemand kann sich im Voraus auf eine legitime Gebühr festlegen und trotzdem bei der Ausführung eine andere einspeisen – außer die Ausführung verweigert es unabhängig voneinander, dem früheren Check zu vertrauen.
Signiere und beweise die maximale Gebühr, prüfe sie im Mempool, und der Proposer baut den Block ohne Verpflichtung, diese Vorgabe zu erhalten. Die VM führt die Refund-Logik gegen das aus, was tatsächlich angekommen ist.
Das dreht sich immer wieder im Kreis: Der Großteil des Vertrauens liegt darauf, dass der Proposer zwischen den Kontrollpunkten ehrlich bleibt – genau diese Annahme, dass der zweite Check existiert, weil man sich nicht darauf verlassen kann.
Ich weiß nicht, wie viele andere Felder in dieser Pipeline nur eine Ebene dieses Mechanismus bekommen.
Was passiert mit diesem Check bei echter Überlast, wenn Proposer unter Druck stehen, schnell zu bauen? 👍
#dusk $DUSK @Dusk
Beim Lesen eines Dusk-Security-Writeups, einer Gebührenformel, Gaslimit mal Gaspreis ergibt maximale Gebühr – das wird zweimal erzwungen: einmal beim Eintritt in den Mempool, nochmal bei der VM-Ausführung.
Beim ersten Lesen dachte ich, das sei Redundanz. Gürtel und Hosenträger, nichts weiter zu vertiefen.
Der nächste Absatz hat das nicht überstanden. Mempool-alleiniger Zwang reicht nicht: Ein böswilliger Proposer muss nicht darauf beschränkt sein, nur die mempool-redliche Version der Felder einer Transaktion einzuschließen.
Das ist die eigentliche Lücke. Ein Wert, der in einem Teil einer Transaktion nachgewiesen oder signiert wurde, bindet nicht jede Ebene, die ihn später verbraucht. Jemand kann sich im Voraus auf eine legitime Gebühr festlegen und trotzdem bei der Ausführung eine andere einspeisen – außer die Ausführung verweigert es unabhängig voneinander, dem früheren Check zu vertrauen.
Signiere und beweise die maximale Gebühr, prüfe sie im Mempool, und der Proposer baut den Block ohne Verpflichtung, diese Vorgabe zu erhalten. Die VM führt die Refund-Logik gegen das aus, was tatsächlich angekommen ist.
Das dreht sich immer wieder im Kreis: Der Großteil des Vertrauens liegt darauf, dass der Proposer zwischen den Kontrollpunkten ehrlich bleibt – genau diese Annahme, dass der zweite Check existiert, weil man sich nicht darauf verlassen kann.
Ich weiß nicht, wie viele andere Felder in dieser Pipeline nur eine Ebene dieses Mechanismus bekommen.
Was passiert mit diesem Check bei echter Überlast, wenn Proposer unter Druck stehen, schnell zu bauen? 👍
#dusk $DUSK @Dusk