O que aprendi fazendo meu TCC e a blockchain fora do DeFi

Existe uma pergunta que parece simples mas que ninguém no Brasil consegue responder direito: esse diploma é verdadeiro?

Se você já tentou validar uma credencial acadêmica sabe do que estou falando. Você acaba no site da universidade, que pode estar fora do ar. Ou no SISTEC, que guarda só metadados (nome, CPF, código do curso, etc) sem o documento assinado. Ou dependendo de cartório. Em 2025. O ponto central de falha é sempre o mesmo: se a instituição emissora some, o diploma some junto.

Foi esse problema que virou meu TCC… na verdade meu, do Leandro e do Thales. Três amigos que entraram no projeto com a mesma vontade de fazer algo que fizesse sentido fora da sala de aula.

A origem foi assim: eu sabia que queria trabalhar com blockchain, mas não queria fazer mais um projeto de DeFi. Esse estereótipo de que blockchain só serve pra movimentar dinheiro ou emitir token já cansava. Ainda mais com o estigma que se criou que a rede só funciona com golpistas e piramideiros. Quando falei da ideia para meus amigos, a reação inicial foi de surpresa por ser um tema não muito popular. A virada veio pelo nosso orientador, o Prof. Leonardo, que jogou a ideia de um “passaporte acadêmico”, um lugar onde diplomas, certificados e experiências ficassem registrados na chain, verificáveis por qualquer um, sem depender de nenhuma instituição específica. A partir daí o problema foi se revelando, e o escopo foi tomando forma.

Os três colocamos a mão em tudo, mas cada um puxou mais pra um lado. O Thales foi mais fundo na parte de negócios e conformidade regulatória. O Leandro ficou mais no backend e na integração com o padrão XML do MEC. Eu fui afundando na rede blockchain em si: configuração do Besu, protocolo de consenso, contrato inteligente, benchmark. É sobre essa parte que vou falar aqui.

O Brasil passou por três fases na certificação acadêmica. O diploma físico com autenticação cartorial. O SISTEC centralizado a partir de 2007. E a Portaria MEC nº 554/2019, que criou o diploma digital com força legal (XML assinado, QR Code, padrão definido).

O problema é que o modelo da Portaria continua centralizado. A verificação depende do portal de cada universidade. Se ela fechar, for descredenciada, ou simplesmente deixar o servidor cair, todos os diplomas que ela emitiu ficam órfãos.

A ideia que perseguimos foi simples: e se o hash criptográfico de cada diploma ficasse registrado em uma rede compartilhada por consórcio de IES? Qualquer nó verifica. Nenhuma instituição é ponto central. O diploma existe independente de quem o emitiu ainda estar de pé.

A primeira armadilha é achar que blockchain significa Ethereum público ou Bitcoin. Para um sistema de diplomas isso não funciona: taxas imprevisíveis, finalidade probabilística, dados sensíveis potencialmente expostos pra sempre.

Precisávamos de uma rede onde só IES autorizadas registram diplomas, onde cada bloco tem finalidade definitiva, sem reorganizações e sem “provavelmente confirmado”, e onde o custo de transação pudesse ser zero. Mas também queríamos manter o ecossistema Ethereum funcionando: Solidity, Hardhat, web3j, ethers.js.

Comparamos três opções.

Hyperledger Fabric é maduro pra consórcios institucionais, mas abandona a EVM completamente. Chaincode em Go ou Java, sem Solidity, sem nada do que já conhecíamos. Curva de aprendizado enorme pra um resultado que dava pra atingir diferente.

GoQuorum compartilha compatibilidade EVM e QBFT com o Besu, mas a ConsenSys descontinuou o projeto open source em 2022 e migrou pra suporte comercial. Pra um sistema com horizonte de décadas, depender de um fornecedor específico não fazia sentido.

O Besu fechou tudo: EVM completa, QBFT maduro, Apache 2.0, mantido pela Linux Foundation. Conseguimos configurar gas price zero no genesis sem comprometer nada do modelo de execução.

Escolhemos o QBFT, Quorum Byzantine Fault Tolerance, e vale explicar por quê isso não foi aleatório.

Proof of Work e Proof of Stake têm finalidade probabilística. Um bloco pode ser revertido. Pra um registro legal de diploma isso seria um problema jurídico sério. Precisávamos de algo determinístico: quando o bloco fecha, fecha.

O QBFT garante isso. Quando ⌊2n/3⌋ + 1 validadores emitem COMMIT, a decisão é irrevogável. Com quatro nós, simulando UFABC, USP, UNICAMP e UNESP no protótipo, a rede tolera até um nó malicioso ou com defeito.

Teve um momento estudando isso em que a fórmula do Lamport, n ≥ 3f + 1, que aparecia nos livros de sistemas distribuídos, parou de ser abstrata e virou uma decisão real: quantos nós a rede mínima precisa?

O contrato DiplomaRegistry em Solidity parece simples na superfície: mapear um hash SHA-256 para dados do diploma. Mas foi escrevendo os casos de borda que as coisas ficaram interessantes.

Registro duplicado: se dois sistemas tentarem registrar o mesmo hash, o contrato usa o próprio hash como chave primária no mapping e reverte se o campo registeredAt for diferente de zero. Sem isso, o segundo registro sobrescreveria o primeiro silenciosamente.

Bloqueio do administrador: se o contrato deixa o admin revogar a própria autorização, ninguém mais consegue adicionar IES à rede. Tivemos que barrar isso explicitamente: revokeUniversityAuthorization rejeita o endereço do próprio admin.

Chave comprometida: chaves privadas vazam. A função transferAdmin permite rotacionar o endereço administrativo sem precisar migrar o contrato inteiro.

Frontrunning: um nó malicioso que intercepte uma transação e reenvie antes consegue… exatamente o mesmo resultado. O hash produz a mesma entrada. Não tem como “roubar” um registro de diploma por esse caminho.

Ao final, 18 casos de teste com Hardhat cobrindo 97,3% das linhas e 100% das funções. Escrever esses testes foi quando eu realmente entendi o contrato, não quando escrevi o código.

Essa foi a tensão mais real do projeto. Não tem como apagar algo de uma blockchain. É a propriedade central dela. Mas a LGPD garante que dados pessoais podem ser excluídos a pedido ou por ordem judicial.

A saída foi separar estritamente o que vai pra chain e o que fica fora.

Na chain, só o hash SHA-256 do XML, um identificador, o nome da IES e o nome do titular. Fora dela, no IPFS e no banco relacional, o XML completo com CPF criptografado em AES-128, RG, naturalidade, endereço e tudo que é dado pessoal sensível.

Diante de uma ordem de apagamento, a IES exclui o XML do IPFS e do banco. Os dados pessoais somem. O hash fica na chain como registro inerte. Sem o XML, ele não revela nada. Isso segue as diretrizes do EDPB sobre blockchain e GDPR.

Pra uma versão de produção, o próximo passo seria tirar o nome do titular da chain também, substituindo por um hash irreversível. Sem nenhum dado pessoal registrado na chain.

Quatro nós Besu em Docker, i7-12700H, 32GB RAM. Script de benchmark em ethers.js com taxas crescentes de envio.

O resultado que mais chamou atenção: o P99 caiu de 5,97s pra 1,73s conforme aumentamos de 10 pra 300 TPS. Parece errado. Mais carga, menos latência?

Não é que o QBFT “acelerou”. A latência que medimos é a diferença entre o timestamp do bloco e o momento do envio. Em carga baixa os envios são esparsos e frequentemente caem logo depois de um bloco selar, esperando quase um período completo até o próximo. Em carga alta o padrão de submissão do script alinha melhor com o ritmo de produção de blocos. A distribuição muda, não o protocolo.

O ponto de saturação apareceu perto de 150 TPS, onde os erros começaram a surgir. Pra emissão nacional de diplomas, estimada em 2 a 3 TPS no pico sazonal, a margem é confortável.

Duas coisas ficaram como trabalho futuro mas merecem menção.

A assinatura XAdES-T com ICP-Brasil. O XML que geramos segue a estrutura do XSD do MEC, mas a assinatura digital real com certificado ICP-Brasil A3 não foi implementada no protótipo. Sem isso o documento não tem força legal equivalente ao diploma físico. Tem um placeholder reservado no XML pra essa integração, mas é o que separa o protótipo de algo que poderia ir pra produção.

zk-SNARKs pra verificação seletiva. Imagine provar que um diploma é válido sem revelar o nome do titular. Provas de conhecimento zero tornariam isso possível. Ficou no horizonte, mas é a direção mais elegante do ponto de vista de privacidade.

A percepção de que toda decisão técnica precisa ter uma razão que vem do problema foi o que me ajudou a entender o projeto.

QBFT porque finalidade determinística não é preferência, é requisito legal. Separação entre o que fica na chain e o que fica fora dela porque LGPD e imutabilidade são tensão real. Besu porque um sistema nacional não pode depender de fornecedor.

Quando você consegue traçar essa linha do problema até a decisão arquitetural é quando o projeto para de ser exercício acadêmico. O nosso poderia existir de verdade. Essa parte ainda me deixa pensando.

Se ficou curioso sobre o contrato, a configuração do genesis, os casos de borda ou o benchmark, é só perguntar nos comentários. Tenho muito mais pra falar sobre cada um desses pedaços.

Fora isso… Obrgiado pela atenção, um abraço e até mais!

j