🔒🖼️ Postare nouă: Tranzacții 🔒🖼️ cu cadre criptate Pe scurt; dr: Tranzacțiile cu cadre criptate se bazează pe LUCID și EIP-8141 pentru a ascunde parametrii de execuție (țintă, date de apel, sume) până după ce ordinea blocului este blocată. Acest design deblochează execuția criptată pe același slot, tranzacții text simplu/criptate intercalate și este compatibil pe viitor cu schemele PQ. 👇🧵

Proiectele mempool criptate de astăzi (de exemplu, LUCID) amână execuția către următorul slot și folosesc o bandă dedicată în partea superioară a blocului pentru tranzacțiile criptate. Această postare propune execuția criptată pe același slot prin separarea ordinii de execuție. Constructorul se angajează la setul complet de tranzacții ordonate înainte ca vreo cheie să fie dezvăluită, apoi execută acea ordine angajată în același slot.

În ePBS standard, licitația constructorului se angajează la un block_hash precalculat. Asta nu funcționează aici pentru că rezultatul final depinde de ce mesaje criptate sunt dezvăluite și în ce funcție se decriptează. În schimb, licitația se angajează la tx_ordering_root, blocând lista completă a tranzacțiilor înainte de dezvăluire. Ieșirile dependente de execuție (state_root, BAL, chitanțe) se leagă doar după.

Aceasta este diferența cheie față de LUCID. În LUCID, cheile sunt eliberate în slotul N, iar execuția are loc în partea superioară a blocului în slotul N+1. Următorul constructor știe deja tranzacțiile decriptate când plasează restul blocului. Aici, angajamentul are loc înainte de dezvăluire, execuția rămâne în același slot, iar mesajele criptate sunt intercalate cu text clar într-o singură ordine.

Fiecare transmisie de cadru criptată are un cadru public VERIFY și o fază ascunsă de execuție criptată. Plicul se confirmă la exec_params_binding = H(exec_params). Target, datele de apel, sumele și, opțional, taxa de prioritate rămân ascunse până la dezvăluire. Dacă o cheie nu sosește înainte de termenul limită de dezvăluire al constructorului, faza criptată este sărită. VERIFY rulează în continuare, nonce-ul este consumat, iar expeditorul plătește pentru partea publică. Gazul de execuție ascuns este rambursat. Comanda rămâne fixă oricum.

Constructorul încă are discreție asupra dezvăluirilor aproape de limită. Pentru a limita acest lucru, designul folosește un view-merge al atestatorului similar cu FOCIL: atestatorii nu vor vota pentru o încărcătură utilă care marchează o dezvăluire ca lipsă dacă au observat cheia înainte de termenul limită de înghețare.

Despre problema (celeilalte) opțiuni libere: Un expeditor care se autodecriptează poate observa ordinea confirmată și poate alege să dezvăluie doar când poziția este favorabilă, menținând efectiv o opțiune liberă la execuție. Există atenuări precum taxe suplimentare pentru mesaje criptate sau penalizări pentru sărituri, dar cred că sunt necesare mai multe explorări pentru a lua decizii finale.