Esta nota analisa os dois modos de falha de equilíbrio que surgem no EIP-8037 quando os utilizadores não desejam gastar 50% do seu orçamento na criação de estados, e apresenta as medidas corretivas de escalonamento de gás de estado que podem então ser implementadas. No extremo, se os usuários continuarem criando tantos bytes de estado por unidade de gás regular consumida como fazem hoje e o Ethereum aumentar o limite de gás em 10x, então cerca de 6,2% do espaço de bloco regular será utilizado em equilíbrio. Isto significaria a perda de grande parte dos ganhos de escala alcançados através do ePBS e dos BALs. Dois ajustes diretos podem ser feitos se se verificar que a procura não produz uma distribuição de despesas 50/50: (1) adotar o preço EIP-8075 que expande e contrai automaticamente o limite estatal de gás; ou (2) expandir/contrair manualmente o limite do gás de estado, seja em um hard fork regular ou em um hardfork “somente parâmetro de gás de estado” (SGPO).
Modos de falha
Ethereum está focado em escalar a camada 1, com os headliners EIP-7732 (ePBS) e EIP-7928 (BALs) programados para inclusão em Glamsterdam. Se o custo do gás para a criação do estado não for ajustado, o estado provavelmente crescerá aproximadamente em linha com um limite de gás em expansão. Portanto, o EIP-8037 aumenta substancialmente o custo do gás para a criação de estados. Uma preocupação (1, 2, 3) associada a esta mudança é que a proporção do gás total gasto na criação do Estado possa aumentar, eliminando assim o gás normal. Por exemplo, suponha que o ePBS e os BALs, juntamente com as reprecificações computacionais, permitam um limite de gás de 600M, um ponto médio dos números discutidos aqui. Com a atual especificação EIP-8037 que se baseia na regra de medição EIP-8011, se os usuários não forem sensíveis ao aumento do custo do gás estatal e criarem tanto estado em relação ao gás regular consumido como fazem hoje, então apenas cerca de 6,2% do espaço de bloco regular seria utilizado em equilíbrio. Os ganhos de escala do ePBS, BALs e reprecificação computacional seriam então em grande parte perdidos.
É claro que podemos esperar que os utilizadores criem menos bytes de estado por unidade de gás normal quando o custo da criação de estado aumentar, mas a elasticidade-preço da procura para a criação de estado é desconhecida e parece impossível de prever de forma fiável. Se os usuários começarem a consumir, por exemplo, metade dos bytes de estado por unidade de gás regular como hoje, a situação melhorará um pouco e 12,3% do limite de gás do bloco poderá ser utilizado. O cenário ideal é que os usuários consumam 8,1 vezes menos bytes de estado por unidade de gás normal do que hoje. Neste caso, tanto o gás estatal como o gás normal podem ser utilizados a uma capacidade de 50/50 (ou realisticamente, talvez mais perto de 40/40, se o preço EIP-8011 utilizar o operador máximo). Se o consumo relativo da criação de estado cair mais do que isso, então ocorre um efeito oposto, e os utilizadores estão a criar menos do que os desejados 100 GiB de estado por ano.
A Figura 1 descreve os dois modos de falha de equilíbrio possíveis sob o preço do EIP-8011: poucos bytes de estado criados ou muito pouco gás regular consumido. A concepção actual funciona de forma óptima se os utilizadores estiverem dispostos a gastar 50% do seu orçamento em gás normal e 50% do seu orçamento em gás estatal, independentemente dos preços relativos entre os dois. Se este não for o caso, um lado irá expulsar o outro em equilíbrio.
Figura 1. Os dois modos de falha do mecanismo de preços EIP-8011 aplicados no EIP-8037. Se a procura pela criação de Estado for relativamente inferior ao previsto pelos investigadores, é criado muito pouco Estado em equilíbrio (o seu preço é demasiado elevado para corresponder à procura). Se a procura para a criação de um Estado for relativamente mais elevada do que o previsto pelos investigadores, é consumido muito pouco gás normal no equilíbrio (o seu preço é demasiado elevado para corresponder à procura).
Evitando falhas
A questão mais profunda é que o mecanismo de preços EIP-8011 não acompanha a criação estatal ao longo do tempo (ou, de um modo mais geral, qualquer valor que reflita o equilíbrio na procura entre operações estatais e não estatais). Portanto, não pode ajustar o custo do gás estatal de modo que tanto o recurso estatal como o recurso regular correspondam à procura pretendida. Podemos acabar com o Estado ou todos os outros recursos significativamente subutilizados em situação de equilíbrio. Existem duas opções para aliviar isso:
- rastrear a criação de estado ao longo do tempo usando uma variável de cabeçalho e ajustar automaticamente o equilíbrio entre o gás estadual e o gás normal, conforme proposto no EIP-8075; ou
- para reajustar manualmente o equilíbrio entre o gás de estado e o gás normal após observar uma distribuição desequilibrada, potencialmente usando apenas hardforks para parâmetros de gás de estado (ou crescimento de estado).
(1) Evitando modos de falha via EIP-8075
A aplicação do mecanismo de preços EIP-8075 para EIP-8037 resolve o problema de maneira baseada em princípios. De acordo com o EIP-8075, a criação de estado tem um custo variável de gás que se adapta à demanda, de modo que o número desejado de bytes de estado seja criado ao longo do tempo. A meta e o limite do gás estadual se expandem e contraem automaticamente com o custo do gás (uma vez que o mecanismo de precificação opera em bytes de estado). O gás medido é calculado como a média do gás normal e um normalizado medida do gás do estado. Isso permite que o gás regular seja consumido no nível desejado ao longo do tempo, enquanto o protocolo também garante que um número alvo de bytes de estado seja criado.
Figura 2. O EIP-8075 ajusta automaticamente o custo do gás com a demanda para garantir uma criação alvo de bytes de estado no longo prazo. Para conseguir isso, o EIP expande e contrai a meta e o limite do gás enquanto adapta o custo do gás de modo que um número alvo de bytes de estado seja consumido.
(2) Evitando modos de falha manualmente em hardforks regulares/SGPO
A segunda opção é espelhar a ideia do EIP-8075, mas fazer os ajustes manualmente. A meta e o limite do gás estadual podem, neste caso, idealmente, ser expandidos e contraídos como no EIP-8075 (Figura 2), de modo que a equação de medição permaneça responsiva tanto ao gás regular quanto ao gás estadual. Se implementado como um hardfork SGPO, um stateSchedule pode ser introduzido e iniciado como:
{
"stateSchedule": {
"gloas": {
"target": 107374182400,
"scale": 100
}
},
"gloasTime": "TBD"
}
O scale parâmetro permite que o limite do gás de estado seja expandido ou contraído em relação ao limite do gás do bloco, e o target parâmetro define o crescimento anual do estado sob plena utilização. O state_gas_limit é calculado como state_gas_limit = gas_limit * stateSchedule.scale // 100e o cost_per_state_byte calculado substituindo gas_limit com state_gas_limit na seguinte expressão:
cost_per_state_byte = state_gas_limit * 7200 * 365 // (stateSchedule.target * 2)
Quando a função de medição F finalmente é aplicado (onde F poderia ser max ou qualquer outra função discutida aqui), é exatamente como no EIP-8075 aplicado a uma medida normalizada de gás de estado: F(regular_gas, state_gas * 100 // stateSchedule.scale). Como a elasticidade da demanda é desconhecida, uma única correção manual pode não atingir o alvo perfeitamente. Portanto, parece razoável ultrapassar um pouco se for consumido muito pouco gás regular em equilíbrio, para manter a incrustação. Também é possível “ultrapassar” de forma mais geral, visando uma proporção maior de gás estatal em relação ao limite do que 0,5, conforme descrito aqui.
Observe que o scale parâmetro seria a principal justificativa para adicionar hardforks SGPO. Sem o scale parâmetro, Ethereum corre o risco de entrar no modo de falha 2 na Figura 1, renunciando a alguma proporção dos ganhos de escala de ePBS e BALs. A capacidade de também ajustar o target o crescimento é bem-vindo, mas não justificaria isoladamente a complexidade da implementação. Em outras palavras, tanto o target e scale poderia ser definido e ajustado em um hardfork normal, mas apenas a falta de um scale parâmetro pode garantir hardforks SGPO.
Equilíbrio estilizado
O resultado de equilíbrio sob os preços do EIP-8011 no EIP-8037 pode ser analisado de forma rudimentar, concentrando-se nas elasticidades da procura relativa entre os dois recursos (como aqui e aqui, com uma descrição geral sobre as elasticidades da procura também disponível aqui).
Existe um custo fixo do gás e ambos os recursos têm a mesma taxa base. Inicialmente, antes da implementação do EIP-8037, 70% de todo o gás é gasto em operações que serão cobradas pelo gás normal, G_1=0,7 e 30% do gás é gasto na criação de estados, G_2 = 0,3. Se a procura ficar equilibrada entre o gás normal e o gás estatal ao abrigo do custo fixo do gás especificado pela EIP-8037 em qualquer limite de gás, de modo que os utilizadores gastem uma quantidade igual de gás em ambos, o mecanismo funcionará perfeitamente como pretendido. A proporção R do gás gasto nos dois recursos é então 1:
r = \frac{G’_1}{G’_2} = 1.
Deixe o custo do gás para a criação do estado aumentar por um fator p e deixe d representam quantas vezes menos bytes de estado os usuários estão dispostos a criar por unidade de gás regular consumida, sob determinado aumento de custo. A nova relação entre o gás normal consumido e o gás estadual é então:
r = \frac{G_1}{G_2(p/d)} = \frac{G_1 d}{G_2 p}.
Em equilíbrio ao usar a função max (como em EIP-8037) e ignorando como a variabilidade do bloco reduz as proporções de equilíbrio, a dimensão medida (a maior entre o gás regular e o gás de estado) ficará no alvo. Os usuários consumirão então gás normal em uma proporção de G^*_1 = \min(0,5, 0,5r) do limite de gás e declarar o gás em uma proporção de G^*_2 = \min(0,5, 0,5/r).
O aumento de custo básico do EIP-8037 com gás 60M é de 1,17x para slots de armazenamento, 3,29x para contas e 3,67x para código. Um aumento médio ponderado do custo do gás nessas três métricas com base nas trajetórias de crescimento atuais (instantâneo de armazenamento, instantâneo de conta, códigos de contrato) entre o bloco 17.165.429 e o bloco 21.000.000 é de cerca de 1,89x. A incerteza na média ponderada atual é devidamente reconhecida.
Investigando um escalonamento de 10x facilitado por BALs, ePBS e reprecificação, o aumento médio ponderado do custo do gás seria de 18,9x com a especificação EIP-8037. Assim, definir p=18,9 e assumindo que os usuários não alterem seu padrão de uso atual (d=1), a proporção se torna
r=0,7/(0,3 \vezes 18,9)=0,123.
Os usuários consumirão então apenas gás normal em uma proporção de
G^*_1 = 0,5 \vezes 0,123 = 0,062
do limite do gás em equilíbrio. Se os usuários reduzirem pela metade a criação de estado por unidade de gás regular, o equilíbrio se tornará G^*_1 = 0,123. A redução ideal no consumo de bytes de estado por unidade de gás regular é obtida restaurando o equilíbrio (r=1), o que implica:
d^* = \frac{G_2p}{G_1} = \frac{0,3\cdot 18,9}{0,7} = 8,1.
Olhando para frente
À medida que o Ethereum continua a crescer, aumenta a dificuldade em prever o custo estatal do gás que equilibra as despesas com gás, assim como a gravidade dos piores modos de falha. Por exemplo, em uma escala L1 de 30x, apenas 2,1% do espaço de bloco para gás normal é utilizado em equilíbrio, se os usuários não alterarem a criação de bytes de estado de acordo com o uso regular de gás (mas o alto custo do gás deve, neste ponto, incentivar os usuários a fazer ajustes bastante substanciais na quantidade de estado que eles criam). Quando uma escala de 30x for alcançada, idealmente uma solução mais abrangente para o problema terá sido implantada. Tal solução consiste num mercado de taxas multidimensional completo, como no EIP-7999, e esforços de engenharia para melhor lidar com o crescimento do estado (potencialmente expirando em alguma parte do estado).
Fontesethresear
