Um L2 do Ethereum que aceita assinaturas zero parece um bug de segurança, mas o BB84 está fazendo isso intencionalmente para evitar ataques quânticos. No fim de semana passado, seu fundador, que posta como Hadamard, publicou o design no Ethereum Research e pediu feedback crítico. BB84 é um rollup da OP Stack no mainnet, ativo desde 30 de setembro, onde as transações L2 não utilizam ECDSA em absoluto. Cada conta é a ponta de uma cadeia de hashes keccak-256 construída a partir de um segredo, com 1.000 passos, por padrão. Para gastar, sua carteira revela o valor anterior na cadeia, que qualquer um pode verificar com um único hash. Dentro do L2, a única suposição restante é a resistência à pré-imagem do keccak-256, que o algoritmo de Grover reduz para cerca de 2^128 de trabalho. Revelar um segredo o torna público, então o protocolo adiciona um passo de commit e reveal para vincular cada pré-imagem a uma transação primeiro. Dois novos tipos de transação no op-geth lidam com isso, e a verificação do remetente substitui o ecrecover. A autorização é consumida mesmo quando a chamada é revertida, e se uma carteira perder o passo de renovação no último elo, esse endereço fica inativo. O post inclui uma falha de front-running que a equipe descobriu enquanto o escrevia. Commits não carregam assinatura, então um novo commit anteriormente podia substituir um pendente, e um atacante poderia vincular uma pré-imagem revelada ao seu próprio pagamento. Uma regra que entrou em vigor em 21 de outubro faz com que o primeiro commit vença. Os limites são explicitados claramente. Depósitos e saques L1 ainda usam ECDSA. Ainda não há fault proofs, e segundo o próprio post, a cadeia nem sequer alcançaria o Estágio 0 do L2BEAT. O sequenciador é executado pela equipe, e endereços de 160 bits deixam cerca de 2^80 de resistência quântica a pré-imagens secundárias. O post também pergunta se contas baseadas em cadeias de hash poderiam se tornar um EIP-7702 ou um modo nativo de validação de abstração de conta em L2s gerais.