Graças a Mteam, Justin Drake e Jonny Rhea, pelo feedback e comentários sobre este artigo. Obrigado ao Ink L2 por financiar minha pesquisa
As confirmações pretações em roluss otimistas podem oferecer níveis variados de garantias aos usuários, desde a inclusão básica a fortes garantias sobre os resultados de pedidos e execução. No entanto, a falta de uma taxonomia formalizada levou a definições sobrepostas e às vezes tautológicas nas discussões. Este documento propõe uma categorização estruturada de garantias de pré -confirmação, com o objetivo de estabelecer limites claros entre cada tipo. Ele também define as condições de corte associadas e as complexidades computacionais necessárias para aplicá -las, permitindo que os designs de rollup raciocinam rigorosamente sobre segurança, UX e compensações de implementação.
Existem três garantias essenciais a uma confirmação pré -pretenente:
-
Inclusão
A aplicação da inclusão através de uma mensagem assinada requer que o sequenciador pré -confirmador inclua a transação no bloco especificado. -
Pedindo
A aplicação da ordem através de uma mensagem assinada requer que o sequenciador pré -confirmador inclua a transação no número de sequência especificado no bloco especificado. -
Sucesso de execução
O sucesso da execução garante que a transação não seja revertida. Se o usuário quiser um pós-estado específico, poderá codificar as condições necessárias na própria lógica de transação, para que qualquer desvio cause reversão. Assim, as garantias pós-Estado podem ser incluídas no sucesso da execução.
Categoria 0
A inclusão é garantida. Não há garantias de solicitar ou executar sucesso.
Esta é a mais fraca das garantias. O transactor recebe uma garantia de inclusão por meio da resposta pré -confirmação. No entanto, a ordem não é garantida e o resultado da execução é incerto.
A condição de corte para essa categoria seria uma prova de não inclusão para a transação na árvore de transações.
No entanto, uma prova de não inclusão para uma árvore de transação não ordenada pode ser computacionalmente complexa dentro do EVM, exigindo uma prova de exclusão para todas as transações dentro da árvore de transações.
Exemplo:
Dex Mempool Inclusão para ordens limitadas
Um usuário envia um pedido limite para um DEX baseado em rollup. O sequenciador fornece uma garantia assinada de que a transação será incluída no próximo bloco, mas a ordem final não é especificada. Isso permite que o Frontend do Dex mostre ao usuário que seu pedido será considerado, mas sem fazer promessas sobre o sucesso ou o resultado da execução (que pode ser afetado por derrapagem, condições de corrida ou pioneiro).
Categoria 1
Inclusão e pedidos são garantidas. O sucesso da execução não é garantido.
A condição de corte para essa categoria seria uma prova de não inclusão para a transação na árvore de transações.
O uso de um número de sequência para uma transação de sequenciador assinado reduz a complexidade computacional, permitindo que a prova de não inclusão seja uma prova por contradição, fornecendo a transação na sequência especificada e a testemunha de Patricia Merkle Tree (PMT).
Exemplo:
NFT cunhando com slot prioritário
Durante uma queda da NFT, os usuários podem pagar por slots prioritários de hortelã. O seqüenciador retorna uma pré -confirmação assinada, prometendo que uma transação de cunhagem será incluída em uma posição de sequência específica. No entanto, se o usuário tiver fundos ou gás insuficientes, a transação ainda poderá reverter. Isso garante justiça em ordenar enquanto descarrega o risco de execução para o usuário.
Categoria 2
O sucesso de inclusão e execução é garantido. Nenhuma garantia de pedido.
Esta categoria garante que a transação seja executada sem reversão, mas permite que o sequenciador a reordene dentro do bloco. Os resultados pós-estados específicos não são aplicados pelo sequenciador, mas podem ser codificados pelo transactor diretamente na lógica da transação, transformando qualquer estado inesperado em uma revertência. Assim, as garantias pós-estados são uma função dos invariantes de transações definidas pelo usuário.
A condição de corte para essa categoria seria idêntica à categoria 0. No entanto, a prova de não reversão exigirá a reexecução do bloco dentro do EVM até a transação ser executada.
Exemplo:
Dex comércio de DEX com flexibilidade de MEV com flexibilidade
Um usuário envia uma troca para um DEX com um deslizamento máximo especificado (por exemplo, “venda 1000 USDC por pelo menos 0,98 ETH”). O seqüenciador retorna uma confirmação prévia que a transação será bem-sucedida (ou seja, não reverter), desde que o preço pós-negociação permaneça dentro da tolerância ao deslizamento do usuário. O sequenciador é livre para reordenar esse comércio em relação a outros e extrair MEV (por exemplo, sanduíche) enquanto a execução final permanecer dentro dos limites e ter sucesso. Isso confere à confiança da execução do usuário sem exigir uma ordem específica ou raiz de estado.
= Garantido | = Não garantido
* O (m) implica execução de transação
Nota de rodapé sobre a complexidade da condição de corte
Embora a abordagem ingênua para verificar as condições de corte (por exemplo, provar não inclusão ou execução com falha) possa exigir operações O (n) ou O (M) no EVM, esses custos podem ser significativamente reduzidos através de sistemas de prova criptográfica. Se o rollup aproveitar as estradas (ou provas sucintas similares), toda a verificação de corte-indefinindo se está checando a inclusão ou o sucesso da execução-poderá ser comprimido para um custo de verificação em tempo constante na cadeia, reduzindo efetivamente a complexidade computacional para O (1).
Por que o colapso pós-estado garante o sucesso da execução?
Se um usuário se preocupa com o estado final resultante de uma transação, poderá codificar essas expectativas como afirmações dentro da própria transação. Se as afirmações falharem, a transação reverter e o seqüenciador não poderá satisfazer uma garantia de sucesso de execução. Isso torna redundante o pós-estado separado: o sucesso da execução já implica que a transação executada exatamente como o usuário pretendia.
Fontesethresear
