Como uma transação é verificada em uma rede de criptomoedas? No Ethereum, a resposta envolve perguntas diferentes: qual conta autorizou a operação, o que acontece durante a execução, se a transação foi incluída em um bloco validado e como a rede chega a um acordo. A palavra “verificada”, sozinha, pode esconder essas diferenças.
Este artigo usa o Ethereum como exemplo delimitado e acompanha transações comuns assinadas. Não apresenta um algoritmo completo de validação nem descreve todas as criptomoedas. A distinção central é esta: uma transação incluída pode ter execução malsucedida, enquanto uma execução bem-sucedida não comprova, por si só, tudo o que a pessoa pretendia realizar.
1. A assinatura demonstra a autorização da conta
Uma transação comum do Ethereum tem uma assinatura gerada com a chave privada do remetente. Ela permite autenticar a autorização associada àquela chave. Na descrição dos campos da transação, from identifica o endereço do remetente.
Essa autenticação tem um alcance específico. Ela não estabelece a identidade civil de quem está usando a conta, seu entendimento da operação ou sua satisfação com o resultado. Portanto, não se deve transformar a confirmação da assinatura em uma garantia geral de segurança.
Outro campo é o nonce, um contador que aumenta sequencialmente e indica o número da transação daquela conta. Entender sua definição ajuda a reconhecer que a operação tem uma posição na sequência da conta. Isso ainda não fornece todas as regras de validação de nonce ou de substituição de transações pendentes.
A documentação de transações do Ethereum apresenta esses campos e o processo de assinatura. Sua explicação deve ser interpretada dentro desse limite: comprovar autorização pela chave não equivale a comprovar que a operação atingirá o objetivo desejado.
2. Transmitir, executar e incluir são etapas distintas
O ciclo descrito pela documentação passa pela transmissão da transação à rede e por sua entrada em um conjunto de transações pendentes. Essa é uma explicação simplificada da propagação. Ela não promete que todos os nós receberão a operação nem que haverá inclusão futura.
O cliente de execução do Ethereum recebe transações transmitidas e as executa na máquina virtual Ethereum, a EVM. Essa execução trata do comportamento das instruções segundo as regras de execução. Já a inclusão trata de sua entrada em um bloco validado. São questões relacionadas, mas diferentes.
A reexecução também aparece na sincronização completa, chamada full sync: o nó reconstrói progressivamente o estado da blockchain executando cada bloco desde o bloco inicial. É um exemplo concreto de reconstrução dos resultados pela execução, em vez de mera aceitação de um resultado informado.
A ressalva importa: essa descrição se refere à sincronização completa. Outros modos podem começar de pontos de controle considerados confiáveis ou tratar o histórico de outra maneira. Não seria correto concluir que todo nó sempre reexecuta todo o histórico.
A referência para essas funções é a documentação de nós e clientes do Ethereum. Ela explica a divisão de responsabilidades, sem que seja necessário transformar este artigo em um manual de instalação de nós.
3. O consenso vai além da validação de um nó
O cliente de consenso implementa o mecanismo de prova de participação, ou proof of stake, que permite à rede chegar a um acordo com base nos dados validados pelo cliente de execução. Validar a execução e alcançar acordo na rede têm, portanto, funções conectadas.
O ciclo da transação distingue a inclusão em um bloco das etapas posteriores de justificação e finalização desse bloco. A primeira aparição em um bloco não deve receber automaticamente o mesmo significado de finalização. Essa descrição também não estabelece um prazo garantido ou uma progressão incondicional.
A dedução é limitada: como a validação de execução fornece dados para o acordo da rede e a finalização é uma etapa separada, o resultado local de um único nó não estabelece, sozinho, a finalidade na rede. Essa conclusão decorre da divisão de funções; não apresenta um número de votos ou uma regra de tempo.
Ao encontrar a afirmação de que uma transação foi verificada, vale identificar a etapa descrita. Uma explicação sobre execução local não responde automaticamente à pergunta sobre finalização.
4. O recibo separa inclusão e resultado de execução
Nos recibos que apresentam o campo status, o valor 1 indica sucesso de execução e 0 indica falha. O campo blockNumber identifica o bloco que contém a transação. Esse número, isoladamente, não estabelece finalidade.
Existe uma delimitação histórica: a documentação diferencia os recibos anteriores à atualização Byzantium, que apresentam uma raiz de estado em vez desse status. Aqui, a interpretação de sucesso e falha se aplica aos recibos com status.
Disso decorre outra dedução: se o recibo identifica um bloco e admite, separadamente, um status de falha, inclusão e execução bem-sucedida não são equivalentes. A rede pode aceitar e incluir uma transação cuja execução falha.
As definições estão na documentação JSON-RPC do Ethereum. O limite interpretativo também decorre delas: um campo binário de execução não compara o resultado com todos os objetivos pessoais do remetente. Para estabelecer um resultado específico do contrato, é necessária evidência desse resultado além do status.
Assim, há duas perguntas úteis: “a execução terminou com sucesso?” e “o resultado pretendido foi demonstrado?”. Elas podem exigir evidências diferentes, mesmo quando se referem à mesma transação.
5. REVERT desfaz mudanças no escopo da execução afetada
A instrução REVERT interrompe a execução afetada, considera essa execução malsucedida e desfaz suas mudanças de estado. O alcance da afirmação é essencial: ela se refere à execução revertida.
Não se deve ampliar essa regra para afirmar que todo gas, taxa, efeito sobre nonce ou alteração externa foi restaurado. A reversão de estado não autoriza essa conclusão abrangente.
Quando funciona normalmente, REVERT não consome todo o gas restante. Isso não significa que a execução foi gratuita ou que o gas já consumido foi restaurado. Há uma exceção: se faltar gas para executar a própria instrução ou ocorrer insuficiência de elementos na pilha, seu comportamento equivale a uma exceção por falta de gas, consumindo todo o gas naquele contexto de execução.
A EIP-140, que especifica REVERT, também descreve a indicação de falha devolvida ao chamador quando uma chamada interna é revertida. A dedução sobre o escopo é que a reversão dessa chamada, sozinha, não demonstra a reversão de todos os efeitos do chamador. Seu comportamento posterior e o resultado da transação inteira precisam de evidência própria.
6. Exemplo hipotético e checklist de interpretação
Exemplo hipotético: Maya autoriza uma transação comum do Ethereum para executar uma operação em um contrato. A transação é transmitida e depois incluída em um bloco validado. Seu recibo identifica o bloco, mas apresenta status igual a 0.
Não há contradição: houve inclusão e falha de execução. A assinatura e a presença no bloco não transformam a falha em sucesso. Se a execução afetada usou REVERT, suas mudanças de estado foram desfeitas naquele escopo, com as ressalvas sobre gas já explicadas.
Em uma alternativa igualmente hipotética, o recibo apresenta status igual a 1. Isso demonstra sucesso de execução, mas não comprova isoladamente todo o objetivo de Maya. A conclusão precisa respeitar o alcance do campo observado.
Use este checklist para avaliar uma explicação sobre verificação:
- Identifique a rede e mantenha as conclusões deste artigo restritas ao Ethereum.
- Separe autorização pela assinatura de resultado da execução.
- Distinga transmissão, inclusão em bloco e finalização.
- Leia o status de execução separadamente do bloco informado.
- Limite a reversão ao contexto afetado e considere as exceções de gas.
- Pergunte qual evidência demonstra o resultado específico pretendido.
Para entender como esses dados são apresentados, consulte o guia sobre como ler uma transação Ethereum em um explorador de blocos.
Material educativo preparado com auxílio de IA. As afirmações e suas evidências precisam de revisão editorial independente.