🔒🖼️ Nieuwe post: Versleutelde Frame Transacties 🔒🖼️ tl;dr: Versleutelde frame transacties bouwen voort op LUCID en EIP-8141 om uitvoeringsparameters (doel, calldata, bedragen) te verbergen totdat de volgorde van het blok is vergrendeld. Dit ontwerp maakt dezelfde-slot versleutelde uitvoering, afgewisselde platte tekst/versleutelde transacties mogelijk en is toekomstbestendig met PQ-schema's. 👇🧵

Versleutelde mempool-ontwerpen vandaag de dag (bijv. LUCID) vertragen de uitvoering naar de volgende slot en gebruiken een speciale top-of-block rij voor versleutelde transacties. Deze post stelt versleutelde uitvoering in dezelfde slot voor door ordening van uitvoering te scheiden. De bouwer verbindt zich om de volledige geordende transactie set te bevestigen voordat er een sleutel wordt onthuld, en voert vervolgens die bevestigde ordening uit in dezelfde slot.

In standaard ePBS verbindt het bod van de bouwer zich aan een vooraf berekende block_hash. Dat werkt hier niet omdat het uiteindelijke resultaat afhangt van welke versleutelde tx's worden onthuld en wat ze ontcijferen. In plaats daarvan verbindt het bod zich aan tx_ordering_root, waardoor de volledige transactie lijst wordt vergrendeld voordat deze wordt onthuld. Uitvoeringsafhankelijke outputs (state_root, BAL, ontvangstbewijzen) worden pas gebonden na.

Dit is het belangrijkste verschil met LUCID. In LUCID worden sleutels vrijgegeven tijdens slot N en vindt de uitvoering plaats aan de bovenkant van het blok in slot N+1. De volgende bouwer weet al de ontsleutelde transacties wanneer hij de rest van het blok plaatst. Hier vindt de verbintenis plaats vóór de onthulling, blijft de uitvoering in hetzelfde slot, en zijn versleutelde tx's verweven met platte tekst in één volgorde.

Elk versleuteld frame tx heeft een openbaar VERIFY-frame en een verborgen versleutelde uitvoeringsfase. De envelop verbindt zich aan exec_params_binding = H(exec_params). Doel, calldata, bedragen en optioneel de prioriteitsvergoeding blijven verborgen tot onthulling. Als een sleutel niet arriveert voor de onthullingsdeadline van de bouwer, wordt de versleutelde fase overgeslagen. VERIFY draait nog steeds, de nonce wordt verbruikt en de afzender betaalt voor het openbare deel. Verborgen uitvoeringsgas wordt terugbetaald. De volgorde blijft vast ongeacht.

De bouwer heeft nog steeds discretie over onthullingen nabij de cutoff. Om dit te beperken, gebruikt het ontwerp een attester view-merge vergelijkbaar met FOCIL: attesters zullen niet stemmen voor een payload die een onthulling als ontbrekend markeert als ze de sleutel voor hun eigen freeze-deadline hebben waargenomen.

Over het probleem van de (andere) gratis optie: Een zelf-decryptie verzender kan de gecommitteerde volgorde observeren en ervoor kiezen om alleen te onthullen wanneer de positie gunstig is, waardoor hij effectief een gratis optie op uitvoering heeft. Er zijn mitigaties zoals extra kosten op versleutelde transacties of skip-boetes, maar ik denk dat er meer verkenningen nodig zijn om definitieve beslissingen te nemen.