Jito BAM en Solana: Repensando la arquitectura de bloques a través de plugins
El panorama MEV de Solana está experimentando una reestructuración significativa. Jito BAM—una capa de infraestructura para la construcción de bloques—aspira a abordar una limitación arquitectónica fundamental: el procesamiento secuencial tradicional de transacciones. A diferencia del modelo PBS (Proposer-Builder Separation) de Ethereum, BAM aprovecha el consenso único de Solana, POH (Proof of History), para preorganizar bloques completos dentro de un TEE (Trusted Execution Environment) antes de su distribución a los validadores.
La iniciativa representa una coalición de actores destacados del ecosistema. Más allá de Jito Labs, que controla el 90% de los validadores de Solana, el elenco de apoyo incluye Triton One, SOL Strategies, Figment, Helius, Drift y Pyth. Este esfuerzo coordinado aborda una amenaza competitiva urgente: cadenas especializadas como Hyperliquid están capturando cuota de mercado mediante la optimización de operaciones nativas en libros de órdenes DEX—capacidades que la producción lineal de bloques de Solana lucha por replicar.
La arquitectura técnica introduce un elemento novedoso: el ordenamiento programable de transacciones mediante código plugin. Esto significa que los desarrolladores pueden codificar reglas específicas de secuenciación directamente en la estructura del bloque. Un proveedor de oráculos podría garantizar que las feeds de precios se ejecuten primero, minimizando riesgos de datos obsoletos. Un constructor de DEX podría filtrar transacciones con altas tasas de fallo en la fase TEE, reduciendo los costos para los usuarios por intercambios fallidos.
La hoja de ruta comienza con Jito Labs operando nodos, expandiéndose gradualmente a validadores que representan más del 30% del staking de la red, avanzando eventualmente hacia una gobernanza descentralizada.
Sin embargo, los desafíos de escalabilidad son inminentes. La capacidad del TEE alcanza un máximo en miles de transacciones por segundo, mientras que las ambiciones de Solana van mucho más allá de este techo. Operar múltiples TEEs introduce complejidad en recuperación ante desastres, gestión de memoria y provisión de ancho de banda. Además, a menos que surjan incentivos económicos convincentes, la infraestructura podría tener dificultades para ser rentable—las ganancias del Q2 2025 de Jito, aproximadamente 4 millones de USD en propinas, subrayan retornos modestos actuales.
Los casos de uso clave—fiabilidad en la secuenciación de oráculos y inmunidad a fallos en transacciones—podrían justificar inversiones de market makers y plataformas de trading institucional. Sin embargo, el riesgo fundamental permanece: incluso una certeza del 99% no es suficiente para garantías deterministas cuando el estándar es el 100%.
BRC2.0: Ejecución EVM anclada en Bitcoin
Bitcoin entra en la carrera de la programabilidad con un enfoque claramente diferente. Programado para activarse el 2 de septiembre de 2025, BRC2.0 replantea la conversación: en lugar de añadir capas computacionales sobre Bitcoin, ancla contratos programables a transacciones de Bitcoin, ejecutándolos en un entorno off-chain compatible con EVM.
Los usuarios inscriben instrucciones en bloques BTC mediante mecanismos de inscripción o compromiso-revelación. Un indexador interpreta estas instrucciones, ejecutándolas en un entorno EVM modificado. De manera crucial, no se aplican tarifas de gas—solo importan las tarifas de transacción de Bitcoin, ya que el parámetro EVM permanece sin empaquetar.
El linaje del protocolo se remonta a Bestinslot, la plataforma de la era de inscripciones que popularizó la teoría ordinal. La continuidad filosófica con BRC20 es evidente: ampliar la utilidad de Bitcoin sin alterar el consenso. Sin embargo, la ejecución técnica difiere sustancialmente—esto apunta a la ejecución en EVM en lugar de la simple emisión de tokens.
Surge una cuestión filosófica: ¿debería Bitcoin buscar la programabilidad en absoluto? La relación entre seguridad, consenso y descentralización que permite la narrativa de reserva de valor de Bitcoin difiere fundamentalmente de las cadenas orientadas a alto rendimiento. Las cadenas de alta velocidad ya superan el techo de rendimiento de Bitcoin en todos los aspectos. El modelo de escasez de Bitcoin y su mecanismo de consenso de suministro fijo crean un marco de valoración único—precisamente porque la programabilidad permanece estructuralmente limitada. Añadir capacidades de ejecución corre el riesgo de diluir esta diferenciación central.
Desde una perspectiva técnica, la implementación actual presenta vulnerabilidades. Las llamadas recursivas en contratos carecen de límites de profundidad, exponiendo teóricamente la VM a escenarios de bloqueo por recursión ilimitada. Aunque las correcciones son sencillas, su ausencia en el código desplegado requiere cautela.
EIP-7999: Harmonizando el mercado de tarifas de múltiples recursos en Ethereum
La última propuesta de Vitalik Buterin para el mercado de tarifas representa una respuesta sistemática a la fragmentación. Actualmente, Ethereum gestiona precios en cuatro dimensiones: gas de ejecución (EIP-1559), gas de blob (post-EIP-4844), bytes de calldata (diferenciado desde 2015), y recursos computacionales.
Para usuarios y desarrolladores de wallets, esta complejidad genera fricciones en la experiencia de usuario. Los constructores de L2 enfrentan una crisis real: calibrar incorrectamente alguna de las tarifas puede hacer fallar toda la transacción, independientemente de la suficiencia del presupuesto total de tarifas. Un pico repentino en el gas de blob podría provocar fallos a pesar de una asignación suficiente de gas de ejecución.
EIP-7999 introduce una tarificación unificada mediante un parámetro max_fee que el EVM asigna dinámicamente a los diferentes recursos. La implementación requiere nuevos tipos de transacción con definiciones de campo reestructuradas, afectando la codificación RLP, las cabeceras de bloque y las reglas de validación del consenso.
El enfoque refleja un diseño de UX mejorado en comparación con la complejidad de ERC-4337, aunque los plazos de adopción siguen siendo inciertos. La integración completa probablemente requerirá 1-2 hard forks mayores, lo que implicará adaptación en el ecosistema de wallets y cambios a nivel de nodo.
El razonamiento económico merece un análisis cuidadoso—los estudios de Vitalik que lo respaldan contienen modelos sofisticados de utilización de recursos, extracción de tarifas y sostenibilidad a largo plazo de la red, que requieren un estudio profundo por parte de los desarrolladores de protocolos y constructores del ecosistema que navegan hacia la próxima fase de escalado.
Estas tres iniciativas—cada una emergiendo de ecosistemas blockchain distintos—reflejan una madurez más amplia: los constructores avanzan más allá del simple escalado hacia una optimización arquitectónica, equilibrando la viabilidad técnica con la alineación de incentivos económicos.
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.
Tres grandes iniciativas técnicas de Web3 descifradas: Jito BAM, BRC2.0 y EIP-7999
Jito BAM en Solana: Repensando la arquitectura de bloques a través de plugins
El panorama MEV de Solana está experimentando una reestructuración significativa. Jito BAM—una capa de infraestructura para la construcción de bloques—aspira a abordar una limitación arquitectónica fundamental: el procesamiento secuencial tradicional de transacciones. A diferencia del modelo PBS (Proposer-Builder Separation) de Ethereum, BAM aprovecha el consenso único de Solana, POH (Proof of History), para preorganizar bloques completos dentro de un TEE (Trusted Execution Environment) antes de su distribución a los validadores.
La iniciativa representa una coalición de actores destacados del ecosistema. Más allá de Jito Labs, que controla el 90% de los validadores de Solana, el elenco de apoyo incluye Triton One, SOL Strategies, Figment, Helius, Drift y Pyth. Este esfuerzo coordinado aborda una amenaza competitiva urgente: cadenas especializadas como Hyperliquid están capturando cuota de mercado mediante la optimización de operaciones nativas en libros de órdenes DEX—capacidades que la producción lineal de bloques de Solana lucha por replicar.
La arquitectura técnica introduce un elemento novedoso: el ordenamiento programable de transacciones mediante código plugin. Esto significa que los desarrolladores pueden codificar reglas específicas de secuenciación directamente en la estructura del bloque. Un proveedor de oráculos podría garantizar que las feeds de precios se ejecuten primero, minimizando riesgos de datos obsoletos. Un constructor de DEX podría filtrar transacciones con altas tasas de fallo en la fase TEE, reduciendo los costos para los usuarios por intercambios fallidos.
La hoja de ruta comienza con Jito Labs operando nodos, expandiéndose gradualmente a validadores que representan más del 30% del staking de la red, avanzando eventualmente hacia una gobernanza descentralizada.
Sin embargo, los desafíos de escalabilidad son inminentes. La capacidad del TEE alcanza un máximo en miles de transacciones por segundo, mientras que las ambiciones de Solana van mucho más allá de este techo. Operar múltiples TEEs introduce complejidad en recuperación ante desastres, gestión de memoria y provisión de ancho de banda. Además, a menos que surjan incentivos económicos convincentes, la infraestructura podría tener dificultades para ser rentable—las ganancias del Q2 2025 de Jito, aproximadamente 4 millones de USD en propinas, subrayan retornos modestos actuales.
Los casos de uso clave—fiabilidad en la secuenciación de oráculos y inmunidad a fallos en transacciones—podrían justificar inversiones de market makers y plataformas de trading institucional. Sin embargo, el riesgo fundamental permanece: incluso una certeza del 99% no es suficiente para garantías deterministas cuando el estándar es el 100%.
BRC2.0: Ejecución EVM anclada en Bitcoin
Bitcoin entra en la carrera de la programabilidad con un enfoque claramente diferente. Programado para activarse el 2 de septiembre de 2025, BRC2.0 replantea la conversación: en lugar de añadir capas computacionales sobre Bitcoin, ancla contratos programables a transacciones de Bitcoin, ejecutándolos en un entorno off-chain compatible con EVM.
Los usuarios inscriben instrucciones en bloques BTC mediante mecanismos de inscripción o compromiso-revelación. Un indexador interpreta estas instrucciones, ejecutándolas en un entorno EVM modificado. De manera crucial, no se aplican tarifas de gas—solo importan las tarifas de transacción de Bitcoin, ya que el parámetro EVM permanece sin empaquetar.
El linaje del protocolo se remonta a Bestinslot, la plataforma de la era de inscripciones que popularizó la teoría ordinal. La continuidad filosófica con BRC20 es evidente: ampliar la utilidad de Bitcoin sin alterar el consenso. Sin embargo, la ejecución técnica difiere sustancialmente—esto apunta a la ejecución en EVM en lugar de la simple emisión de tokens.
Surge una cuestión filosófica: ¿debería Bitcoin buscar la programabilidad en absoluto? La relación entre seguridad, consenso y descentralización que permite la narrativa de reserva de valor de Bitcoin difiere fundamentalmente de las cadenas orientadas a alto rendimiento. Las cadenas de alta velocidad ya superan el techo de rendimiento de Bitcoin en todos los aspectos. El modelo de escasez de Bitcoin y su mecanismo de consenso de suministro fijo crean un marco de valoración único—precisamente porque la programabilidad permanece estructuralmente limitada. Añadir capacidades de ejecución corre el riesgo de diluir esta diferenciación central.
Desde una perspectiva técnica, la implementación actual presenta vulnerabilidades. Las llamadas recursivas en contratos carecen de límites de profundidad, exponiendo teóricamente la VM a escenarios de bloqueo por recursión ilimitada. Aunque las correcciones son sencillas, su ausencia en el código desplegado requiere cautela.
EIP-7999: Harmonizando el mercado de tarifas de múltiples recursos en Ethereum
La última propuesta de Vitalik Buterin para el mercado de tarifas representa una respuesta sistemática a la fragmentación. Actualmente, Ethereum gestiona precios en cuatro dimensiones: gas de ejecución (EIP-1559), gas de blob (post-EIP-4844), bytes de calldata (diferenciado desde 2015), y recursos computacionales.
Para usuarios y desarrolladores de wallets, esta complejidad genera fricciones en la experiencia de usuario. Los constructores de L2 enfrentan una crisis real: calibrar incorrectamente alguna de las tarifas puede hacer fallar toda la transacción, independientemente de la suficiencia del presupuesto total de tarifas. Un pico repentino en el gas de blob podría provocar fallos a pesar de una asignación suficiente de gas de ejecución.
EIP-7999 introduce una tarificación unificada mediante un parámetro max_fee que el EVM asigna dinámicamente a los diferentes recursos. La implementación requiere nuevos tipos de transacción con definiciones de campo reestructuradas, afectando la codificación RLP, las cabeceras de bloque y las reglas de validación del consenso.
El enfoque refleja un diseño de UX mejorado en comparación con la complejidad de ERC-4337, aunque los plazos de adopción siguen siendo inciertos. La integración completa probablemente requerirá 1-2 hard forks mayores, lo que implicará adaptación en el ecosistema de wallets y cambios a nivel de nodo.
El razonamiento económico merece un análisis cuidadoso—los estudios de Vitalik que lo respaldan contienen modelos sofisticados de utilización de recursos, extracción de tarifas y sostenibilidad a largo plazo de la red, que requieren un estudio profundo por parte de los desarrolladores de protocolos y constructores del ecosistema que navegan hacia la próxima fase de escalado.
Estas tres iniciativas—cada una emergiendo de ecosistemas blockchain distintos—reflejan una madurez más amplia: los constructores avanzan más allá del simple escalado hacia una optimización arquitectónica, equilibrando la viabilidad técnica con la alineación de incentivos económicos.