Um dApp é um aplicativo capaz de se conectar a um blockchain. Normalmente, as equipes empresariais não conectam um front-end diretamente a um nó porque isso é arriscado e difícil de gerenciar.
Então, em vez disso, eles constroem camadas: uma API REST na frente, um serviço de back-end no meio e o blockchain na parte de trás como registro final.
Neste artigo, orientaremos você no processo de construção de dApps empresariais com contratos inteligentes e APIs REST.
Qual é a aparência de uma arquitetura dApp corporativa
Uma API REST se comunica com um serviço de back-end. O back-end atinge um nó blockchain por meio de JSON-RPC.
Fluxo de solicitação
API REST
-> Cliente Web3
-> Nó Blockchain
-> Contrato Inteligente
O contrato inteligente possui mudanças de estado e regras básicas. O back-end cuida do resto, como verificar dados, gerenciar usuários e vincular-se a sistemas mais antigos.
- Como uma solicitação flui. Digamos que um cliente envie POST/pedidos. A API verifica a solicitação e a identidade do usuário. O cliente Web3 formata os dados para corresponder à ABI do contrato. Um sistema de gerenciamento de chaves (KMS) assina-o com uma chave segura. O backend envia com eth_sendRawTransaction e retorna 202 Aceito com um hash de transação. Uma vez extraído, o contrato dispara um evento e o backend atualiza seu banco de dados.
- As leituras ignoram tudo isso. Pesquisas somente leitura usam eth_callque é executado no nó gratuitamente, sem assinatura.
- Ethereum ou Tecido. Ethereum e outras cadeias EVM ordenam as transações primeiro e depois cada nó as executa. Tecido Hyperledger executa transações primeiro com pares endossados. Um serviço de pedido então os sequencia e os pares de commit verificam os resultados. Muitas gravações nos mesmos dados causam conflitos de MVCC (controle de simultaneidade multiversão), portanto, os back-ends precisam de uma lógica de repetição forte.
- Gateway e back-end. Nunca exponha um contrato diretamente a um aplicativo. Coloque um gateway e um back-end na frente, seguindo regras de Zero Trust como NIST SP 800-207. O gateway verifica cada solicitação, encerra o TLS e verifica os logins OAuth e JWT. Sem limites de taxas, os invasores podem inundar o back-end ou drenar fundos por meio de taxas de gás.
- Lendo dados on-chain de um endpoint REST
const { ethers } = require("ethers");
const express = require("express");
const app = express();
const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const abi = ("function getAssetStatus(uint256 id) view returns (string)");
const contract = new ethers.Contract(process.env.CONTRACT_ADDRESS, abi, provider);
app.get("/api/assets/:id/status", async (req, res) => {
try {
const status = await contract.getAssetStatus((req.params.id)(http://req.params.id));
res.status(200).json({ assetId: (req.params.id)(http://req.params.id), status });
} catch (error) {
res.status(500).json({ error: "Failed to read on-chain state" });
}
});
Projete o contrato inteligente em torno de transações empresariais
Os contratos devem agir sempre da mesma maneira e armazenar poucos dados, uma vez que o armazenamento em cadeia custa muito mais do que um banco de dados normal.
- Funções e eventos: As funções de gravação mudam de estado e criam uma transação e um recibo. As funções de visualização apenas retornam dados. Os blockchains são confirmados depois da execução dos back-ends, portanto, cada função de gravação deve disparar um evento. Uma função transferAsset deve emitir AssetTransferred com o remetente, o destinatário e o ID do ativo. O back-end lê esses logs para confirmar se a lógica funcionou.
- Solidez e o ABI: A ABI é JSON que lista cada nome de função, suas entradas e saídas. A biblioteca Web3 o usa para compactar o nome da função e os argumentos em uma carga hexadecimal. Os primeiros quatro bytes da chamada com hash tornam-se o seletor de função. O back-end precisa da ABI exata e do endereço do contrato. Uma incompatibilidade pode fazer com que as transações falhem silenciosamente ou executem a lógica errada.
- Assinatura, recibos e erros: Cada endereço de carteira tem um nonce, um número que aumenta uma unidade a cada transação. Quando um back-end é executado em muitos servidores, duas solicitações podem capturar o mesmo nonce e deixar as transações travadas. É seguro tentar novamente um tempo limite de rede. A rejeição do contrato não o é, uma vez que uma nova tentativa custa apenas mais gás. O back-end lê códigos de erro JSON-RPC para diferenciar os dois.
Conecte APIs REST a contratos inteligentes
Chamando funções de contrato
Os back-ends costumam usar uma biblioteca como ethers.js com três objetos. O Provedor se conecta à rede e lida com as leituras.
O Signatário detém a chave privada e comprova quem enviou cada transação. A instância do Contrato vincula a ABI a um endereço. Uma chamada por meio do Signatário cria a carga útil, assina-a, adiciona os números nonce e gas e a envia.
Convertendo solicitações em transações
Para uma solicitação POST/assets, o backend funciona nesta ordem:
- Verifique a forma e os tipos da carga útil.
- Verifique o login do usuário no sistema de identidade empresarial.
- Aplique regras fora da rede, como confirmar o pagamento de uma fatura.
- Mapeie os dados para a ABI do contrato.
- Assine a transação através do KMS.
- Transmita-o para a rede.
- Aguarde o recebimento em segundo plano e leia os eventos.
Retornando Hashes e Recibos
Uma transação pode esperar no mempool por segundos ou minutos. Aguardar o recebimento congelaria o thread HTTP.
Portanto, o backend retorna 202 Aceito com o hash logo após a transmissão. O cliente então pesquisa um endpoint de status ou escuta webhooks.
Enviando uma transferência de ativos
const express = require("express");
const { ethers } = require("ethers");
const app = express();
app.use(express.json());
const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const wallet = new ethers.Wallet((process.env.SECURE)(http://process.env.SECURE)_PRIVATE_KEY, provider);
const contract = new ethers.Contract(
process.env.CONTRACT_ADDRESS,
("function transferAsset(address to, uint256 amount)"),
wallet
);
(app.post)(http://app.post)("/api/assets/transfer", async (req, res) => {
try {
const { toAddress, amount } = req.body;
if (!ethers.isAddress(toAddress)) {
return res.status(400).json({ error: "Invalid recipient address" });
}
const tx = await contract.transferAsset(toAddress, ethers.parseUnits(amount.toString(), 18));
res.status(202).json({
message: "Transaction submitted",
transactionHash: tx.hash,
statusUrl: `/api/transactions/${tx.hash}/status`
});
tx.wait().then((receipt) => {
console.log`Mined in block ${receipt.blockNumber}`);
}).catch((err) => {
console.error`Transaction reverted:`, err);
});
} catch (error) {
res.status(500).json({ error: "Failed to submit transaction" });
}
});
Adicione identidade, autenticação e segurança de transação
Misturar logins corporativos e assinatura de blockchain é um dos maiores riscos em um dApp.
- Carteiras e assinatura. A autenticação verifica quem é uma pessoa. A assinatura prova ao blockchain que uma ação está autorizada. A maioria dos sistemas corporativos assina para o usuário. Módulos de segurança de hardware ou sistemas de chave em nuvem retêm a chave e assinam remotamente, para que a chave nunca toque na memória de back-end. Se os usuários assinarem com suas próprias carteiras, use EIP-712. Este padrão mostra aos usuários exatamente o que eles aprovam e bloqueia ataques de repetição nas redes.
- Autenticação e autorização de API. OAuth e JWTs ainda são importantes, mas não podem substituir as verificações na cadeia. OWASP nomeia a Autorização em Nível de Objeto Quebrado e a Autorização em Nível de Função Quebrada como riscos principais. Se um back-end apenas verificar se um JWT é válido, um invasor poderá alterar a carga útil e mover os ativos de outra pessoa. O gateway deve mapear cada usuário para sua identidade exata na cadeia antes que o backend construa a transação.
- Chaves e acesso ao contrato. Adicione controle de acesso também dentro do contrato. O AccessControl do OpenZeppelin configura funções como MINTER_ROLE ou PAUSER_ROLE em vez de um proprietário. Um único DEFAULT_ADMIN_ROLE é um ponto de falha, porque um KMS hackeado transfere o controle total. AccessControlDefaultAdminRules força uma transferência administrativa em duas etapas com atraso, dando às equipes de segurança uma janela para detectar problemas.
Torne os dados Blockchain utilizáveis por aplicativos empresariais
Consultar um nó, uma chamada por vez, não é escalonável, portanto, os sistemas extraem os dados da cadeia com antecedência. Para uma visão mais aprofundada de como essas camadas se unem, veja isto guia de desenvolvimento de dApp empresarial antes de projetar sua arquitetura de dados.
- Eventos e assinaturas. Os back-ends abrem conexões WebSocket e escutam assinaturas de eventos específicos. Quando um evento Transfer é acionado, o ouvinte envia a carga útil para uma fila de mensagens como Kafka. Outros serviços leem a fila e atualizam seus próprios armazenamentos de dados sem sobrecarregar o nó.
- Lendo através de JSON-RPC. Chamar eth_call verifica o estado atual, o que é adequado para verificações de saldo em tempo real. Um recibo de transação confirma que a gravação foi concluída. Grandes lotes de logs históricos sobrecarregam o nó, portanto execute-os como trabalhos em segundo plano.
- Respostas REST rápidas. As equipes usam CQRS, abreviação de Command Query Responsibility Segregation. O blockchain continua sendo a fonte da verdade para gravações, e um banco de dados como o PostgreSQL serve para leituras. Os ouvintes de eventos mantêm o banco de dados sincronizado, portanto, uma solicitação GET nunca espera no nó. As leituras podem atrasar alguns segundos, mas esse padrão se mantém sob tráfego intenso.
Construa para produção, não apenas para demonstração Blockchain
- Gás e falhas. EIP-1559 estabelece um mercado de taxas para cadeias EVM. Os backends estimam maxPriorityFeePerGas, a dica do validador, e maxFeePerGas, a taxa mais alta permitida. Números errados deixam as transações travadas quando a rede está ocupada. Uma transação com falha ainda custa gás, então execute um teste seco com eth_call antes de assinar.
- Gateway, limites e monitoramento. Cada gravação custa dinheiro real, portanto, os gateways precisam de limites de taxas rígidos contra maus atores e clientes quebrados. Os logs devem seguir uma solicitação do ID de solicitação do gateway até o hash da transação no log de auditoria. Observe a integridade do nó, os tempos de resposta do RPC e o atraso entre o banco de dados de leitura e a cadeia.
- Testando. Ferramentas como Slither ou Mythril detectam bugs como reentrada antes do lançamento. Os testes de integração devem abranger a API REST, o assinante de back-end e o nó juntos. Ferramentas locais como Hardhat ou Anvil permitem que as equipes acionem falhas propositalmente, como ficar sem combustível.
- Lendo dados da cadeia de suprimentos
const express = require("express");
const { ethers } = require("ethers");
const app = express();
const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const abi = (
"function getSupplyChainData(string batchId) view returns (uint256 timestamp, string location, string status)"
);
const contract = new ethers.Contract(process.env.CONTRACT_ADDRESS, abi, provider);
app.get("/api/supply-chain/:batchId", async (req, res) => {
try {
const data = await contract.getSupplyChainData(req.params.batchId);
res.status(200).json({
batchId: req.params.batchId,
timestamp: Number(data.timestamp),
location: data.location,
status: data.status
});
} catch (error) {
res.status(404).json({ error: "Batch not found or network unavailable" });
}
});
Lista de verificação de desenvolvimento de dApp empresarial
Antes de passar do teste para a rede principal, verifique cada item.
Contrato inteligente e ABI
- Use controle de acesso baseado em função, não em um único proprietário.
- Exigir uma transferência em duas etapas e um atraso para funções administrativas.
- Dispare um evento de cada função de gravação.
- Controle de versão da ABI e do endereço do contrato em todos os serviços.
Provedor de nó e Web3
- Estime o gás dinamicamente sob EIP-1559.
- Distribua chamadas JSON-RPC em mais de um nó.
- Teste cada transação com eth_call antes de assinar.
API REST e back-end
- Retorne 202 Aceito para gravações e confirme os recebimentos em segundo plano.
- Centralize o tratamento de nonce para que serviços ampliados não colidam.
- Sirva leituras de um banco de dados CQRS, não do nó.
Identidade, segurança e monitoramento
- Mantenha as chaves privadas em um KMS ou HSM, nunca na memória do aplicativo ou em variáveis de ambiente.
- Aplique limites de taxa e verificações de confiança zero no gateway.
- Rastreie cada solicitação de API até seu hash de transação na cadeia.
Conectando APIs empresariais a aplicativos Blockchain
Um contrato inteligente não é uma troca imediata para um banco de dados ou servidor back-end. As equipes precisam de camadas que vinculem o tráfego diário da web a uma rede mais lenta e descentralizada.
A API REST e o gateway formam o principal limite de segurança. Eles verificam identidades, aplicam limites de taxas e seguem regras de confiança zero. O back-end verifica regras de negócios, estima gás, assina por meio de chaves apoiadas por hardware e envia cargas úteis por meio de bibliotecas Web3.
Mantenha o contrato restrito, limitado a verificações de estado e ativos, e mova consultas complexas para o back-end. O tratamento de transações assíncronas, a sincronização orientada a eventos e a segurança rígida das chaves separam um dApp de produção real de uma demonstração.
Você achou este artigo útil? Entre em contato conosco se houver mais alguma coisa que você queira usar para cobrir!
