O que são binários Solidity?

Os dados brutos publicados por um smart contract na blockchain Ethereum são bytecode, ou seja, longas sequências de caracteres hexadecimais. Embora os desenvolvedores escrevam e leiam smart contracts em código Solidity legível por humanos, esse não é o texto publicado na blockchain.

Da mesma forma, toda "chamada" a um smart contract, ou requisição feita a uma das funções externamente visíveis publicadas por um smart contract, tem a forma de bytecode bruto, ou "binários".

Considere um smart contract publicado na Ethereum mainnet com a seguinte estrutura (codificada em Solidity):

Digamos que um usuário queira fazer uma chamada à função baz com os parâmetros 69 e true.

Veja como a requisição realmente se parece quando transmitida em bytecode:

0xcdcd77c000000000000000000000000000000000000000000000000000000000000000450...

Bem difícil de ler, não é?

Neste artigo vamos discutir por que a Ethereum Virtual Machine codifica tudo em bytecode, entender o que é uma ABI e como usá-la, e conhecer algumas ferramentas básicas para descompilar bytecode de volta para Solidity legível por humanos.

Nota: os exemplos deste artigo foram retirados da documentação oficial da ABI do Solidity.

Por que o Solidity codifica smart contracts em binário?

Como é extremamente caro armazenar dados na blockchain Ethereum, e todo byte de dado enviado precisa ser replicado em todos os full nodes da blockchain, é mais eficiente em termos de custo escrever e ler bytecode bruto do que enviar código Solidity.

Fazer parsing e armazenar código legível por humanos pode custar uma ordem de grandeza a mais em dados, o que é um problema quando smart contracts já podem custar milhares de dólares cada um na mainnet.

O que é uma ABI do Solidity e por que você precisa de uma para ler um smart contract?

Quando smart contracts são publicados, eles são automaticamente transpilados para bytecode antes de serem publicados na Ethereum. Porém, uma vez publicados na rede, como um indivíduo saberá como interagir com o smart contract? É praticamente impossível olhar para uma longa sequência de bytecode e entender quais funções estão disponíveis para chamada.

Uma Application Binary Interface, ou ABI, é a resposta.

Uma ABI é uma lista pública e legível por humanos de métodos que descreve as chamadas que podem ser feitas a um smart contract específico e o que cada chamada retornará.

Com uma ABI, os usuários de smart contracts não precisam ler bytecode e podem traduzir suas chamadas em bytecode para interagir com smart contracts.

ABIs são extremamente parecidas com APIs (Application Programming Interfaces) na arquitetura tradicional da Web2. Porém, a principal diferença é que uma ABI do Solidity permite que o usuário acesse métodos em smart contracts codificados em binário, enquanto as APIs permitem que os usuários acessem métodos de endpoints de servidores online.

Como são feitas para serem usadas e lidas por humanos, os desenvolvedores de smart contracts não publicam a ABI de um smart contract na blockchain, pois isso seria extremamente caro.

Em vez disso, você pode obter a ABI de:

1. Código-fonte publicamente disponível para o contrato, fornecido pelo desenvolvedor do smart contract, que pode ser usado para gerar uma ABI.
2. Se o smart contract estiver verificado no Etherscan, a partir das informações do contrato no Etherscan.
3. Fazendo engenharia reversa da ABI a partir do bytecode do smart contract (não recomendado).

Uma ABI é tipicamente publicada como uma codificação em formato JSON das declarações de funções públicas de um smart contract Solidity.

Considere a seguinte definição de função de um smart contract:

A codificação JSON correspondente seria assim:

Como interpretar binários de call data do Solidity

Embora você não deva fazer parsing manual de binários do Solidity para chamar funções, pois isso é complicado, pouco intuitivo, e você provavelmente cometerá vários erros, é bastante útil entender aproximadamente como os binários são formados no Solidity, para que você possa examinar rapidamente call data ou verificar valores.

Vamos indicar algumas ferramentas na próxima seção que devem cuidar da maior parte dessa transcrição para você.

Considere o exemplo acima.

Digamos que um usuário queira fazer uma chamada à função baz em um smart contract com os parâmetros 69 e true. Veja como a requisição se parece em bytecode, com 68 bytes no total:

0xcdcd77c0000000000000000000000000000000000000000000000000000000000000004500...

1. Use os primeiros 4 bytes do call data para identificar o method ID.

Neste caso, 0xcdcd77c identifica o método baz, obtido a partir dos primeiros 4 bytes do hash Keccak da forma ASCII da assinatura baz(uint32,bool).

2. Use os 32 bytes seguintes para identificar o primeiro parâmetro

0x00000000000000000000000000000000000000000000000000000000000000045 identifica o primeiro parâmetro 69, que é um valor uint32 preenchido (padded) para 32 bytes. Padding significa simplesmente que zeros são adicionados para garantir que toda a sequência tenha 32 bytes de comprimento (neste caso), independentemente do tamanho real do número.

0x00000000000000000000000000000000000000000000000000000000000000045 

3. Use os 32 bytes finais para identificar o segundo parâmetro

O segundo parâmetro é true, que é um valor bool preenchido (padded) para 32 bytes:

0x0000000000000000000000000000000000000000000000000000000000000001

A codificação é um pouco diferente para parâmetros que incluem tipos dinâmicos, porque, ao contrário de tipos estáticos como address, bool ou uint32, que são codificados no próprio local, tipos dinâmicos são codificados em um local alocado separadamente.

Como posso interpretar binários de event data do Solidity?

Um evento é um log publicado por um smart contract durante a execução de uma chamada de método, e eventos são publicados como dados binários.

Eventos podem receber parâmetros, que ajudam a especificar o que o evento vai gerar como saída. Esses parâmetros podem ser indexados, o que significa que o evento poderá ser pesquisado usando esse parâmetro indexado como filtro. Esses parâmetros indexados também são conhecidos, em termos do Solidity, como topics!

De forma geral, um evento em Solidity segue a seguinte estrutura:

• address: o endereço de um contrato
• topics[n]: 0 a 4 topics, ou parâmetros indexados
• dados binários de comprimento arbitrário, que podem ser interpretados de acordo com a ABI.

Quais ferramentas devo usar para descompilar binários do Solidity?

Existe uma variedade de descompiladores de EVM disponíveis que podem ajudar você a obter uma versão mais legível dos binários do Solidity, incluindo o EtherVM Decompiler e o Panoramix decompiler.

Esses descompiladores de EVM não retornam uma recriação perfeita do código-fonte original (nomes ou outras informações importantes podem ser removidos para minimizar o tamanho dos binários), mas devem oferecer uma compreensão de alto nível das requisições permitidas pela ABI.