🔒🖼️ Nuovo post: Transazioni di Frame Crittografate 🔒🖼️ tl;dr: Le transazioni di frame crittografate si basano su LUCID e EIP-8141 per nascondere i parametri di esecuzione (target, calldata, importi) fino a dopo che l'ordinamento del blocco è bloccato. Questo design sblocca l'esecuzione crittografata nello stesso slot, transazioni in testo semplice/critto in modo intercalato, ed è compatibile con i futuri schemi PQ. 👇🧵

I progetti di mempool crittografati di oggi (ad es., LUCID) ritardano l'esecuzione al successivo slot e utilizzano una corsia dedicata in cima al blocco per le transazioni crittografate. Questo post propone un'esecuzione crittografata nello stesso slot separando l'ordinamento dall'esecuzione. Il costruttore si impegna al set completo di transazioni ordinate prima che venga rivelata qualsiasi chiave, quindi esegue quell'ordinamento impegnato nello stesso slot.

Nell'ePBS standard, l'offerta del costruttore si impegna a un block_hash precomputato. Questo non funziona qui perché il risultato finale dipende da quali tx crittografati vengono rivelati e a cosa si decrittano. Invece, l'offerta si impegna a tx_ordering_root, bloccando l'intera lista delle transazioni prima della rivelazione. Gli output dipendenti dall'esecuzione (state_root, BAL, ricevute) si legano solo dopo.

Questa è la differenza chiave rispetto a LUCID. In LUCID, le chiavi vengono rilasciate durante lo slot N e l'esecuzione avviene all'inizio del blocco nello slot N+1. Il prossimo costruttore conosce già le transazioni decrittografate quando posiziona il resto del blocco. Qui, l'impegno avviene prima della rivelazione, l'esecuzione rimane nello stesso slot e le tx criptate sono intercalate con il testo in chiaro in un unico ordinamento.

Ogni frame tx crittografato ha un frame pubblico di VERIFICA e una fase di esecuzione crittografata nascosta. L'involucro si impegna a exec_params_binding = H(exec_params). Target, calldata, importi e, facoltativamente, la commissione di priorità rimangono nascosti fino al momento della rivelazione. Se una chiave non arriva prima della scadenza di rivelazione del costruttore, la fase crittografata viene saltata. La VERIFICA continua a funzionare, il nonce viene consumato e il mittente paga per la parte pubblica. Il gas di esecuzione nascosta viene rimborsato. L'ordinamento rimane fisso indipendentemente da tutto.

Il costruttore ha ancora discrezionalità sui rivelamenti vicino alla scadenza. Per limitare questo, il design utilizza una fusione della vista degli attestatori simile a FOCIL: gli attestatori non voteranno per un payload che segna un rivelamento come mancante se hanno osservato la chiave prima della propria scadenza di congelamento.

Riguardo al problema dell'opzione gratuita (altra): un mittente auto-decrittante può osservare l'ordinamento impegnato e scegliere di rivelare solo quando la posizione è favorevole, mantenendo di fatto un'opzione gratuita sull'esecuzione. Esistono mitigazioni come commissioni aggiuntive sulle transazioni criptate o penali per il salto, ma penso che siano necessarie ulteriori esplorazioni per prendere decisioni finali.