At @lifiprotocol, we often talk about the need for bridges to be "trustless" or trust minimized.
Today, we attempt to define & measure the level of "trust" required by various bridge designs.
And what we found is that, with bridges, trust is a spectrum.
blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8
1/ What is a Trustless System?
A trustless system is one that does not depend on external actors to facilitate transactions from point A to B.
However, this is a very simple definition.
On a technical level, it is much more nuanced 👇
2/ .@jadler0 and @badcryptobitch say:
“A blockchain system is trustless if and only if its state is (i.e., all its state elements are) both live and safe.”
Let’s dig deeper into this explanation.
3/ Here, we need to know 2 properties:
• Safety — User funds can’t be stolen & they can’t be locked up forever. Only the owner can update the state (ex: move the funds)
• Liveness — As of some bounded time, the owner of the state (ex: funds) will be able to move/transfer it
4/ Thus, a trustless system can preserve both the safety and the liveness of its state.
This means trustless bridges are those where:
1. user funds are never lost (never stolen or locked forever)
2. users (owners of the state) can move/redeem their funds after a fixed period
5/ Also, bridges can be effectively trustless if their security is higher than the two blockchains it’s connecting.
However, this is impractical due to the significant capital required to secure such a system.
6/ Now that we have created a baseline understanding of trustless systems, let’s take a look at why and where trust is introduced into bridge designs.
From there, we will then dive into the trust spectrum of bridges.
7/ The Root of Trust in Bridges
With the help of examples, let’s try to narrow down where trust is introduced in bridge design.
A completely trustless cross-chain transaction would be — Alice on Blockchain A sends $1000 to her wallet address on Blockchain B.
8/ This is ideal, but it is not possible since blockchains cannot communicate between themselves.
Another way to do it is by swapping funds with a user on Blockchain B.
Example — Alice sends $1000 to Bob on Blockchain A. In return, Bob sends $1000 to Alice on Blockchain B.
9/ Theoretically, two users interested in transacting with one another can do so directly.
But in reality, this has many constraints:
1. Alice has to trust that Bob will send the funds
2. What if Alice cannot find someone like Bob who is interested in such a swap every time?
10/ While constraint #1 can be addressed via smart contracts, this method is not scalable because of constraint #2.
To address constraint #2, we introduce bridges between blockchains that act as the ‘man-in-the-middle’
This makes communication between them possible.
11/ To overcome the communication & trust boundaries b/w blockchains, some bridges use off-chain actors or validators.
These validators responsible for verifying the system are the root of trust in bridges.
They introduce new trust assumptions unique to the validator set.
12/ However, and this is hopefully the future of the cross-chain ecosystem, some bridge designs don’t need to add their own validators in the middle.
Instead, they use the blockchains and their respective validator sets to make bridging possible.
13/ For instance, light client bridges like @cosmosibc or liquidity networks like @ConnextNetwork do not add trust assumptions to the system.
Therefore, the root of trust remains on the blockchains associated with the cross-chain transfer.
14/ Trustlessness in bridges does not exist in an absolute form.
If trusted and trustless were two extremes, most bridges would lie somewhere in between.
15/ When it comes to trustlessness in bridges, the main question is: who is verifying the system?
This has been explained in detail by @arjunbhuptani in the interoperability trilemma.
Read more 👇
blog.connext.network/the-interoperability-trilemma-657c2cf69f17
16/ By answering this, trust as a spectrum in bridges comes to:
• External validators and federations — Externally Verified
• Optimistic bridges — Optimistically Verified
• Liquidity networks — Locally Verified
• Light clients and relays + ZK Bridges — Natively Verified
17/ Code has no trust assumptions; only humans do.
Here’s a graphic showing where each bridge design falls in the trust spectrum.
18/ From the left (trust the human) to the right (trust the code), the systems become more trust minimized.
They remove the need for users to rely on humans and either distribute it across the system or replace it with code.
19/ To learn more about how these different systems function and why one is more/less trust minimized than the other, check out the blog!
Also, read in detail about:
• Trustless systems
• Root of trust in bridges
• Comparison b/w bridge designs
blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8
Shoutout to our researchers @arjunnchand & @mark_murdock3 for their work!
Huge thanks to @pranaymohan for the insightful feedback 😄
If you liked reading our research, please follow @lifiprotocol and like/RT/QT the first tweet.
Want to keep up with the latest cross-chain news? Join us over on Telegram.
t.me/lifinews