A Máquina Virtual Ethereum EVM é o ambiente de execução para contratos inteligentes. Ele não está apenas em área restrita, mas também completamente isolado, o que significa que o código executado no EVM não pode acessar a rede, o sistema de arquivos e outros processos. Até o acesso entre contratos inteligentes é limitado.
2.Conta
Existem dois tipos de contas no Ethereum (elas compartilham o mesmo espaço de endereço): contas externas são controladas por pares de chaves público-privadas (ou seja, pessoas); contas de contrato são controladas por código armazenado com a conta.
O endereço da conta externa é determinado pela chave pública, enquanto o endereço da conta do contrato é determinado quando o contrato é criado (este endereço é calculado a partir do endereço do criador do contrato e do número de transações enviadas deste endereço, que é o chamado "nonce")
Independentemente de a conta armazenar código ou não, esses dois tipos de contas são iguais para o EVM.
Cada conta possui um armazenamento persistente na forma de pares de valores-chave. Os comprimentos da chave e do valor são ambos de 256 bits, o que chamamos de armazenamento.
Além disso, cada conta possui um saldo de éter (saldo) (a unidade é "Wei", 1 éter é 10 ** 18 wei), e o saldo será alterado com o envio de transações contendo éter.
3. Transação
Uma transação pode ser vista como uma mensagem enviada de uma conta para outra conta (a conta aqui pode ser a mesma ou a conta zero especial, veja abaixo). Ele pode conter dados binários (carga útil do contrato) e éter. Se a conta de destino contiver código, este código será executado com carga útil como parâmetro de entrada. Se a conta de destino for uma conta zero (o endereço da conta é 0), esta transação criará um novo contrato. Conforme mencionado anteriormente, o endereço de um contrato não é um endereço zero, mas é calculado a partir do endereço do criador do contrato e do número de transações enviadas desse endereço (o chamado “nonce”). A carga útil da transação usada para criar o contrato será convertida em bytecode EVM e executada. A saída da execução será armazenada permanentemente como código do contrato. Isso significa que para criar um contrato, não é necessário enviar o código do contrato real, mas sim o código que produz o código do contrato.
Nota: Durante o processo de criação do contrato, seu código ainda permanece vazio. Portanto, até que o construtor seja executado, você não deve chamar nele as funções do próprio contrato.
4.Gás
Uma vez criada, cada transação é cobrada uma certa quantia de gás, que deve ser paga pelo iniciador da transação original (tx.orgin). Quando o EVM executa transações, o gás será esgotado gradativamente de acordo com regras específicas. Não importa onde a execução chegue, uma vez que o gás se esgote (como cair para um valor negativo), uma exceção de falta de gás será acionada. Todas as modificações de estado feitas durante o quadro de chamada atual serão revertidas.
O mecanismo Gas incentiva o uso econômico do tempo de execução do EVM, ao mesmo tempo que compensa os executores do EVM (ou seja, mineradores) por seu trabalho. Como cada bloco tem uma quantidade máxima de gás (limite de gás do bloco), isso também limita a quantidade de trabalho necessária para verificar um bloco.
o preço do gás é um valor definido pelo remetente da transação. A conta do remetente precisa pagar antecipadamente a taxa de manuseio = gas_price * gas. Se sobrar gás após a transação ser executada, o gás será devolvido ao longo do caminho. Caso ocorra uma exceção e a transação seja revertida, o gás esgotado não será reembolsado.
Já os executores da EVM podem escolher se desejam incluir as transações. Os remetentes de transações não podem abusar do sistema estabelecendo um preço baixo para o gás.
5. Armazenamento, memória e pilha
A Máquina Virtual Ethereum possui três áreas para armazenamento de dados: armazenamento, memória e pilha.
Cada conta possui uma área de memória persistente chamada armazenamento. O armazenamento é um armazenamento de valores-chave que mapeia palavras de 256 bits para palavras de 256 bits. É impossível enumerar o armazenamento em um contrato, e a sobrecarga relativa de leitura do armazenamento é alta, e a sobrecarga de modificação do armazenamento é ainda maior. Um contrato só pode ler e escrever sua própria parte da área de armazenamento.
A segunda área de memória é chamada de memória, e o contrato tentará obter uma instância de memória que foi apagada para cada chamada de mensagem. A memória é linear e endereçável em nível de byte, mas as leituras são limitadas a 256 bits, enquanto as gravações podem ser de 8 ou 256 bits. Ao acessar (seja lendo ou escrevendo) uma palavra de memória que nunca foi acessada antes (seja deslocada para qualquer local dentro da palavra), a memória é expandida por palavras (cada palavra tem 256 bits). A expansão também consumirá uma certa quantidade de gás. À medida que o uso da memória aumenta, também aumenta o seu custo (em escala quadrada).
O EVM não é baseado em registro, mas sim em pilha, portanto todos os cálculos são realizados em uma área chamada pilha. A pilha tem no máximo 1.024 elementos e cada elemento tem uma palavra (256 bits) de comprimento. O acesso à pilha é limitado ao topo da pilha e é restrito ao permitir a cópia de um dos 16 elementos do topo para o topo da pilha ou a troca do elemento do topo da pilha por um dos 16 elementos abaixo. Todas as outras operações podem pegar apenas os dois primeiros (ou um, ou mais, dependendo da operação específica) elementos e colocar o resultado no topo da pilha após a operação. Claro, você pode colocar elementos da pilha no armazenamento ou na memória. Entretanto, não é possível acessar apenas o elemento em uma profundidade especificada na pilha sem primeiro remover outros elementos do topo da pilha.
6. Conjunto de instruções
O conjunto de instruções do EVM deve ser o menor possível para minimizar erros de implementação que podem levar a problemas de consenso. Todas as instruções operam no tipo de dados básico de "palavra de 256 bits". Apresenta operações aritméticas, bit a bit, lógicas e de comparação comuns. Saltos condicionais e incondicionais também podem ser realizados. Além disso, o contrato pode acessar propriedades relevantes do bloco atual, como número e carimbo de data/hora.
7. Mensagem de chamada
Os contratos podem ligar para outros contratos ou enviar Ether para contas não contratuais por meio de chamadas de mensagens. As chamadas de mensagens são muito semelhantes às transações, pois possuem origem, destino, dados, éter, gás e dados de retorno. Na verdade, cada transação consiste em uma chamada de mensagem de nível superior, que por sua vez cria mais chamadas de mensagem.
O contrato pode decidir quanto do gás restante deverá ser enviado e retido em suas chamadas de mensagens internas. Se ocorrer uma exceção de falta de gás (ou qualquer outra exceção) durante uma chamada de mensagem interna, isso será indicado por um valor de erro colocado no topo da pilha. Neste ponto, apenas será consumido o gás enviado com a chamada de mensagem interna. Além disso, no Solidity, o contrato de chamada acionará uma exceção manual por padrão, para que a exceção possa "surgir" na pilha de chamadas. Conforme mencionado acima, o contrato chamado (que pode ser o mesmo contrato do chamador) obterá um pedaço de memória que acabou de ser limpo e poderá acessar o payload da chamada - os dados fornecidos por uma área independente chamada calldata. Após a execução da chamada, os dados retornados serão armazenados em um espaço de memória pré-alocado pelo chamador. A profundidade da chamada é limitada a 1024, portanto, para operações mais complexas, devemos usar loops em vez de recursão.
8. Delegar chamadas/chamadas de código e bibliotecas
Existe um tipo especial de chamada de mensagem chamada delegadocall. A diferença entre ela e uma chamada de mensagem geral é que o código do endereço de destino será executado no contexto do contrato que iniciou a chamada, e msg.sender e msg.value permanecem inalterados. Isso significa que um contrato pode carregar dinamicamente código de outro endereço em tempo de execução. Armazenamento, endereço atual e saldo apontam para o contrato de chamada, apenas o código é obtido do endereço chamado. Isso permite que o Solidity implemente recursos de "biblioteca": bibliotecas de códigos reutilizáveis podem ser colocadas no armazenamento de um contrato, como bibliotecas usadas para implementar estruturas de dados complexas.
9.Registro
Existe uma estrutura de dados indexável especial que armazena dados que podem ser mapeados até o nível do bloco. Esse recurso é chamado de logs e o Solidity o utiliza para implementar eventos. Os dados de log não podem ser acessados após a criação do contrato, mas os dados podem ser acessados de forma eficiente de fora do blockchain. Como parte dos dados de log são armazenados em um filtro Bloom, podemos pesquisar os logs de forma eficiente e criptograficamente segura, para que eles também possam ser encontrados por nós de rede (clientes leves) que não baixaram todo o blockchain.
10. Criação de contrato
Os contratos podem até criar outros contratos através de uma instrução especial (em vez de simplesmente chamar o endereço zero). A única diferença entre chamadas de criação e chamadas de mensagens comuns para criar um contrato é que a carga útil será executada, o resultado da execução é armazenado como código do contrato e o chamador/criador obtém o endereço do novo contrato na pilha.
11. Fracasso e autodestruição
A única maneira de o código do contrato ser removido do blockchain é o contrato realizar uma operação de autodestruição no endereço do contrato. O éter restante na conta do contrato é enviado para o destino especificado e, em seguida, seu armazenamento e código são removidos do estado. Remover um contrato parece bom, mas é potencialmente perigoso. Se alguém enviar Ether para o contrato removido, o Ether será perdido para sempre.
Aviso: Mesmo que um contrato seja excluído por autodestruição, ele ainda fará parte da história do blockchain e poderá ser retido pela maioria dos nós Ethereum. Portanto, usar a autodestruição é diferente de excluir dados do disco rígido.
Nota: Mesmo que a autodestruição não seja explicitamente chamada no código de um contrato, ainda é possível realizar a autodestruição por meio de delegadocall ou callcode.
12. Contratos pré-compilados
Há um pequeno número de endereços de contrato que são especiais. O intervalo de endereços entre 1 e (inclusive) 8 contém "contratos pré-compilados", que podem ser chamados como outros contratos, mas suas ações (e seu consumo de gás) não são armazenadas lá. Os endereços são definidos pelo código EVM (os contratos pré-compilados não contêm código ). Em vez disso, é implementado no próprio ambiente de execução EVM.
Cadeias compatíveis podem usar um conjunto diferente de contratos pré-compilados. Também é possível que novos contratos pré-compilados sejam adicionados à cadeia principal do Ethereum no futuro. Mas você pode razoavelmente esperar que eles estejam sempre no 0xffffintervalo de endereços 1 e (inclusive).