EIP-8032 (e EIP-2926, aliás) vêm com um processo de conversão. Percebi que esse processo é pouco compreendido, mesmo pelos desenvolvedores principais. Antes do próximo ACDE, estou escrevendo uma explicação rápida.

No fundo, não passa de um simples iterador, revisando contas e contando folhas. Quando todas as folhas foram contadas, essa contagem é adicionada como um campo à conta. A cada bloco, o iterador avança por N posições. A conversão para quando a última posição é alcançada.

Aqui, "posição" significa tanto uma conta quanto um espaço, onde o iterador poderia "parar". Devido à quantidade de dados, é importante que a iteração pare em um ponto "seguro" e retome no próximo bloco.

Vamos analisar o exemplo simplificado a seguir. Há muito menos dados no estado do que na vida real, e a árvore é binária, mas o exemplo é preciso de outra forma. O símbolo ∅ significa uma conta sem armazenamento. Se estiver faltando, então a conta tem uma árvore de armazenamento.

Inicialmente, o iterador é definido como 0, ou seja, - posição de hash da conta = 0 - posição do hash do slot = 0 Ele é representado com uma seta vermelha.

Neste exemplo, tomamos o passo do iterador N = 2 (na prática, N > 10_000). No bloco de bifurcação, o iterador se move em duas posições. A primeira posição é uma conta sem armazenamento, então nada é feito.

Ainda no bloco de fork, o iterador se move para a segunda posição, que é um slot (ou seja, o iterador para no armazenamento da conta antes de parar na conta propriamente dita). O contador de slot é definido para 1, e como o iterador já fez toda a sua passada para o bloco de garfo, ele para.

No próximo bloco, o iterador cobre novamente duas posições: - O 1º é o 2º slot da 2ª conta, para o qual o contador foi incrementado - A segunda é a própria segunda conta. O valor do contador é somado como campo de conta, e o contador é reiniciado.

No bloco seguinte (fork + 2), o iterador passa pelos dois slots da terceira conta, mas seu passo é alcançado antes que a própria conta (próxima posição) seja atualizada com o contador (que é 2).

No último bloco da conversão, a terceira conta recebe um contador, e então a última conta é verificada quanto ao estado (que não tem, então nenhuma atualização é necessária).

Como não há mais contas, o iterador termina e a conversão é concluída.

E se o armazenamento for adicionado à conta A depois que o iterador já passou pela conta A? O contador dentro de A é simplesmente aumentado.

E se o armazenamento for adicionado à conta que está sendo convertida? - à frente do iterador: nada a fazer, pois o iterador contará quando chegar lá - após a passagem do iterador: armazená-lo na conta, adicioná-lo ao contador de iteradores após o término da enumeração de slots

Quando os custos da gasolina se aplicam? Quando a conta for convertida.

Quanto tempo vai durar a conversão? Dependendo do passo, até um mês. O valor é escolhido de modo que o cálculo adicionado seja desprezível em comparação com a operação regular em blocos. 10.000 é herdado de Verkle, e levaria um mês. Os benchmarks certamente encontrariam um valor mais rápido

E é só isso, obrigado por ler até o fim 🫶