🔒🖼️ Neuer Beitrag: Verschlüsselte Rahmen-Transaktionen 🔒🖼️ tl;dr: Verschlüsselte Rahmen-Transaktionen basieren auf LUCID und EIP-8141, um Ausführungsparameter (Ziel, calldata, Beträge) zu verbergen, bis die Reihenfolge des Blocks gesperrt ist. Dieses Design ermöglicht die gleichzeitige verschlüsselte Ausführung im selben Slot, abwechselnde Klartext-/verschlüsselte Transaktionen und ist zukunftssicher mit PQ-Schemata.

Verschlüsselte Mempool-Designs heute (z. B. LUCID) verzögern die Ausführung bis zum nächsten Slot und verwenden eine dedizierte Top-of-Block-Spur für verschlüsselte Transaktionen. Dieser Beitrag schlägt eine verschlüsselte Ausführung im selben Slot vor, indem die Reihenfolge von der Ausführung getrennt wird. Der Builder verpflichtet sich, das vollständige geordnete Transaktionsset zu committen, bevor ein Schlüssel enthüllt wird, und führt dann diese verpflichtete Reihenfolge im selben Slot aus.

Im Standard-ePBS verpflichtet sich das Builder-Gebot zu einem vorab berechneten block_hash. Das funktioniert hier nicht, da das Endergebnis davon abhängt, welche verschlüsselten Transaktionen offenbart werden und was sie entschlüsseln. Stattdessen verpflichtet sich das Gebot zu tx_ordering_root und sperrt die vollständige Transaktionsliste vor der Offenbarung. Ausführungsabhängige Ausgaben (state_root, BAL, Quittungen) binden sich erst danach.

Dies ist der entscheidende Unterschied zu LUCID. Bei LUCID werden die Schlüssel während Slot N freigegeben und die Ausführung erfolgt am Anfang des Blocks in Slot N+1. Der nächste Builder kennt bereits die entschlüsselten Transaktionen, wenn er den Rest des Blocks platziert. Hier erfolgt das Commitment vor der Offenlegung, die Ausführung bleibt im selben Slot, und die verschlüsselten Transaktionen sind mit Klartext in einer Reihenfolge vermischt.

Jeder verschlüsselte Frame tx hat einen öffentlichen VERIFY-Frame und eine versteckte verschlüsselte Ausführungsphase. Der Umschlag verpflichtet sich zu exec_params_binding = H(exec_params). Ziel, calldata, Beträge und optional die Prioritätsgebühr bleiben verborgen, bis sie offenbart werden. Wenn ein Schlüssel nicht vor der Offenlegungsfrist des Builders ankommt, wird die verschlüsselte Phase übersprungen. VERIFY läuft weiterhin, die Nonce wird verbraucht und der Absender zahlt für den öffentlichen Teil. Die versteckten Ausführungskosten werden zurückerstattet. Die Reihenfolge bleibt unverändert.

Der Builder hat weiterhin Ermessensspielraum bei Enthüllungen nahe der Frist. Um dies einzuschränken, verwendet das Design eine Attester-View-Merge, ähnlich wie FOCIL: Attester werden nicht für eine Nutzlast stimmen, die eine Enthüllung als fehlend markiert, wenn sie den Schlüssel vor ihrer eigenen Einfrierfrist beobachtet haben.

Zum Problem der (anderen) kostenlosen Option: Ein selbstentschlüsselnder Sender kann die festgelegte Reihenfolge beobachten und wählen, wann er nur dann offenbart, wenn die Position günstig ist, wodurch er effektiv eine kostenlose Option auf die Ausführung hält. Es gibt zwar Maßnahmen wie zusätzliche Gebühren für verschlüsselte Transaktionen oder Strafen für das Überspringen, aber ich denke, dass weitere Erkundungen notwendig sind, um endgültige Entscheidungen zu treffen.