A porta de entrada para serviços de ativos digitais, infraestrutura de dados on-chain - Tiger Research

1. O muro que os ativos digitais enfrentam, dados on-chain pouco amigáveis {#rps-1}

O mercado de ativos digitais está se desenvolvendo rapidamente. As stablecoins já processam transações no valor de trilhões de dólares anualmente e são utilizadas nas áreas de pagamentos e remessas, enquanto a tokenização de ativos financeiros tradicionais, como ações e títulos, também está se intensificando. Isso demonstra que o papel da tecnologia blockchain está se expandindo por toda a cadeia de valor financeira, desde a emissão e distribuição de ativos até pagamentos e liquidações.

Agora, a blockchain passou da fase de discussão de possibilidades para a fase de construção de infraestrutura prática. Assim, o foco da discussão não é mais provar a necessidade da adoção da tecnologia, mas sim como operá-la dentro do sistema financeiro institucional. Em particular, como integrar a infraestrutura blockchain aos fluxos de trabalho existentes, como contabilidade, tributação, auditoria e conformidade. Mesmo que a blockchain funcione como uma nova infraestrutura básica, os procedimentos e critérios exigidos pelo sistema financeiro institucional ainda precisam ser mantidos.

O problema é que o processo de integração da infraestrutura blockchain aos fluxos de trabalho financeiros existentes é complicado. O sistema financeiro legado opera com dados estruturados padronizados, enquanto os dados on-chain são mais próximos de dados brutos que requerem indexação, decodificação e normalização separadas. Para ilustrar, é como uma pilha desordenada de recibos em vez de um livro contábil bem organizado.

Portanto, para utilizar dados on-chain, é essencial ter um pipeline de dados separado. É necessário coletar registros de transações de livros distribuídos e refiná-los para um propósito específico. Além disso, deve-se ter uma infraestrutura capaz de armazenar de forma confiável dados que chegam a dezenas de terabytes e de consultar rapidamente quando necessário. No final, embora os dados on-chain sejam públicos para todos, não são dados que podem ser facilmente utilizados por si só.

2. Realidade e limitações da construção de infraestrutura de dados on-chain {#rps-2}

No entanto, no início, quando o tamanho e o escopo de uso do mercado de ativos digitais eram limitados, esses problemas de acessibilidade a dados não eram tão evidentes. A maioria dos serviços de ativos digitais era mais como experimentos em pequena escala voltados para um número limitado de participantes. Por exemplo, o projeto de token de depósito do banco de investimento global JP Morgan era um meio de pagamento limitado, projetado apenas para um pequeno número de clientes institucionais. Em um ambiente onde os participantes e os objetivos de uso eram claros, o tipo de transações a serem processadas também era simples, e a temporalidade ou precisão dos dados não era tão importante.

Naquela época, os critérios exigidos para os dados on-chain eram relativamente frouxos. Mesmo que todos os estados não corressem rigorosamente em tempo real, não havia grandes problemas operacionais desde que, após um certo tempo, a consistência fosse alcançada. Ou seja, um método de processamento baseado na consistência eventual era suficientemente aceitável. Nesse ambiente, era possível lidar sem problemas operando nós limitados ou integrando endpoints RPC externos ou APIs de dados on-chain simples.

No entanto, à medida que o ambiente on-chain se expandiu, tornou-se cada vez mais difícil lidar apenas com os métodos existentes. A diversidade dos grupos de ativos tratados e o rápido aumento do volume de transações ampliaram drasticamente o escopo de processamento de dados. Consequentemente, os requisitos técnicos que a infraestrutura de dados deve atender também estão se sofisticando, indo além do nível de consulta simples para formas muito mais refinadas e que garantem a temporalidade. À medida que se entra em uma fase operacional real, os critérios exigidos pela infraestrutura mudaram fundamentalmente.

3. Requisitos de infraestrutura de dados on-chain para o sistema financeiro institucional {#rps-3}

Para atender a esses níveis de exigência elevados, os critérios para avaliar a infraestrutura também precisam mudar. A Tiger Research apresenta três critérios principais para a infraestrutura de dados on-chain que o sistema financeiro institucional pode confiar e utilizar: completude (Completeness), consistência (Consistency) e estabilidade (Stability). Esses são requisitos essenciais que os dados on-chain devem atender para funcionar como um livro-razão padrão de serviços reais.

3.1. Completude (Completeness): todas as transações estão incluídas? {#rps-4}

A completude é o requisito mais básico da infraestrutura de dados on-chain. Este é o critério que determina se todos os registros de transações registrados no livro-razão da blockchain foram coletados sem omissões e se foram refletidos no processo de tratamento subsequente sem falhas. No sistema financeiro institucional, a omissão de uma única transação pode alterar o cálculo de saldo, o tratamento contábil e os resultados de liquidação.

As omissões de dados podem ocorrer primeiro na fase de coleta. A blockchain agrupa transações que ocorrem durante um certo período em blocos para registrá-las no livro-razão. A infraestrutura de dados coleta e processa esses blocos em ordem. No entanto, se a coleta de blocos em um determinado intervalo for interrompida devido a falhas de nó ou problemas de rede, os registros de transações incluídos nesse intervalo também podem ser omitidos. No entanto, as omissões na fase de coleta podem ser verificadas e tratadas de forma relativamente clara. Isso porque é possível preencher os dados por meio de um trabalho de backfill que recolhe novamente os intervalos de blocos omitidos.

Outro problema é o processo de tratamento após a coleta de todos os dados de blocos originais. O indexador extrai os registros de transações necessários dos dados originais e os converte em uma forma consultável. Nesse momento, se os dados não forem analisados corretamente, alguns registros podem ser perdidos no processo de tratamento. Por exemplo, suponha que estamos indexando dados de transferência de tokens da Solana. A Solana possui padrões de tokens existentes, além de padrões de extensão. Se o indexador estiver projetado para analisar apenas o padrão existente, o histórico de movimentação de tokens emitidos sob o padrão de extensão pode ser omitido.

Em cadeias de alto desempenho, a carga para manter a completude aumenta ainda mais. Quanto mais curto o ciclo de criação de blocos e maior o volume de transações, maior será a quantidade de dados que o pipeline de dados deve processar em um curto período de tempo. Mesmo que não haja falhas na lógica de coleta e processamento, se o processamento em tempo real não acompanhar a velocidade da cadeia, a reflexão dos registros de transações que ocorreram nesse meio tempo pode ser atrasada. No final, a completude deve ir além de simplesmente obter dados sem omissões; deve ser capaz de responder continuamente às mudanças e à velocidade da cadeia.

3.2. Consistência (Consistency): os dados coletados são precisos? {#rps-5}

Se a completude verifica a ausência de omissões de dados, a consistência é o critério que determina se os dados coletados correspondem ao livro-razão da blockchain. No sistema financeiro institucional, a consistência é tão importante quanto a completude. Se um único dado estiver incorreto, todos os cálculos e julgamentos baseados nele também podem ser distorcidos.

No blockchain, o processo de confirmação do livro-razão pode levar a variações temporárias nos dados. Enquanto os sistemas financeiros tradicionais registram e gerenciam dados com base em um servidor central, o blockchain permite que vários participantes verifiquem blocos individualmente e atualizem o livro-razão após um consenso. Durante esse processo, podem ocorrer situações em que diferentes blocos parecem válidos simultaneamente devido a atrasos na rede ou diferenças nos momentos de verificação.

Nesse processo, um bloco que inicialmente foi considerado válido pode ser posteriormente excluído do livro-razão final e substituído por outro, resultando em um ajuste de bloco (Reorg). Nesse caso, as transações incluídas nesse bloco podem ser excluídas do livro-razão final ou re-incluídas em outro bloco. Isso pode levar a problemas de consistência, pois os dados coletados em um determinado momento podem diferir do estado final do livro-razão.

Problemas de consistência também podem ocorrer no cliente do nó. O cliente do nó é o software central que opera os nós do blockchain, funcionando como um sistema operacional (OS) para o blockchain. Se houver falhas nesse software, podem ocorrer erros ao interpretar e calcular os dados do livro-razão. De fato, houve casos em que os principais clientes de nós do Ethereum apresentaram erros durante o processamento de transações ou cálculos de taxas. Isso é semelhante a incidentes em serviços financeiros onde os ativos dos clientes são exibidos incorretamente ou as taxas são calculadas de forma errada.

Assim, a consistência dos dados on-chain não é garantida apenas pela coleta de dados. Os dados coletados em um determinado momento podem diferir do livro-razão final, e falhas no cliente do nó podem levar a uma interpretação incorreta dos dados do livro-razão. Portanto, para utilizar dados on-chain como dados de referência no sistema financeiro tradicional, é necessário continuamente comparar e verificar se os dados coletados correspondem ao livro-razão.

3.3. Estabilidade: É estável em ambientes de operação em larga escala?

Se a integridade e a consistência são critérios para verificar a qualidade dos dados, a estabilidade é um critério para determinar se a coleta, processamento e consulta de dados podem continuar sem interrupções em ambientes de operação em larga escala. Devido à natureza da indústria, onde até mesmo uma única falha ou atraso pode resultar em consequências graves, essa é uma exigência inegociável. Especialmente, a infraestrutura on-chain pressupõe uma rede que não para 24 horas por dia, portanto, os requisitos de estabilidade são ainda mais elevados.

Em ambientes de operação em larga escala, é necessário processar muitas solicitações simultaneamente. Em uma infraestrutura de servidor tradicional, a carga pode ser distribuída entre vários servidores por meio de balanceamento de carga (Load Balancing) para aumentar a capacidade de processamento. No entanto, na infraestrutura de blockchain, operar vários nós não garante o mesmo efeito. Os momentos de sincronização dos blocos de cada nó podem ser diferentes, resultando em resultados diferentes para a mesma solicitação de consulta.

Por exemplo, suponha que um usuário consulte o status de processamento logo após enviar uma transação. O nó que recebeu a solicitação inicialmente pode ter verificado a transação, mas outro nó que recebeu a solicitação de consulta pode ainda não ter refletido isso. Nesse caso, mesmo que a infraestrutura responda normalmente, o usuário verá estados diferentes para uma única transação.

À medida que o volume de dados aumenta, garantir a estabilidade se torna mais difícil. No sistema financeiro tradicional, não é suficiente apenas verificar o estado mais recente. É necessário avaliar o estado dos ativos em um determinado momento e verificar quais históricos de transações levaram a esse estado. Para isso, são necessários nós de arquivo (Archive Node) que preservem registros históricos, mas dependendo da cadeia, seu tamanho pode chegar a dezenas de terabytes. Em um ambiente onde vastos dados precisam ser armazenados e consultados, a possibilidade de atrasos nas consultas e gargalos no sistema também aumenta.

A manutenção contínua também é um requisito importante para a estabilidade. O blockchain continua a mudar durante a operação, com hard forks (Hard Fork), atualizações de cadeia e atualizações de clientes de nós. Se o pipeline de coleta e processamento de dados não conseguir se adaptar a essas mudanças, a infraestrutura que estava funcionando normalmente pode parar de funcionar instantaneamente. Portanto, a estabilidade não é garantida apenas pela construção inicial, mas deve ser mantida por meio de uma adaptação contínua às mudanças no ambiente da cadeia.

4. Lambda256: Infraestrutura de Dados On-Chain para o Sistema Financeiro Tradicional

É raro que uma empresa que está se preparando para negócios de ativos digitais construa toda a infraestrutura de base de forma independente. Normalmente, elas escolhem uma infraestrutura de cadeia global com tecnologia comprovada e concretizam seu modelo de negócios sobre ela. A infraestrutura de dados on-chain também deve ser vista sob essa perspectiva. A infraestrutura de dados on-chain que possui integridade, consistência e estabilidade não é apenas uma tarefa de construção de um banco de dados simples.

Em um ambiente complexo de múltiplas cadeias, é necessário indexar em tempo real dados estruturados de forma diferente em cada cadeia e manter alta estabilidade e desempenho de processamento mesmo com tráfego intenso. Além disso, é necessário responder continuamente a novos padrões e atualizações de cadeia. Portanto, a infraestrutura de dados on-chain não é um projeto de desenvolvimento que termina em um curto período, mas sim um empreendimento de grande escala que requer enormes capitais, tempo e experiência operacional prática.

Assim, do ponto de vista das empresas, é mais realista escolher parceiros de infraestrutura comprovados e se concentrar em seus negócios principais, em vez de desenvolver toda a infraestrutura internamente. É por isso que a Lambda256 se estabeleceu como parceira tecnológica de principais empresas de ativos digitais na Coreia do Sul. A Lambda256, uma subsidiária de tecnologia blockchain da Dunamu, fornece infraestrutura de blockchain para bolsas, instituições financeiras e empresas Web3, acumulando experiência operacional no mercado interno.

Com base nessa experiência, a Lambda256 lançou a plataforma de desenvolvimento Web3 'Nodit' em 2024. O 'DataShare', recentemente revelado, é um produto de infraestrutura de dados on-chain do Nodit, projetado considerando a qualidade dos dados e o ambiente operacional exigidos pelo sistema financeiro tradicional. Antes do lançamento oficial, o serviço foi fornecido a alguns parceiros por mais de dois anos na forma de um armazém de dados, o que indica que a infraestrutura já passou por um processo de validação em ambientes práticos.

4.1. Diferenciação Técnica: Motor de Indexação Próprio e Pipeline de Dados de Alto Desempenho

A diferenciação técnica do DataShare reside em fornecer dados fragmentados de um ambiente de múltiplas cadeias como conjuntos de dados adequados ao fluxo de trabalho existente. Em um ambiente de múltiplas cadeias, as estruturas de dados e os métodos de registro variam entre as cadeias, portanto, os critérios de coleta e processamento devem ser projetados de acordo com as características de cada cadeia. Além disso, à medida que o ambiente operacional de cada cadeia continua a mudar, como a introdução de novos padrões ou atualizações de rede, a complexidade da gestão da infraestrutura de dados aumenta. O DataShare possui uma estrutura que pode responder continuamente a essas diferenças entre cadeias e mudanças operacionais, com pessoal especializado em conhecimento de domínio, um motor de indexação próprio e um pipeline de dados de alto desempenho. Mais detalhes sobre a diferenciação técnica do DataShare podem ser encontrados em um artigo co-escrito pela Lambda256 e pela Decipher (Associação de Tecnologia Blockchain da Universidade Nacional de Seul).

Para que essa estrutura funcione de forma estável, é necessário que a infraestrutura do nó que obtém os dados de origem também seja suportada. O DataShare é servido sobre a arquitetura Hyper Node da Nodit, permitindo uma resposta flexível a grandes solicitações ou falhas de nós. A gestão do critério mínimo de nós disponíveis e o controle dos limites de latência e recuperação foram projetados para evitar que problemas em um nó se espalhem por todo o processo de coleta. Além disso, a estrutura está preparada para responder sem interrupções a mudanças no ambiente, como atualizações da mainnet ou substituições de software de nós.

Outro ponto importante que diferencia o DataShare é que os dados coletados passam por um processo de validação separado. O DataShare verifica continuamente, por meio de um processo de validação interno, se os dados coletados correspondem ao estado real da cadeia. Nesse processo, são verificados ajustes de blocos, erros de clientes de nós e diferenças de dados que podem ocorrer após atualizações da cadeia, além de confirmar se os resultados do processamento de transações individuais são refletidos de maneira consistente nos registros de eventos e nas mudanças de saldo. Em outras palavras, ao validar cruzadamente o que está registrado na cadeia e os resultados processados pelo DataShare, a estrutura reduz a possibilidade de perda de dados ou erros de processamento, garantindo a confiabilidade que pode ser utilizada como dados de referência em fluxos de trabalho existentes.

No entanto, para que os dados on-chain sejam utilizados em operações reais, é necessário que não apenas a precisão dos dados, mas também a ampla oferta de tipos de cadeia e dados necessários estejam disponíveis. O DataShare atualmente oferece suporte básico a 13 cadeias principais que têm alta demanda no mercado e pode expandir conjuntos de dados personalizados com base nas mais de 50 multichains operadas pela Nodit. No futuro, planeja-se fornecer dados rotulados que combinem endereços de carteiras de exchanges, contratos inteligentes DeFi e dados de preços, ampliando assim o escopo de utilização para contabilidade, tributação, gerenciamento de riscos e monitoramento de transações suspeitas.

4.2. Diferenciação Operacional: Resposta à Conformidade e Integração com Fluxos de Trabalho Existentes

Para utilizar dados on-chain no setor financeiro regulamentado, é necessário atender não apenas à qualidade dos dados, mas também aos requisitos de conformidade. Especialmente no setor financeiro nacional, os critérios aplicados ao introduzir infraestrutura de dados externos são rigorosos, incluindo separação de redes, controle de acesso e padrões de operação de redes internas. O DataShare apoia a construção on-premise dentro de IDC nacional, considerando esse ambiente, e garante a confiabilidade do sistema de gerenciamento de segurança por meio da certificação SOC2. Isso permite que as instituições financeiras adotem dados on-chain de acordo com suas políticas de segurança interna e diretrizes regulatórias.

É também importante que as instituições financeiras possam gerenciar diretamente a localização de armazenamento e os direitos de acesso aos dados. O DataShare suporta uma arquitetura que envia dados on-chain diretamente para o armazenamento em nuvem utilizado pelas instituições financeiras. Por exemplo, ao carregar dados on-chain em tempo real em ambientes de dados internos, como AWS S3, as instituições podem utilizar soluções de infraestrutura externa enquanto mantêm o controle sobre a gestão de dados e o controle de acesso internamente.

Além disso, o DataShare planeja continuar a fortalecer a conectividade com os ambientes de análise de dados já utilizados pelas instituições financeiras. Ao suportar a integração com principais plataformas de data warehouse e análise, como Snowflake, BigQuery e Databricks, o objetivo é garantir que os dados on-chain se conectem organicamente aos fluxos de trabalho existentes.

O sistema de suporte operacional da Lambda256 também é uma força do DataShare. A infraestrutura de dados on-chain é baseada em uma rede blockchain que opera 24 horas por dia, portanto, a capacidade de detectar e responder rapidamente a falhas ou atrasos é crucial. O DataShare fornece monitoramento contínuo e suporte técnico dedicado por meio de profissionais especializados no país, reduzindo a carga operacional que as instituições financeiras precisam gerenciar diretamente. Isso permite que as instituições financeiras gerenciem e utilizem dados on-chain de forma estável, sem precisar expandir significativamente suas organizações de infraestrutura blockchain.

5. Momentos em que a Infraestrutura de Dados On-Chain é Necessária

Cenário 1: Problema de Rastrear Precisamente a Situação dos Detentores de Ações Tokenizadas

No setor financeiro regulamentado, o número de casos em que ações listadas são emitidas simultaneamente na forma de tokens on-chain está aumentando. Um exemplo representativo é a Galaxy Digital, uma empresa global de ativos digitais, que tokenizou suas ações ordinárias ($GLXY) e as emitiu na blockchain Solana. A Securitize, uma empresa de tokenização de ativos, também emitiu suas ações ($SECZ) na Solana simultaneamente à listagem na Bolsa de Valores de Nova York (NYSE). A Solana, com sua rápida velocidade de processamento e baixos custos, está se tornando a infraestrutura principal escolhida por instituições financeiras que desejam tokenizar ações listadas de forma compatível com a regulamentação.

Instituições financeiras que lidam com ativos tradicionais e títulos tokenizados on-chain enfrentam novos desafios operacionais. As corretoras precisam rastrear com precisão a situação dos detentores de tokens registrados na blockchain e provar isso para as autoridades regulatórias e auditores. Essa é uma tarefa central que se repete não apenas no momento do fechamento, mas também nas datas de referência para dividendos e na determinação de direitos de voto. Se os dados forem perdidos ou se o saldo em um determinado momento for calculado incorretamente, isso pode levar a riscos fatais, como pagamentos excessivos, erros de divulgação e falhas na resposta a auditorias.

O problema é que a estrutura de dados única da Solana torna essas operações financeiras desafiadoras. Embora a Solana seja vantajosa em termos de custo e velocidade, sua estrutura de armazenamento de registros de transações é distribuída entre inúmeras contas. Mesmo uma única transação DeFi pode fragmentar dados em contas de tokens, pools de liquidez e contas de taxas. Além disso, o tamanho acumulado dos dados nos nós de arquivo da Solana chega a centenas de terabytes, tornando a tarefa de rastrear e reconstruir a situação dos detentores e o histórico de transações em momentos específicos do passado uma limitação realista para as instituições lidarem diretamente.

Portanto, para integrar ativos tokenizados baseados na Solana ao setor financeiro regulamentado, uma infraestrutura de dados que possa ser analisada imediatamente e sem processamento é essencial. O DataShare purifica os dados de origem fragmentados e os fornece em uma forma normalizada que pode ser consultada imediatamente nos data warehouses existentes das instituições financeiras. Especialmente, ao otimizar o pipeline para um ambiente de alta velocidade com um ciclo de geração de blocos inferior a 0,4 segundos, o DataShare garante a capacidade de processar em tempo real cerca de 20.000 transações por segundo por cadeia, minimizando atrasos na indexação.

Cenário 2: Pagamento Agente, Problemas de Gestão de Risco em Pagamentos On-Chain {#rps-12}

O mercado de Pagamento Agente (Agentic Payment), onde agentes de IA decidem e executam pagamentos em nome dos usuários, está emergindo. Desde o lançamento do protocolo de pagamento on-chain x402 pela Coinbase, a construção de uma infraestrutura de pagamento autônoma baseada em stablecoins também está em andamento.

No entanto, para que os pagamentos autônomos entre agentes se estabeleçam como serviços financeiros comerciais, a qualidade dos dados on-chain que servem como base para as decisões é de suma importância. À medida que os procedimentos de verificação humana diminuem, o sistema deve determinar a disponibilidade de saldo, a confirmação de transações e a possibilidade de transações anômalas apenas com base em dados. Se, durante esse processo, os dados on-chain forem omitidos ou distorcidos, erros fatais podem ocorrer em todo o processo de aprovação e rejeição de pagamentos.

Então, quais são os fatores concretos que causam essa omissão e distorção de dados em um ambiente de blockchain real? A causa mais representativa pode ser as transações que falharam na execução. Dependendo da congestão da rede, mais de 20% de todas as transações podem falhar, e especialmente no caso da Solana, a taxa de falha para transações não votadas pode ultrapassar 40%.

Se o sistema de pagamento confundir essas transações falhadas como se fossem processadas normalmente, um erro de discrepância de saldo pode ocorrer, onde o saldo é considerado reduzido mesmo que o pagamento real não tenha ocorrido. Além disso, a reestruturação de blocos (Reorg), onde uma transação que parecia ter sido aprovada em um determinado momento é cancelada posteriormente, também atua como uma variável crítica que agrava a distorção dos dados.

A DataShare busca resolver fundamentalmente esses problemas de confiabilidade dos dados, fornecendo apenas dados cuja integridade (Finality) foi garantida e cujo sucesso final foi confirmado ao sistema de pagamento. Isso é feito validando em tempo real transações não confirmadas ou registros de falha contidos nos dados de origem da blockchain na fase de pipeline, e fornecendo apenas conjuntos de dados refinados para eliminar preocupações com falhas operacionais devido a distorções on-chain.

Além disso, a DataShare está continuamente expandindo seu escopo de suporte para principais blockchains locais, como GIWA e Kaia, garantindo também a versatilidade dos negócios. Isso é de valor fundamental, pois permite que a infraestrutura de pagamento agente supere as limitações de depender de uma única mainnet global, oferecendo uma base de dados estável que pode ser flexivelmente diversificada para atender às necessidades do ambiente de serviço e requisitos regulatórios de cada região.

6. Conclusão {#rps-13}

O sucesso ou fracasso dos negócios de ativos digitais depende de quão precisamente os dados são tratados. Todos os processos financeiros, desde a emissão de ativos até pagamentos e liquidações, estão sendo reestruturados em torno de dados on-chain. Portanto, a omissão ou erro de dados pode não apenas reduzir a confiabilidade do serviço, mas também resultar em riscos regulatórios fatais. A DataShare atua como uma infraestrutura conectiva que reduz esses riscos operacionais e permite que as instituições financeiras utilizem dados on-chain de acordo com seus critérios operacionais.

Além disso, as instituições financeiras podem, além da DataShare, utilizar diversas soluções de tecnologia financeira da Lambda256 para expandir as funcionalidades necessárias de forma personalizada. Por exemplo, é possível introduzir o SCOPE para liquidação e operação de ativos digitais ou o CLAIR para conformidade regulatória, de acordo com a fase de crescimento do negócio, aumentando assim a integridade do sistema. Em outras palavras, é uma abordagem que permite combinar gradualmente as funcionalidades necessárias ao ambiente existente, sem a carga de reconstruir toda a infraestrutura desde o início.

Como resultado, as instituições financeiras podem se livrar completamente da carga operacional, como gerenciamento de infraestrutura complexa ou manutenção de sistemas, e se concentrar no valor comercial intrínseco de inovação de serviços e diferenciação de produtos. Uma estrutura é completada que, ao mesmo tempo em que reduz as barreiras de entrada iniciais, garante que as funcionalidades necessárias possam ser adquiridas de forma estável a qualquer momento, acompanhando a expansão dos negócios e as mudanças regulatórias.

Este artigo é uma especialidade da Tiger Research, uma instituição de pesquisa especializada em Web3 global, parceira da Block Media, intitulado 'A Porta de Serviços de Ativos Digitais, Infraestrutura de Dados On-Chain'. O relatório pode ser verificado no site oficial da .