Esta proposta é coautora por mim e @dcrapis
Gostaríamos de agradecer a @soispoke, @julian, @adietrichs e @vbuterin pela discussão, comentários e revisão.
Motivação
No Ethereum, usamos o gás como uma medida de dois conceitos importantes para o EVM. Por um lado, o gás é usado para medir o consumo de recursos por transações. Quanto mais uma transação usa, mais paga nas taxas de transação. Por outro lado, o gás também é usado para controlar os limites dos recursos e garantir que os blocos não estejam sobrecarregando a rede. Atualmente, os validadores aplicam um limite de 36 milhões de unidades de gás por bloco. Se um bloco precisar de mais do que esse limite, ele é considerado inválido.
Podemos pensar no primeiro uso do gás como “preço da transação” e o segundo como “medição de blocos”. Como a mesma métrica sempre representou os dois conceitos, é natural pensar neles como intercambiáveis. No entanto, argumentamos que podemos considerá -los separadamente e, de fato, há ganhos a serem obtidos ao fazê -lo. Mais concretamente, Podemos introduzir um esquema de medição multidimensional que seja responsável pelos diferentes recursos do EVM, mantendo o modelo de preços inalterado.
Mas qual é o benefício de fazer isso? Primeiro, o uso de um esquema multidimensional para os recursos do medidor nos permite embalar blocos com mais eficiência. Nesses esquemas, mesmo que um bloco já tenha atingido o limite de um recurso, ainda podemos adicionar mais transações a esse bloco se elas não usarem o recurso de gargalo. Por exemplo, um bloco que já está “cheio” dos dados de chamada ainda pode incluir transações com uso intensivo de computação que não gastam gás nos dados de chamada. Esta postagem do blog da Vitalik explica bem por que o atual esquema unidimensional não é ideal.
Com base em nossa análise empírica anterior, um esquema de medição de quadridimensional que separa computação, crescimento do estado, acesso ao estado e todos os outros recursos permitiriam um aumento de ~ 240% na taxa de transferência da transaçãoassumindo uma demanda infinita de transações históricas.
Segundo, embora os preços multidimensionais completos possam permitir preços mais flexíveis, essa flexibilidade tem o custo de uma experiência pior da UX para usuários finais e desenvolvedores (pois agora eles precisam lidar com várias taxas básicas e limites de gás) e o risco de incentivos adicionais para agrupar as transações para economizar em taxas de transação. Além disso, as restrições de EVM, como nos subcalões, tornam a implementação de preços multidimensionais tecnicamente desafiadores. Em outras palavras, não está claro se as vantagens dos preços multidimensionais superam os problemas em potencial. A troca é muito mais óbvia ao alterar o esquema de medição sozinho.
O novo esquema de medição
Nós propomos Medição multidimensional Como uma mudança na maneira como explicamos o gás usado em um bloco. Isso nos permite utilizar completamente o limite de gás para cada recurso individual, enquanto ainda estiver no limite de segurança, e produz ganhos significativos de rendimento sem alterar o limite de gás. Além disso, a transação UX e a estrutura das taxas cobradas pelos usuários permanecem inalteradas.
O novo esquema de medição apresenta uma nova variável chamada block.gas_metered. Durante a execução da transação, medidamos o gás usado ao longo de cada dimensão do recurso (computação, estado, acesso, memória, etc.), digamos (r_1, ... r_k). Então nós calculamos
block.gas_metered = max(r_1, ... r_k)Assim,
enquanto a fórmula para a definição atual de gás usada é
block.gas_used = sum(r_1, ... r_k).
Do Perspectiva do usuário tudo permanece o mesmo. Uma transação ainda tem um único tx.gas_limit e paga de acordo com o real tx.gas_used. O tx.gas_used e tx.gas_limit ainda são usados para verificar a condição “fora de gás” da transação (se durante a execução da transação tx.gas_used excede tx.gas_limit a transação é revertida).
No nível do bloco, block.gas_metered substitui block.gas_used em (1) Bloquear a condição de validade e (2) Cálculo de atualização de taxa EIP-1559.
LIMIT = 36_000_000
TARGET = LIMIT // 2
# sender is charged based on sum of resources
def compute_price_for_usage(tx_bundle):
return basefee * sum(tx_bundle)
# block limit is enforced on the highest individual resource
def is_valid_consumption(block_bundle):
return max(block_bundle) <= LIMIT
# basefee is updated using the highest individual resource
def compute_new_excess_gas(block_bundle):
return max(0, excess_gas + max(block_bundle) - TARGET)
Esta proposta tem as seguintes propriedades:
- Aumentar a utilização de recursos
- Mantenha o limite de segurança para cada recurso
- Sem alterações em UX
Essa mudança é relativamente simples em comparação com outras abordagens de preços multidimensionais e produz melhorias significativas com um aumento modesto na complexidade. Em particular, a construção ideal de blocos se torna mais difícil, mas as heurísticas simples ainda podem ser usadas para produzir blocos. As alterações do protocolo envolvem (i) a introdução de um cronograma de custo de gás para outros recursos que não a computação e (ii) medindo o gás usado por recurso. Observe que, como outros recursos que não a computação são usados por um número relativamente pequeno de códigos OPC, isso envolverá apenas o aumento do número de parâmetros de custo de gás de ~ 100 hoje para ~ 150 para explicar todos os outros recursos.
Além de produzir ganhos significativos diretamente, essa melhoria também é um importante Pedras de piso para desbloquear ganhos futuros de preços multidimensionais.
Exemplo
O block.gas_target e block.gas_limit Mantenha -se inalterado, 18m e 36m, respectivamente. Suponha que obtemos um bloco onde o perfil de demanda para cada recurso, medido em milhões de unidades de gás, é (18, 9, 9, 6, 3)onde cada dimensão no vetor é o gás atribuído a um único recurso. Este bloco seria inválido sob a especificação atual, pois sum(18, 9, 9, 6, 3) = 45 excede o limite de gás em 9 milhões de unidades de gás. Com a nova proposta, o gás medido é max(18, 9, 9, 6, 3) = 18 O que torna o bloco válido e também certo no Target, para que a taxa de gás não mude. Suponha que tenhamos um bloco com alta carga no segundo recurso (18, 30, 9, 6, 3)Assim, block.gas_metered = 30 milhões de unidades de gás. Embora ainda seja um bloco válido, pois está abaixo do limite, a taxa básica aumentará, pois está acima da meta.
PRÓXIMOS PASSOS
Duas perguntas -chave precisam ser respondidas para especificar completamente essa proposta. Primeiro, precisamos definir os recursos que queremos rastrear. O modelo de gás original foi projetado para explicar os seguintes recursos:
- Compute: o custo da execução/CPU, representando o trabalho computacional realizado durante a execução do contrato.
- Memória: Uma área transitória e expansível usada durante a execução para armazenamento temporário de dados, liberado após a conclusão da transação.
- Estado: o instantâneo atual de todos os saldos de conta, armazenamento de contratos e código mantidos em um trie Merkle Patricia.
- História: o registro completo de transações e transições de estado armazenadas na cadeia, que permite que os nós reconstruam os estados anteriores. A história pode ser podada, o que é uma diferença fundamental do estado.
- Leia / gravação Acesso: a quantidade de dados (componentes de prova) necessários para verificar uma leitura / gravação do estado no TRIE Merkle, impactando o custo e a eficiência da verificação.
- Largura de banda: o custo de compartilhar o conteúdo do bloco, ou seja, tamanho do bloco em KB.
- Tópico Bloom: Um valor de 32 bytes hashed dos tópicos de eventos incorporados em um filtro de Bloom de 2048 bits para filtragem de log eficiente e aceleração de consultas.
A questão é se o novo sistema de medição deve rastrear esses mesmos recursos ou não. Algum outro recurso deve ser adicionado (por exemplo, comprovando os custos)? Alguns recursos devem ser combinados para simplificar a medição? Com base em nossa análise anterior, há um ganho claro da separação de pelo menos computação, estado e acesso, pois esses são os recursos de gargalo em nossos dados. No entanto, podemos querer isolar mais recursos para à prova de futuro desta proposta.
A segunda questão é como dividir adequadamente o custo total do gás de cada operação de EVM nos vários recursos. Depois de definirmos os recursos, podemos realizar uma referência nos vários clientes da EL para medir os recursos usados por cada operação de EVM (códigos opciais, pré -compilos, etc.). Obviamente, isso requer definir como medir o uso do recurso. Por exemplo, para computação, podemos usar o tempo de execução, enquanto para a largura de banda, podemos rastrear o tamanho do bloco em KB. Depois de termos o uso de recursos para cada operação, podemos definir os limites de segurança para cada recurso e convertê -los em unidades de gás.
Esses benchmarks se conectam bem aos esforços atuais para aumentar o limite de gás. Aqui, as equipes de clientes já estão configurando benchmarks e testes para analisar o desempenho da rede. Um bom exemplo é o projeto do estimador de custos de gás, que implementa uma referência abrangente em diferentes clientes focados nos custos de computação. Além disso, este trabalho está intimamente ligado a esforços recentes de reprição, como EIP-7904 e EIP-7883.
Fontesethresear
