"EVM compatível" são quatro palavras já gastas até o osso na narrativa de escalabilidade do ecossistema ETH, mas se você abrir de verdade o fluxo de saída do OP Stack, vai ver que não está fazendo uma ponte entre cadeias, e sim conciliando uma máquina de estados de quatro etapas: L2 inicia → espera o output proposal cobrir aquele estado → no L1, o prove_withdrawal entrega a prova de Merkle → só depois de concluir a janela de disputa de 7 dias o finalize pode acontecer. No Base/OP Mainnet, os usuários já reclamaram bastante dessa conta: entre as três primeiras etapas, os fundos ficam presos no contrato L1 bridge; não é perda, mas também não é, de forma alguma, seu; se em qualquer passo faltar gas no L1, o output root for contestado ou o proposer parar, a retirada fica travada em "Ready to prove" ou "Waiting for finalization".
No Arbitrum, à primeira vista só há duas etapas (criar um retryable ticket no L1 + executar no L2), mas se o ticket falhar no redeem automático, ele cai num buffer de memória; dentro de 7 dias qualquer pessoa pode fazer redeem manualmente, e só após o prazo o escrow é reembolsado; o pior é o execício fora de ordem apontado pelo Trail of Bits — se A não conclui e B já roda, e o protocolo não lida com essa temporalidade, isso equivale a enterrar uma vulnerabilidade do tipo reentrância. Isso mostra que "menos etapas" não significa "estado mais compreensível"; apenas esconde a complexidade dentro de um precompile.
Por isso, no #dusk EVM Testnet, dividir a retirada em initiate / submit proof / finalize não é porque @Dusk quis dificultar a vida do usuário; é porque ele não simplificou discretamente a lógica de "janela de contestação de 7 dias + maturidade da prova" da OP. Mas rodar na testnet com tokens de teste só prova que a carteira consegue reconhecer enums de estado como Waiting for output proposal / Ready to prove / Waiting to finalize; não prova que, sob carga alta na mainnet, o proposer consegue publicar roots de forma estável, que o dispute game não é arrastado até travar por contestações contínuas, nem que o usuário terá gas suficiente ao mesmo tempo na camada EVM e para as duas operações no L1.
Quando analiso as pontes de L2 da ETH, nunca conto "quantas toolchains elas suportam"; só aceito três sinais fortes: se a mediana do tempo de saída converge para baixo, saindo do valor teórico de 7 dias; se uma falha no prove consegue pegar o próximo output root e continuar a vida sem refazer todo o fluxo; e se, quando os ativos travam, o usuário consegue ler no contrato no Etherscan a prova de armazenamento daquela withdrawal. Menos botões é doce de UX; estado explicável é o verdadeiro fundo da segurança. Antes que essas três coisas sejam revalidadas pelos dados da mainnet, "EVM compatível" é apenas conveniência para desenvolvedores, não prontidão para usuários — $DUSK assim, Base assim, Arbitrum também assim.
No Arbitrum, à primeira vista só há duas etapas (criar um retryable ticket no L1 + executar no L2), mas se o ticket falhar no redeem automático, ele cai num buffer de memória; dentro de 7 dias qualquer pessoa pode fazer redeem manualmente, e só após o prazo o escrow é reembolsado; o pior é o execício fora de ordem apontado pelo Trail of Bits — se A não conclui e B já roda, e o protocolo não lida com essa temporalidade, isso equivale a enterrar uma vulnerabilidade do tipo reentrância. Isso mostra que "menos etapas" não significa "estado mais compreensível"; apenas esconde a complexidade dentro de um precompile.
Por isso, no #dusk EVM Testnet, dividir a retirada em initiate / submit proof / finalize não é porque @Dusk quis dificultar a vida do usuário; é porque ele não simplificou discretamente a lógica de "janela de contestação de 7 dias + maturidade da prova" da OP. Mas rodar na testnet com tokens de teste só prova que a carteira consegue reconhecer enums de estado como Waiting for output proposal / Ready to prove / Waiting to finalize; não prova que, sob carga alta na mainnet, o proposer consegue publicar roots de forma estável, que o dispute game não é arrastado até travar por contestações contínuas, nem que o usuário terá gas suficiente ao mesmo tempo na camada EVM e para as duas operações no L1.
Quando analiso as pontes de L2 da ETH, nunca conto "quantas toolchains elas suportam"; só aceito três sinais fortes: se a mediana do tempo de saída converge para baixo, saindo do valor teórico de 7 dias; se uma falha no prove consegue pegar o próximo output root e continuar a vida sem refazer todo o fluxo; e se, quando os ativos travam, o usuário consegue ler no contrato no Etherscan a prova de armazenamento daquela withdrawal. Menos botões é doce de UX; estado explicável é o verdadeiro fundo da segurança. Antes que essas três coisas sejam revalidadas pelos dados da mainnet, "EVM compatível" é apenas conveniência para desenvolvedores, não prontidão para usuários — $DUSK assim, Base assim, Arbitrum também assim.