A infraestrutura financeira precisa de arquitetura blockchain

A indústria de criptomoedas tem um problema de infraestrutura que raramente é discutido diretamente: temos construído sistemas financeiros em blockchains que não foram projetados para finanças, o que nos obriga a repensar a arquitetura da blockchain.

Resumo

  • Blockchains de propósito geral enfrentam dificuldades com finanças. A execução sequencial cria gargalos; transações financeiras precisam de processamento paralelo para escalar de forma eficiente.
  • A composibilidade impulsiona o valor do ecossistema. Primitivas de infraestrutura compartilhadas permitem que os protocolos se construam uns sobre os outros, reduzindo a fragmentação e possibilitando produtos que geram rendimento de forma eficiente em termos de capital.
  • A adoção institucional requer infraestrutura, não apenas funcionalidades. A conformidade autorizada, KYC e módulos de auditoria em sistemas descentralizados são pré-requisitos para uma participação institucional séria.

Notei isso no momento em que começamos a construir o Momentum. A maioria dos protocolos é lançada como produtos isolados, um DEX, um mercado de empréstimos, uma solução de staking, tratando cada um como uma ferramenta separada em vez de parte de um sistema interconectado. Mas essa fragmentação revela uma desadequação arquitetónica mais profunda. A camada de blockchain subjacente simplesmente não foi construída para lidar com o que as finanças exigem: processamento paralelo em escala, primitivas compostas e infraestrutura sobre a qual outros protocolos possam construir de forma fiável.

Isto não é teórico. Manifesta-se em falhas de transação durante a demanda máxima, ineficiência de capital nos mercados de liquidez e um ecossistema onde cada protocolo opera de forma isolada em vez de sinergicamente.

A verdadeira restrição: As blockchains não foram projetadas para finanças

Quando estávamos a decidir onde construir o nosso DEX, a escolha foi óbvia para mim, mas parecia contra-intuitiva para muitos. Todos perguntavam: Por que não Ethereum (ETH)? A resposta revela tudo sobre como eu penso sobre infraestrutura.

Considere a diferença fundamental entre como o Ethereum e o Sui (SUI) processam transações. O modelo de execução sequencial do Ethereum significa que cada transação deve ser processada em ordem, criando gargalos sob carga. Isto não era um erro no design do Ethereum; nunca foi o caso de uso pretendido. O Ethereum foi construído para ser uma plataforma de computação de uso geral.

As finanças exigem algo diferente. A maioria das operações financeiras é independente. Quando Alice troca tokens e Bob coloca ativos em stake, essas transações não dependem uma da outra. O processamento sequencial cria congestionamento artificial. O processamento paralelo não é apenas uma otimização; é estruturalmente necessário.

A Sui foi construída do zero com execução paralela e design centrado em objetos usando a linguagem de programação Move. Esta escolha arquitetônica não é apenas mais rápida — ela permite que uma categoria inteiramente diferente de produtos financeiros exista em escala.

A prova veio mais rápido do que esperávamos. Em seis meses, o nosso DEX escalou de zero para $500M em liquidez e $1.1B em volume de negociação diário, acumulando $22B em volume de negociação cumulativo enquanto integrava 2.1 milhões de usuários sem congestionamento significativo. Processar esse tipo de volume sem falhas de transação não é uma conquista de marketing; é uma evidência de solidez arquitetônica fundamental. Tente alcançar essas métricas em uma blockchain de execução sequencial e você verá exatamente por que a arquitetura é importante.

Por que a composabilidade da infraestrutura é mais importante do que produtos individuais

Há um segundo problema, mais sutil, que aprendi a reconhecer: os produtos financeiros devem ser blocos de construção compostáveis, não silos isolados.

Uma camada de infraestrutura financeira bem projetada deve permitir que outros protocolos construam sobre primitivos compartilhados. Se cada protocolo tiver que construir sua própria gestão de tesouraria, sua própria solução de staking, sua própria infraestrutura de liquidez, o ecossistema se fragmenta. Os desenvolvedores gastam tempo resolvendo problemas idênticos em vez de inovar em novos. Eu vi isso acontecer repetidamente através das chains.

É aqui que a maioria dos protocolos falha. Eles constroem um produto bem, depois o ecossistema ao seu redor se calcifica. Cada novo protocolo essencialmente começa do zero.

Quando construímos o nosso protocolo, escolhemos deliberadamente não criar apenas um DEX. Construímos primitivas de infraestrutura que outros protocolos racionalmente escolheriam usar em vez de reconstruir. O MSafe, a nossa solução de gestão de tesouraria, agora protege centenas de milhões em todo o ecossistema Move. Não porque forçámos a adoção, mas porque resolveu um problema real melhor do que as alternativas.

Mais protocolos construindo sobre infraestrutura compartilhada significa mais pontos de integração, mais composabilidade e maior valor do sistema para todos. Isso só funciona se os primitivos forem realmente bons. A tecnologia de criação de mercado com liquidez concentrada e incentivos alinhados cria eficiência de capital que os AMMs tradicionais não conseguem igualar. O staking líquido que produz um token de recibo que gera rendimento cria colateral que é simultaneamente produtivo. A gestão de tesouraria com múltiplas assinaturas que funciona de forma fiável reduz a fricção para a governança do protocolo.

Estas não são conveniências que podemos considerar agradáveis. Elas são a diferença entre um ecossistema que gera valor e um que se fragmenta. É precisamente isso que permite que o Momentum forneça infraestrutura sobre a qual outros protocolos escolhem racionalmente construir em vez de reconstruir por conta própria.

O problema do capital institucional é a infraestrutura, não as características

O crypto sempre lutou com a adoção institucional. A explicação padrão foca na incerteza regulatória ou nas limitações de UX. O verdadeiro gargalo é muitas vezes mais simples: as instituições não podem usar infraestruturas descentralizadas que carecem de capacidades de conformidade.

Esta não é uma razão para centralizar. É uma razão para construir a camada certa em cima de uma infraestrutura descentralizada. Se você puder oferecer conformidade permissionada como um módulo opcional, permitindo que os usuários institucionais verifiquem sua identidade e negociem com total clareza regulatória, enquanto mantém a infraestrutura base sem permissão, você resolve o problema sem compromissos.

As instituições não vão investir capital sério em sistemas que não conseguem fornecer auditoria regulatória, verificação KYC ou documentação de conformidade. Estas não são funcionalidades, são pré-requisitos estruturais para a participação institucional. Isso não é exclusão. É reconhecer a realidade.

O argumento real

Aqui está a afirmação que estou a fazer, separada de qualquer protocolo específico: As blockchains construídas para computação geral não podem servir eficientemente como infraestrutura financeira. A finança requer uma arquitetura especificamente projetada para processamento paralelo, primitivas compostas e conformidade institucional. Os protocolos migrarão para blockchains com estas propriedades—não porque estão na moda, mas porque a economia de operar em uma infraestrutura melhor é simplesmente superior.

Este não é um argumento de que “Sui é melhor que Ethereum.” Ethereum pode e deve continuar a evoluir. Soluções de camada 2 são abordagens legítimas. Este é um argumento de que os sistemas financeiros precisam ser construídos sobre fundamentos arquitetónicos diferentes dos plataformas de computação de propósito geral.

O corolário é menos óbvio: se uma blockchain é construída especificamente para finanças e alcança uma adoção significativa, ela se torna a base natural para a inovação financeira. Não por causa do marketing, mas porque outros protocolos escolhem racionalmente construir lá.

A questão para a indústria não é qual cadeia “vence”. É se estamos dispostos a reconhecer que uma arquitetura de blockchain de tamanho único nunca foi a abordagem certa, e que uma infraestrutura especializada produz melhores resultados financeiros.

Essa realização muda tudo sobre como os protocolos devem ser construídos e onde devem ser implementados. Está mudando a forma como penso sobre Momentum, e deve mudar a forma como você pensa sobre onde construir a seguir.

ChefWen

ChefWen

ChefWen é a fundadora da Momentum, o Motor de Liquidez Central do Move. Com uma forte formação em engenharia — incluindo cargos de engenheira de software sênior na Libra do Facebook e na Amazon — Wendy combina uma profunda expertise técnica com uma liderança visionária para construir soluções escaláveis que moldam a indústria. Wendy possui mestrados em Engenharia da Computação e em Pesquisa Operacional em Engenharia Industrial e de Sistemas pelo Georgia Institute of Technology. Na Momentum, Wendy está liderando esforços para se tornar o motor de liquidez central para o ecossistema Move com o lançamento da primeira DEX multi-chain ve(3,3). Atualmente a DEX nº 1 na Sui. Sua combinação de alta capacidade técnica, impulso empreendedor e perspectiva intercultural torna-a uma palestrante atraente para públicos interessados no futuro do Web3, inovação e engenharia de software.

Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
  • Recompensa
  • Comentário
  • Repostar
  • Compartilhar
Comentário
0/400
Sem comentários
  • Marcar
Negocie criptomoedas a qualquer hora e em qualquer lugar
qrCode
Escaneie o código para baixar o app da Gate
Comunidade
Português (Brasil)
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)