Passei pela implementação de referência de @jbaylina e pelo POC de @mkoeppelmann. Algumas observações sobre o design e código do mecanismo.
1. Na tabela de execução Privacy e Builder MEV: Por que commit-reveal não ajuda (ainda)
@TimTinkers levanta uma preocupação crítica de que, se o construtor é quem gera as provas, a composição síncrona não se torna outro canal privado para o duopólio do construtor? A questão DOS de @tbrannt converge para a mesma questão estrutural.
Meu primeiro instinto foi que um esquema de confirmação-revelação poderia ajudar: forçar o remetente da tabela de execução a confirmar um hash antes de revelar o conteúdo, evitando que os construtores inspecionassem e reordenassem as tabelas de execução do usuário para extração de MEV.
Mas depois de rastrear ambas as implementações, percebi que isso não funciona na arquitetura atual, e o motivo é instrutivo:
O construtor é o construtor da tabela de execução. Em Rollups.sol, loadL2Executions() realiza execuções pré-computadas com uma prova ZK. Em Koeppelmann NativeRollupCore.sol, registerIncomingCall() e processSingleTxOnL2() desempenhar o mesmo papel. Em ambos os casos, a construção da tabela de execução requer:
- Saber o estado L1 exato contra o qual a transação será executada
- Simulando a execução L2 completa
- Gerando uma prova de validade
Somente o construtor/proponente do bloco tem (1) – eles sabem o estado do bloco pendente porque o estão construindo. Portanto, o construtor deve construir a tabela, o que significa que já conhece seu conteúdo. A confirmação-revelação protegeria o remetente do construtor, mas o remetente e o construtor são a mesma entidade.
Isso se torna um problema quando a composição síncrona permite entre domínios MEV que não existe hoje. No MEV de cadeia única, a vantagem do construtor é limitada à solicitação de transações dentro de um domínio. Com tabelas de execução, o construtor pode arbitrar atomicamente as discrepâncias de preços entre rollups, algo que atualmente exige estratégias de ponte multibloco com risco de liquidação. A tabela de execução é estritamente mais valiosa que um mempool de domínio único.
A revelação de compromisso ajudaria em um mercado de provadores descentralizado, onde usuários ou terceiros podem construir e enviar de forma independente tabelas de execução comprovadas. Isso é arquitetonicamente possível (loadL2Executions() não tem permissão), mas requer comprovação de que a infraestrutura está amplamente disponível, o que nos leva de volta ao ponto de @jbaylina sobre os requisitos de hardware não serem triviais.
A questão em aberto é sobre qual é o caminho de “o construtor constrói tudo” até “os usuários podem enviar suas próprias tabelas de execução comprovadas”? Protocolos de delegação de prova (onde os usuários podem terceirizar a prova sem revelar a intenção de execução) podem ser o primitivo que falta.
2. Custo de pesquisa de execução em escala
Em Rollups.sol, _findAndApplyExecution() faz uma varredura retroativa linear sobre todas as execuções armazenadas em um determinado actionHash. Na produção, diferentes construtores carregariam execuções especulativas para a mesma ação em diferentes instantâneos de estado. Isso faz a pesquisa O(n) por execução.
Chaveando execuções por keccak256(actionHash, currentStateRoots()) faria a pesquisa O(1) ao custo de uma construção de chave mais complexa durante loadL2Executions(). A economia no tempo de execução dominaria.
3. Limpeza de execução obsoleta
Execuções pré-carregadas que não podem mais corresponder (porque o estado de rollup avançou além de seu currentState instantâneos) persistem no armazenamento indefinidamente. Sem um mecanismo de expiração ou limpeza, o _executions o mapeamento acumula entradas mortas. Adicionando um blockLoaded campo e permitir a limpeza sem permissão após N blocos atenuaria isso.
4. Granularidade do modo de falha
Olhando para _handleScopeRevert()a propagação de reversão restaura de forma limpa as raízes do estado de rollup e continua via REVERT_CONTINUE. Isso fornece uma semântica de tudo ou nada em cada limite do escopo, o que é correto para o caso geral.
Para operações de liquidação de vários domínios (leitura Oracle em L1, verificação de conformidade em L1, pagamento em L2), a atomicidade estrita significa que toda a operação falhará se algum rollup único estiver temporariamente indisponível. UM TRY_CALL tipo de ação onde o chamador obtém (success, returnData) voltar e poder ramificar em vez de forçar uma reversão na cadeia de escopo permitiria uma degradação elegante. A tabela de execução precisaria codificar caminhos de sucesso e falha, o que aumenta a complexidade da prova, mas esperançosamente permite limites de atomicidade parciais.
5. Cobertura de teste entre domínios
Descobri que o conjunto de testes cobre completamente os fluxos de execução de rollup único, mas a proposta de valor principal das chamadas atômicas de vários rollup entre domínios ainda não foi testada. Um teste como Rollup A calls L1, which calls Rollup B, result propagates back and influences Rollup A's state transition seria o teste de integração canônica. Fico feliz em contribuir com um.
Para contextualizar, tenho analisado isso da perspectiva da liquidação paramétrica entre cadeias e da avaliação de risco. Portanto, aprofunde-se nos detalhes de como isso funcionaria para coisas como seguros, derivativos, etc., especificamente liquidação atômica entre cadeias e verificação de conformidade em tempo real. Compartilhei algumas idéias sobre isso em uma resposta recente do fórum Gnosis.
Fontesethresear
