Rascunho na Ethereum propõe pagamentos compartilhados para provas em lote

ETH
verificação de provaspagamentos patrocinadosproposta de rascunhoprovas em loteEthereumEIP
há 17 horasFonte: crypto.news
Rascunho na Ethereum propõe pagamentos compartilhados para provas em lote

O colaborador do Ethereum Marchhill submeteu uma proposta preliminar para permitir verificação genérica de provas e processamento em lote patrocinado, permitindo que múltiplas reivindicações de transação compartilhem uma prova enquanto mantêm pagamentos e assinaturas separados.

Resumo

  • Patrocinadores poderiam pagar por provas em lote enquanto as transações dos membros pagam por suas reivindicações individuais.
  • Subconjuntos válidos poderiam entrar em um bloco sem exigir que os membros assinem suas transações novamente.
  • As taxas propostas e os limites de recursos permanecem provisórios, com ativação dependente de medições de desempenho.
  • A submissão é um pull request preliminar, sem número de EIP atribuído ou data de ativação na mainnet.

A proposta de Marchhill, submetida ao repositório de EIPs do Ethereum em 13 de novembro, ativaria o LEANSTARK_SCHEME reservado na EIP-8288 e introduziria regras para lotes patrocinados. A submissão permanece em desenvolvimento e não foi adotada como uma atualização da rede Ethereum.

O rascunho reúne verificação genérica, identidade de prova, limites de recursos, resumos de dependência e pagamentos em lote em uma única proposta. Ele substitui uma submissão anterior, o pull request #12654, enquanto um número de EIP e uma thread de discussão dedicada ainda precisam ser atribuídos.

Provas em lote do Ethereum separariam pagamentos de patrocinadores e membros

No centro do rascunho está um arranjo de pagamento no qual um patrocinador cobre cada folha de lote retida, um componente individual de prova contendo várias reivindicações. As transações dos membros pagariam de acordo com suas próprias reivindicações submetidas.

Um construtor poderia incluir qualquer subconjunto válido sem pedir aos membros que assinassem novamente. Alguém cuja transação estivesse pronta para inclusão, portanto, não precisaria de uma nova assinatura apenas porque outros membros do grupo original foram deixados de fora, de acordo com o mecanismo proposto.

O rascunho preservaria nonces e recibos individuais de transação. Um nonce identifica a posição de uma transação na sequência de transações de uma conta, enquanto um recibo registra seu resultado de execução. Compartilhar o trabalho de prova deixaria esses registros vinculados às transações separadas.

A correspondência de pagamentos seria verificada durante a finalização, com provas recursivas autenticando as fontes usadas no lote. A submissão distingue o trabalho de estabelecer que as reivindicações são válidas do trabalho de confirmar que os pagamentos necessários as acompanham.

Reivindicações com desconto e pagamentos de patrocinadores iriam diretamente para os construtores de blocos. Provas ordinárias cobrindo uma única declaração permaneceriam elegíveis para o mempool público, onde as transações aguardam para serem incluídas em blocos.

Verificação genérica se baseia na EIP-8288

A EIP-8288 subjacente, de autoria de Vitalik Buterin e Thomas Coratger, propõe agregar assinaturas criptográficas e provas fora do processo de execução principal do Ethereum. As transações identificariam as declarações que precisam ser verificadas, e um STARK recursivo estabeleceria sua validade no nível do bloco.

STARKs são provas criptográficas que demonstram que uma computação foi realizada corretamente sem exigir que cada verificador a repita. A recursão permite que uma prova verifique outras provas, combinando seus resultados.

A EIP-8288 atualmente reserva o esquema genérico leanSTARK em vez de permitir seu uso em quadros de dependência. A submissão de Marchhill propõe habilitar esse caminho e substituir a declaração de hash de dados simples do rascunho base por um digest estável representando uma lista de reivindicações.

O design segue a discussão anterior sobre verificação criptográfica, incluindo o apoio de Buterin ao tratamento de criptografia complexa por meio de provas agregadas. Seus comentários diziam respeito à arquitetura subjacente; o rascunho de Marchhill estabelece um arranjo específico de verificação e pagamento.

As cobranças propostas permanecem sujeitas a calibração

A revisão fornecida lista cobranças provisórias de 15.400 de gas para verificação nativa e 572.000 de gas para verificação genérica ordinária. Ela atribui 5.100 de gas à parcela intrínseca de prova, 675.000 de gas a um pagamento de folha e 4.200 de gas a uma reivindicação de lote.

Os pagamentos de folha têm uma cobrança separada porque os pagamentos vinculativos adicionam trabalho fixo além da verificação ordinária, explica o rascunho. Reivindicações e pagamentos não incorreriam em parcela intrínseca de prova adicional. Os números exigem calibração conjunta, portanto não estabelecem uma tabela final de taxas nem uma economia confirmada para os usuários.

Os controles de recursos incluem um limite provisório de bloco de 16.384 dependências distintas, aplicado independentemente do gás, juntamente com uma regra correspondente de adequação à lista de inclusão. Uma folha poderia conter até 256 declarações, enquanto uma etapa de prova poderia ter 16 entradas. Nenhum dos números é um limite de bloco inteiro.

A ativação exigiria medições de desempenho de bloco completo

Antes da ativação, a proposta exige medições que abranjam o cronograma completo de processamento, o reparo tardio do patrocinador e as cobranças por prova que se enquadrem nos limites de gás da transação, incluindo a sobrecarga necessária.

Seu material de referência distingue resultados de bloco medidos em nó individual e em máquina única dos números modelados para 16 trabalhadores. O rascunho exige que as evidências e as lacunas de desempenho remanescentes sejam registradas em seu material de referência.

Um patrocínio invalidado poderia desperdiçar o trabalho de um construtor, e a submissão afirma que o gás de inclusão não reembolsaria esse trabalho. A construção concreta de compromissos e as codificações permanecem na especificação fixada do sistema de provas. A proposta não introduz novas mensagens de rede.