Ephemeral Rollup: padrão "L1.5" é proposto para o Ethereum e dispensa operador de longa duração

A proposta, publicada no ethresear.ch, trata o "L1.5" mais como padrão arquitetural do que como camada. A divisão é simples: a carteira guarda o estado do usuário e os segredos que o abrem, a L1 guarda um commitment por peça de estado, um nullifier por peça gasta e o verifier de cada transição, e o compute no meio roda sem reter nada que o próximo job precise. O texto lembra que rollups já fazem commit-and-prove, mas guardam o estado dos usuários, e por isso todo rollup precisa de uma saída (exit). No L1.5, commitments e nullifiers vão direto para a L1.

O autor define quatro propriedades para um job ser L1.5 e não um operador: ser stateless, ter a saída verificada pela L1, ser pago sem vincular identidade e chegar à L1 sem conta de longa duração. A última depende de abstração de conta nativa. Pelo EIP-8141, uma transação é uma lista de frames, e um frame VERIFY (até 100.000 de gas, lendo só o estado do próprio remetente) pode aprovar execução e pagamento. O EIP-8250 permite nonces chaveados, por exemplo derivados de um nullifier. O EIP-8288 faz o bloco carregar uma única prova STARK recursiva. Segundo o texto, a EIP-8141 foi agendada para inclusão na Hegota em agosto, e o autor rodou um resgate de privacy pool na testnet Hegota. O texto também admite que parte das aplicações (tickets, fair exchange, stealth pool) são esboços que dependem de upgrades só propostos.

Em 3 de março de 2026, o CEVIU noticiou "Vitalik Comenta a EIP-8141: Uma Abordagem Integral à Abstração de Contas no Ethereum", quando as frame transactions eram descritas como proposta. Agora o EIP-8141 aparece como peça de um padrão concreto, com teste na Hegota. Em 10 de setembro de 2026, o CEVIU publicou "EIP-8250: Bloom Filters e a Otimização de Nonces no Ethereum", sobre nonces chaveados em vez de nonce único por conta. A novidade é o uso desses nonces como nullifiers contra gasto duplo. Em 27 de março de 2026, a cobertura sobre L1 e L2 como camadas complementares já tratava o papel da L1 em liquidação e estado compartilhado, linha que o L1.5 leva adiante ao tirar o estado do usuário de dentro do L2.

Para quem opera um L2 ou um app com privacidade, a leitura é que o modelo desloca o risco: sem operador que guarde estado, some a necessidade de exit e o ponto único de falha. Mas é uma proposta de pesquisa, e boa parte depende de EIPs que ainda não estão em produção. Vale tratar como direção de arquitetura, não como roteiro pronto.