BALS para compromissos de propositores – pesquisa de camada de execução

Obrigado a Toni e Ladislaus para discussão e feedback.

O EIP-7928 apresenta listas de acesso em nível de bloco (BALS) para melhorar a execução paralela em L1. Além da escala, Bals também desbloqueia uma base mais simples para protocolos de compromisso de propositores, especialmente Preconfs de execução. Em vez de confiar em provas fragmentadas em várias tentativas de Merkle Patricia, as bals fornecem um registro canônico de todos os valores pós-transação aos quais os compromissos podem ser vinculados.

Dito isto, as especificações atuais do EIP-7928 não são diretamente passíveis de eficiente Provas no nível do EVM. Esta postagem tem como objetivo motivar o uso de BALS para PreCONFs, destaca as alterações propostas para torná-las amigas à prova e descreve as compensações de complexidade em discussão em discórdia.

Motivação

A execução PreCONFS permite que os proponentes (ou delegados) dêem aos usuários compromissos precoces sobre os resultados da transação antes que eles atinjam a cadeia. Isso reduz o tempo de confirmação pré -preten a apenas um “ping” do premiário para o usuário, fornecendo um UX mais rápido do que o que um protocolo de consenso pode alcançar. Em vez de esperar por confirmações de blocos, os usuários podem agir com confiança no momento em que recebem um credível execução PreConf.

Hoje, os compromissos credíveis exigem que seja capaz de provar sem confiança quando um compromisso foi interrompido para impor condições de corte na cadeia contra pré -fers de ligação (por exemplo, usando o URC). Essas provas estão espalhadas por várias tentativas: o Trie de transação para inclusão/pedido, o Trie de recebimento para o sucesso da execução, o Trie de conta para alterações de NONCE ou BALANCE e o Trie State for Storage. Isso funciona, mas sofre de fragmentação, requer a lógica de comprovação sob medida e é limitada em granularidade.

1. fragmentação: A cobertura completa requer compromisso com os valores em várias tentativas para cada parte do estado modificado.

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

3. granularidade: As tentativas registram apenas o estado depois de aplicar todas as transações que significa 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) transações revertidas se o pós-estado se desviar do que o usuário esperava, por exemplo, “venda 1000 USDC por pelo menos 0,98 ETH”. Embora pragmático, isso muda o ônus para os desenvolvedores de contratos, que devem codificar essas condições manualmente. Na prática, assemelha-se à programação de estilo intenção, onde toda ação carrega condições de validade sob medida.

Ao fornecer um registro canônico de diferenças de estado no nível da transação, as BALS oferecem um primitivo mais simples para criar protocolos de compromissos de propositores. Um preconef de execução pode ser expresso como um compromisso com um subconjunto de um BAL, e compromissos quebrados podem ser comprovados contra o BAL canônico. Isso simplifica os compromissos mais simples sobre, aplicar e padronizar, diminuir o atrito para designers e usuários de protocolo. Como resultado, um único protocolo de comprometimento de propositores genéricos que aproveita efetivamente as BALS pode cobrir todos os casos de uso de preconetes atuais.

Bals hoje

Um BAL é um RLP codificado List(AccountChanges)onde um AccountChanges REGISTROS DE OBJETO ATRANSAÇÃO O estado de transação muda para o nonce, equilíbrio, armazenamento e/ou código de um endereço. Aplicando iterativamente todos AccountChangesum cliente pode determinicamente e paralelo, reconstruir como toda conta afetada evoluiu ao longo do bloco.

Isso é suficiente para enfrentar nossos desafios com a execução PreConfs:

1. fragmentação: Somente o BAL é necessário para assumir compromissos versus várias tentativas

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

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

Limitação atual

Claramente, as balas melhoram os protocolos PreCONF; No entanto, o desafio está em como as BALS são codificadas. Nas especificações atuais do EIP-7928, as bals são codificadas por RLP e o cabeçalho do bloco contém o hash BAL.

Isso torna mais pesado provar ao EVM que um compromisso foi quebrado. Um usuário precisaria passar por todo o BAL como calldata, verificar seu hash contra o hash do bloco pai e, em seguida, manualmente, RLP-Decode para localizar o valor conflitante. Atualmente, um BAL não compactado está na ordem de ~ 100kb, que está dentro do limite de caldata. Dado compromissos quebrados deve Seja uma ocorrência rara, isso não é irracional.

Mudança EIP proposta (mais difícil)

À medida que os blocos e as bals aumentam, passar o BAL como Calldata será ainda mais caro. A mudança proposta facilitaria a provar a associação à BAL do EVM.

Como é improvável que os clientes de execução usem o SSZ para codificar o BAL, uma abordagem alternativa é codificar o BAL como seu próprio MPT, conforme proposto pela TONI. O cabeçalho do bloco conteria a raiz BAL em vez do hash, permitindo provas de MPT eficientes contra o hash dos pais EIP-2935.

Uma codificação ideal para preconetos teria dois níveis de tentativas. O trie externo mapeia o bal_index (também conhecido como índice de transação) chave para um subTrieRoot valor, onde cada um bal_index representa um índice de transação exclusivo. O interior subTrie Contém teclas exclusivas que cobrem todas as diferentes mudanças na 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 por RLP (ou seja, RLP((uint256))).

Isso permitiria que um pré-dom subTrieRoot para um dado bal_index. Provando que um compromisso foi quebrado, então reduz a mostrar que o real subTrieRoot nisso bal_index difere do assinado. A conta individual muda no subTrie são abstraídos do protocolo de compromisso.

Isso é muito mais simples do que a situação de hoje, onde um pré-domínio precisaria se comprometer com diferenças pós-estados em várias tentativas para cada local que uma transação toque. Em vez subTrieRoot.

No entanto, essa abordagem requer a introdução de outro trie que aumente a complexidade do EIP.

Mudança EIP proposta (mais fácil)

Supondo que o cabeçalho do bloco ainda se comprometa com o hash BAL codificado por RLP, uma ligeira reestruturação do layout BAL pode simplificar bastante compromissos. Esta proposta é indexar o BAL por bal_index em vez de contas, de modo que o BAL seja codificado como um RLP codificado List(TransactionDiff).

UM TransactionDiff Conteria todas as alterações de NONCE, BALANCE, ARMAZENAMENTO e Código da transação fornecida. Isso entraria em colapso no compromisso de muitos AccountChanges valores para um TransactionDiffque funciona como o subTrieRoot na proposta anterior.

Sucintamente se comprometendo com um TransactionDiff Tornaria a construção de blocos contínuos mais realidade, pois as carteiras e o restante do oleoduto da PBS podem se manter atualizados com o estado mais recente após a aplicação de preconetos de execução.

Outros benefícios do BALS

• Os principais roluss já estão experimentando confirmações mais rápidas para melhorar o UX por meio de esquemas de compromisso, como fragmentos, bloqueios de flash e frags. Hoje, eles dependem de implementações de terceiros e os compromissos exigem confiar totalmente no seqüenciador.

  BALS padroniza 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 credíveis. Com efeito, Bals consagra o que já está começando a acontecer na prática.

• Vitalik apontou que o BAL como uma abordagem MPT permite que nós apátridas parciais verifiquem as provas sobre apenas as partes dos BALS com os quais se preocupam, ou seja, como meu equilíbrio mudou ao longo do curso.

• Os PreCONFs de execução são um precursor fora do protocolo de idéias como Chunking da carga útil.