BALs para compromissos do proponente – Pesquisa da camada de execução

Graças a Tony e Ladislau para discussão e feedback.

EIP-7928 introduz listas de acesso em nível de bloco (BALs) para melhorar a execução paralela em L1. Além do escalonamento, os BALs também abrem uma base mais simples para protocolos de compromisso de proponentes, especialmente pré-configurações de execução. Em vez de confiar em provas fragmentadas em vários Merkle Patricia Tries, os BALs fornecem um registro canônico de todos os valores pós-transação aos quais os compromissos podem ser vinculados.

Dito isto, a especificação atual do EIP-7928 não é diretamente passível de eficiente Provas de nível EVM. Esta postagem tem como objetivo motivar o uso de BALs para pré-confs, destaca as alterações propostas nas especificações para torná-las fáceis de verificar e descreve as compensações de complexidade em discussão no Discord.

Motivação

Os pré-conf de execução permitem que os proponentes (ou delegados) forneçam aos usuários compromissos antecipados sobre os resultados das transações antes de entrarem na cadeia. Isso reduz o tempo de pré-confirmação para apenas um único “ping” da pré-conferência para o usuário, fornecendo uma UX que é mais rápida do que um protocolo de consenso pode alcançar. Em vez de esperar por confirmações de bloqueio, os usuários podem agir com confiança no momento em que recebem uma mensagem. credível pré-configuração de execução.

Hoje, compromissos credíveis exigem a capacidade de provar sem confiança quando um compromisso foi quebrado para impor condições de corte na cadeia contra preconferências vinculadas (por exemplo, usando o URC). Essas provas estão espalhadas por várias tentativas: a tentativa de transação para inclusão/pedido, a tentativa de recebimento para execução bem-sucedida, a tentativa de conta para alterações nonce ou de saldo e a tentativa de estado para armazenamento. Isso funciona, mas sofre de fragmentação, requer lógica de prova personalizada e é limitado em granularidade.

1. fragmentação: a cobertura completa requer a confirmação de valores em várias tentativas para cada parte do estado modificado.

2. lógica: Cada compromisso faz promessas diferentes e afeta estados diferentes, exigindo lógica personalizada.

3. granularidade: As tentativas apenas registram o estado após a aplicação de todas as transações, o que significa que atualizações de estado intermediário (por exemplo, o saldo de Alice após a quarta transação) não são diretamente comprováveis.

Alguns designs propostos funcionam em torno de 1) e 3) reverter transações se o pós-estado se desviar do que o usuário esperava, por exemplo, “vender 1000 USDC por pelo menos 0,98 ETH”. Embora pragmático, isto transfere o fardo para os promotores de contratos, que devem codificar estas condições manualmente. Na prática, assemelha-se à programação de estilo intencional, onde cada ação carrega condições de validade personalizadas.

Ao fornecer um registro canônico de diferenças de estado em nível de transação, os BALs oferecem uma primitiva mais simples para construir protocolos de compromissos de proponentes. Um pré-conf de execução pode ser expresso como um compromisso com um subconjunto de um BAL, e compromissos quebrados podem ser comprovados em relação ao BAL canônico. Isso torna os compromissos mais simples de raciocinar, aplicar e padronizar, reduzindo o atrito tanto para os projetistas de protocolos quanto para os usuários. Como resultado, um único protocolo genérico de compromisso do proponente que aproveite efetivamente os BALs poderia cobrir todos os casos de uso pré-configurados atuais.

BALs hoje

Um BAL é um código RLP List(AccountChanges)onde um AccountChanges o objeto registra alterações de estado por transação no nonce, saldo, armazenamento e/ou código de um endereço. Ao aplicar iterativamente todos AccountChangesum cliente pode reconstruir de forma determinística e paralela como cada conta afetada evoluiu ao longo do bloco.

Isso é suficiente para enfrentar nossos desafios com pré-configurações de execução:

1. fragmentação: Somente o BAL é necessário para assumir compromissos versus múltiplas tentativas

2. lógica: Um único protocolo genérico é suficiente para capturar todos os casos de uso pré-configurados atuais sem programação de estilo intencional.

3. granularidade: AccountChanges objetos permitem compromissos com diferenças de estado por transação.

Limitação atual

Claramente os BALs melhoram os protocolos pré-conf; no entanto, o desafio reside na forma como os BALs são codificados. De acordo com as especificações EIP-7928 atuais, os BALs são codificados em RLP e o cabeçalho do bloco contém o hash BAL.

Isto torna difícil provar ao EVM que um compromisso foi quebrado. Um usuário precisaria passar todo o BAL como calldata, verificar seu hash em relação ao hash do bloco pai e, em seguida, decodificar RLP manualmente para localizar o valor conflitante. Atualmente, um BAL não compactado é da ordem de aproximadamente 100 KB, o que está dentro do limite de dados de chamada. Dados compromissos quebrados deve ser uma ocorrência rara, isso não é irracional.

Alteração proposta de EIP (mais difícil)

À medida que os blocos e BALs crescem, passar o BAL como calldata será ainda mais caro. A alteração proposta tornaria mais fácil comprovar a adesão ao BAL pelo EVM.

Como é improvável que os clientes de execução utilizem SSZ para codificar o BAL, uma abordagem alternativa é codificar o BAL como seu próprio MPT, conforme proposto por Toni. O cabeçalho do bloco conteria a raiz BAL em vez do hash, permitindo provas MPT eficientes em relação ao hash pai EIP-2935.

Uma codificação ideal para pré-confs teria dois níveis de tentativas. A tentativa externa mapeia o bal_index (também conhecido como índice de transação) chave para um subTrieRoot valor, onde cada bal_index representa um índice de transação exclusivo. O interior subTrie contém chaves exclusivas que cobrem todas as diferentes alterações da conta:

• RLP(("balance_change", address))

• RLP(("storage_change", address, slot))

• RLP(("nonce_change", address))

• RLP((“code_change”, address))

com valores contendo os dados pós-transação codificados em RLP (ou seja, RLP((uint256))).

Isto permitiria que uma pré-conferência assumisse compromissos sucintos sobre diferenças de estado pós-transação, ou seja, uma assinatura sobre um subTrieRoot para um determinado bal_index. Provar que um compromisso foi quebrado reduz-se então a mostrar que o valor real subTrieRoot nisso bal_index difere daquele assinado. A conta individual muda no subTrie são abstraídos do protocolo de compromisso.

Isso é muito mais simples do que a situação atual, onde uma pré-conferência precisaria se comprometer com diferenças pós-estado em diversas tentativas para cada local que uma transação tocasse. Em vez disso, cada transação agora se resume a um único pacote bem organizado. subTrieRoot.

No entanto, esta abordagem requer a introdução de outra tentativa que aumenta a complexidade do EIP.

Alteração proposta de EIP (mais fácil)

Supondo que o cabeçalho do bloco ainda esteja comprometido com o hash BAL codificado em RLP, uma ligeira reestruturação do layout BAL pode simplificar enormemente os compromissos. Esta proposta consiste em indexar o BAL por bal_index em vez de contas, de modo que o BAL seja codificado como um código RLP List(TransactionDiff).

UM TransactionDiff conteria todas as alterações de nonce, saldo, armazenamento e código de uma determinada transação. Isto colapsaria o compromisso de muitos AccountChanges valores para um TransactionDiffque funciona exatamente como o subTrieRoot na proposta anterior.

Comprometendo-se sucintamente com um TransactionDiff tornaria a construção contínua de blocos mais uma realidade, já que as carteiras e o restante do pipeline do PBS podem se manter atualizados com o estado mais recente após a aplicação de pré-confs de execução.

Outros benefícios dos BALs

• Os principais rollups já estão experimentando confirmações mais rápidas para melhorar a experiência do usuário por meio de esquemas de compromisso como fragmentos, flashblocks e frags. Hoje, estes dependem de implementações de terceiros e os compromissos exigem confiança total no sequenciador.

  Os BALs padronizam esse padrão: os rollups que usam BALs não precisam mais manter seus próprios esquemas de compromisso personalizados e os usuários podem se beneficiar mais facilmente de compromissos confiáveis. Com efeito, os BALs consagram o que já começa a acontecer na prática.

• Vitalik apontou que o BAL como uma abordagem MPT permite que nós parciais sem estado verifiquem provas apenas sobre as partes dos BALs que lhes interessam, ou seja, como meu equilíbrio mudou ao longo do bloco.

• Os pré-confs de execução são um precursor fora do protocolo para ideias como fragmentação de carga útil.