Transacción
Un tipo de transacción introducido en el EIP-4844 de Ethereum, diseñado para reducir las tarifas de transacción almacenando bloques de datos por separado de los datos de la transacción principal.
Las transacciones blob, introducidas a través de la Propuesta de Mejora de Ethereum (EIP) 4844 (también conocida como Proto-Danksharding), representan un cambio arquitectónico significativo destinado a reducir las tarifas de transacción, particularmente para las soluciones de escalado de Capa 2. A diferencia de las transacciones tradicionales de Ethereum que incrustan datos directamente en el calldata de la transacción principal, las transacciones blob utilizan una estructura de datos separada, aunque todavía en cadena, llamada 'blobs'. Estos blobs están diseñados para ser más baratos de publicar y están sujetos a límites de gas y mecanismos de precios diferentes a los datos de transacciones regulares. La motivación principal es reducir el costo de la disponibilidad de datos para los rollups. Los rollups agrupan transacciones fuera de la cadena y publican un resumen comprimido o una prueba en la cadena principal de Ethereum (Capa 1). El costo de publicar estos datos en la Capa 1 es un cuello de botella importante. El EIP-4844 introduce un nuevo tipo de transacción que permite a los rollups publicar mayores cantidades de datos de manera más económica al separarlos en estos blobs. Estos blobs no son procesados directamente por la Máquina Virtual de Ethereum (EVM), sino que se comprometen a través de un esquema de compromiso de polinomios KZG (Kalai-Shen-Goldwasser). Este compromiso se incluye en la cabecera del bloque, asegurando la disponibilidad de datos sin requerir que cada nodo descargue y almacene los datos completos del blob indefinidamente. Esta separación y manejo especializado reducen significativamente el costo de gas asociado con la disponibilidad de datos, haciendo que los rollups sean más viables económicamente y, por lo tanto, mejorando la escalabilidad general de Ethereum.
graph LR
Center["Transacción"]:::main
Pre_digital_signature["digital-signature"]:::pre --> Center
click Pre_digital_signature "/terms/digital-signature"
Pre_private_key["private-key"]:::pre --> Center
click Pre_private_key "/terms/private-key"
Rel_block["block"]:::related -.-> Center
click Rel_block "/terms/block"
Rel_smart_contract["smart-contract"]:::related -.-> Center
click Rel_smart_contract "/terms/smart-contract"
Rel_data_availability["data-availability"]:::related -.-> Center
click Rel_data_availability "/terms/data-availability"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Explícalo como si tuviera 5 años
Imagina que envías un paquete grande (tu transacción) y antes pagabas mucho por incluir todo el papel de embalaje dentro. Las transacciones blob te permiten enviar el papel de embalaje por separado y mucho más barato, haciendo que el costo total de tu envío sea mucho menor.
🤓 Expert Deep Dive
El EIP-4844 altera fundamentalmente la estrategia de disponibilidad de datos de Ethereum al introducir 'blobs' y compromisos KZG. Los blobs son fragmentos contiguos de datos adjuntos a un bloque, con un tamaño máximo y un límite de gas separado distinto del calldata. Crucialmente, los blobs no son directamente accesibles por la lógica del contrato EVM; su propósito principal es la verificación de la disponibilidad de datos. El compromiso con los datos del blob se logra utilizando compromisos de polinomios KZG, donde los datos del blob representan coeficientes de un polinomio y el compromiso es un punto en una curva elíptica. Esto permite una generación y verificación de pruebas eficientes. Se requiere que los nodos descarguen los datos del blob durante un período limitado (por ejemplo, ~4096 bloques o ~27 horas) para fines de verificación, después de lo cual pueden eliminarlos, reduciendo la hinchazón del estado. El costo de gas para publicar blobs es significativamente menor que el calldata, calculado en función del tamaño del blob y un 'precio de gas de blob' separado. Este mecanismo es un precursor del Danksharding completo, donde el espacio de blobs se expandirá y distribuirá en múltiples shards. Las compensaciones incluyen la complejidad del esquema de compromiso KZG y el requisito de almacenamiento temporal para los nodos, pero el beneficio principal es una reducción sustancial en los costos de publicación de datos de rollups.