¿Es realmente suficiente la velocidad y el volumen de transacciones de Solana?
Solana es conocida por su alta velocidad de transacciones y gran volumen de operaciones, pero ¿eso significa que ha alcanzado la perfección? Al analizar estas transacciones en profundidad, surge una pregunta clave: ¿todas estas transacciones están creando valor real?
De hecho, gran parte de las transacciones en Solana no provienen de una demanda de transacciones real. Una parte considerable proviene de 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 al aumentar las tarifas de Gas justo cuando los creadores de mercado están a punto de cancelar sus órdenes, lo que les permite realizar arbitrajes y causando pérdidas a los creadores de mercado. Para compensar estas pérdidas, los creadores de mercado se ven obligados a ampliar el diferencial de compra-venta, y al final, 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 y reemplazar los intercambios centralizados. Sin embargo, la existencia de "comerciantes tóxicos" se ha convertido en un obstáculo para lograr este sueño. Esto revela un nuevo desafío que enfrenta Solana: el volumen de transacciones no es equivalente a la liquidez. Un mercado verdaderamente saludable no necesita más transacciones, sino transacciones de mayor calidad.
¿Cómo eliminar 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 ejecutan órdenes tienen en realidad prioridad, lo que permite que el comportamiento malicioso de MEV (valor máximo extraíble) afecte la equidad del mercado.
Específicamente, en el mecanismo de consenso de Solana, las transacciones se ordenan según el costo de Gas prioritario pagado en intervalos de tiempo de 400 milisegundos (Slot), ejecutándose primero las transacciones con las ofertas más altas. Con este mecanismo, los creadores de mercado necesitan ajustar sus cotizaciones con frecuencia, retirando y volviendo a colocar órdenes para adaptarse a los cambios en el precio del mercado.
Los arbitrajistas de alta frecuencia monitorean las diferencias de precios y realizan la transacción de inmediato tan pronto como detectan una oportunidad. Pueden asegurarse de que sus transacciones se ejecuten antes de que los creadores de mercado cancelen sus órdenes pagando tarifas más altas, lo que lleva a los creadores de mercado a sufrir pérdidas con frecuencia.
Para un intercambio descentralizado (DEX) basado en libro de órdenes, el orden de operaciones ideal debería ser: a medida que fluctúa el precio, primero ejecutar todas las operaciones de cancelación, luego las nuevas órdenes de venta, y finalmente las transacciones. Sin embargo, el mecanismo de consenso actual de Solana no puede lograr esto a nivel micro.
Igualmente, en cuanto a la cotización de los oráculos, la situación ideal es actualizar primero el precio del oráculo y luego ejecutar las transacciones que dependen de ese precio. Sin embargo, en el intervalo actual de 400 milisegundos, el mercado puede experimentar fluctuaciones drásticas que provocan que las transacciones se ejecuten aún al precio original.
Para los protocolos de préstamo, la mejor práctica es primero aportar más garantía y luego proceder con la liquidación.
Por lo tanto, una solución ideal debería permitir que diferentes protocolos ordenen las transacciones según sus propias necesidades, que es el concepto de Ejecución Controlada por Aplicaciones (Application-Controlled Execution, ACE) que Solana ha enfatizado.
Para hacer frente a estos desafíos, Solana propuso la solución BAM (Mercado de Ensamblaje de Bloques).
Mercado de ensamblaje de bloques: la nueva respuesta de Solana
BAM construyó una capa de ordenación, también conocida como capa de preprocesamiento, entre la capa de aplicación de Solana y la red principal. Utiliza entornos de ejecución confiables (TEEs) para construir un sandbox de privacidad, donde 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 los protocolos como los libros de órdenes, los intercambios de contratos perpetuos y las dark pools.
¿Cómo BAM cambia el proceso de transacciones de Solana?
En el proceso de transacción tradicional de Solana, después de que el usuario confirma la transacción, esta se envía al nodo líder del Slot actual a través de un nodo RPC. El líder recopila las transacciones del pool de transacciones, las ordena y las empaqueta en un bloque para su difusión, y finalmente, otros nodos votan para confirmar.
Y en las aplicaciones que integran BAM, el proceso de transacción es ligeramente diferente:
El usuario confirma la transacción
Transacción enviada al nodo RPC
Transacción ingresada a la red BAM, clasificada en un entorno TEE.
El paquete de transacciones ordenado se envía al nodo líder de la red principal de Solana.
Leader incluirá el paquete de datos BAM en el bloque y lo transmitirá.
Otras nodos realizan la votación de confirmación
Es importante destacar 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. Completa la ordenación de transacciones "fuera de la cadena" de antemano y luego envía el paquete de transacciones ordenadas a la red principal de Solana.
Modo de operación de BAM
BAM admite tres modos de funcionamiento:
Modo predeterminado de Solana
Modo Block-Engine (actualmente la solución MEV de Jito, el núcleo es el mecanismo de subasta)
Modo BAM (los validadores se ordenan estrictamente por FIFO)
Las características clave del modo BAM incluyen:
Utilizar entornos de ejecución confiables (TEEs) para construir un entorno de privacidad, asegurando la equidad en el orden de las transacciones.
Permitir a las aplicaciones construir lógica de ordenamiento de transacciones personalizada a través del sistema de complementos, logrando requisitos de ordenamiento complejos.
Aplicaciones prácticas de BAM
Las aplicaciones de BAM son amplias, a continuación se presentan algunos ejemplos específicos:
Protección de liquidación de préstamos: ejecutar primero la operación de colateral adicional, luego realizar la verificación de liquidación.
Combinación de transacciones a nivel atómico: primero actualiza el precio del oracle, luego ejecuta las transacciones que dependen de ese precio, y para el DEX de contratos, también se pueden liquidar simultáneamente los derivados relacionados.
Protección contra la volatilidad de precios: Detectar órdenes grandes anormales y dividirlas en transacciones pequeñas para ejecutarlas por partes, dando tiempo de reacción al mercado.
Protección de creadores de mercado: en caso de eventos imprevistos, se permite la cancelación de órdenes, actualización de precios de oráculos y re-listado en milisegundos, evitando arbitraje malicioso.
El despliegue de BAM mejorará significativamente la experiencia de transacción de Solana, acercando la experiencia de las aplicaciones de su red principal a la de los intercambios centralizados.
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 preciso, ejecución determinista y salvaguardias de 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.
9 me gusta
Recompensa
9
4
Compartir
Comentar
0/400
HappyToBeDumped
· hace8h
sol mis tontos tomar a la gente por tonta
Ver originalesResponder0
SingleForYears
· hace8h
¿Los usuarios comunes asumen el costo? Ser engañados.
Ver originalesResponder0
ruggedNotShrugged
· hace8h
Lávate y a dormir, sol tomar a la gente por tonta se ha hecho.
Solana lanza la solución BAM para mejorar la calidad y la equidad de las transacciones
¿Es realmente suficiente la velocidad y el volumen de transacciones de Solana?
Solana es conocida por su alta velocidad de transacciones y gran volumen de operaciones, pero ¿eso significa que ha alcanzado la perfección? Al analizar estas transacciones en profundidad, surge una pregunta clave: ¿todas estas transacciones están creando valor real?
De hecho, gran parte de las transacciones en Solana no provienen de una demanda de transacciones real. Una parte considerable proviene de 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 al aumentar las tarifas de Gas justo cuando los creadores de mercado están a punto de cancelar sus órdenes, lo que les permite realizar arbitrajes y causando pérdidas a los creadores de mercado. Para compensar estas pérdidas, los creadores de mercado se ven obligados a ampliar el diferencial de compra-venta, y al final, 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 y reemplazar los intercambios centralizados. Sin embargo, la existencia de "comerciantes tóxicos" se ha convertido en un obstáculo para lograr este sueño. Esto revela un nuevo desafío que enfrenta Solana: el volumen de transacciones no es equivalente a la liquidez. Un mercado verdaderamente saludable no necesita más transacciones, sino transacciones de mayor calidad.
¿Cómo eliminar 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 ejecutan órdenes tienen en realidad prioridad, lo que permite que el comportamiento malicioso de MEV (valor máximo extraíble) afecte la equidad del mercado.
Específicamente, en el mecanismo de consenso de Solana, las transacciones se ordenan según el costo de Gas prioritario pagado en intervalos de tiempo de 400 milisegundos (Slot), ejecutándose primero las transacciones con las ofertas más altas. Con este mecanismo, los creadores de mercado necesitan ajustar sus cotizaciones con frecuencia, retirando y volviendo a colocar órdenes para adaptarse a los cambios en el precio del mercado.
Los arbitrajistas de alta frecuencia monitorean las diferencias de precios y realizan la transacción de inmediato tan pronto como detectan una oportunidad. Pueden asegurarse de que sus transacciones se ejecuten antes de que los creadores de mercado cancelen sus órdenes pagando tarifas más altas, lo que lleva a los creadores de mercado a sufrir pérdidas con frecuencia.
Para un intercambio descentralizado (DEX) basado en libro de órdenes, el orden de operaciones ideal debería ser: a medida que fluctúa el precio, primero ejecutar todas las operaciones de cancelación, luego las nuevas órdenes de venta, y finalmente las transacciones. Sin embargo, el mecanismo de consenso actual de Solana no puede lograr esto a nivel micro.
Igualmente, en cuanto a la cotización de los oráculos, la situación ideal es actualizar primero el precio del oráculo y luego ejecutar las transacciones que dependen de ese precio. Sin embargo, en el intervalo actual de 400 milisegundos, el mercado puede experimentar fluctuaciones drásticas que provocan que las transacciones se ejecuten aún al precio original.
Para los protocolos de préstamo, la mejor práctica es primero aportar más garantía y luego proceder con la liquidación.
Por lo tanto, una solución ideal debería permitir que diferentes protocolos ordenen las transacciones según sus propias necesidades, que es el concepto de Ejecución Controlada por Aplicaciones (Application-Controlled Execution, ACE) que Solana ha enfatizado.
Para hacer frente a estos desafíos, Solana propuso la solución BAM (Mercado de Ensamblaje de Bloques).
Mercado de ensamblaje de bloques: la nueva respuesta de Solana
BAM construyó una capa de ordenación, también conocida como capa de preprocesamiento, entre la capa de aplicación de Solana y la red principal. Utiliza entornos de ejecución confiables (TEEs) para construir un sandbox de privacidad, donde 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 los protocolos como los libros de órdenes, los intercambios de contratos perpetuos y las dark pools.
¿Cómo BAM cambia el proceso de transacciones de Solana?
En el proceso de transacción tradicional de Solana, después de que el usuario confirma la transacción, esta se envía al nodo líder del Slot actual a través de un nodo RPC. El líder recopila las transacciones del pool de transacciones, las ordena y las empaqueta en un bloque para su difusión, y finalmente, otros nodos votan para confirmar.
Y en las aplicaciones que integran BAM, el proceso de transacción es ligeramente diferente:
Es importante destacar 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. Completa la ordenación de transacciones "fuera de la cadena" de antemano y luego envía el paquete de transacciones ordenadas a la red principal de Solana.
Modo de operación de BAM
BAM admite tres modos de funcionamiento:
Las características clave del modo BAM incluyen:
Aplicaciones prácticas de BAM
Las aplicaciones de BAM son amplias, a continuación se presentan algunos ejemplos específicos:
El despliegue de BAM mejorará significativamente la experiencia de transacción de Solana, acercando la experiencia de las aplicaciones de su red principal a la de los intercambios centralizados.
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 preciso, ejecución determinista y salvaguardias de privacidad, impulsando así la innovación y el desarrollo del ecosistema de Solana.