🔒🖼️ Nytt innlegg: Krypterte rammetransaksjoner 🔒🖼️ tl; dr: Krypterte rammetransaksjoner bygger på LUCID og EIP-8141 for å skjule utførelsesparametere (mål, calldata, mengder) til etter at blokkens rekkefølge er låst. Dette designet åpner for kryptert utførelse med samme plass, interleaved klartekst/kryptert transaksjoner, og er fremtidskompatibel med PQ-ordninger. 👇🧵

Krypterte mempool-design i dag (f.eks. LUCID) utsetter utførelsen til neste slot og bruker en dedikert top-of-block-lane for krypterte transaksjoner. Dette innlegget foreslår utførelse av samme spor kryptert ved å skille rekkefølge fra utførelse. Byggeren forplikter seg til det fullstendige ordnede transaksjonssettet før noen nøkkel avsløres, og utfører deretter den forpliktede rekkefølgen i samme slot.

I standard ePBS forplikter byggerbudet seg til en forhåndsberegnet block_hash. Det fungerer ikke her fordi sluttresultatet avhenger av hvilke krypterte behandlinger som blir avslørt og hva de dekrypteres til. I stedet forplikter budet seg til tx_ordering_root, og låser hele transaksjonslisten før avsløring. Utførelsesavhengige utganger (state_root, BAL, kvitteringer) binder først etterpå.

Dette er den viktigste forskjellen fra LUCID. I LUCID slippes nøkler under spor N, og utførelsen skjer øverst i blokken i spor N+1. Neste bygger kjenner allerede de dekrypterte transaksjonene når resten av blokken plasseres. Her skjer commitment før avsløring, utførelsen forblir i samme slot, og krypterte behandlinger er flettet sammen med klartekst i én rekkefølge.

Hver kryptert ramme har en offentlig VERIFY-ramme og en skjult kryptert utførelsesfase. Konvolutten forplikter seg til exec_params_binding = H(exec_params). Mål, samtaledata, beløp og eventuelt prioritetsgebyret forblir skjult til det blir avslørt. Hvis en nøkkel ikke ankommer før byggherrens avsløringsfrist, hoppes den krypterte fasen over. VERIFY kjører fortsatt, nonce-en blir brukt opp, og avsenderen betaler for den offentlige delen. Skjult henrettelsesgass refunderes. Rekkefølgen forblir fast uansett.

Byggherren har fortsatt skjønn over avsløringer nær grensen. For å begrense dette bruker designet en attester-view-merge lik FOCIL: attestere stemmer ikke på en nyttelast som markerer en avsløring som manglende hvis de observerte nøkkelen før sin egen fryse-frist.

Om det (andre) problemet med gratis opsjon: En selvdekrypterende sender kan observere den forpliktede rekkefølgen og velge å avsløre kun når posisjonen er gunstig, og dermed i praksis holde en fri opsjon ved utførelse. Avbøtende tiltak som ekstra gebyrer på krypterte behandlinger eller skip-straffer finnes, men jeg mener det trengs flere undersøkelser for å ta endelige beslutninger.