🔒🖼️ Novo post: Transações 🔒🖼️ de Quadros Criptografados Resumo; dr: Transações de quadro criptografado são construídas no LUCID e EIP-8141 para ocultar parâmetros de execução (alvo, dados de chamada, montantes) até que a ordem do bloco seja bloqueada. Esse design desbloqueia execução criptografada no mesmo slot, transações intercaladas de texto simples/criptografado e é compatível com esquemas PQ futuros. 👇🧵

Projetos de mempool criptografados 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 criptografadas. Este post propõe a execução criptografada no mesmo slot, separando a ordem da execução. O construtor faz commit no conjunto completo de transações ordenadas antes que qualquer chave seja revelada, e então executa essa ordem comprometida no mesmo slot.

No ePBS padrão, o lance do construtor se compromete com uma block_hash pré-computada. Isso não funciona aqui porque o resultado final depende de quais transmissões criptografadas são reveladas e para quais são descriptografadas. Em vez disso, o lance se compromete 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) só se vinculam depois.

Essa é a principal diferença em relação ao LUCID. No LUCID, as chaves são liberadas durante o slot N e a execução ocorre 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 ocorre antes da revelação, a execução permanece no mesmo slot, e os testes criptografados são intercalados com texto simples em uma única ordem.

Cada trama criptografada tem uma trama VERIFY pública e uma fase oculta de execução criptografada. O envelope compromete com exec_params_binding = H(exec_params). Alvo, dados de chamadas, valores e, opcionalmente, a taxa de prioridade permanecem ocultos até serem revelados. Se uma chave não chegar antes do prazo de revelação do construtor, a fase criptografada é pulada. O VERIFY ainda roda, o nonce é consumido e o remetente paga pela parte pública. O gás de execução escondido é reembolsado. A ordem permanece fixa mesmo assim.

O construtor ainda tem discricionariedade sobre revelações próximas ao limite. Para restringir isso, o design usa uma fusão de visualização do atestado semelhante ao FOCIL: os atestados não votarão em uma carga útil que marque uma revelação como ausente se eles observaram a chave antes do próprio prazo de congelamento.

Sobre o problema da opção livre (outra): Um remetente auto-decriptado pode observar a ordem comprometida e escolher revelar apenas quando a posição for favorável, mantendo efetivamente uma opção livre na execução. Mitigações como taxas adicionais em transmissões criptografadas ou penalidades de skip existem, mas acho que mais explorações são necessárias para tomar decisões finais.