top of page

FLAREPEDIA

LayerCake Bridges

LB

LayerCake Bridges

Terminology

LB

average rating is 3 out of 5

No Ratings

-

Developer

-

1018

Views

1 year ago

Last Updated

Network

LayerCake is a smart contract, layer one consensus bridging application built using theState Connector protocol. LayerCake bridges connect two non-Flare layer one blockchains with transactions being secured by Flare Network. They also connect Flare Network with other smart contract, layer one blockchains to facilitate value transfer back and forth. LayerCake bridges utilize short duration collateral lockups to allow value to transfer between layer one blockchains and protect against reorganization attacks on either chain. LayerCake bridges only facilitate value transfer between an origination chain and one destination chain. This is because each additional destination chain added brings in more complexity and risk to the bridge transactions. For example, LayerCake bridges would facilitate a transfer of ETH from Ethereum to Solana, but not a transfer of Solana issued ETH to the Terra blockchain. LayerCake bridges aim to be as secure and non-custodial as possible. 


The two most common implementations of cross-chain bridges today utilize either multi-signature or light client relay schemes to accommodate value transfer between two blockchains. These bridges do not offer the same fundamental safety guarantees as the layer one blockchains that they facilitate value transfer for. Multi-signature bridges essentially custody user funds between a group of counterparties ranging from single to double digits. This bridge construction opens technical and regulatory attack vectors as they are not decentralized and open to social engineering attacks. Light client relay bridges often require a large code base which can make them cumbersome and removes the full richness of properties available through layer one blockchain consensus. 


LayerCake bridges also can be a solution to the anti-network effect problem, which theorizes that the more users and value a system has the less useful it becomes due to an increasing risk of hacking. LayerCake aims to solve this problem by utilizing the State Connector protocol, which relays state between connected chains without deteriorating the safety guarantees of those connected chains. The State Connector can validate and propagate state proofs between connected chains while being protected against safety and liveness attacks on the connected chains. 

Introduction

There are two implementations for LayerCake bridges. The first is through connecting two smart contract blockchains with reorganization attacks being secured against via Flare Network. The second allows Flare Network to transfer value to other smart contract blockchains and to itself from those connected chains. LayerCake bridges are a product for users of Flare Network and the broader smart contract blockchain communities.

Implementations

Aside from the user, LayerCake bridges have two main parties participating in it called bandwidth providers and admins. Bandwidth providers post collateral for the assets being transferred from an origination chain to a destination chain. They also post Spark (FLR) tokens as collateral on Flare Network to protect against reorganization and liveness attacks for a pre-defined period. Collateral posted on the origination chain or Flare is only locked for a short duration, which after passing allows the collateral to be used for other value transfers. It is important to note that the collateral posted at any given time across all bandwidth providers only represents the current rate at which value can be transferred but not the total value transferred across the bridges. Admins sole-responsibility is to bench faulty bandwidth providers that have either incorrectly minted or unlocked value on an origination or destination chain.

Parties

Mint Flow example for a LayerCake bridge connecting Ethereum and Solana:

  1. User deposits 1 ETH into LayerCake smart contract on Ethereum plus a fee.
  2. Bandwidth collateral reserved on Ethereum for short duration.
  3. State Connector observes the deposits.
  4. Bandwidth collateral reserved on Flare Network.
  5. Bandwidth providers mint 1 Solana ETH (sETH) and deliver to user address.
  6. State Connector observes sETH mint.
  7. Bandwidth collateral unlocks on Flare Network after enough layer one confirmations.

Redeem Flow example for a LayerCake bridge connecting Ethereum and Solana:

  1. User returns 1 sETH to burn contract on Solana plus a fee.
  2. Bandwidth collateral reserved on Ethereum for short duration.
  3. State Connector observes the deposits.
  4. Bandwidth collateral reserved on Flare Network.
  5. Bandwidth providers unlock 1 ETH on Ethereum and deliver to user address.
  6. State Connector observes unlock of ETH.
  7. Bandwidth collateral unlocks onFlare Network after enough layer one confirmations.

Layer One Chain attack example for a LayerCake bridge connecting Ethereum and Solana:

  1. User deposits 1 ETH into LayerCake smart contract on Ethereum plus a fee.
  2. Bandwidth collateral reserved on Ethereum for short duration.
  3. State Connector observes the deposits.
  4. Bandwidth collateral reserved on Flare Network.
  5. Bandwidth providers mint 1 Solana ETH (sETH) and deliver to user address.
  6. State Connector observes sETH mint.
  7. Ethereum suffers 51% attack and user’s ETH returns to them.
  8. State Connector observes the reorganization on Ethereum.
  9. Bandwidth collateral on Flare Network provides backing for user’s share in sETH pool.

Mint, Redeem, and Security Flows

LayerCake is a proposed solution for the anti-network effect problem of layer one, cross-chain bridges. The protocol only requires collateral for value being transferred across the bridge and not the total value that has crossed the bridge. It is designed to withstand any safety and liveness attacks on connected chains as well as fault bandwidth providers who incorrectly mint or unlock value. Please see the official documents and blogs for more information on how the bridge works, the underlying protocols, and parties involved.

Conclusion

-

Introduction

Implementations

Parties

Mint, Redeem, and Security Flows

Conclusion

CONTENTS

-

-

RATINGS

-

SOCIALS

-

LINKS

Introduction

bottom of page