Descreva brevemente a arquitetura técnica do dYdX V4

dYdX V4 será um blockchain L1 independente com um livro de pedidos off-chain totalmente descentralizado e mecanismo de correspondência.

**Escrito por:**dYdX

Compile: IBCL

dYdX Chain V4 é a mais recente iteração do protocolo dYdX, que consistirá em software de código aberto. A versão atualmente em produção é chamada v3, v3 e as versões anteriores do dYdX têm em seu núcleo contratos inteligentes implantados em cadeias existentes combinadas com serviços centralizados hospedados na nuvem.

v4 será um blockchain L1 independente com um livro de pedidos off-chain totalmente descentralizado e um mecanismo de correspondência. A cadeia dYdX será baseada no Cosmos SDK e no protocolo de consenso CometBFT PoS.

À medida que nos aproximamos do lançamento da rede principal v4, queremos dar a você um vislumbre do que a equipe dYdX está construindo. Este artigo fornece uma visão geral de alto nível da arquitetura v4. Dado que v4 ainda está em desenvolvimento, pode haver mudanças.

arquitetura do sistema v4

O dYdX v4 foi projetado para ser totalmente descentralizado de ponta a ponta. Os componentes principais incluem amplamente protocolos, indexadores e frontends. Cada um desses componentes será fornecido como software de código aberto. A dYdX Trading Inc. não executará nenhum componente.

Acordo

O protocolo é um blockchain L1 construído no CometBFT e usando o CosmosSDK. O software Node é escrito em Go e compilado em um único binário. Como todos os blockchains do CosmosSDK, o v4 usa um mecanismo de consenso de prova de participação.

O protocolo será suportado por uma rede de nós. Existem dois tipos de nós:

• Validadores: Os validadores são responsáveis por armazenar pedidos em um livro de pedidos na memória (ou seja, fora da cadeia e sem comprometer o consenso), fofocar transações para outros validadores e gerar novos blocos para a cadeia dYdX por meio do processo de consenso. O processo de consenso fará com que os validadores se revezem como proponentes de novos blocos em um modo round-robin ponderado (ponderado pela quantidade de tokens apostados em seus nós). Os proponentes são responsáveis por propor o conteúdo do próximo bloco. Quando um pedido é correspondido, os proponentes o adicionam ao bloco proposto e iniciam uma rodada de consenso. Um bloco é considerado comprometido e adicionado ao blockchain se ⅔ ou mais validadores (por peso de aposta) o aprovarem. Os usuários enviarão transações diretamente aos validadores.
• Full Node: Um full node representa um processo executando um aplicativo v4 que não participa do consenso. É um nó com peso de participação 0, que não apresenta propostas nem as vota. No entanto, os nós completos se conectam à rede de validadores, participam da fofoca das transações e processam cada bloco recém-enviado. Os nós completos têm uma visão completa da cadeia dYdX e seu histórico e são projetados para oferecer suporte a indexadores. Algumas partes podem decidir (por motivos de desempenho ou custo) executar seus próprios nós completos e/ou indexadores.

indexador

O Indexer é uma coleção de serviços somente leitura cujo objetivo é indexar e fornecer dados de blockchain para usuários de maneira mais eficiente e compatível com a Web2. Isso é feito usando dados em tempo real de nós completos v4, armazenando-os em um banco de dados e disponibilizando esses dados aos usuários finais por meio de websocket e solicitações REST.

Embora o próprio protocolo v4 seja capaz de expor endpoints a consultas de serviço sobre alguns dados básicos na cadeia, essas consultas tendem a ser lentas porque validadores e nós completos não são otimizados para tratá-los com eficiência. Além disso, consultas excessivas aos validadores podem prejudicar sua capacidade de participar do consenso. Por esse motivo, muitos validadores do Cosmos preferem desabilitar essas APIs na produção. É por isso que é importante criar e manter indexadores e nós completos separados dos validadores.

Os indexadores usarão o banco de dados Postgres para armazenamento de dados on-chain, Redis para armazenamento de dados off-chain e Kafka para consumo de dados on-chain/off-chain e streaming para vários serviços de indexação.

front-end

Para criar uma experiência descentralizada de ponta a ponta, a dYdX está construindo três front-ends de código aberto: um aplicativo da web, um aplicativo iOS e um aplicativo Android.

• Aplicação Web: O site será construído usando Java e React. O site irá interagir com o Indexador via API para obter informações do livro de pedidos fora da cadeia e enviar negociações diretamente na cadeia. A dYdX abrirá o código-fonte da base de código front-end e os scripts de implantação relacionados. Isso permitirá que qualquer pessoa implante e acesse facilmente o front-end dYdX de/para seu próprio domínio/solução hospedada por meio de um gateway IPFS/Cloudflare.
• Mobile: aplicativos iOS e Android são construídos usando Swift e Kotlin nativos, respectivamente. O aplicativo móvel irá interagir com o indexador da mesma forma que o aplicativo web e enviar transações diretamente para a cadeia. O aplicativo móvel também será de código aberto, permitindo que qualquer pessoa implante o aplicativo móvel na App Store ou na Play Store. Especificamente para lojas de aplicativos, os implantadores precisam ter uma conta de desenvolvedor e uma conta Bitrise para concluir o processo de envio do aplicativo.

Ciclo de vida do pedido

Agora que temos uma melhor compreensão de cada componente do dYdX v4, vamos dar uma olhada em como tudo se encaixa ao fazer um pedido. Ao fazer um pedido na v4, seguirá o seguinte processo:

1. Os usuários realizam transações em um front-end descentralizado (por exemplo, um site) ou por meio de uma API
2. A encomenda é encaminhada para o validador. Esse validador fofoca sobre a transação para outros validadores e nós completos para atualizar seus livros de pedidos com o novo pedido.
3. O processo de consenso seleciona um validador como o proponente. Os validadores selecionados correspondem ao pedido e o adicionam ao próximo bloco proposto.
4. O bloco proposto continua através do processo de consenso. a. Se ⅔ dos validadores votarem para confirmar o bloco, o bloco será confirmado e salvo no banco de dados on-chain de todos os validadores e nós completos. b. Se o bloco proposto não conseguir atingir o limite de ⅔, o bloco será rejeitado.
5. Depois que um bloco é confirmado, os dados atualizados na cadeia (e fora da cadeia) são transmitidos de nós completos para indexadores. O indexador fornece esses dados via API e Websockets para o front-end e/ou qualquer outro serviço externo que consulte esses dados.

O fluxo acima é uma visão geral de alto nível de como os pedidos/dados passam pela v4. À medida que o lançamento da rede principal v4 se aproxima, nos aprofundaremos mais no protocolo, nos indexadores e em várias infraestruturas de front-end nas postagens subsequentes do blog.