# Introducción a la Data Availability

By [L2 en Español](https://paragraph.com/@layer2es) · 2023-04-28

---

📌Introducción
--------------

Uno de los conceptos que más se repiten en la industria cripto es “**trustless**”, lo cual significa en esencia que no debes confiar en nadie sin validarlo primero.

Es por esto que las _blockchains_ poseen nodos completos, los cuales descargan y ejecutan la **_data_** que proporcionan los “**bloques**” (**_blocks_** en inglés) y se aseguran que los cálculos propuestos por el _block producer_ coinciden precisamente con los cálculos hechos por el validador. De esta manera, los nodos verifican que esta nueva información es válida en lugar de tener que confiar ciegamente en que los **_block producers_** (en español, **productores de bloques**) son honestos.

De lo dicho anteriormente podemos decir que **no es posible validar cálculos si falta algún dato**. Y es allí donde la **_Data Availability_** entra en escena.

* * *

🤷‍♂️¿Qué es la Data Availability (DA)?
=======================================

En términos de una blockchain, la **_Data Availability_**, o “**Disponibilidad de datos**” en español, se refiere a la capacidad de los nodos de la red para acceder a la información de los [_blocks_](https://ethereum.org/en/developers/docs/blocks/) almacenados en la blockchain. Esto incluye **la capacidad de leer y verificar los datos, así como la capacidad de escribir y reproducir de nuevo los mismos datos para su verificación**.

Asegurar la **_Data Availability_** es crucial para el funcionamiento de una _blockchain_, ya que permite a los nodos participar en el proceso de consenso y garantiza que la _blockchain_ pueda continuar funcionando incluso si algunos nodos fallan o se desconectan.

Podemos decir entonces que la **_Data Availability_** depende de la información que contienen los _blocks_. Por su parte los _blocks_ están conformados por 2 partes:

*   **_Block Head_:** este contiene información (_metadata_) sobre el _block_. Esto incluye el número del _block_, el hash del _block_, la [_timestamp_](https://academy.bit2me.com/timestamp-blockchain/#:~:text=El%20timestamp%20o%20marca%20de,validado%20por%20la%20red%20blockchain.), etc.
    
*   **_Block Body_:** El cuerpo de _block_ consiste en todos los datos de transacciones procesados como parte del _block_ en cuestión.
    

![Partes de un block. Fuente: www.researchgate.net](https://storage.googleapis.com/papyrus_images/19f16247d2eff087edbd69945ed5548f8efacf748b9a9c7691e736cef550acd5.png)

Partes de un block. Fuente: www.researchgate.net

* * *

🤔¿Cómo funciona la verificación de un block?
---------------------------------------------

En primer lugar, el _block producer_:

1.  Toma transacciones de la [_mempool_](https://academy.binance.com/es/glossary/mempool).
    
    (La **_mempool_** es un mecanismo que actúa como una “**sala de espera**” para las transacciones que aún no han sido incluidas en un _block_)
    
2.  Produce un nuevo _block_ con esas transacciones con un orden específico.
    
3.  Transmite el nuevo _block_ a la red _P2P_ de validadores para que sea agregado a la _chain_.
    
    (En una red de “**_Proof of work_**” se llama al _block_ _producer_ "**_miner_**", mientras que en una red de “**_Proof of stake_**” se llama "**_validator_**".)
    

A continuación, los nodos validadores (también conocidos como [nodos completos](https://www.alchemy.com/overviews/archive-nodes) o **Full nodes** en inglés):

1.  Descargan la **_data_** de las transacciones del _block_ recién propuesto.
    
2.  Reejecutan las transacciones para confirmar su cumplimiento con las reglas de consenso.
    
3.  Agregan el _block_ a la cabeza de la _chain_ una vez que la red determina que el _block_ es válido.
    
    La siguiente ilustración se encuentra un como ejemplo de una _block verification_:
    

![Verificación de un Block. Fuente: www.researchgate.net](https://storage.googleapis.com/papyrus_images/24c1d072bd5eb577ad2747a004dce9230f7864002d5771bacae09c3cdd0ffebe.png)

Verificación de un Block. Fuente: www.researchgate.net

* * *

👊Los desafíos de la Data Availability
--------------------------------------

Como se mencionó previamente, la **_Data Availability_** es esencial para la mayoría de las _blockchains_. Sin embargo, mantener esta disponibilidad puede ser complicado y está sujeto a problemas. _¿Cuáles son los desafíos comunes asociados a la disponibilidad de datos?_ Pues tenemos dos grandes desafíos que deben abordarse:

1.  Requerir que los nodos de la _blockchain_ descarguen y verifiquen los datos **puede reducir el rendimiento, o sea, la escalabilidad**.
    
2.  El uso de almacenamiento _on-chain_ para una cantidad cada vez mayor de datos **limita intrínsecamente el número de entidades que pueden ejecutar nodos**.
    

Las redes **_blockchain_ monolíticas** (ejemplo: Bitcoin, Solana o Ethereum hoy) garantizan la **_Data Availability_** almacenandola en varios nodos para que los participantes de la red que necesiten esta información puedan solicitarla a otro _peer_ (“par” en español) o nodo de la red. Por desgracia, esta implementación de la disponibilidad de datos **incluye numerosos problemas**.

Requerir que un gran número de nodos descarguen, almacenen y verifiquen los mismos datos **reduce significativamente el rendimiento** de las _blockchains_. Esta es la razón por la que la velocidad de procesamiento de las redes blockchain como Ethereum y Bitcoin es relativamente baja.

Por otro lado, el almacenamiento de datos en la _chain_ también conlleva un aumento significativo del tamaño de la blockchain, lo que resulta en un aumento exponencial de los requisitos de _hardware_ para los llamados nodos completos, que necesitan acumular mayores cantidades de _states_. Además, el aumento de los costes de _hardware_ **reduce el número de individuos o entidades con recursos suficientes para correr nodos**, lo que contribuye al riesgo de **centralización**.

* * *

🎭Diferencia entre Storage, Data Availability (DA) y Data Availability Committee (DAC)
======================================================================================

El término "**_Storage_**" se refiere al proceso de almacenamiento de datos en una red. En el contexto de las criptomonedas, se utiliza para hacer referencia al almacenamiento de información de las transacciones en la _blockchain_. La _blockchain_ es una base de datos distribuida que almacena todos los registros de las transacciones realizadas en la red. El proceso de "**_Storage_**" garantiza que los datos se almacenen de manera segura y permanente, lo que asegura la integridad y transparencia de las transacciones en la red.

![Almacenamiento Físico. www.malwarebytes.com](https://storage.googleapis.com/papyrus_images/2946cfeccd4b3a5987d67622220455dcdbf162c02ab4e0a20f94b67d17bc4770.png)

Almacenamiento Físico. www.malwarebytes.com

Por otro lado, "**_Data Availability_**" hace referencia a la disponibilidad de los datos en la red. Su objetivo es asegurar que los datos almacenados en la blockchain estén disponibles para los nodos de la red en todo momento. Esto es esencial para el correcto funcionamiento de la red, ya que cualquier interrupción o pérdida de datos podría generar graves problemas.

Finalmente, el "**_Data Availability Committee_**" es un grupo de personas o entidades que manejan nodos en conjunto para garantizar la disponibilidad de los datos en la red. Este comité está conformado por diferentes nodos y su objetivo principal es asegurar que los datos estén disponibles en todo momento. Los miembros del comité supervisan la disponibilidad de los datos y toman medidas inmediatas en caso de que se produzca alguna interrupción.

![Comité. Fuente: https://westsiderc.org/](https://storage.googleapis.com/papyrus_images/877a5ce7a04fb4cbdd7eb814ffad2ea9c43a7b9de8946b2b71455e891fa233c8.png)

Comité. Fuente: https://westsiderc.org/

En conclusión, en la industria cripto, el proceso de "**_Storage_**" se encarga del almacenamiento de datos en la _blockchain_, la "**_Data Availability_**" garantiza la disponibilidad de los datos en la red y el "**_Data Availability Committee_**" son un grupo de nodos que se encargan de supervisar y garantizar que los datos estén siempre disponibles. Estos tres conceptos son fundamentales para asegurar la seguridad y el correcto funcionamiento de la red en la industria cripto.

* * *

📊Tipos de sistemas de Data Availability en blockchain
------------------------------------------------------

![Enfoque Monolítico y Modular. Fuente: https://blog.celestia.org/modular-vs-monolithic-a-beginners-guide/](https://storage.googleapis.com/papyrus_images/6e546036e8dca6140633999f326e97ff975fc8a48d8b1d1ed6c859439f07750c.png)

Enfoque Monolítico y Modular. Fuente: https://blog.celestia.org/modular-vs-monolithic-a-beginners-guide/

### ⛓On-chain Data Availability

La solución convencional para abordar la **_Data Availability_** consiste en exigir a los block producer que publiquen todas las transacciones on-chain y que los nodos de validación las descarguen. Esta **_On-chain Data Availability_** es una característica de las "[_blockchains_ monolíticas](https://www.youtube.com/watch?v=pHBktwEswec)", las cuales se encargan de la **_Data Availability_**, la ejecución de transacciones y el consenso **en una sola _layer_**. Ethereum, por ejemplo, almacena datos de estado de manera redundante en toda la red para garantizar que los nodos tengan acceso a los datos necesarios para reproducir transacciones, verificar actualizaciones de estado y señalar transiciones de estado no válidas.

No obstante, esta **_On-chain Data Availability_** puede representar un obstáculo para la escalabilidad. Las **_blockchains_ monolíticas** suelen tener velocidades de procesamiento lentas debido a que los nodos deben descargar cada _block_ y reproducir las mismas transacciones. Además, requiere que todos los nodos almacenen cantidades cada vez mayores de estado, lo que puede afectar la descentralización. Si el estado de Ethereum aumenta, los validadores deberán invertir en máquinas más grandes, lo que probablemente reduciría el número de personas dispuestas a ejecutar un nodo validador.

### 💾Off-chain Data Availability

La **_Off-chain Data Availability_**  se refiere a sistemas que trasladan el almacenamiento de datos de la _blockchain_ a otra _layer_, lo que **permite obtener escalabilidad sin aumentar los requisitos de nodos**. Este tipo de _DA_ es la utilizada por las **_blockchains_ modulares**, la _chain_ gestiona algunas tareas como la ejecución de transacciones y el consenso, mientras que otras, como la **_Data Availability_**, se descargan en otra _layer_.

Por ejemplo, las soluciones de escalado como [_validiums_](https://ethereum.org/en/developers/docs/scaling/validium/) y [_plasma_](https://ethereum.org/en/developers/docs/scaling/plasma/) utilizan el almacenamiento _off-chain_ para separar la **_Data Availability_** del consenso y la ejecución. Aunque esta técnica mejora la eficiencia, también tiene **implicaciones negativas** para la descentralización, la seguridad y la confianza, ya que los participantes deben confiar en los _block producers_ para que no incluyan transacciones no válidas en los _blocks_ propuestos.

Para evitar estos problemas, algunas soluciones de escalado, como los **_Optimistic Rollups_** y los **_ZK Rollups_**, almacenan los datos de las transacciones en la _blockchain_ matriz, como Ethereum, utilizando esta _mainnet_ como _layer_ de **_Data Availability_**. De esta manera, se evita la necesidad de confiar en terceros, garantizando una mayor seguridad y descentralización.

* * *

📝Soluciones para los problemas de la Data Availability
-------------------------------------------------------

Los problemas de **_Data Availability_** están asociados a la capacidad de verificar si los datos de una transacción están disponibles para un _block_ recién propuesto. Para resolver este problema, se necesitan mecanismos que garanticen la **_Data Availability_** de las transacciones. A continuación, se presentan 4 posibles soluciones:

### 🧩Data Availability Sampling (DAS)

Es un mecanismo criptográfico que permite a los nodos de la _blockchain_ verificar que los datos están disponibles sin tener que descargar la totalidad de un _block_. En este sistema, **los nodos toman pequeñas muestras aleatorias** de diferentes partes del _block_ simultáneamente para verificar la disponibilidad de los datos. Debido a que muchos nodos toman muestras de diferentes partes del bloque, la disponibilidad se puede verificar con gran certeza estadística.

![Data Sampling. Fuente: https://hackmd.io/@vbuterin/sharding_proposal](https://storage.googleapis.com/papyrus_images/7fba1f4a3f1ba9bf1e6ebafc18f6bbc782dd1902821ad26b534d98e8f66eb408.png)

Data Sampling. Fuente: https://hackmd.io/@vbuterin/sharding\_proposal

### 📜Data Availability Proofs

Aunque el mecanismo _DAS_ garantiza estadísticamente la disponibilidad de los datos de un _block_, los nodos maliciosos pueden ocultar datos. Por lo tanto, para resolver este problema, se puede combinar el DAS con la "[codificación de borrado](https://www.computerweekly.com/es/definicion/Codigo-de-borrado-EC#:~:text=El%20c%C3%B3digo%20de%20borrado%20\(Erasure,de%20almacenamiento%20o%20ubicaciones%20geogr%C3%A1ficas.)" para crear **_Data Availability Proofs_**. La codificación de borrado **es un método que permite a las redes duplicar conjuntos de datos añadiendo piezas redundantes** conocidas como "códigos de borrado". Si se pierden los datos originales, es posible utilizar códigos de borrado para reconstruir la información original.

### 👨‍👩‍👧‍👦Data Availability Committees (DAC)

Son grupos de entidades autorizadas encargadas de **mantener copias de los datos _off-chain_ de la _blockchain_**. Un _DAC_ está formado por miembros de confianza designados para esta función específica. Los productores de _blocks_ deben enviar los datos de las transacciones a los miembros del _DAC_ cuando realizan transiciones de estado. Aunque este método logra poner la información a disposición de los usuarios, tiene un **efecto negativo en la descentralización**, ya que se depende de los miembros del comité para disponer de la data.

### 💰Data Availability Committees basados en Proof of Stake

Si bien los _Data Availability Committees_ son mejores para asegurar la data, **aún quedan huecos en la confianza**. ¿Qué sucede si el _DAC_ se asocia con el _block producer_ para retener los datos de transacción? Los _DAC_ suelen ser pequeños, lo que aumenta el riesgo de que sean sobornados y la posibilidad de que un actor externo comprometa al grupo.

Algunos _validiums_ reemplazan los _DAC_ con un sistema validador basado en **_proof of stake (PoS)_**. Aquí, **cualquiera puede convertirse en validador** y almacenar datos _off-chain_. Sin embargo, deben proporcionar un "**garantía o _bond_**", que se deposita en un _smart contract_. En caso de **comportamiento malintencionado**, como la retención de datos por parte del validador, **está garantía será tomada como castigo**.

Los **_Data Availability Committees basados en Proof of Stake_** son considerablemente más seguros que los _DAC_ regulares. No solo son permisivos y _trustless_, sino que también tienen incentivos bien diseñados para fomentar un comportamiento honesto.

* * *

🌌¿Cómo funciona la Data Availability Layer con los rollups?
------------------------------------------------------------

Los **_rollups_** otorgan escalabilidad a  Ethereum moviendo la computación y el almacenamiento del estado fuera del entorno de ejecución de Ethereum: la Máquina Virtual Ethereum (**_EVM_**). La **EVM** solo acepta resultados de la computación off-chain y los aplica a su estado sin tener que volver a ejecutar transacciones, mejorando así la velocidad de procesamiento y reduciendo costos.

Lo que hace que los **_rollups_** sean más seguros que otras soluciones de escalado de Ethereum, incluyendo las sidechains o Plasma, es su dependencia de Ethereum para la **_Data Availability_**. Además de publicar resultados de transacciones en Ethereum, los **_Optimistic rollups_**  y los **_ZK Rollups_** también publican datos de transacciones en la _Layer 1_ como **_CALLDATA_**.

![Soluciones de Escalabilidad de Ethereum. Fuente: https://twitter.com/MessariCrypto/status/1546886356277891078](https://storage.googleapis.com/papyrus_images/7c6a9484541ccc3dcc70f323059a69885146c76d429ee2f69133ddd6a01f2bdb.png)

Soluciones de Escalabilidad de Ethereum. Fuente: https://twitter.com/MessariCrypto/status/1546886356277891078

Los datos de los blocks publicados desde un rollup a Ethereum están disponibles públicamente, lo que permite a cualquier persona ejecutar transacciones y validar la _rollup chain_. También promueve la **_censorship resistance_** (resistencia a la censura) porque los datos publicados pueden ser utilizados por los futuros productores de _blocks_ para reconstruir el estado de la cadena y comenzar a producir nuevos _blocks_. Ningún operador de la _Layer_ 2 puede congelar arbitrariamente la _chain_ y censurar a los usuarios en el _rollup_ debido a esta medida.

Con la **_Data Availability Layer_** proporcionando seguridad, los _rollups_ pueden optimizar la escalabilidad. Por ejemplo, un _rollup_ puede elegir _blocks_ grandes y tiempos de _block_ más rápidos para acelerar la velocidad de procesamiento. Si bien esto aumenta los requisitos de _hardware_ para los nodos (la mayoría de los _rollups_ tienen algunos "**_supernodes_**" que ejecutan transacciones), la **_Data Availability_** de estado permite que cualquiera desafíe transiciones de estado inválidas o produzca _blocks_ para evitar la censura.

* * *

🗂Ejemplos en el espacio de L2
------------------------------

Los protocolos que utilizan **_Optimistic Rollups_** (como [Optimism](https://layer2es.notion.site/Arbitrum-One-8a807a8154ed41d9a1554f8206321867) o [Arbitrum One](https://layer2es.notion.site/Optimism-2623d3f6fd9a459ba1e5b07e89daa34a)) y **_ZK Rollups_** (como [zkSync Era](https://layer2es.notion.site/zkSync-Era-5948dd56f580431a8de584a7ad428ba4) o [Starknet](https://layer2es.notion.site/Starknet-973f10f9c26c48e28f76f44506dd190b)) usan la “**_Data Availability On-Chain_**”, ya que todos los datos necesarios para la construcción de Validity proofs y Fraud proofs son publicados en la cadena matriz de Ethereum (L1).

Por otro lado los **_Validiums_** como [Immutable X](https://layer2es.notion.site/Immutable-X-a55467c6dca04675a5e9dde750f42e9b), [Sorare](https://layer2es.notion.site/Sorare-ccada96ecb624ed58603023a23510125) y [rhino.fi](https://layer2es.notion.site/Rhino-fi-a73427efe8fd40d8b72b6950b736fe86) , junto a la **_Optimistic Chain_**, [Arbitrum Nova](https://layer2es.notion.site/Arbitrum-Nova-e892fda4cd084834adf3f46be79f8d0c), usan el esquema de **_Data Availability Committee_**, ya que la construcción de **_validity proofs_** se basa totalmente en datos que **no están publicados _on-chain_ (es decir, _Off-chain_)**. Existe un **_Data Availability Committee_** (DAC) encargado de proteger y suministrar los datos.

Otro caso es [Apex](https://layer2es.notion.site/ApeX-bc4d13f8f2a44b81a9c487339593b5bb), que almacena sus datos de manera externa, por lo que su **_Data Availability_** _se encuentra fuera de Ethereum o la red matriz. Por consecuencia la creación de sus_ **_validity proofs_** se basa totalmente en datos que **no se publican _on-chain_**.

Por último está [Metis](https://layer2es.notion.site/Metis-Andromeda-16dd2dd1e7d242eca59805de7faa7fb6), que con la ayuda de uno de sus socios, [MemoLabs](https://www.memolabs.org/), es capaz de almacenar y garantizar su **_Data Availability_** para operaciones a través del servicio de **_Storage_** descentralizado que ofrece [MemoLabs](https://www.memolabs.org/). En pocas palabras Metis, utiliza un sistema **_DAC_** pero en vez de almacenar su data en su propio **_Storage_**, utiliza el de uno de sus _partners_.

* * *

✅Conclusión
===========

La **_Data Availability_** en la cripto industria es esencial para entender y mejorar la escalibilidad de las _blockchains_ monolíticas y modulares. La transparencia y la accesibilidad de los datos son clave para tomar decisiones informadas y precisas de cómo mejorar el rendimiento de una _blockchain_ y mantener su seguridad _trustless_ para todos sus usuarios.

Sin embargo, una **_Data Availability_** "confiable" sigue siendo un desafío a superar debido a la naturaleza descentralizada y anónima de muchos protocolos o redes que la usan.

A medida que los protocolos y la tecnología blockchain en general vaya madurando, es esencial que los datos estén disponibles para que los _developers_ y/o expertos puedan realizar acciones en pro de crear un mejoramiento continuo de la cripto esfera. Además, es importante que se establezcan estándares claros para la calidad y la veracidad de los datos para garantizar que los inversores tengan acceso a información confiable y precisa. **Lo cual podrá contribuir a la adopción masiva de la blockchain que tanto se busca y que quizás ha costado conseguir…**

![](https://storage.googleapis.com/papyrus_images/fc55ac0fc385eb5c2314f9921b077d054f75604ea20c5a48f0150a731b78e0af.png)

* * *

📚Referencias
=============

1️⃣[Data Availability in Blockchains - Exploring the Data Availability Layer](https://moralis.io/data-availability-in-blockchains-exploring-the-data-availability-layer/)

2️⃣[Data availability | ethereum.org](https://ethereum.org/en/developers/docs/data-availability/#:~:text=Data%20availability%20is%20the%20guarantee,transactions%20get%20processed%20in%20blocks)

3️⃣[What is the data availability layer?](https://www.alchemy.com/overviews/data-availability-layer)

* * *

🎉 ¡Gracias por leer hasta el final! En L2 en Español estamos avocados en educar, aprender y estudiar juntos, sigue nuestras redes sociales y únete a la conversación en nuestra comunidad de Telegram!

[https://t.me/l2espaniol](https://t.me/l2espaniol)

[https://twitter.com/Layer2es](https://twitter.com/Layer2es)

---

*Originally published on [L2 en Español](https://paragraph.com/@layer2es/introducci-n-a-la-data-availability)*
