El equilibrio entre la velocidad de transacción de Solana y la creación de valor
Solana es conocida por su rápida velocidad de transacción y gran volumen de transacciones, pero ¿significa esto que ha alcanzado la perfección? Cuando examinamos de cerca estas transacciones, surge una pregunta clave: ¿todas estas transacciones están creando valor real?
De hecho, una gran cantidad de transacciones en Solana no provienen de una demanda real de transacciones. Una parte considerable proviene de los arbitrajistas de alta frecuencia, que aprovechan las diferencias de información en milisegundos para obtener ganancias. Estos llamados "traders tóxicos" utilizan ventajas tecnológicas para priorizar sus transacciones aumentando las tarifas de Gas justo cuando los creadores de mercado están a punto de cancelar sus órdenes, lo que les permite completar el arbitraje y provoca pérdidas en los creadores de mercado. Para compensar estas pérdidas, los creadores de mercado se ven obligados a ampliar el diferencial de compra-venta, y finalmente, estos costos adicionales son asumidos por los usuarios comunes.
Solana siempre ha tenido la visión de implementar un libro de órdenes en la cadena, reemplazando los intercambios centralizados. Sin embargo, la existencia de "traders tóxicos" se ha convertido en el principal obstáculo para lograr este objetivo. Este es el nuevo desafío que enfrenta Solana actualmente: el volumen de transacciones no es igual a la liquidez. Un mercado realmente saludable no necesita más transacciones, sino transacciones de mayor calidad.
¿Cómo eliminar las transacciones tóxicas y proteger mejor la liquidez?
En el sistema actual, debido a que el mecanismo de consenso de Solana utiliza subastas periódicas, los que comen órdenes tienen en realidad prioridad, lo que lleva a comportamientos maliciosos de MEV (valor extraíble por mineros) que afectan la equidad del mercado.
En concreto, en el mecanismo de consenso de Solana, las transacciones dentro de cada intervalo de tiempo (Slot) se ordenan según la tarifa de Gas prioritaria pagada, siendo las transacciones con la oferta más alta las que se ejecutan primero. Este mecanismo de subasta se lleva a cabo cada 400 milisegundos. En este proceso, los creadores de mercado necesitan ajustar frecuentemente sus ofertas, incluyendo la cancelación de órdenes y la reubicación de nuevas órdenes, para adaptarse a los cambios en el precio del mercado.
Los que operan en solitario, especialmente los arbitrajistas de alta frecuencia, monitorean constantemente las diferencias de precios y, al detectar una oportunidad, realizan la transacción de inmediato. Pueden asegurarse de completar la transacción pagando tarifas más altas antes de que el creador de mercado retire su orden, lo que hace que los creadores de mercado sufran pérdidas con frecuencia.
Para un intercambio descentralizado (DEX) con libro de órdenes, el orden de ejecución ideal de las operaciones debería ser: a medida que fluctúa el precio, primero ejecutar todas las operaciones de cancelación, luego las nuevas órdenes y, por último, las transacciones. Sin embargo, el mecanismo de consenso actual de Solana no puede lograr esto a nivel microscópico.
El mismo problema también existe en el nivel de cotización de los oráculos. En un escenario ideal, los precios de los oráculos deberían actualizarse primero y luego ejecutarse las transacciones que dependen de esos precios. Sin embargo, en el intervalo actual de 400 milisegundos, el mercado puede experimentar fluctuaciones bruscas que resultan en transacciones que se ejecutan al precio original.
Para los protocolos de préstamos, el mejor orden de operación debe ser primero aportar margen y luego proceder a la liquidación.
Por lo tanto, Solana necesita un mecanismo que permita a diferentes protocolos ordenar las transacciones según sus propias necesidades. Este es el concepto de Ejecución Controlada por la Aplicación (Application-Controlled Execution, ACE) que Solana ha enfatizado continuamente.
Para abordar estos problemas, Solana propuso la solución BAM (mercado de ensamblaje de bloques).
BAM: La nueva respuesta de Solana
BAM ha construido una capa de orden entre la capa de aplicación y la red principal de Solana, que también se puede llamar capa de preprocesamiento. Utiliza entornos de ejecución confiables (TEEs) para construir un espacio de privacidad, en el que las transacciones se ordenan según reglas predefinidas o el principio de primero en entrar, primero en salir (FIFO).
Esta innovación tiene como objetivo servir mejor a protocolos como el libro de órdenes, los intercambios de contratos perpetuos y las piscinas oscuras.
Comparación entre el procesamiento de transacciones tradicional de Solana y el modo BAM
Para entender mejor cómo BAM construye una capa de orden entre las aplicaciones de Solana y la red principal, podemos comparar el flujo de transacciones tradicional de Solana con el flujo posterior a la adopción de BAM:
Flujo de transacciones tradicionales de Solana:
El usuario confirma la transacción en la billetera
Transacción enviada al nodo RPC
RPC envía la transacción al nodo líder de la red principal de Solana en el período actual.
El líder recoge las transacciones del pool de transacciones, las ordena, las agrupa en bloques y las transmite.
Otros nodos votan
Proceso de transacción después de adoptar BAM:
El usuario confirma la transacción en la cartera.
Transacción enviada al nodo RPC
Reenviar la transacción a la red BAM y ordenarla en un entorno TEE. Durante este proceso, los nodos pueden agregar transacciones adicionales a través de complementos (como la actualización de precios de oráculos) y luego generar pruebas.
Paquete de datos de transacción enviado al nodo líder de la red principal de Solana
El líder incluye paquetes de datos BAM al recopilar transacciones, los empaqueta en bloques y los difunde.
Otros nodos votan
Es importante señalar que BAM no entra en conflicto con el proceso de consenso de la red principal de Solana, sino que actúa como una función opcional. BAM no opera directamente en la red principal de Solana, sino que completa la ordenación de transacciones "fuera de la cadena" de manera anticipada, empaquetando las transacciones antes de enviarlas a la red principal de Solana.
El modo de ordenación de transacciones de BAM
BAM admite tres modos de ejecución:
Modo predeterminado de Solana
Modo Block-Engine: La solución MEV actual de Jito, cuyo núcleo es el mecanismo de puja.
Modo BAM: los validadores ordenan estrictamente según el principio de primero en entrar, primero en salir (FIFO)
Las características clave del modo BAM incluyen:
Entornos de ejecución confiables (TEEs): Utilizar TEEs para construir un entorno de privacidad que ordene las transacciones, asegurando la equidad.
Sistema de plugins: A través del sistema de plugins, BAM permite a las aplicaciones construir una lógica de ordenamiento de transacciones personalizada. Este ordenamiento personalizado se basa en reglas preestablecidas, en lugar de un ordenamiento arbitrario por parte de los nodos. Se planea que el sistema de plugins implemente un ordenamiento de transacciones complejo, mientras mantiene las garantías de seguridad del entorno TEE. Actualmente, este sistema aún se encuentra en una etapa temprana de desarrollo.
Aplicaciones prácticas de BAM
Las aplicaciones prácticas de BAM incluyen:
Protección de liquidación de préstamos: para el protocolo de préstamos, después de detectar un riesgo de liquidación, se prioriza la operación de suministro de colateral adicional, antes de realizar la verificación de liquidación.
Combinación de transacciones a nivel atómico: Para DEX, primero se actualiza el precio del oráculo y luego se ejecutan las transacciones que dependen de ese precio. Para los DEX de contratos, también se pueden liquidar los derivados relacionados dentro de la misma ventana de tiempo.
Protección contra la volatilidad de precios: Para los DEX, detectar órdenes grandes anormales, descomponerlas en transacciones pequeñas y ejecutarlas en lotes, dando al mercado suficiente tiempo para reaccionar y evitar que una liquidación en cadena o arbitraje cause un espiral de muerte.
Protección de creadores de mercado: en caso de eventos imprevistos, es capaz de completar la cancelación de órdenes, actualizar los precios del oráculo y volver a colocar órdenes de creadores de mercado en milisegundos, evitando el arbitraje malicioso y reduciendo el diferencial de precios.
Con el despliegue de BAM, se espera que la experiencia de transacción de Solana mejore significativamente, acercando la experiencia de sus aplicaciones en la mainnet a la de un intercambio centralizado.
En general, BAM aporta verificabilidad, protección de la privacidad y programabilidad al proceso de procesamiento de transacciones de Solana. Esto permite a los desarrolladores construir libros de órdenes centralizados, intercambios de contratos perpetuos, dark pools y otras infraestructuras financieras que requieren control de orden, ejecución determinista y protección de la privacidad, impulsando así la innovación y el desarrollo del ecosistema de Solana.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
10 me gusta
Recompensa
10
6
Republicar
Compartir
Comentar
0/400
blockBoy
· 08-12 17:19
Ser engañados no tiene velocidad ni lentitud.
Ver originalesResponder0
shadowy_supercoder
· 08-12 17:19
¿Jugando con palabras? Ser esquilmado se llama innovación.
Ver originalesResponder0
ThreeHornBlasts
· 08-12 17:18
Solo es un tumor de alta velocidad.
Ver originalesResponder0
SchrödingersNode
· 08-12 17:18
Alta frecuencia de trampa de perros, es muy engañoso.
La solución BAM de Solana: equilibrar transacciones rápidas con la creación de valor real
El equilibrio entre la velocidad de transacción de Solana y la creación de valor
Solana es conocida por su rápida velocidad de transacción y gran volumen de transacciones, pero ¿significa esto que ha alcanzado la perfección? Cuando examinamos de cerca estas transacciones, surge una pregunta clave: ¿todas estas transacciones están creando valor real?
De hecho, una gran cantidad de transacciones en Solana no provienen de una demanda real de transacciones. Una parte considerable proviene de los arbitrajistas de alta frecuencia, que aprovechan las diferencias de información en milisegundos para obtener ganancias. Estos llamados "traders tóxicos" utilizan ventajas tecnológicas para priorizar sus transacciones aumentando las tarifas de Gas justo cuando los creadores de mercado están a punto de cancelar sus órdenes, lo que les permite completar el arbitraje y provoca pérdidas en los creadores de mercado. Para compensar estas pérdidas, los creadores de mercado se ven obligados a ampliar el diferencial de compra-venta, y finalmente, estos costos adicionales son asumidos por los usuarios comunes.
Solana siempre ha tenido la visión de implementar un libro de órdenes en la cadena, reemplazando los intercambios centralizados. Sin embargo, la existencia de "traders tóxicos" se ha convertido en el principal obstáculo para lograr este objetivo. Este es el nuevo desafío que enfrenta Solana actualmente: el volumen de transacciones no es igual a la liquidez. Un mercado realmente saludable no necesita más transacciones, sino transacciones de mayor calidad.
¿Cómo eliminar las transacciones tóxicas y proteger mejor la liquidez?
En el sistema actual, debido a que el mecanismo de consenso de Solana utiliza subastas periódicas, los que comen órdenes tienen en realidad prioridad, lo que lleva a comportamientos maliciosos de MEV (valor extraíble por mineros) que afectan la equidad del mercado.
En concreto, en el mecanismo de consenso de Solana, las transacciones dentro de cada intervalo de tiempo (Slot) se ordenan según la tarifa de Gas prioritaria pagada, siendo las transacciones con la oferta más alta las que se ejecutan primero. Este mecanismo de subasta se lleva a cabo cada 400 milisegundos. En este proceso, los creadores de mercado necesitan ajustar frecuentemente sus ofertas, incluyendo la cancelación de órdenes y la reubicación de nuevas órdenes, para adaptarse a los cambios en el precio del mercado.
Los que operan en solitario, especialmente los arbitrajistas de alta frecuencia, monitorean constantemente las diferencias de precios y, al detectar una oportunidad, realizan la transacción de inmediato. Pueden asegurarse de completar la transacción pagando tarifas más altas antes de que el creador de mercado retire su orden, lo que hace que los creadores de mercado sufran pérdidas con frecuencia.
Para un intercambio descentralizado (DEX) con libro de órdenes, el orden de ejecución ideal de las operaciones debería ser: a medida que fluctúa el precio, primero ejecutar todas las operaciones de cancelación, luego las nuevas órdenes y, por último, las transacciones. Sin embargo, el mecanismo de consenso actual de Solana no puede lograr esto a nivel microscópico.
El mismo problema también existe en el nivel de cotización de los oráculos. En un escenario ideal, los precios de los oráculos deberían actualizarse primero y luego ejecutarse las transacciones que dependen de esos precios. Sin embargo, en el intervalo actual de 400 milisegundos, el mercado puede experimentar fluctuaciones bruscas que resultan en transacciones que se ejecutan al precio original.
Para los protocolos de préstamos, el mejor orden de operación debe ser primero aportar margen y luego proceder a la liquidación.
Por lo tanto, Solana necesita un mecanismo que permita a diferentes protocolos ordenar las transacciones según sus propias necesidades. Este es el concepto de Ejecución Controlada por la Aplicación (Application-Controlled Execution, ACE) que Solana ha enfatizado continuamente.
Para abordar estos problemas, Solana propuso la solución BAM (mercado de ensamblaje de bloques).
BAM: La nueva respuesta de Solana
BAM ha construido una capa de orden entre la capa de aplicación y la red principal de Solana, que también se puede llamar capa de preprocesamiento. Utiliza entornos de ejecución confiables (TEEs) para construir un espacio de privacidad, en el que las transacciones se ordenan según reglas predefinidas o el principio de primero en entrar, primero en salir (FIFO).
Esta innovación tiene como objetivo servir mejor a protocolos como el libro de órdenes, los intercambios de contratos perpetuos y las piscinas oscuras.
Comparación entre el procesamiento de transacciones tradicional de Solana y el modo BAM
Para entender mejor cómo BAM construye una capa de orden entre las aplicaciones de Solana y la red principal, podemos comparar el flujo de transacciones tradicional de Solana con el flujo posterior a la adopción de BAM:
Flujo de transacciones tradicionales de Solana:
Proceso de transacción después de adoptar BAM:
Es importante señalar que BAM no entra en conflicto con el proceso de consenso de la red principal de Solana, sino que actúa como una función opcional. BAM no opera directamente en la red principal de Solana, sino que completa la ordenación de transacciones "fuera de la cadena" de manera anticipada, empaquetando las transacciones antes de enviarlas a la red principal de Solana.
El modo de ordenación de transacciones de BAM
BAM admite tres modos de ejecución:
Las características clave del modo BAM incluyen:
Entornos de ejecución confiables (TEEs): Utilizar TEEs para construir un entorno de privacidad que ordene las transacciones, asegurando la equidad.
Sistema de plugins: A través del sistema de plugins, BAM permite a las aplicaciones construir una lógica de ordenamiento de transacciones personalizada. Este ordenamiento personalizado se basa en reglas preestablecidas, en lugar de un ordenamiento arbitrario por parte de los nodos. Se planea que el sistema de plugins implemente un ordenamiento de transacciones complejo, mientras mantiene las garantías de seguridad del entorno TEE. Actualmente, este sistema aún se encuentra en una etapa temprana de desarrollo.
Aplicaciones prácticas de BAM
Las aplicaciones prácticas de BAM incluyen:
Protección de liquidación de préstamos: para el protocolo de préstamos, después de detectar un riesgo de liquidación, se prioriza la operación de suministro de colateral adicional, antes de realizar la verificación de liquidación.
Combinación de transacciones a nivel atómico: Para DEX, primero se actualiza el precio del oráculo y luego se ejecutan las transacciones que dependen de ese precio. Para los DEX de contratos, también se pueden liquidar los derivados relacionados dentro de la misma ventana de tiempo.
Protección contra la volatilidad de precios: Para los DEX, detectar órdenes grandes anormales, descomponerlas en transacciones pequeñas y ejecutarlas en lotes, dando al mercado suficiente tiempo para reaccionar y evitar que una liquidación en cadena o arbitraje cause un espiral de muerte.
Protección de creadores de mercado: en caso de eventos imprevistos, es capaz de completar la cancelación de órdenes, actualizar los precios del oráculo y volver a colocar órdenes de creadores de mercado en milisegundos, evitando el arbitraje malicioso y reduciendo el diferencial de precios.
Con el despliegue de BAM, se espera que la experiencia de transacción de Solana mejore significativamente, acercando la experiencia de sus aplicaciones en la mainnet a la de un intercambio centralizado.
En general, BAM aporta verificabilidad, protección de la privacidad y programabilidad al proceso de procesamiento de transacciones de Solana. Esto permite a los desarrolladores construir libros de órdenes centralizados, intercambios de contratos perpetuos, dark pools y otras infraestructuras financieras que requieren control de orden, ejecución determinista y protección de la privacidad, impulsando así la innovación y el desarrollo del ecosistema de Solana.