Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed changes #109

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
+15 −6
Open

Proposed changes #109

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5d0392d
proposed changes to what-is-a-bridge in docs
hadasz Jun 8, 2023
41006ac
proposed changes to bridge explanation
hadasz Jun 26, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 15 additions & 6 deletions docs/concepts/background/what-is-a-bridge.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
---
\65;6800;1c---
sidebar_position: 1
id: "what-is-a-bridge"
---
Expand All @@ -20,19 +20,28 @@ While there are many bridges out there today, every bridge has the same core str

### Transport

Transport is how a payload of data gets read from one domain and posted to another, making no assumptions about the correctness of the data.
The transport layer sends a message from the origin blockchain to the destination blockchain.

To describe it in terms of more traditional systems, imagine that you are maintaining a database that collects data from an external API such as google maps or the washington post. To do this, you will poll the external databse periodically (say every few seconds) and post any changes to your internal database. In the transport layer of a bridge, a node on the destination chain acts as the application that is collecting data. They collect data by periodically checking the origin chain for new queued transactions, and pulling the new data and then "storing" it on the destination chain.

This is typically done by one or many offchain actors that watch an *outbox* of data on the origin chain, and then post the corresponding data to an *inbox* on a connected destination domain. To keep this process scalable, protocols will typically relay merkle roots rather than data in raw form.
Typically, this is done by actors that are running nodes on both chains.

### Verification

Verification is how crosschain communication is *secured*. After a payload is transported across chains, a bridge will verify the data prior to it becoming usable on the destination domain.
The verification layer is the trickiest layer to both describe and design. While it is fairly straightforward to poll an origin chain for new data and then post it to a destination chain, it is not at all simple to verify that the polled data is actually correct. The problem is that in many cases, both the origin chain and the destination chain are decentralized networks, and therefore the claim of a signular node is not trustworthy.

To understand this better, we will use a non-technical analogy.
Imagine that there are two communities of people, community A and community B. Each community has a history spanning thousands of years, and in those thousands of years they have developed a strong folklore, mythology, and set of shared values and truths. However, they have never written these things down on a shared document.

Now a member of community B wants to know something about an event that occured in community A's past. So they travel to where community A lives, befriend somebody and ask them about that event. Can the person from community B trust the person from community A to tell the truth?

A good verification layer needs to figure out how to find out the truth from a collection of independent parties who are not necessarily trustworthy. Unfortunately, in the case of bridging, the person from community A will be highly incentivized to lie. Obviously, the more people you ask, the easier it is to know what is true and what is not. But asking too many people will take too long, so there is an inherent tradeoff between scalability and security.

There are many different ways to verify messages across domains, each with their own tradeoffs on trust, cost, and latency. See Message Verification for a longer discussion about this step.
Connext masterfully sidesteps this issue by using game-theoretic techniques that switch the incentive structure so that nodes on the origin chain are incentivized to tell the truth, and other nodes are incentivized to report bad behavior. See Message Verification for a longer discussion about this step.

### Execution

Once a verified payload is available on the destination, some offchain infrastructure is needed to "push" that payload into a target function.
One a message as been sent to the destination chain and verified, it needs to be processed by a smart contract on the destination chain, that is specified in the meta-data of the transaction. This happens in the execution layer.

Bridge execution layers are the interface that developers will typically interact with when integrating with a bridge. Execution layers collect gas fees (in Connext, this is collected as additional gas paid on the origin chain) and use those fees to execute a transaction on the destination chain against the target function the developer intends to interact with.

Expand Down