Autores originales: Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

Publicado 2026-06-15

📖 6 min de lectura🧠 Análisis profundo

Autores originales: Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina una autopista concurrida donde, en lugar de que los coches circulen uno por uno en un solo carril, ahora se permite que el tráfico fluya simultáneamente por múltiples carriles. Esto es la ejecución en paralelo en las blockchains modernas: una forma de procesar muchas transacciones a la vez para que el sistema sea más rápido.

Sin embargo, este documento argumenta que, si bien las autopistas paralelas son más rápidas, los sistemas actuales de "peaje" (mecanismos de tarifas) están rotos. No saben cómo cobrar de manera justa cuando los conductores podrían tomar rutas diferentes, o cuando conductores falsos intentan engañar al sistema.

Aquí está el desglose de los hallazgos del documento utilizando analogías sencillas.

1. Los dos grandes problemas

Los autores identifican dos "peligros" principales que ocurren cuando intentas cobrar tarifas por el procesamiento en paralelo.

Peligro A: El conductor del "tal vez" (Transacciones contingentes)

Imagina que estás pidiendo una pizza personalizada. Le dices a la cocina: "Quiero una pizza con pepperoni, champiñones y aceitunas".

La realidad: En realidad, solo te comes el pepperoni. La cocina preparó los champiñones y las aceitunas, pero tú no los tocaste.
El problema: En una blockchain paralela, una transacción (el pedido de la pizza) a menudo dice: "Podría necesitar estos 5 objetos (ingredientes)". Pero dependiendo del estado actual del mundo (el precio del pepperoni), podría terminar usando solo 1 objeto.
- Si cobras por lo que usas: La cocina (el programador/scheduler) pierde dinero porque prepararon ingredientes que se desperdiciaron.
- Si cobras por lo que dijiste que usarías: Tú (el usuario) pagas de más por ingredientes que ni siquiera tocaste.

El gran descubrimiento del documento: No puedes tener ambas cosas. No puedes diseñar un sistema donde el usuario nunca pague de más Y la cocina nunca pierda dinero por el trabajo de preparación no utilizado. Es una imposibilidad matemática. Tienes que elegir quién asume el riesgo: el usuario o el sistema.

Peligro B: Los conductores "falsos" (Ataques de suplantación o Shill Attacks)

Ahora, imagina un peaje que cobra según cuánto tráfico hay en la carretera.

El truco del usuario: Un conductor quiere pagar un peaje bajo. Envía un montón de coches falsos e inútiles (transacciones de suplantación) a la carretera. Estos coches falsos ocupan espacio pero no van a ninguna parte. El peaje ve "tráfico pesado" y distribuye el costo, de modo que el conductor real paga menos.
El truco de la cabina de peaje: La persona que gestiona la cabina quiere ganar más dinero. Envía sus propios coches falsos a la carretera para que parezca que los conductores reales están causando un atasco masivo. La cabina de peaje luego cobra a los conductores reales una prima por "congestión".

El descubrimiento del documento: Los sistemas actuales son vulnerables a estos trucos. Si el sistema cobra según cuánto "trabajo en paralelo" se está realizando, los actores malintencionados pueden manipular las matemáticas añadiendo transacciones falsas para bajar o subir las tarifas.

2. Tres formas de dividir la cuenta

Dado que no se puede eliminar el riesgo de los ingredientes no utilizados (Peligro A), el documento sugiere tres formas de dividir la cuenta entre el Usuario y el Sistema:

El enfoque "Amigable con el Usuario": Solo pagas por el pepperoni que realmente comiste.
- Resultado: El usuario está feliz (no paga de más), pero la cocina (el sistema) pierde dinero por los champiñones y aceitunas desperdiciados.
El enfoque "Amigable con el Programador (Scheduler)": Pagas por toda la pizza que pediste, incluso si solo comiste el pepperoni.
- Resultado: La cocina está feliz (garantía de ingresos), pero el usuario podría estar pagando de más.
El enfoque "A partes iguales": Se divide el costo de los ingredientes desperdiciados 50/50.
- Resultado: Un compromiso donde ambas partes comparten el riesgo de los ingredientes del "tal vez".

3. La solución: La cabina de peaje "ponderada por objetos"

Para solucionar el problema de los "Conductores Falsos" (Peligro B) mientras se gestiona el problema del "Tal vez" (Peligro A), los autores proponen un nuevo sistema llamado OW-TFM (Mecanismo de Tarifas de Transacción Ponderado por Objetos).

La analogía:
En lugar de cobrar según cuántos coches hay en la carretera en este momento (lo cual puede ser falsificado), imagina un sistema de peaje que cobra según qué tan popular fue un carril específico ayer.

Si un objeto específico (como un ingrediente de pizza popular) se usó mucho en el último bloque, su precio sube ligeramente para el siguiente bloque.
Si no se usó, el precio se mantiene bajo.

Por qué esto detiene los trucos:

Para los usuarios: Si intentas añadir transacciones falsas para bajar tu tarifa, no puedes. Añadir una transacción falsa solo aumenta el recuento de uso de un objeto, lo que podría subir el precio para todos, incluyéndote a ti. No puedes bajar el precio añadiendo más coches.
Para el sistema: El sistema establece los precios basándose en datos pasados, por lo que no necesita adivinar qué pasará en el futuro.

4. La conclusión

El documento concluye que construir una blockchain paralela que sea justa, rápida y segura es difícil debido a un intercambio fundamental:

Velocidad vs. Justicia: No puedes predecir perfectamente qué "ingredientes" utilizará una transacción sin ejecutarla primero (lo que toma tiempo y anula el propósito del paralelismo).
Seguridad vs. Eficiencia: No puedes tener un sistema que sea perfectamente eficiente (cobrar exactamente por lo que se usa) y perfectamente seguro (inmune a las transacciones falsas) al mismo tiempo.

Los autores sugieren que los diseñadores de blockchains (como los que construyen Sui, Solana o Monad) deben decidir explícitamente quién asume el riesgo de los recursos no utilizados (Usuario o Sistema) y utilizar un modelo de precios basado en el uso histórico de objetos para evitar que la gente manipule el sistema con transacciones falsas.

En resumen: Las blockchains paralelas son como una cocina concurrida. No puedes cobrar perfectamente por una comida antes de saber qué comerá realmente el cliente, y no puedes evitar que la gente finja pedir comida para alterar la cuenta. La solución es acordar quién paga por la comida desperdiciada y basar los precios en lo que la gente suele pedir, no en lo que dice que va a pedir en este momento.

Resumen Técnico: Los Peligros del Paralelismo: Mecanismos de Tarifas de Transacción bajo la Incertidumbre de Ejecución

1. Planteamiento del Problema

Las blockchains modernas están transitando de una ejecución serial a una paralela para superar los cuellos de botella de rendimiento causados por la ejecución más que por el consenso. Si bien la ejecución paralela (utilizada o planeada por cadenas como Sui, Solana, Monad y Ethereum) aumenta la capacidad, introduce dos desafíos económicos críticos cuando las transacciones involucran incertidumbre de ejecución (contingencia) y contención de recursos:

Contingencia de Ejecución y Asignación de Riesgo: En lenguajes de contratos inteligentes expresivos (Turing-completos), el uso de recursos de una transacción (objetos accedidos) a menudo depende del estado de la blockchain en tiempo de ejecución, lo cual no puede conocerse antes de la ejecución. Esto crea una tensión entre el Riesgo del Usuario (los usuarios pagan de más por objetos declarados que no se utilizan) y el Riesgo del Programador (Scheduler Risk) (los programadores pierden ingresos cuando la capacidad reservada no se paga debido a una sub-ejecución).
Ataques de "Shill" en el Cálculo de Gas: Los mecanismos actuales de Cálculo de Gas (GCM) diseñados para entornos paralelos (por ejemplo, valor de Shapley o Makespan Proporcional al Tiempo) son vulnerables a la manipulación racional. Tanto los usuarios como los programadores pueden inyectar transacciones "shill" (falsas) para alterar estratégicamente el gas o las tarifas calculadas. Los usuarios pueden reducir sus tarifas añadiendo transacciones paralelas inútiles, mientras que los programadores pueden inflar las tarifas añadiendo contención falsa.

El artículo argumenta que los diseños actuales no logran contabilizar simultáneamente el paralelismo, la incertidumbre de ejecución y la robustez económica, lo que conduce a ineficiencias y vulnerabilidades explotables.

2. Metodología y Modelo

Los autores formalizan un marco para analizar los Mecanismos de Tarifas de Transacción (TFM) bajo ejecución paralela con incertidumbre.

Modelo de Transacción: Una transacción $tx$ se define por unidades de cómputo $t$ , una tarifa de prioridad $g$ , y conjuntos de lectura/escritura declarados $(R, W)$ . Crucialmente, los objetos realmente accedidos ( $X_R, X_W$ ) pueden ser un subconjunto de los conjuntos declarados dependiendo de la ruta de ejecución (contingencia).
Definiciones de Tarifas: El artículo distingue entre:
- Tarifa Alcanzable ( $f_{att}$ ): La tarifa si se utilizan todos los objetos declarados.
- Tarifa Base ( $f_{base}$ ): La tarifa solo por los objetos deterministas.
- Tarifa Ideal del Usuario ( $f_{ui}$ ): La tarifa por los objetos exactamente utilizados.
- Tarifa Real Pagada ( $f_{act}$ ): La tarifa cobrada.
Métricas de Riesgo:
- **Riesgo del Usuario ($UR $):**$ f_{act} - f_{ui}$ (sobrepago).
- **Riesgo del Programador ($SR $):**$ f_{att} - f_{act}$ (ingresos no realizados).
Modelo Adversario: Los usuarios y programadores se modelan como agentes racionales y económicamente motivados que pueden insertar transacciones shill para minimizar sus costos o maximizar sus ingresos, respectivamente.
Análisis de Complejidad: El artículo utiliza la teoría de la complejidad (específicamente la P-completitud) para analizar la dificultad de predecir el uso de objetos sin la ejecución.

3. Contribuciones Clave y Resultados

A. Imposibilidad de la Eliminación Simultánea de Riesgos

El artículo demuestra un resultado de imposibilidad fundamental: Ningún mecanismo puede eliminar simultáneamente el Riesgo del Usuario y el Riesgo del Programador sin pre-ejecutar las transacciones o colapsar hacia tarifas constantes.

Teorema 1: Si un programador está limitado por un límite de cómputo $G$ (no puede realizar más trabajo del que permite el bloque), es imposible establecer pagos tales que $UR=0 $y$ SR=0$ para todas las entradas que involucren transacciones contingentes en conflicto.
Teorema 2 (P-completitud): Decidir si un objeto específico es utilizado por una transacción contingente (el Problema de Decisión de Uso de Objetos) es P-completo. Esto implica que verificar el uso de objetos requiere un trabajo secuencial proporcional al tiempo de ejecución, lo que hace computacionalmente inviable para un programador predecir el uso de forma "barata" antes de la ejecución.
Compromiso (Trade-off): Existe un compromiso lineal inherente. Reducir el riesgo del usuario (cobrar solo por objetos usados) aumenta el riesgo del programador (pérdida de ingresos), y viceversa.

B. Caracterización de los Mecanismos de División de Riesgo

Dada la imposibilidad, los autores caracterizan el espacio de diseño a través de tres mecanismos canónicos de división de riesgo, parametrizados por $\alpha \in [0,1]$ :

Amigable para el Usuario ( $\alpha=0$ ): Los usuarios pagan solo por la ejecución realizada ( $f_{act} = f_{ui}$ ). El programador asume todo el riesgo.
Amigable para el Programador ( $\alpha=1$ ): Los usuarios pagan por todos los objetos declarados ( $f_{act} = f_{att}$ ). El usuario asume todo el riesgo.
Equitativo ( $\alpha=0.5$ ): El riesgo se divide equitativamente.
El artículo analiza estos bajo diferentes modelos de utilidad del programador (Optimista, Pesimista, Mediana) para mapear las implicaciones de ingresos.

C. Ataques de Shill y la Resistencia a la Tarifa (Fee-Based Shill-Proofness)

El artículo identifica que las propiedades estándar de los GCM (como la Inclusión de Conjuntos) son insuficientes para prevenir ataques de shill en presencia de contingencia.

Ataques de Shill de Usuarios: Los usuarios inyectan transacciones falsas para reducir el gas/tarifa efectiva de su transacción real.
Ataques de Shill de Programadores: Los programadores inyectan transacciones falsas para aumentar la tarifa/gas cobrada a los usuarios honestos.
Resistencia a la Tarifa (Fee-Based Shill-Proofness): Los autores proponen nuevas definiciones de resistencia a shill basadas en tarifas en lugar de solo gas, teniendo en cuenta las tarifas de prioridad y la contingencia de ejecución. Demuestran que, para los mecanismos amigables para el usuario, la resistencia a shill solo es alcanzable si la tarifa es independiente del esquema (Teorema 3).

D. El TFM de Peso por Objeto (OW-TFM)

Para resolver estos problemas, los autores proponen el Mecanismo de Tarifa de Transacción con Peso por Objeto (OW-TFM).

Mecanismo: Las tarifas se calculan basándose en el precio de los objetos declarados por la transacción, donde los precios de los objetos se actualizan según la utilización histórica (similar a EIP-1559).
Parametrización de Riesgo: El mecanismo utiliza un parámetro $\alpha$ para determinar cuánto paga un usuario por los objetos declarados pero no utilizados ( $\alpha \cdot \text{precio}$ ).
Resistencia a Shill: Se demuestra que el OW-TFM es resistente a shill bajo condiciones específicas. Debido a que los precios se derivan de la utilización de bloques pasados, una transacción shill en el bloque actual no puede bajar el precio de un objeto para el bloque actual (solo puede subir los precios futuros).
Condiciones: El Lemma 4 establece un umbral para $\alpha$ requerido para prevenir ataques de shill del programador, dependiente de la relación de prioridad-a-tarifa base ( $\pi_o$ ), la capacidad de respuesta del precio ( $\eta$ ) y la razón de retención ( $\gamma$ ).

4. Significado y Reivindicaciones

El artículo afirma proporcionar los fundamentos rigurosos para evaluar y diseñar mecanismos de tarifas para blockchains paralelas. Su importancia radica en:

Identificar Límites Fundamentales: Demuestra que la tensión entre la equidad del usuario y los ingresos del programador en la ejecución paralela no es un error de diseño, sino una consecuencia fundamental de la incertidumbre de ejecución y la complejidad computacional.
Exponer Vulnerabilidades: Revela que las propuestas existentes para el cálculo de gas paralelo (por ejemplo, enfoques basados en Shapley) son vulnerables a ataques de shill racionales, una amenaza previamente no abordada en la literatura.
Proveer un Marco de Diseño: Ofrece un espacio de diseño con principios (el espectro $\alpha$ ) y un mecanismo concreto (OW-TFM) que permite a los diseñadores de sistemas elegir explícitamente su estrategia de asignación de riesgo mientras mantienen la resistencia a la manipulación.
Relevancia para la Industria: Los resultados se aplican directamente y critican los diseños de las prominentes cadenas paralelas (Sui, Monad, Solana) y la hoja de ruta de Ethereum para la ejecución paralela mediante listas de acceso.

Los autores mantienen un tono modesto, señalando que su trabajo identifica limitaciones fundamentales y compromisos en lugar de prescribir una única solución "perfecta", reconociendo que el despliegue práctico requiere una consideración adicional de modelos de ejecución probabilísticos y detalles específicos de implementación.

Perils of Parallelism: Transaction Fee Mechanisms under Execution Uncertainty