¿Cómo puede Solana mejorar para lograr la visión de un Nasdaq on-chain?

Para lograr esto, debemos ofrecer precios mejores que los de Nasdaq y otorgar a la aplicación la capacidad de cancelar operaciones con prioridad antes de la ejecución.

**Escrito por: **Max Resnick (Anza) & Anatoly Yakovenko (Solana Labs)

Compilado por: GaryMa Wu dijo Blockchain

Resumen

Solana tiene como objetivo construir una red comercial descentralizada que sea más eficiente que el NASDAQ, pero el diseño de la cadena de bloques existente no cumple con las expectativas, el actual creador de mercado de Solana tiene una baja tasa de ganancias en la carrera de cancelación de órdenes (mucho más baja que el 13% de los intercambios centralizados) y Jito Auctions exacerba el control del acceso estatal por parte de un solo líder, lo que resulta en diferenciales cada vez mayores. En este sentido, se propone reconstruir el mecanismo de consenso e introducir múltiples líderes concurrentes para optimizar el ordenamiento de las órdenes, reducir el costo de selección adversa de los creadores de mercado y mejorar la eficiencia de los precios.

El objetivo inicial de la creación de Solana era construir una blockchain lo suficientemente rápida y económica para poder ejecutar un libro de órdenes centralizado y utilizable. La versión de prueba de la red principal de Solana se lanzó en marzo de 2020 — hoy en día ya han pasado cinco años, y aunque hemos logrado bastante, se ha vuelto cada vez más evidente que aún no hemos alcanzado este objetivo.

La infraestructura blockchain existente no está diseñada para transacciones. Si queremos cumplir con la misión original de Solana, debemos regresar al punto de partida, partir de los principios más básicos y rediseñar completamente el mecanismo de consenso, con el objetivo final de construir una red descentralizada capaz de competir con la Bolsa de Valores de Nueva York.

Lo que decimos sobre competir con la Bolsa de Nueva York se refiere a que los intercambios en Solana necesitan poder ofrecer mejores precios que los intercambios centralizados. En el mundo del mercado, el precio se define a través del "spread": es decir, la diferencia entre el precio más alto que alguien está dispuesto a pagar por un activo y el precio más bajo que alguien está dispuesto a vender ese activo.

Cuanto menor sea la diferencia de precio, mejor será el precio que obtenga el trader, y mayor será la eficiencia del mercado.

La fórmula para la propagación es simple. Los spreads se establecen de tal manera que el beneficio esperado que un creador de mercado recibirá al operar con un operador sin información es igual a la pérdida esperada en la que incurriría al operar con un operador de información. Cuando los creadores de mercado tienen más información que sus contrapartes, ganan dinero; Cuando hay menos información que la contraparte, pierden dinero. Los creadores de mercado suelen ganar un poco de dinero en cada operación con inversores minoristas, pero pierden mucho si se cubren en la dirección opuesta cuando el precio salta violentamente (esperemos que con poca frecuencia). Este es el origen de la frase "el creador de mercado levanta la puerta y pierde la sandía".

¿Qué determina el costo de la selección adversa?

Para comprender mejor la selección adversa, debemos comprender a qué están jugando los creadores de mercado de juegos. Los creadores de mercado toman decisiones basadas en un "precio justo" que cambia aleatoriamente con el tiempo. Cuando el precio justo está dentro del diferencial entre la oferta y la demanda, la cotización del creador de mercado es segura porque la contraparte no puede obtener ganancias comiendo la cotización. Pero tan pronto como el precio justo supera el diferencial entre la oferta y la demanda, comienza una carrera: el creador de mercado intenta cancelar la orden lo más rápido posible y el tomador intenta agarrar la orden obsoleta antes de que el creador de mercado la cancele. La expectativa de un tomador exitoso es la diferencia entre el precio justo y la oferta obsoleta. La clave para reducir la fricción de la selección adversa es permitir que los creadores de mercado ganen la carrera tanto como sea posible.

Los datos de un intercambio centralizado indican que, después de un salto en el precio, los creadores de mercado solo tienen un 13% de probabilidad de cancelar órdenes de manera anticipada.

Los creadores de mercado en los exchanges centralizados tienen menos probabilidades de ganar en la carrera de cancelación, pero aún más en Solana. El mecanismo de subasta de Jito, que es un efecto secundario de un solo proponente que controla el acceso estatal durante un período prolongado de tiempo, hace que sea casi imposible para los creadores de mercado ganar la carrera de la cancelación. Incluso si el creador de mercado es más rápido, la verdadera decisión es quién puja más alto en la subasta de Jito. Esto pone a los creadores de mercado en un dilema: pueden pagar mucho dinero para cancelar sus órdenes o dejar que otra persona pague un alto precio para dispararles. De cualquier manera, estaban perdiendo dinero y, como resultado, tuvieron que ampliar el margen.

En la práctica, la actual microestructura del mercado en la cadena ofrece a los tomadores la ventaja de ser los primeros en actuar en términos de selección adversa. Para resolver este problema, necesitamos darle a la aplicación más flexibilidad para ordenar transacciones. Si queremos reducir el spread, la aplicación debe ser capaz de dar a los creadores de mercado una ventaja en la carrera de cancelación de órdenes. Una forma de hacerlo es introducir una estrategia de clasificación de "cancelar primero, rellenar después". Observamos los bloques y procesamos todas las cancelaciones antes de procesar todas las tomas.

Podemos implementar esta estrategia de inmediato en Solana, simplemente cambiando el orden de reproducción actual de un patrón decidido por un líder a priorizar el procesamiento de transacciones canceladas. Pero esto no resuelve el problema por completo. Si todavía está controlado por un solo líder, él aún puede elegir ignorar las transacciones canceladas, entonces volveríamos al punto de partida: los creadores de mercado seguirían en desventaja en la carrera de cancelación.

La única manera de resolver este problema es introducir múltiples líderes concurrentes. De esta manera, si un líder bloquea una transacción, puedes optar por enviarla a otro líder.

Implementación — Orden de transacciones

La pregunta más importante sobre los múltiples líderes paralelos es: ¿Cómo fusionamos sus respectivos bloques de transacciones cuando hay un conflicto? La respuesta es simple: dividimos las tarifas en dos categorías: tarifas de inclusión y tarifas de pedido. La tarifa de inclusión se paga al validador que contiene la transacción, y la tarifa de clasificación se paga al protocolo (burn). Cuando queremos fusionar los bloques de cada líder, simplemente tomamos la unión de todas las transacciones de todos los bloques en una ranura y los ordenamos de acuerdo con sus tarifas de clasificación.

Esta única medida no es suficiente. Lo que realmente queremos lograr es permitir que la aplicación controle de manera más flexible el orden de las transacciones. Agreguemos un elemento más: la llamada al sistema get\_transaction\_metadata, que permite a los programas leer las tarifas de orden de las transacciones con las que interactúan, proporcionando así a la aplicación una poderosa herramienta de control del orden.

Implementación — Mecanismo de consenso

Nuestros objetivos de diseño del mecanismo de consenso incluyen:

  1. Vínculo y Ceguera (Binding & Blinding): Los líderes paralelos no pueden incluir información de otros bloques de líderes en su propio bloque (como la interceptación de transacciones privadas), ni pueden cancelar su propio bloque en función del contenido de otros bloques de líderes (por ejemplo, cancelar su oferta después de ver otras ofertas).

  2. Equidad de reloj (Wallclock Fairness): Los líderes paralelos deben presentar bloques en un tiempo real aproximadamente igual.

A continuación se presenta un resumen de las soluciones más efectivas que hemos desarrollado en colaboración con Pranav Garimidi y Joachim Neu de a16z Research:

  1. Cada líder convertirá su bloque en fragmentos de código de borrado (shreds). Una vez que se hayan recuperado suficientes fragmentos (por encima de la tasa de codificación), se podrá recuperar el bloque. No es posible una recuperación parcial.

  2. Los líderes envían fragmentos a los nodos de retransmisión de la primera capa del árbol Turbine. Cada líder envía su primer fragmento al retransmisor 1, el segundo fragmento al retransmisor 2, y así sucesivamente. Si todo va bien, cada retransmisor recibirá fragmentos de todos los líderes.

  3. Después del tiempo de espera, el relé envía un mensaje IHAVE firmado al único líder de consenso, informándole de los fragmentos recibidos.

  4. El líder de consenso luego construye un bloque que contiene estos mensajes IHAVE; si no se incluyen suficientes mensajes IHAVE, el bloque será inválido.

  5. Los líderes de consenso difunden el bloque a los validadores, quienes comienzan a alcanzar consenso sobre este bloque.

Este esquema satisface las propiedades de enlace y cegamiento con una alta probabilidad y tiene una buena equidad de reloj, aunque puede haber mejores esquemas en el futuro.

Conclusión

Solana se creó con el objetivo de superar al NASDAQ. Para ello, tenemos que ofrecer un mejor precio que el NASDAQ. Para ello, debemos darle a la app la posibilidad de priorizar las cancelaciones antes de cerrar. Para potenciar la aplicación de esta habilidad, debemos evitar que los líderes revisen unilateralmente las órdenes. Y para hacer eso, tenemos que traer a varios líderes en paralelo.

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
Opere con criptomonedas en cualquier momento y lugar
qrCode
Escanee para descargar la aplicación Gate
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)