Como os desenvolvedores do DAPP podem otimizar a velocidade e o custo da transação Ethereum

Tabela de hyperlinks

Resumo e 1 Introdução

2 Antecedentes e 2.1 blockchain

2.2 Transações

3 Exemplo motivador

4 tempos de processamento de transações de computação

5 coleta de dados e 5.1 fontes de dados

5.2 Abordagem

6 resultados

6.1 RQ1: Quanto tempo leva para processar uma transação no Ethereum?

6.2 RQ2: Qual a precisão das estimativas para o tempo de processamento de transações fornecido pelo EtherScan e EtgasStation?

7 Um modelo mais simples pode ser derivado? Um estudo post-hoc

8 implicações

8.1 Que tal usuários finais?

9 Trabalho relacionado

10 ameaças à validade

11 Conclusão, isenção de responsabilidade e referências

A. Tempos de processamento de transações de computação

A.1 TIMESTAMP pendente

A.2 Timestamp processado

B. RQ1: distribuição de preços de gás para cada categoria de preço do gás

B.1 Análise de sensibilidade no lookback do bloco

C. RQ2: Resumo das estatísticas de precisão para os modelos de previsão

D. Estudo post-hoc: Resumo das estatísticas de precisão para os modelos de previsão

8 implicações

A seguir, discutimos as principais implicações de nossas descobertas.

EUmplication 1) Os desenvolvedores de ðapp agora têm uma linha de base para os tempos de processamento de transações no Ethereum. Até onde sabemos, nosso estudo é o primeiro a investigar empiricamente os tempos de processamento de transações no Ethereum. Em specific, o RQ1 inclui várias informações que os desenvolvedores de ðapp podem usar como critério. Essas informações também devem ser úteis para organizações que desejam avaliar a adequação da plataforma Ethereum como um again -end para um prospectivo. Por exemplo, na observação 1, observamos que três trimestres dos tempos de processamento estão na faixa de 33 a 2m 23s. Como parte da observação 2, também mostramos que os preços mais usados ​​e seu respectivo tempo de processamento do percentil 90 (Tabela 3). Como parte da observação 3, analisamos os preços do gás, agrupamos -os em categorias e descrevemos os intervalos dessas categorias (Tabela 4). Esses intervalos devem ajudar os desenvolvedores a entender o que é considerado barato e o que é considerado caro em termos de preço do gás. Finalmente, nossas estatísticas para o tempo de processamento podem ser usadas como uma linha de base para avaliar a eficácia das alterações que melhoram o rendimento nas versões futuras da plataforma Ethereum.

Implicação 2) Os desenvolvedores de ðapp podem avaliar melhor o trade-off entre o tempo de processamento e o custo da transação. Na observação 4, destacamos que os preços mais altos do gás têm retornos decrescentes em termos de tempo de processamento. Portanto, os desenvolvedores ðapp devem avaliar cuidadosamente se o uso de preços mais altos do gás é digno. Em specific, nossas descobertas indicam que os desenvolvedores ðapp normalmente devem evitar transações muito caras, pois não há diferença prática (conforme o delta do penhasco) em seu tempo de processamento em comparação com transações caras.

Implicação 3) Os desenvolvedores de ðapp podem tomar decisões mais informadas sobre a escolha de um modelo de previsão para os tempos de processamento de transações no Ethereum. No RQ2, mostramos que o EtherScan Fuel Tracker é o melhor modelo para transações muito baratas e baratas. Do RQ1, sabemos que o tempo de processamento das transações mais barato varia consideravelmente mais em comparação com as das transações em outras categorias de preços. Portanto, acreditamos que os desenvolvedores ðapp normalmente se beneficiam mais do uso do modelo EtherScan Fuel Tracker. Também mostramos que a API do preço do GAS EthgasStation é o melhor modelo para as categorias de preços de gás restantes. Portanto, os desenvolvedores que desejam maximizar a precisão da previsão podem combinar os dois modelos em um modelo de conjunto (por exemplo, da mesma forma que nosso design mostrado na Figura 9). No entanto, os desenvolvedores ðapp devem estar cientes de que, para uma determinada categoria de preços, os melhores EAs medianos que podem ser alcançados com esses dois modelos são: 7m 7s para transações muito baratas, 1M 36s para transações baratas, 28s para transações regulares, 14s para transações caras e 12s para transações muito caras (Tabela 9).

À luz dos resultados acima mencionados, realizamos um estudo post-hoc, no qual propusemos um modelo alternativo simples em design e inerentemente interpretável. Mostramos que nosso modelo supera o rastreador de gás EtherScan para transações muito baratas e baratas. Além disso, nosso modelo tem um desempenho com tanta precisão quanto a API de preço do GAS ETHGASSTATION para as categorias restantes. No entanto, os desenvolvedores ðapp devem ser os que fazem a chamada last, uma vez que o contexto em que cada ðapp opera pode ser diferente e pode levar a diferentes requisitos em termos de precisão da previsão.

8.1 Que tal usuários finais?

Nosso artigo se concentra no modelo de desenvolvimento em que (i) as complexidades da blockchain (por exemplo, configuração do parâmetro de transação) estão ocultas dos usuários finais e (ii) os desenvolvedores carregam o ônus de enviar transações com parâmetros adequados. Nesse contexto, a configuração de parâmetros de transação apropriados (por exemplo, preço do gás) se torna um problema claro de engenharia de software program.

No entanto, reconhecemos a existência de vários ðapps que seguem um modelo de desenvolvimento alternativo no qual as complexidades da blockchain são expostas aos usuários finais. Em outras palavras, os usuários finais desses DAPPs precisam enviar transações próprias e comumente usar uma carteira (por exemplo, metamask) para fazê-lo. Ao usar carteiras, os usuários finais podem aceitar os preços sugeridos da carteira para diferentes categorias de velocidade de processamento de transações ou inserir manualmente um preço do gás. Portanto, nesse contexto, os usuários finais também podem achar importante alcançar um bom equilíbrio entre o custo da transação e a velocidade do tempo de processamento (por exemplo, no evento em que um determinado usuário last freqüentemente usa um determinado DAPP). Nesse sentido, as duas implicações discutidas na seção anterior também se aplicam a esses usuários finais. Os usuários finais avançados podem até usar modelos de previsão, como o que propomos no estudo post-hoc, a fim de fazer escolhas de preços de gás mais informadas.