---
# System prepended metadata

title: Data Availability and bridging

---

# Data Availability and bridging

One potential evolution of IBC is going from sheer message passing to having a shared data layer where chains can share state between them. This scenario is introduced by the appearence of Data Availability layers that are chain agnostic and optimize storage {access, update, consensus}. This document is a draft that aims to explore a potential form that both trustless bridging might take in the near future.


## Message passing vs shared state

IBC as we know it today works using the message passing paradigm. Light clients can be thought as actors, and every IBC event is analogous to a message. This is a proven model that has delivered fabulous results so far, particularly in the Cosmos ecosystem.

An alternative way to communicate between processes in computer science is *shared memory*. Here, two processes agree on having a piece of their state shared in order to synchronize communication between them.

### Advantages of the shared memory model

- Less latency due to reduction of idle time as data doesn't have to be placed in the blockchain's blocks.
- Faster read access to existing state of anther chain
- Cache friendlieness -> not sure whether this is relevant for blockchains though

### Disadvantages of shared memory
- Might require some synchronization primitives. Probably embedded in the DA feature set though.


## The future of IBC

blas:
I envision a future where both paradigms will co-exist. IBC through message passing assumes nothing over the data availability layer. However, seems reasonable to think that DA providers will optimize the layer considerable and more chains will off-load that element over to them. 

Perhaps, at some point Composable could setup an R&D team to explore the limits of this approach and see whether it's possible to have two dummy chains commuincating with each other using IBC through shared state.

@brainjar maybe wants to take the mic here