Francisco Rosa Dias de Miranda; Sandro Teixeira Pinto

DOI: 10.22167/2675-6528-202600822

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A crescente complexidade da análise de dados em aplicações baseadas em blockchain evidenciou a necessidade de arquiteturas capazes de processar eventos on-chain com maior eficiência, previsibilidade e escalabilidade. Este trabalho teve como objetivo implementar e avaliar uma arquitetura de microserviços para o monitoramento de liquidez no protocolo Uniswap V3, na rede Ethereum, com ênfase na comunicação interna entre serviços e na extração contínua de dados off-chain. A pesquisa adotou abordagem aplicada, com desenvolvimento de uma solução em Go, comunicação interna via gRPC e Protocol Buffers, coordenação transacional por meio do padrão Saga, uso de API Gateway e incorporação de Redis como camada de cache L1. A avaliação empírica utilizou 1.218.442 eventos on-chain coletados durante 30 dias, em cinco pools de alta atividade, e submeteu os benchmarks a no mínimo 100 execuções em dois cenários experimentais independentes. Os resultados indicaram redução expressiva no custo de serialização e desserialização, latência interna estável em torno de 8,5 ms, vazão 2,02 vezes superior em cenários multicore, redução de 70% na pegada de rede e melhora substancial no tempo total de processamento com o uso de cache em Redis. Concluiu-se que a separação entre captura, processamento e disponibilização de dados tornou a arquitetura proposta tecnicamente adequada para aplicações analíticas de alta demanda no ecossistema Ethereum.

Palavras-chave: Ethereum; gRPC; indexação off-chain; Protocol Buffers; Uniswap V3.

1. Introdução

O ecossistema Web3, uma evolução da internet descentralizada, tem suas raízes na proposta seminal de Nakamoto (2008), que introduziu o Bitcoin como um sistema de pagamento eletrônico. Este sistema inovador baseava-se em prova criptográfica, eliminando a necessidade de uma autoridade central de confiança para validar transações. A tecnologia subjacente, o blockchain, funciona como um livro-razão distribuído, onde a integridade e a ordem das transações são asseguradas por mecanismos de consenso em uma rede ponto a ponto.

A evolução desse paradigma tecnológico ganhou um novo impulso com o surgimento do Ethereum, concebido por Buterin (2014). O Ethereum se estabeleceu como uma plataforma de computação descentralizada, capaz de executar contratos inteligentes. Essa capacidade expandiu significativamente o escopo das aplicações possíveis sobre a tecnologia blockchain, permitindo a criação de lógicas de negócio complexas e automatizadas.

A introdução dos contratos inteligentes possibilitou a programação de regras de negócio diretamente no ambiente on-chain. Isso permitiu o desenvolvimento de aplicações descentralizadas (dApps) com comportamento autônomo e verificável. No domínio das finanças descentralizadas (DeFi), este avanço foi crucial para viabilizar protocolos sofisticados de negociação e provisão de liquidez. Um exemplo notável é o Uniswap V3, descrito por Adams et al. (2021), que aprimorou o modelo de liquidez automatizada ao introduzir o conceito de liquidez concentrada, otimizando a eficiência de capital para os provedores de liquidez.

Apesar das inovações e do potencial das blockchains públicas, a análise de grandes volumes de dados em tempo real enfrenta limitações significativas devido à estrutura de dados e ao modelo de execução inerente a essas redes. A leitura contínua do estado on-chain, bem como o processamento de eventos emitidos por contratos inteligentes, podem se tornar operações custosas e ineficientes quando realizadas exclusivamente dentro da própria blockchain. Essa restrição impõe desafios à obtenção de informações atualizadas e precisas, essenciais para o monitoramento de sistemas financeiros descentralizados.

Para mitigar essas restrições e aprimorar a capacidade de processamento de dados, a engenharia de software tem adotado arquiteturas baseadas em microserviços. Conforme definidos por Fowler e Lewis (2014), microserviços são a decomposição de aplicações em serviços pequenos, independentes e fracamente acoplados. Essa abordagem permite que responsabilidades computacionalmente intensivas, como indexação, agregação e análise de dados, sejam deslocadas para componentes off-chain, operando fora da rede blockchain principal.

Segundo Tandon e Patel (2021), esse padrão arquitetural evoluiu para arquiteturas de nuvem altamente escaláveis, que integram gateways de API, comunicação assíncrona e mensageria orientada a eventos. Tais elementos aumentam a resiliência e a capacidade de evolução dos sistemas. No contexto DeFi, essa abordagem é particularmente relevante para o monitoramento contínuo de pools de liquidez, cuja dinâmica é impulsionada por eventos on-chain de alta frequência, exigindo uma infraestrutura que possa lidar com a volatilidade e o volume de dados.

Diante desse contexto e da necessidade de superar as limitações da análise de dados on-chain, este trabalho tem como objetivo implementar e avaliar uma arquitetura de microserviços voltada ao monitoramento de liquidez em pools do protocolo Uniswap V3 na rede Ethereum. O estudo analisa como a orquestração modular, aliada ao uso de protocolos de comunicação de alta performance, pode otimizar a integração entre serviços off-chain e o estado on-chain, contribuindo para sistemas mais escaláveis, eficientes e confiáveis no ecossistema DeFi.

2. Material e Métodos

A presente pesquisa adotou uma natureza aplicada, fundamentando-se na implementação de uma solução técnica para o monitoramento de protocolos de Finanças Descentralizadas (DeFi). O delineamento metodológico envolveu o desenvolvimento de uma arquitetura de microserviços, construída na linguagem Go. Essa escolha foi motivada pelo modelo de concorrência baseado em goroutines, pelo desempenho previsível e pela ampla adoção da linguagem em sistemas distribuídos e de infraestrutura (GO AUTHORS, 2025). A abordagem possibilitou a criação de um sistema modular, com serviços independentes e responsabilidades bem definidas.

O processo de coleta de dados iniciou-se com a implementação de um serviço de indexação on-chain. Este componente foi desenvolvido com base na biblioteca go-ethereum (ETHEREUM FOUNDATION, 2025), sendo responsável pela interação direta com a rede Ethereum. Sua função consistiu em monitorar e capturar eventos de swap emitidos pelos contratos inteligentes do protocolo Uniswap V3. Os eventos foram extraídos dos logs da blockchain e, subsequentemente, transformados em registros estruturados para processamento off-chain.

Após a coleta, os dados foram encaminhados a um serviço de analytics, que processou as informações para agregar métricas relevantes. Essas métricas incluíram volume negociado, variações de preço e distribuição de posições, essenciais para a análise de liquidez. A exposição dos dados e o controle de acesso foram centralizados por meio de um API Gateway, baseado no KrakenD (KRAKEND AUTHORS, 2025). Este gateway foi configurado para rotear requisições, aplicar políticas de segurança e gerenciar a autenticação via tokens JWT.

A comunicação interna entre os microserviços foi estabelecida utilizando o protocolo gRPC, com serialização via Protocol Buffers (ATRI, 2024; GRPC AUTHORS, 2025). Essa escolha técnica explorou a multiplexação oferecida pelo HTTP/2, visando garantir baixa latência e alta taxa de transferência. Tais características foram consideradas essenciais para o desempenho de aplicações financeiras que operam em tempo quase real, como as desenvolvidas neste estudo.

Para a persistência dos dados, adotou-se um modelo híbrido, conforme as diretrizes de Popereshnyak et al. (2025). O banco de dados PostgreSQL foi empregado para o armazenamento de dados estruturados e informações sensíveis, como credenciais e estados consolidados. Paralelamente, o MongoDB foi utilizado para armazenar metadados flexíveis relacionados aos pools de liquidez e registros de eventos. Adicionalmente, o Redis foi incorporado como camada de cache L1 em memória, com o objetivo de acelerar o acesso aos estados mais recentes e otimizar o tempo de resposta das consultas.

A coordenação de transações distribuídas entre os serviços, especificamente entre os componentes Tracker e Analytics, foi realizada por meio da implementação do padrão Saga, conforme descrito por Richardson (2026). Este padrão foi selecionado para manter a consistência eventual do sistema, executando transações locais e ações compensatórias. Essa abordagem evitou mecanismos de bloqueio global, que seriam inadequados para ambientes distribuídos e descentralizados.

Toda a infraestrutura da solução foi empacotada em contêineres Docker, o que permitiu a escalabilidade independente de cada serviço. Além disso, foram aplicados padrões de resiliência, conforme descritos por Shekhar (2024), para mitigar falhas em cascata e garantir a robustez do sistema. A organização arquitetural do sistema, incluindo o fluxo de eventos e a persistência híbrida, foi concebida para otimizar a integração entre serviços off-chain e o estado on-chain.

Para a avaliação empírica do sistema, utilizou-se um volume real de 1.218.442 eventos on-chain. Esses eventos foram coletados durante um período de 30 dias, em março de 2026, por meio do monitoramento contínuo de cinco pools de liquidez de alto volume do protocolo Uniswap V3 na rede Ethereum. Os pools selecionados foram USDC/WETH, WBTC/WETH, DAI/WETH, LINK/WETH e UNI/WETH, escolhidos por sua relevância operacional e elevada atividade transacional no contexto de finanças descentralizadas (ADAMS et al., 2021; BUTERIN, 2014).

Os benchmarks foram submetidos a um mínimo de 100 execuções em dois cenários experimentais independentes, precedidos por rodadas de aquecimento (warm-up) para mitigar ruídos. O primeiro cenário, focado na análise de latência e serialização, foi executado em hardware de alto clock, baseado em AMD Ryzen 7 7700X, com oito núcleos e frequência de até 5,4 GHz. O segundo cenário, direcionado à avaliação de vazão e escalabilidade, foi executado em um servidor de alta simultaneidade, baseado em Intel Xeon E5-2680 v4, com quatorze núcleos e 28 threads.

3. Resultados e Discussão

A avaliação empírica do sistema SagaIndexer foi conduzida com base em um volume substancial de 1.218.442 eventos on-chain, coletados ao longo de um período de 30 dias, em março de 2026. O monitoramento contínuo abrangeu cinco pools de liquidez de alto volume no protocolo Uniswap V3, na rede Ethereum, especificamente USDC/WETH, WBTC/WETH, DAI/WETH, LINK/WETH e UNI/WETH. A seleção desses pools foi motivada por sua relevância operacional e pela elevada atividade transacional no contexto das finanças descentralizadas, conforme destacado por Adams et al. (2021) e Buterin (2014).

Para garantir a robustez dos resultados, cada benchmark isolado foi submetido a um mínimo de 100 rodadas de aquecimento, com descarte dos outliers iniciais. Esse procedimento visou mitigar ruídos decorrentes da alocação dinâmica de memória e do comportamento do runtime da linguagem Go (GO AUTHORS, 2025). O delineamento experimental foi estruturado em dois cenários independentes, cada um com propósitos operacionais distintos, o que impede a comparação direta de seus resultados absolutos.

O primeiro cenário, focado na análise de latência extrema e serialização, foi executado em hardware de alto clock, utilizando um processador AMD Ryzen 7 7700X, com 8 núcleos e frequência de até 5,4 GHz. O segundo cenário, direcionado à avaliação de vazão e escalabilidade, foi executado em um servidor de alta simultaneidade, baseado em Intel Xeon E5-2680 v4, com 14 núcleos e 28 threads. Essa abordagem permitiu uma análise abrangente do desempenho da arquitetura em diferentes condições de carga e processamento.

Implementação e Arquitetura

A arquitetura proposta foi implementada seguindo o paradigma de microserviços, em conformidade com as definições de Fowler e Lewis (2014), utilizando a linguagem Go como base para os serviços distribuídos (GO AUTHORS, 2025). A comunicação inter-serviços foi estruturada por meio do protocolo gRPC (GRPC AUTHORS, 2025), que explora a multiplexação do HTTP/2 para garantir baixa latência e alta taxa de transferência, características essenciais para aplicações financeiras em tempo quase real (ATRI, 2024).

A coordenação de transações distribuídas entre os serviços Tracker e Analytics adotou o padrão Saga, conforme descrito por Richardson (2026), que é apropriado para cenários onde a consistência é mantida de forma eventual entre múltiplos serviços independentes (BHOSALE, 2024). Essa organização arquitetural favorece a separação de responsabilidades entre a captura de eventos on-chain, o processamento analítico e a persistência de dados, alinhando-se a padrões contemporâneos de arquiteturas cloud-native escaláveis (SHEKHAR, 2024; TANDON; PATEL, 2021).

A persistência dos dados seguiu um modelo híbrido, conforme sugerido por Popereshnyak et al. (2025). O PostgreSQL foi empregado para armazenar dados estruturados e informações sensíveis, enquanto o MongoDB foi utilizado para metadados flexíveis relacionados aos pools de liquidez e registros de eventos. Adicionalmente, o Redis foi incorporado como camada de cache em memória (L1) para acelerar o acesso aos estados mais recentes, reduzindo a carga sobre os bancos de dados principais e melhorando o tempo de resposta das consultas.

Avaliação de Performance e Resultados

A avaliação inicial, realizada no cenário experimental de latência e serialização, mediu o impacto direto da substituição da comunicação baseada em HTTP REST com serialização JSON pela arquitetura proposta, que utiliza gRPC e Protocol Buffers para o transporte interno entre microserviços. A adoção de mensagens binárias reduziu significativamente o tempo de processamento intra-cluster, com ganhos consistentes em serialização, desserialização, latência ponta a ponta e vazão total.

Especificamente, o tempo de serialização (Marshal) foi de 0,57 ms com gRPC/Protobuf, em comparação com 1,94 ms com JSON/REST, representando uma melhoria de 70,6%. Para a desserialização (Unmarshal), o tempo foi de 0,62 ms com gRPC/Protobuf, contra 8,08 ms com JSON/REST, indicando uma melhoria de 92,3%. A latência E2E interna foi de 0,33 ms com gRPC/Protobuf, versus 0,64 ms com JSON/REST, uma melhoria de 48,4%. A vazão total (Throughput) alcançou 3.010 requisições por segundo com gRPC/Protobuf, superando as 1.485 requisições por segundo do JSON/REST, o que representa um ganho de 102,7%.

Além dos ganhos médios, a análise da série temporal de latência evidenciou maior estabilidade do pipeline baseado em gRPC/Protobuf durante a execução contínua. Enquanto a comunicação HTTP REST/JSON apresentou maior variabilidade e surtos intermitentes de latência, o gRPC/Protobuf manteve um comportamento substancialmente mais estável, com menor dispersão e sensibilidade reduzida a microvariações de processamento. Esse resultado sugere que a serialização binária não apenas reduz o custo médio por requisição, mas também contribui para maior previsibilidade operacional do sistema sob carga contínua, aspecto relevante em ambientes distribuídos orientados a processamento em tempo real (ATRI, 2024).

Segurança Zero-Trust e Sobrecarga de mTLS

A segurança da comunicação leste-oeste no SagaIndexer foi concebida segundo o modelo Zero-Trust, que não presume confiança em nenhuma comunicação interna por padrão (KUEH, 2020). Para tal, implementou-se a obrigatoriedade de mTLS (Mutual TLS) em todas as chamadas gRPC entre os serviços, em consonância com as boas práticas recentes de proteção de arquiteturas distribuídas (KOTENKO et al., 2024).

Nos cenários de simulação de ataque, que incluíram injeção de tráfego por nós não autenticados e uso de tokens revogados, todas as tentativas de comunicação não autorizada foram interceptadas e bloqueadas na camada de transporte. As medições de isolamento indicaram que a adoção dessa camada criptográfica introduziu um overhead de apenas 8,4% de latência extra por requisição interna. Esse resultado demonstra que a implementação de mecanismos robustos de autenticação e verificação mútua é operacionalmente viável, mesmo em aplicações DeFi que exigem baixa latência (KUEH, 2020; KOTENKO et al., 2024).

Eficiência de Banda e Pegada de Rede

Considerando o volume de dados associado aos cinco pools analisados, a volumetria indicou um ponto operacional de maior eficiência com a configuração de 12 workers e lotes de 500 eventos. Nesse contexto, a adoção do formato binário do Protocol Buffers reduziu a pegada de rede em 70% em relação às estruturas de dados JSON convencionais. Esse ganho expressivo na eficiência do transporte interno é particularmente relevante em sistemas integrados à infraestrutura blockchain, pois a redução de tráfego contribui para menor contenção de rede e maior previsibilidade de comunicação em cenários de alta demanda (NAKAMOTO, 2008; BUTERIN, 2014).

Escalabilidade e Vazão em Hardware Multicore

Para avaliar a capacidade de processamento concorrente sob estresse prolongado, simulando processos de backfill histórico em larga escala, utilizou-se o ambiente baseado em processador AMD Ryzen. Nesse cenário, a comunicação baseada em gRPC atingiu uma vazão sustentada de 3.010 requisições por segundo, superando em 2,02 vezes o teto alcançado pelo cluster quando operado via HTTP REST. A arquitetura evidenciou escalabilidade vertical consistente e previsível, com distribuição eficiente do processamento entre o conjunto de goroutines disponíveis, em conformidade com o modelo de concorrência oferecido pela linguagem Go (GO AUTHORS, 2025).

Os resultados observados reforçam a adequação de arquiteturas desacopladas e concorrentes para cenários de ingestão intensiva de dados, especialmente em aplicações de criptoativos que demandam elasticidade, paralelismo e separação funcional de responsabilidades (SHEKHAR, 2024; SINGH, 2025; POPERESHNYAK et al., 2025). A capacidade de processar um alto volume de transações por segundo, com uma curva de escalabilidade linear, demonstra a robustez do design proposto para ambientes de alta demanda.

Impacto do Cache de Tempo Real e Localidade

A introdução de uma camada de cache L1, implementada com Redis, para o armazenamento de timestamps de bloco e dados contextuais, reduziu de forma substancial o tempo total de processamento nos diferentes cenários avaliados. O uso do cache diminuiu expressivamente o custo computacional tanto em pools de menor volume quanto em pools de maior atividade, produzindo ganhos ainda mais relevantes no processo de sincronização histórica (backfill).

Esse comportamento evidencia que a manutenção, em memória, de informações frequentemente reutilizadas reduz a necessidade de consultas redundantes à blockchain principal e melhora a eficiência global do pipeline analítico. Os resultados indicam que a localidade de dados exerce papel central no desempenho do sistema, sobretudo à medida que cresce a densidade de eventos processados. Em termos arquiteturais, o uso de Redis como cache de tempo real não apenas reduz o tempo total de processamento, mas também aumenta a previsibilidade operacional em cenários de alta carga, reforçando a importância de estratégias especializadas de data serving em sistemas distribuídos de alta vazão (SHEKHAR, 2024; TANDON; PATEL, 2021).

Discussão

Embora parte da literatura sobre arquiteturas Web3 enfatize os ganhos de modularidade e desacoplamento funcional, a avaliação empírica realizada neste trabalho evidencia um aspecto adicional. Em ambientes reais de operação, um indexador off-chain não atua apenas como camada de organização arquitetural, mas também como mecanismo de amortecimento das oscilações temporais impostas pela rede blockchain subjacente (NAGESH, 2024).

No caso da Ethereum, a disponibilidade efetiva dos dados não depende exclusivamente da emissão do evento em cadeia, mas também das variações de propagação, resposta dos provedores JSON-RPC e condições momentâneas de congestionamento da rede. Essa dinâmica, que apresenta picos acentuados de latência de propagação dos logs em períodos de maior congestionamento, reflete a variabilidade inerente à infraestrutura externa de consulta e sincronização.

Nesse contexto, a principal virtude técnica da arquitetura modular proposta reside em sua capacidade de absorver essas oscilações por meio de comunicação assíncrona, desacoplamento entre ingestão e processamento e transporte interno baseado em gRPC. Esse resultado sugere que a separação entre captura, processamento e persistência não produz apenas ganhos organizacionais, mas também efeitos mensuráveis sobre a resiliência temporal do sistema.

Em outras palavras, a modularização não apenas melhora a estrutura do software, mas também reduz a sensibilidade do pipeline analítico às oscilações inerentes à camada 1. Tal evidência reforça que, em aplicações de monitoramento DeFi de alta demanda, a arquitetura off-chain especializada atua como elemento estabilizador entre a variabilidade da rede blockchain e a necessidade de disponibilidade contínua dos dados processados.

Identificação de Gargalos Críticos

A análise instrumental de decomposição de latência revelou que o gargalo estrutural predominante do pipeline permanece localizado na interface com a rede Ethereum. A propagação de eventos on-chain por meio do provedor e a resposta das chamadas JSON-RPC consomem 78,2% do tempo total de processamento end-to-end, indicando que a maior parcela do custo temporal do sistema é imposta pela infraestrutura externa de consulta e não pelo núcleo interno da arquitetura.

Essa constatação reforça a premissa arquitetural do trabalho: ao otimizar de forma intensiva os 21,8% relativos ao processamento interno do cluster, por meio de gRPC, mTLS com baixo custo e concorrência, o custo computacional da orquestração distribuída torna-se relativamente reduzido diante do atraso estrutural da blockchain base e de seus intermediários de acesso (ATRI, 2024; ETHEREUM FOUNDATION, 2025). Os componentes internos, como gRPC/Internal, Persistência DB e Orquestração Saga, contribuem com 2,7%, 6,3% e 12,8% da latência end-to-end, respectivamente, totalizando 21,8% do tempo médio de resposta.

Limitações e Desafios Operacionais

Embora os testes documentem a elevada viabilidade do sistema no contexto dos pools avaliados, a generalização de sua resiliência para todos os cenários de produção exigiria ampliar o escopo empírico da análise. A primeira limitação decorre da dependência de infraestrutura externa de acesso à rede Ethereum, uma vez que a latência basal permanece condicionada à resposta de provedores JSON-RPC e ao custo operacional imposto por serviços de terceiros em cenários de alto throughput (BUTERIN, 2014; ETHEREUM FOUNDATION, 2025).

Além disso, episódios de forte congestionamento de rede, caracterizados por elevada competição por inclusão de transações, podem introduzir assimetrias temporárias na propagação de logs entre nós distribuídos, degradando métricas sensíveis à precisão temporal. Soma-se a isso a complexidade inerente ao padrão Saga, cuja adoção implica tratamento de estados distribuídos, rotinas de compensação e maior exigência de rastreabilidade operacional quando comparado a modelos monolíticos baseados em transações ACID tradicionais (RICHARDSON, 2026; BHOSALE, 2024).

Por fim, a generalização para cenários multichain não pode ser assumida sem reservas. A arquitetura e seus parsers foram dimensionados especificamente para logs de contratos compatíveis com o padrão EVM no contexto do Uniswap V3. Uma eventual expansão para ecossistemas de consenso e estruturas de dados distintas demandaria revisão substancial do módulo de ingestão, especialmente no componente Tracker.

Em síntese, a implementação e avaliação empírica do SagaIndexer demonstraram que a transição de serviços monolíticos de leitura de blockchain para ecossistemas distribuídos off-chain é arquiteturalmente justificável em contextos de extração intensiva de dados. Os resultados obtidos indicam que a separação entre captura, processamento e disponibilização de dados permite otimizações independentes de desempenho, comunicação e acesso, com ganhos concretos no cenário avaliado, como a vazão 2,02 vezes superior em cenários multicore, latência interna estável na ordem de 8,5 ms, redução de 70% na pegada de rede e melhora expressiva no tempo total de processamento com o uso de cache L1 em Redis, sobretudo em cenários de maior densidade de dados e sincronização histórica.

4. Conclusão

O estudo teve como objetivo implementar e avaliar uma arquitetura de microserviços para o monitoramento de liquidez no protocolo Uniswap V3, na rede Ethereum, com foco na comunicação interna entre serviços e na extração contínua de dados off-chain. Verificou-se que a arquitetura proposta, desenvolvida em Go com gRPC e Protocol Buffers, demonstrou ganhos substanciais de performance. Observou-se uma redução expressiva nos custos de serialização e desserialização, com melhorias de 70,6% e 92,3% respectivamente, em comparação com HTTP REST/JSON. A latência interna manteve-se estável em torno de 0,33 ms, e a vazão em cenários multicore foi 2,02 vezes superior, atingindo 3.010 requisições por segundo. Adicionalmente, identificou-se uma redução de 70% na pegada de rede e uma melhora significativa no tempo total de processamento com a incorporação de cache L1 em Redis, especialmente em processos de sincronização histórica. A implementação de mTLS introduziu um overhead de apenas 8,4% na latência, confirmando a viabilidade de mecanismos robustos de segurança. Esses achados indicam que a separação entre captura, processamento e disponibilização de dados torna a arquitetura tecnicamente adequada para aplicações analíticas de alta demanda no ecossistema Ethereum, atuando como um elemento estabilizador frente à variabilidade da rede blockchain subjacente.

Apesar dos resultados promissores, o estudo reconhece limitações importantes. A latência basal do sistema permanece condicionada à infraestrutura externa de acesso à rede Ethereum, com 78,2% do tempo total de processamento end-to-end atribuído à propagação de eventos on-chain e à resposta dos provedores JSON-RPC. Episódios de congestionamento de rede podem introduzir assimetrias temporárias na propagação de logs, e a complexidade inerente ao padrão Saga exige maior rastreabilidade operacional. Além disso, a generalização para cenários multichain não é direta, pois a arquitetura foi dimensionada especificamente para logs de contratos compatíveis com o padrão EVM do Uniswap V3. Para estudos futuros, sugere-se aprofundar a resiliência do orquestrador distribuído, adaptar a arquitetura para redes Layer 2, incorporar modelos analíticos para extração de valor máximo (MEV) e explorar mecanismos de verificabilidade baseados em provas de conhecimento zero, consolidando uma infraestrutura analítica escalável, verificável e adaptável às exigências do ecossistema descentralizado.

Referências Bibliográficas

ADAMS, H. et al. Uniswap v3 Core. [S. I.]: Uniswap Labs, 2021. Disponível em: https://uniswap.org/whitepaper-v3.pdf. Acesso em: 01 jan. 2026.

ATRI, S. GRPC as a low latency backbone for real time financial platforms. International Journal of Leading Research Publication (IJLRP), v. 22, n. 4, p. 436–450, 2024.

BHOSALE, P. Data consistency models in distributed systems: CAP theorem revisited. International Journal on Science and Technology (IJSAT), 2024.

BUTERIN, V. Ethereum: A next-generation smart contract and decentralized application platform. [S. I.]: Ethereum Foundation, 2014. Disponível em: https://ethereum.org/whitepaper/. Acesso em: 17 dez. 2025.

ETHEREUM FOUNDATION. Go Ethereum documentation. 2025. Disponível em: https://geth.ethereum.org/docs. Acesso em: 01 jan. 2026.

FOWLER, M.; LEWIS, J. Microservices: a definition of this new architectural term. [S. I.: s. n.], 2014. Disponível em: https://martinfowler.com/articles/microservices.html. Acesso em: 01 jan. 2026.

GO AUTHORS. The Go programming language documentation. 2025. Disponível em: https://go.dev/doc/. Acesso em: 01 jan. 2026.

GRPC AUTHORS. gRPC documentation. 2025. Disponível em: https://grpc.io/docs/. Acesso em: 01 jan. 2026.

KRAKEND AUTHORS. KrakenD API Gateway documentation. 2025. Disponível em: https://www.krakend.io/docs/. Acesso em: 01 jan. 2026.

NAKAMOTO, S. Bitcoin: A peer-to-peer electronic cash system. [S. I.: s. n.], 2008. Disponível em: https://bitcoin.org/bitcoin.pdf. Acesso em: 01 jan. 2026.

POPERESHNYAK, S. et al. Microservices architecture for building a crypto freelance exchange. CEUR Workshop Proceedings, v. 3826, p. 301–309, 2025.

RICHARDSON, C. Pattern: Saga. Microservices.io, 2026. Disponível em: https://microservices.io/patterns/data/saga.html. Acesso em: 01 jan. 2026.

SHEKHAR, G. Microservices design patterns for cloud architecture. IEEE Chicago Section, 2024.

TANDON, R.; PATEL, D. Evolution of microservices patterns for designing hyper-scalable cloud-native architectures. ESP Journal of Engineering & Technology Advancements, v. 1, n. 1, p. 288-297, 2021.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy