Describa brevemente la arquitectura técnica de dYdX V4

dYdX V4 será una cadena de bloques L1 independiente con un libro de pedidos fuera de la cadena completamente descentralizado y un motor de correspondencia.

**Escrito por:**dYdX

Compilar: IBCL

dYdX Chain V4 es la última versión del protocolo dYdX, que consistirá en un software de código abierto. La versión actualmente en producción se llama v3, v3 y las versiones anteriores de dYdX tienen en su núcleo contratos inteligentes implementados en cadenas existentes combinados con servicios centralizados alojados en la nube.

v4 será una cadena de bloques L1 independiente con un libro de pedidos fuera de la cadena totalmente descentralizado y un motor de coincidencia. La cadena dYdX se basará en Cosmos SDK y el protocolo de consenso CometBFT PoS.

A medida que nos acercamos al lanzamiento de la red principal v4, queríamos darles una idea de lo que está construyendo el equipo de dYdX. Este artículo proporciona una descripción general de alto nivel de la arquitectura v4. Dado que v4 aún está en desarrollo, puede haber cambios.

arquitectura del sistema v4

dYdX v4 está diseñado para ser completamente descentralizado de extremo a extremo. Los componentes principales incluyen ampliamente protocolos, indexadores y frontends. Cada uno de estos componentes se proporcionará como software de código abierto. dYdX Trading Inc. no ejecutará ningún componente.

Acuerdo

El protocolo es una cadena de bloques L1 basada en CometBFT y que utiliza CosmosSDK. El software del nodo está escrito en Go y compilado en un solo binario. Como todas las cadenas de bloques de CosmosSDK, v4 utiliza un mecanismo de consenso de prueba de participación.

El protocolo estará soportado por una red de nodos. Hay dos tipos de nodos:

  • Validadores: los validadores son responsables de almacenar pedidos en un libro de pedidos en memoria (es decir, fuera de la cadena y sin comprometerse con el consenso), cotillear transacciones con otros validadores y generar nuevos bloques para la cadena dYdX a través del proceso de consenso. El proceso de consenso hará que los validadores se turnen como proponentes de nuevos bloques en forma de turno rotativo ponderado (ponderado por la cantidad de tokens apostados en sus nodos). Los proponentes son responsables de proponer el contenido del siguiente bloque. Cuando se empareja un pedido, los proponentes lo agregan a su bloque propuesto y comienzan una ronda de consenso. Un bloque se considera comprometido y agregado a la cadena de bloques si ⅔ o más validadores (por peso de participación) lo aprueban. Los usuarios enviarán transacciones directamente a los validadores.
  • Nodo completo: un nodo completo representa un proceso que ejecuta una aplicación v4 que no participa en el consenso. Es un nodo con un peso de participación de 0, que no presenta propuestas ni las vota. Sin embargo, los nodos completos se conectan a la red de validadores, participan en el chisme de las transacciones y procesan cada bloque recién enviado. Los nodos completos tienen una vista completa de la cadena dYdX y su historial y están diseñados para admitir indexadores. Algunas partes pueden decidir (por motivos de rendimiento o costo) ejecutar sus propios nodos y/o indexadores completos.

indexador

Indexer es una colección de servicios de solo lectura cuyo propósito es indexar y servir datos de blockchain para los usuarios de una manera más eficiente y compatible con web2. Esto se hace mediante el uso de datos en tiempo real de nodos completos v4, almacenándolos en una base de datos y poniendo esos datos a disposición de los usuarios finales a través de websocket y solicitudes REST.

Si bien el protocolo v4 en sí es capaz de exponer puntos finales a consultas de servicio sobre algunos datos básicos en cadena, estas consultas tienden a ser lentas porque los validadores y los nodos completos no están optimizados para manejarlos de manera eficiente. Además, las consultas excesivas a los validadores pueden afectar su capacidad para participar en el consenso. Por esta razón, muchos validadores de Cosmos prefieren deshabilitar estas API en producción. Por eso es importante crear y mantener indexadores y nodos completos separados de los validadores.

Los indexadores utilizarán la base de datos de Postgres para el almacenamiento de datos en la cadena, Redis para el almacenamiento de datos fuera de la cadena y Kafka para el consumo de datos dentro y fuera de la cadena y la transmisión a varios servicios de indexación.

Interfaz

Para crear una experiencia descentralizada de extremo a extremo, dYdX está creando tres interfaces de código abierto: una aplicación web, una aplicación para iOS y una aplicación para Android.

  • Aplicación web: el sitio web se construirá utilizando Java y React. El sitio web interactuará con Indexer a través de la API para obtener información del libro de pedidos fuera de la cadena y enviar operaciones directamente en la cadena. dYdX abrirá el código base del front-end y los scripts de implementación relacionados. Esto permitirá que cualquier persona implemente y acceda fácilmente a la interfaz de dYdX hacia/desde su propio dominio/solución alojada a través de una puerta de enlace IPFS/Cloudflare.
  • Móvil: las aplicaciones de iOS y Android se crean con Swift y Kotlin nativos, respectivamente. La aplicación móvil interactuará con el indexador de la misma manera que la aplicación web y enviará transacciones directamente a la cadena. La aplicación móvil también será de código abierto, lo que permitirá que cualquiera pueda implementar la aplicación móvil en App Store o Play Store. Específicamente para las tiendas de aplicaciones, los implementadores deben tener una cuenta de desarrollador y una cuenta de Bitrise para completar el proceso de envío de la aplicación.

Ciclo de vida del pedido

Ahora que tenemos una mejor comprensión de cada componente del dYdX v4, echemos un vistazo a cómo encaja todo al realizar un pedido. Al realizar un pedido en v4, seguirá el siguiente proceso:

  1. Los usuarios realizan transacciones en un front-end descentralizado (por ejemplo, un sitio web) o a través de una API
  2. El pedido se enruta al validador. Ese validador chismea sobre la transacción a otros validadores y nodos completos para actualizar sus libros de pedidos con el nuevo pedido.
  3. El proceso de consenso selecciona un validador como proponente. Los validadores seleccionados coinciden con el pedido y lo agregan al siguiente bloque propuesto.
  4. El bloque propuesto continúa a través del proceso de consenso. a. Si ⅔ de los validadores votan para confirmar el bloque, el bloque se confirmará y guardará en la base de datos en cadena de todos los validadores y nodos completos. b) Si el bloque propuesto no logra alcanzar el umbral de ⅔, el bloque será rechazado.
  5. Después de confirmar un bloque, los datos actualizados en la cadena (y fuera de la cadena) se transmiten desde los nodos completos a los indexadores. Luego, el indexador proporciona estos datos a través de API y Websockets al front-end y/o cualquier otro servicio externo que consulte estos datos.

El flujo anterior es una descripción general de alto nivel de cómo se mueven los pedidos/datos a través de v4. A medida que se acerque el lanzamiento de la red principal v4, profundizaremos en el protocolo, los indexadores y varias infraestructuras front-end en publicaciones de blog posteriores.

Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
  • Recompensa
  • Comentar
  • Compartir
Comentar
0/400
Sin comentarios
  • Anclado
Comercie con criptomonedas en cualquier lugar y en cualquier momento
qrCode
Escanee para descargar la aplicación Gate.io
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • ไทย
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)