image

Minha pesquisa inicial mostra que é possível obter uma redução adicional de 30% no armazenamento do código do contrato, além da desduplicação do contrato e da compactação do código no momento do armazenamento.

Necessariamente, o compilador solidity e todos os outros compiladores criarão bytecode com padrões de opcodes. Ao compactar um contrato individual, um algoritmo de compactação ideal aprende esses padrões depois que eles ocorreram uma vez no contrato individual e pode então consultá-los de forma abreviada ao longo do restante do contrato.

No entanto, isto significa que o algoritmo de compressão é sempre surpreendido pela primeira ocorrência de um padrão num contrato individual, porque o algoritmo não tem ideia de que isto é comum a muitos contratos inteligentes e, portanto, só pode aprender com o contrato individual em que está a trabalhar.

A solução para isso está incorporada na maioria das bibliotecas de algoritmos de compactação – você pode fornecer um pequeno “dicionário” pré-treinado que codifica padrões comuns já vistos em dados históricos. Isso permite a compactação imediata de padrões comuns na primeira vez que aparecem em novos dados.

Um segundo benefício quando um dicionário pré-treinado é usado é que ele também lembra grandes padrões de contratos de fraude e spam superrepresentados. Para os contratos que receberam spam dezenas de milhares de vezes com pequenas variações, um dicionário pode reduzi-los a porcentagens de um dígito em relação ao seu tamanho original.

Aqui estão os resultados, em comparação com o conjunto original de contratos desduplicados:

Usando o conjunto de dados zelliac de todos os bytecodes de contrato implantados até o início de 2025, há 1,539,858 conjuntos de bytecode implementados desduplicados.

Usando a biblioteca de compactação Zstandard em seu nível de compactação rápida padrão de 3 e compactando cada conjunto de bytecode individual, o tamanho total vai de 100% para 41.8% do tamanho original. Adicionar um dicionário de 100 KB, treinado nas configurações padrão para nível de compactação, resulta na ocupação de bytecode 29.3% do tamanho original, um 30% redução do tamanho comprimido.

Aumentar o tamanho do dicionário de compactação ou aumentar o nível de compactação reduz ainda mais o tamanho final. Eu mantive isso otimizado para velocidade. Também é bem possível que um ajuste adicional dos parâmetros de treinamento do dicionário resulte em tamanhos ainda menores.

Espaço de armazenamento total necessário em códigos de bytes de contrato de tamanhos diferentes:

Do pior para o melhor desempenho em todos os contratos.

Notas finais:

  • Se estiver usando isso em um cliente, eu presumiria armazenar um único byte que diria se um contrato foi compactado e, em caso afirmativo, qual dicionário/algo foi usado. Isso permitiria atualizações suaves para dicionários melhores no futuro, bem como não compactaria contratos que a compactação pioraria. Eu testei isso brevemente, e o byte extra por contrato torna o armazenamento total menor em geral, apenas escolhendo quando não usar a compactação.
  • Usei zstandard como biblioteca de compactação simplesmente porque tive boas experiências com ela no passado. Não comparei diferentes bibliotecas ou algoritmos de compactação neste momento.
  • O dicionário foi treinado em 500.000 contratos selecionados aleatoriamente. É realista que façam parte do conjunto de dados, já que a maior parte do que armazenamos são dados históricos de longo prazo. O desempenho com uma divisão pura de teste/trem é apenas um pouco diferente, e você pode treinar um dicionário em apenas algumas dezenas de milhares de contratos e ainda ver resultados semelhantes.

Fontesethresear

By victor

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *