Solana ya es lo suficientemente rápida, el volumen es lo suficientemente grande. ¿Entonces, realmente es "suficiente"?
Cuando examinamos esas transacciones, hay una pregunta que persiste: ¿realmente todas estas transacciones están creando valor?
El gran volumen de transacciones de Solana no proviene de la demanda real de transacciones, sino de los arbitrajistas de alta frecuencia que aprovechan las diferencias de información en milisegundos para obtener ganancias. Estos "comerciantes tóxicos" (Toxic-takers) utilizan ventajas tecnológicas para aumentar el Gas justo cuando el creador de mercado (Maker) está a punto de retirar su orden, haciendo que su transacción sea empaquetada primero, completando así el arbitraje y causando pérdidas al creador de mercado. Para compensar las pérdidas, el creador de mercado solo puede ampliar el diferencial de compra-venta.
Al final, los usuarios comunes son quienes pagan por esto. Solana siempre ha tenido el sueño de implementar un libro de órdenes en la cadena, reemplazando a los CEX. Pero de esta manera, los "traders tóxicos" se convierten en un obstáculo para alcanzar ese sueño. Este es el nuevo desafío que enfrenta Solana: volumen ≠ liquidez. Un mercado realmente saludable no necesita más transacciones, sino mejores transacciones.
¿Cómo se pueden eliminar las transacciones tóxicas para proteger mejor la liquidez?
En el sistema actual, los tomadores (Takers) gozan de una ventaja real debido al mecanismo de subasta cíclica de consenso de Solana, lo que afecta la equidad del mercado debido a la influencia maliciosa de MEV.
¿Cómo entender?
En el consenso actual de Solana, dentro de cada período de tiempo Slot, las transacciones se ordenan según la tarifa de Gas prioritaria pagada; quien ofrezca más, su transacción se ejecutará primero. Esta subasta es periódica, cada 400 milisegundos un Slot.
En este proceso, los creadores de mercado necesitan ajustar frecuentemente las cotizaciones, cancelar órdenes y volver a colocar órdenes. Es necesario actualizar inmediatamente cuando el precio del mercado cambia.
Los que toman la oferta (Taker), especialmente los arbitrajistas de alta frecuencia, monitorean las diferencias de precios y ejecutan la operación tan pronto como encuentran una oportunidad. Por lo tanto, los arbitrajistas pueden pagar tarifas más altas para ejecutar antes de que se retire la oferta. Esto lleva a que los creadores de mercado a menudo sean "atacados", asumiendo pérdidas.
Para un libro de órdenes DEX, el orden ideal debería ser que, con la fluctuación de precios, primero se ejecuten todas las cancelaciones, luego se ejecuten las nuevas órdenes pendientes y, por último, se ejecuten las transacciones. Esto es algo que el consenso de Solana no puede lograr en el nivel microactual.
Y en el nivel de precios de los oráculos es lo mismo, la situación ideal es actualizar primero el precio del oráculo y luego ejecutar las transacciones que dependen de ese precio. Pero en el intervalo actual de 400 milisegundos, el mercado puede experimentar fluctuaciones bruscas, lo que puede llevar a que las transacciones se realicen al precio original.
Para los protocolos de préstamo, lo mejor es aportar garantías primero y luego proceder a la liquidación.
Por lo tanto, es mejor tener una forma que permita a diferentes protocolos ordenar las transacciones según la demanda, es decir, la ejecución controlada por la aplicación (Application-Controlled Execution) que Solana ha estado enfatizando.
BAM (Block Assembly Marketplace, mercado de ensamblaje de bloques) es la respuesta de Solana.
BAM ha construido una capa de ordenación, o capa de preprocesamiento, entre la aplicación en la cadena de Solana y la red principal.
Utilizando Entornos de Ejecución Confiables (Trusted Execution Environments, TEEs) para construir una caja de privacidad, donde se ordenan las transacciones dentro de la caja de acuerdo con reglas de ordenamiento previamente determinadas, o FIFO (primero en entrar, primero en salir).
Mejor servir a los libros de órdenes (CLOBs), intercambios de contratos perpetuos (Perpetual Exchanges) y protocolos de piscinas oscuras (Dark Pools).
Solana generalmente se compara el empaquetado de transacciones con el modo BAM
¿Cómo entender que BAM ha construido una capa de orden entre las aplicaciones de Solana y la red principal? Comencemos con una comparación intuitiva.
Flujo de transacción normal de Solana,
1）El usuario confirma la transacción en la billetera,
2）Transacción enviada al nodo RPC,
3）RPC enviado al nodo líder de la red principal de Solana en el período de Slot actual,
El líder recoge las transacciones del pool de transacciones, las ordena, las empaqueta en bloques y las transmite.
Votación de los nodos restantes.
Si una aplicación integra BAM, el flujo de transacciones es el siguiente,
1）El usuario confirma la transacción en la billetera,
Envío de la transacción al nodo RPC,
Transacciones transferidas a la red BAM, ordenadas en la privacidad TEE. En el proceso, los nodos pueden agregar transacciones adicionales a través de plugins, como la actualización del precio del oráculo, y luego generar pruebas,
4）El paquete de datos de la transacción se envía al nodo líder de la red principal de Solana,
El líder recoge las transacciones, recoge el paquete de datos BAM, lo empaqueta en un bloque y lo transmite.
Voto de los nodos restantes.
Por lo tanto, en realidad BAM no entra en conflicto con el proceso de consenso actual de la red principal de Solana, sino que actúa como una "opción". BAM no se ejecuta directamente en la red principal de Solana, sino que se realiza de manera "fuera de la cadena", completando previamente el ordenamiento de las transacciones, empaquetando las transacciones y luego enviándolas a la red principal de Solana.
BAM modo de ordenación de volumen
BAM admite tres modos de operación,
1）Solana modo predeterminado;
2）Modo Block-Engine; la solución MEV actual de Jito se basa en un mecanismo de pujas.
Modo BAM, los validadores siguen estrictamente el orden FIFO (primero en entrar, primero en salir).
El núcleo del modo BAM tiene los siguientes puntos,
Entornos de Ejecución Confiables TEEs: Privacidad y Equidad Utilizando Entornos de Ejecución Confiables TEEs, construir un entorno de privacidad y ordenar las transacciones. El otro lado de la privacidad se llama equidad.
2）Sistema de plugins Plugin: Ordenamiento complejo A través del sistema de plugins, BAM permite a las aplicaciones construir lógica de ordenamiento de transacciones personalizada. Y este ordenamiento personalizado no significa que los nodos lo hagan como quieran, sino que se ordena según reglas preestablecidas.
El plan del complemento implementa un ordenamiento de transacciones complejo, mientras mantiene las garantías de seguridad del entorno TEE. Actualmente se encuentra en una fase de desarrollo temprano.
Como se mencionó anteriormente,
Para un libro de órdenes DEX, el orden ideal debería ser ejecutar primero todas las cancelaciones, luego las nuevas órdenes y, por último, las transacciones, a medida que fluctúa el precio. Esto es algo que actualmente el consenso de Solana no puede lograr a nivel micro.
Y en el nivel de cotización de los oráculos es igual, la situación ideal es actualizar primero el precio del oráculo y luego ejecutar las transacciones que dependen de ese precio. Pero en el intervalo actual de 400 milisegundos, los precios pueden fluctuar drásticamente, lo que puede resultar en que las transacciones se realicen al precio original.
Para los protocolos de préstamo, es mejor primero aumentar el margen y luego proceder con la liquidación. Esto implementa de hecho la función de control de ejecución de la aplicación ACE.
Entonces, ¿qué logró realmente BAM?
Por ejemplo,
1）Protección de liquidación de préstamos
Para los acuerdos de préstamo, después de detectar el riesgo de liquidación, se debe priorizar la ejecución de operaciones de colateral adicional, y luego proceder con la verificación de liquidación.
Combinación de transacciones a nivel atómico
Para DEX, primero actualiza el precio del oráculo y ejecuta las transacciones que dependen de ese precio. Si es un DEX de contrato, también se pueden liquidar los derivados relacionados. Todas las operaciones anteriores se completan dentro de la misma ventana de tiempo.
Protección contra la volatilidad de precios
Para DEX, detectar grandes órdenes anómalas, dividir grandes órdenes en fragmentos más pequeños, ejecutarlas en lotes, dar tiempo al mercado para reaccionar y evitar espirales mortales causadas por liquidaciones en cadena o arbitrajes.
Protección de creadores de mercado
Ocurre un evento inesperado, se cancela la orden en milisegundos, el oráculo actualiza el precio, el creador de mercado vuelve a colocar la orden. Evitar el arbitraje malicioso, reducir la diferencia de precio.
BAM se iba a lanzar a finales de julio.
Y, con el despliegue de BAM, la experiencia de trading en Solana mejorará significativamente. BAM hará que la experiencia de las aplicaciones en la mainnet de Solana se acerque más a la de un CEX.
En resumen,
BAM aporta verificabilidad, protección de la privacidad y programabilidad al proceso de procesamiento de transacciones de Solana, permitiendo a los desarrolladores construir libros de órdenes centralizados (CLOBs), intercambios de contratos perpetuos (Perpetual Exchanges), piscinas oscuras (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.
Interpretación del mercado de ensamblaje de bloques BAM de Solana: cuando la velocidad ya no es la única búsqueda
Solana ya es lo suficientemente rápida, el volumen es lo suficientemente grande. ¿Entonces, realmente es "suficiente"?
Cuando examinamos esas transacciones, hay una pregunta que persiste: ¿realmente todas estas transacciones están creando valor?
El gran volumen de transacciones de Solana no proviene de la demanda real de transacciones, sino de los arbitrajistas de alta frecuencia que aprovechan las diferencias de información en milisegundos para obtener ganancias. Estos "comerciantes tóxicos" (Toxic-takers) utilizan ventajas tecnológicas para aumentar el Gas justo cuando el creador de mercado (Maker) está a punto de retirar su orden, haciendo que su transacción sea empaquetada primero, completando así el arbitraje y causando pérdidas al creador de mercado. Para compensar las pérdidas, el creador de mercado solo puede ampliar el diferencial de compra-venta.
Al final, los usuarios comunes son quienes pagan por esto. Solana siempre ha tenido el sueño de implementar un libro de órdenes en la cadena, reemplazando a los CEX. Pero de esta manera, los "traders tóxicos" se convierten en un obstáculo para alcanzar ese sueño. Este es el nuevo desafío que enfrenta Solana: volumen ≠ liquidez. Un mercado realmente saludable no necesita más transacciones, sino mejores transacciones.
¿Cómo se pueden eliminar las transacciones tóxicas para proteger mejor la liquidez?
En el sistema actual, los tomadores (Takers) gozan de una ventaja real debido al mecanismo de subasta cíclica de consenso de Solana, lo que afecta la equidad del mercado debido a la influencia maliciosa de MEV.
¿Cómo entender?
En el consenso actual de Solana, dentro de cada período de tiempo Slot, las transacciones se ordenan según la tarifa de Gas prioritaria pagada; quien ofrezca más, su transacción se ejecutará primero. Esta subasta es periódica, cada 400 milisegundos un Slot.
En este proceso, los creadores de mercado necesitan ajustar frecuentemente las cotizaciones, cancelar órdenes y volver a colocar órdenes. Es necesario actualizar inmediatamente cuando el precio del mercado cambia.
Los que toman la oferta (Taker), especialmente los arbitrajistas de alta frecuencia, monitorean las diferencias de precios y ejecutan la operación tan pronto como encuentran una oportunidad. Por lo tanto, los arbitrajistas pueden pagar tarifas más altas para ejecutar antes de que se retire la oferta. Esto lleva a que los creadores de mercado a menudo sean "atacados", asumiendo pérdidas.
Para un libro de órdenes DEX, el orden ideal debería ser que, con la fluctuación de precios, primero se ejecuten todas las cancelaciones, luego se ejecuten las nuevas órdenes pendientes y, por último, se ejecuten las transacciones. Esto es algo que el consenso de Solana no puede lograr en el nivel microactual.
Y en el nivel de precios de los oráculos es lo mismo, la situación ideal es actualizar primero el precio del oráculo y luego ejecutar las transacciones que dependen de ese precio. Pero en el intervalo actual de 400 milisegundos, el mercado puede experimentar fluctuaciones bruscas, lo que puede llevar a que las transacciones se realicen al precio original.
Para los protocolos de préstamo, lo mejor es aportar garantías primero y luego proceder a la liquidación.
Por lo tanto, es mejor tener una forma que permita a diferentes protocolos ordenar las transacciones según la demanda, es decir, la ejecución controlada por la aplicación (Application-Controlled Execution) que Solana ha estado enfatizando.
BAM (Block Assembly Marketplace, mercado de ensamblaje de bloques) es la respuesta de Solana.
BAM ha construido una capa de ordenación, o capa de preprocesamiento, entre la aplicación en la cadena de Solana y la red principal.
Utilizando Entornos de Ejecución Confiables (Trusted Execution Environments, TEEs) para construir una caja de privacidad, donde se ordenan las transacciones dentro de la caja de acuerdo con reglas de ordenamiento previamente determinadas, o FIFO (primero en entrar, primero en salir).
Mejor servir a los libros de órdenes (CLOBs), intercambios de contratos perpetuos (Perpetual Exchanges) y protocolos de piscinas oscuras (Dark Pools).
Solana generalmente se compara el empaquetado de transacciones con el modo BAM
¿Cómo entender que BAM ha construido una capa de orden entre las aplicaciones de Solana y la red principal? Comencemos con una comparación intuitiva.
Flujo de transacción normal de Solana,
1）El usuario confirma la transacción en la billetera,
2）Transacción enviada al nodo RPC,
3）RPC enviado al nodo líder de la red principal de Solana en el período de Slot actual,
El líder recoge las transacciones del pool de transacciones, las ordena, las empaqueta en bloques y las transmite.
Votación de los nodos restantes.
Si una aplicación integra BAM, el flujo de transacciones es el siguiente,
1）El usuario confirma la transacción en la billetera,
Envío de la transacción al nodo RPC,
Transacciones transferidas a la red BAM, ordenadas en la privacidad TEE. En el proceso, los nodos pueden agregar transacciones adicionales a través de plugins, como la actualización del precio del oráculo, y luego generar pruebas,
4）El paquete de datos de la transacción se envía al nodo líder de la red principal de Solana,
El líder recoge las transacciones, recoge el paquete de datos BAM, lo empaqueta en un bloque y lo transmite.
Voto de los nodos restantes.
Por lo tanto, en realidad BAM no entra en conflicto con el proceso de consenso actual de la red principal de Solana, sino que actúa como una "opción". BAM no se ejecuta directamente en la red principal de Solana, sino que se realiza de manera "fuera de la cadena", completando previamente el ordenamiento de las transacciones, empaquetando las transacciones y luego enviándolas a la red principal de Solana.
BAM modo de ordenación de volumen
BAM admite tres modos de operación,
1）Solana modo predeterminado;
2）Modo Block-Engine; la solución MEV actual de Jito se basa en un mecanismo de pujas.
El núcleo del modo BAM tiene los siguientes puntos,
2）Sistema de plugins Plugin: Ordenamiento complejo A través del sistema de plugins, BAM permite a las aplicaciones construir lógica de ordenamiento de transacciones personalizada. Y este ordenamiento personalizado no significa que los nodos lo hagan como quieran, sino que se ordena según reglas preestablecidas.
El plan del complemento implementa un ordenamiento de transacciones complejo, mientras mantiene las garantías de seguridad del entorno TEE. Actualmente se encuentra en una fase de desarrollo temprano.
Como se mencionó anteriormente,
Para un libro de órdenes DEX, el orden ideal debería ser ejecutar primero todas las cancelaciones, luego las nuevas órdenes y, por último, las transacciones, a medida que fluctúa el precio. Esto es algo que actualmente el consenso de Solana no puede lograr a nivel micro.
Y en el nivel de cotización de los oráculos es igual, la situación ideal es actualizar primero el precio del oráculo y luego ejecutar las transacciones que dependen de ese precio. Pero en el intervalo actual de 400 milisegundos, los precios pueden fluctuar drásticamente, lo que puede resultar en que las transacciones se realicen al precio original.
Para los protocolos de préstamo, es mejor primero aumentar el margen y luego proceder con la liquidación. Esto implementa de hecho la función de control de ejecución de la aplicación ACE.
Entonces, ¿qué logró realmente BAM?
Por ejemplo,
1）Protección de liquidación de préstamos
Para los acuerdos de préstamo, después de detectar el riesgo de liquidación, se debe priorizar la ejecución de operaciones de colateral adicional, y luego proceder con la verificación de liquidación.
Para DEX, primero actualiza el precio del oráculo y ejecuta las transacciones que dependen de ese precio. Si es un DEX de contrato, también se pueden liquidar los derivados relacionados. Todas las operaciones anteriores se completan dentro de la misma ventana de tiempo.
Para DEX, detectar grandes órdenes anómalas, dividir grandes órdenes en fragmentos más pequeños, ejecutarlas en lotes, dar tiempo al mercado para reaccionar y evitar espirales mortales causadas por liquidaciones en cadena o arbitrajes.
Ocurre un evento inesperado, se cancela la orden en milisegundos, el oráculo actualiza el precio, el creador de mercado vuelve a colocar la orden. Evitar el arbitraje malicioso, reducir la diferencia de precio.
BAM se iba a lanzar a finales de julio.
Y, con el despliegue de BAM, la experiencia de trading en Solana mejorará significativamente. BAM hará que la experiencia de las aplicaciones en la mainnet de Solana se acerque más a la de un CEX.
En resumen,
BAM aporta verificabilidad, protección de la privacidad y programabilidad al proceso de procesamiento de transacciones de Solana, permitiendo a los desarrolladores construir libros de órdenes centralizados (CLOBs), intercambios de contratos perpetuos (Perpetual Exchanges), piscinas oscuras (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.
Lo anterior.