🔒🖼️ Nova publicação: Transações de Quadro Encriptadas 🔒🖼️ tl;dr: As transações de quadro encriptadas baseiam-se no LUCID e no EIP-8141 para ocultar parâmetros de execução (destino, calldata, montantes) até que a ordenação do bloco esteja bloqueada. Este design desbloqueia a execução encriptada no mesmo slot, transações em texto simples/encriptadas intercaladas e é compatível com esquemas PQ no futuro. 👇🧵

Os designs de mempool encriptados hoje (por exemplo, LUCID) atrasam a execução para o próximo slot e usam uma faixa dedicada no topo do bloco para transações encriptadas. Este post propõe a execução encriptada no mesmo slot, separando a ordenação da execução. O construtor compromete-se com o conjunto completo de transações ordenadas antes de qualquer chave ser revelada, e então executa essa ordenação comprometida no mesmo slot.

No ePBS padrão, a proposta do construtor compromete-se com um block_hash pré-computado. Isso não funciona aqui porque o resultado final depende de quais txs criptografadas são reveladas e o que elas decifram. Em vez disso, a proposta compromete-se com tx_ordering_root, bloqueando a lista completa de transações antes da revelação. Saídas dependentes da execução (state_root, BAL, recibos) vinculam-se apenas depois.

Esta é a principal diferença em relação ao LUCID. No LUCID, as chaves são liberadas durante o slot N e a execução acontece no topo do bloco no slot N+1. O próximo construtor já conhece as transações descriptografadas ao colocar o restante do bloco. Aqui, o compromisso acontece antes da revelação, a execução permanece no mesmo slot e as txs criptografadas são intercaladas com texto claro em uma única ordenação.

Cada frame tx encriptado tem um frame público de VERIFICAÇÃO e uma fase de execução encriptada oculta. O envelope compromete-se a exec_params_binding = H(exec_params). O alvo, calldata, montantes e, opcionalmente, a taxa de prioridade permanecem ocultos até a revelação. Se uma chave não chegar antes do prazo de revelação do construtor, a fase encriptada é ignorada. A VERIFICAÇÃO ainda é executada, o nonce é consumido e o remetente paga pela parte pública. O gás de execução oculta é reembolsado. A ordenação permanece fixa independentemente.

O construtor ainda tem discrição sobre as revelações próximas ao limite. Para restringir isso, o design utiliza uma fusão de visão de atestadores semelhante ao FOCIL: os atestadores não votarão para um payload que marque uma revelação como ausente se eles observaram a chave antes do seu próprio prazo de congelamento.

Sobre o problema da (outra) opção gratuita: Um remetente auto-descriptografante pode observar a ordenação comprometida e escolher revelar apenas quando a posição for favorável, efetivamente mantendo uma opção gratuita sobre a execução. Existem mitigações como taxas adicionais em transações criptografadas ou penalidades por pular, mas acho que mais explorações são necessárias para tomar decisões finais.