🔒🖼️ Nový příspěvek: Šifrované rámcové transakce 🔒🖼️ Shrnutí; dr: Šifrované rámcové transakce jsou postaveny na LUCID a EIP-8141, aby skryly výkonné parametry (cíl, volací data, množství) až do uzamčení pořadí bloku. Tento design odemyká vykonávání šifrovaných funkcí ve stejném slotu, prokládané transakce v otevřeném textu/šifrovaném textu a je kompatibilní s PQ schématy do budoucna. 👇🧵

Dnešní návrhy šifrovaných mempoolů (např. LUCID) odkládají provádění do dalšího slotu a používají vyhrazenou horní část bloku pro šifrované transakce. Tento příspěvek navrhuje provedení šifrované ve stejném slotu oddělením pořadí od vykonání. Builder se zaváže k celé uspořádané sadě transakcí před odhalením jakéhokoli klíče a poté vykoná toto popsané pořadí ve stejném slotu.

Ve standardním ePBS se nabídka stavitele zavazuje k předpočtenému block_hash. To zde nefunguje, protože konečný výsledek závisí na tom, které zašifrované příkazy se odhalí a na co se dešifrují. Místo toho se nabídka zavazuje k tx_ordering_root, čímž před zveřejněním uzamkne celý seznam transakcí. Výstupy závislé na vykonání (state_root, BAL, účtování) se vážou až poté.

To je klíčový rozdíl oproti LUCID. V LUCID jsou klíče uvolněny během slotu N a vykonání probíhá nahoře v bloku ve slotu N+1. Další builder už zná dešifrované transakce při umístění zbytku bloku. Zde se závazek odehrává před odhalením, vykonání zůstává ve stejném slotu a šifrované převody jsou prokládány s otevřeným textem v jednom pořadí.

Každý zašifrovaný rámec tx má veřejný VERIFY rámec a skrytou šifrovanou fázi vykonání. Obálka se zaváže na exec_params_binding = H(exec_params). Cíl, data hovorů, částky a volitelně i poplatek za prioritu zůstávají skryté až do zveřejnění. Pokud klíč nedorazí před termínem zveřejnění stavitele, fáze šifrovaní se přeskočí. VERIFY stále běží, nonce se spotřebuje a odesílatel platí za veřejnou část. Skrytý popravčí plyn je vrácen. Pořadí zůstává nezměněné bez ohledu na to.

Stavitel má stále volnost při odkryvání blízko hranice. Aby se tomu zabránilo, návrh používá attester view-merge podobný FOCIL: attestující nebudou hlasovat pro payload, který označí odhalení jako chybějící, pokud klíč pozorovali před svým vlastním termínem zmrazení.

K problému (jiné) volné opce: Samodešifrující odesílatel může pozorovat zavázané pořadí a rozhodnout se odhalit pouze tehdy, když je pozice příznivá, čímž efektivně drží volnou opci při vykonání. Existují opatření jako další poplatky za šifrované přenosy nebo sankce za vynechání, ale myslím, že je potřeba více zkoumání pro konečné rozhodnutí.