How Do Optimistic Bridges Work? — Deep Dive Into Pheasant Network’s Mechanism

*This blog is a transcription of the December 2022 Pheasant blog here.

This is the second article of the Pheasant Network introduction series. Click here to read the first post.

2022 saw an explosion of Layer 2 technology despite the market downtown. Thanks to the dedicated engineers working on Layer 2 projects, the scalability issue, which used to be one of the main criticisms from blockchain opponents, is becoming yesterday’s problem. We, Pheasant Network, believe optimistic bridges have the potential to offer the most cost-efficient and secure way to boost scalability out of other Layer 2 solutions.

To help you learn the benefits of optimistic bridges, this post, a sequel to What are optimistic bridges? — Overview and what they offer, will cover how optimistic bridges work, citing Pheasant Network as an example. Let’s dive in!

🏁 Goal: Understanding how optimistic bridges and Pheasant Network work

👦 Target: Beginner to intermediate

📖 Summary:

• Pheasant Network’s top features include 1) higher security and resilience, 2) lower gas fees and faster transactions and 3) compartmentalized architecture to minimize risks.
• Optimistic bridges like Pheasant Network usually require three crucial parties: user, relayer and disputer.
• Pheasant Network uses different mechanisms for transactions from Layer 2 to Layer 1 and from Layer 1 to Layer 2. This architecture results in a significant reduction in gas costs.

Higher security and resilience

We have already seen lots of bridge exploitations in the history of blockchain technology. What might be surprising is that in most cases, it takes the hacker only a single attack to snatch all of the protocol’s assets because most bridges employ a design that aggregates and keeps all of the tokens in one pool. This means that once malicious hackers find a way to access the pool in some way, they gain access to all of the assets and can easily exploit the entire pool, which makes bridges a juicy target for them. In addition, bridges with this “one-pool” design lead to lower resilience. It usually takes a long time to recover once they are hacked as the protocol loses all of its reserves, leading to a frustrating user experience.

Pheasant Network aims to solve this problem by making each relayer create an independent liquidity pool and protect and manage the liquidity in it with their own private keys so the network can prevent all the assets from being centralized in a single pool. This means that even if one of the relayers’ pools is compromised by a bad actor, the rest of the pools and protocol will keep operating as if nothing happened, and the network is safe from losing all of the assets. Furthermore, thanks to this system, even in the event of hacks there’s no need to halt the entire protocol.

Another safety feature unique to Pheasant’s bridge design is an actor named disputer, who monitors transactions and alerts the system when finding suspicious behaviors. Disputers discourage relayers from acting maliciously as relayers get slashed if disputers find a questionable transaction and can prove the invalidity of it. An optimistic bridge like Pheasant Network could not function without them.

At Pheasant Network, in the future, anyone can be a disputer including users. Users are often the first to spot any fraudulent-looking behavior since they can easily notice the absence of the sent assets in their address on the destination chain if a relayer steals the tokens and refuses to send them over. In addition to users, third parties can also serve as a disputer, preventing relayers from swindling and providing higher security and more resilience.

Lower gas fees and faster transactions

To achieve the aforementioned decentralized liquidity provision, Pheasant Network has chosen an optimistic approach as a communication method. In optimistic verification mechanisms, the protocol verifies transactions only when a suspicious transaction is found, resulting in lower calculation costs. This is much cheaper than burn-and-mint bridges, where they need to verify every burning transaction.

Compartmentalized architecture to minimize risks

When users transfer tokens via burn-and-mint bridges, the value of wrapped tokens on the destination chain is collateralised by the tokens deposited on the origin chain. This means exploitation of the collateral on the origin chain could affect the value of the wrapped tokens on the target chain. Moreover, a transaction rollback, whether a burn or mint transaction, could cause a disrupting discrepancy in the total amount of tokens between the origin and target chain.

On the other hand, optimistic bridges like Pheasant Network, which do not adopt the “burn-and-mint” approach, are free from such intertwined disruptions, mitigating the risk of exploitation on one chain affecting the other. Although it is still possible for some bridging transactions to fail when a rollback occurs, Pheasant’s model hugely minimizes the overall effect on the whole ecosystem due to the compartmentalized structure.

As mentioned above, optimistic approaches offer safety and efficiency advantages over the burn-and-mint design. But how does it actually work? Now, let’s dive into how Pheasant Network achieves its advantages.

Three network participants

Pheasant Network consists of three participants — user, relayer and disputer.

• User: a participant who wishes to transfer tokens from one network to another through the bridge (e.g. send ETH on Optimism to Arbitrum)
• Relayer: an actor who accommodates users’ requests to transfer assets from an origin chain to a destination chain (e.g. send ETH on Arbitrum to a user and receive their ETH on Optimism)
• Disputer: a party who flags the system when noticing a suspicious action on the network and challenges the transaction’s validity. Anyone can be a disputer including users. They need to object to the relayer within a dispute period of about 51 min when they catch a dubious transaction since Ethereum’s BLOCKHASH opcode limitation only allows verification for transactions in the last 256 blocks at this time, and they might fail to spot invalid transactions. (e.g. question a relayer when a user has yet to receive their asset on a destination chain after a certain period, detect an invalid transactional data registered with BridgeChildContract) However, the BLOCKHASH opcode limitation is now being resolved.

Depending on which way assets are transferred, Pheasant Network employs two different communication mechanisms.

L2 > L1 and L2 > L2

Default

1. A relayer deposits liquidity to the BondManager contract (Layer2 Bridge Contract).
2. A user sends assets they want to transfer to the PheasantNetworkBridgeChild contract deployed on the source chain and submits a request to relayers.
3. The relayer directly send asset to the user address on destination chain.
4. The relayer generates proof of the directly transferred assets from its transactional hash and registers it with the PheasantNetworkBridgeChild contract. This proof enables the relayer to withdraw the assets deposited by the user.

In the event of fraud

1. A disputer triggers a verification process by pointing out a relayer’s misbehavior. The disputer needs to deposit a certain amount of assets to initiate a challenge period.
2. The relayer submits evidence to vindicate themselves within a designated period of time after the disputer’s claim.
3. If the evidence proves the relayer’s legitimacy, meaning if the disputer’s claim was false, the assets locked by the disputer will be confiscated as a punishment and sent to the relayer.
4. If the evidence does not clear the relayer, or they are unable to submit evidence within the designated period of time, the disputer will be able to slash the relayer’s bond and reclaim the locked assets.

Click here to see the Sequence Diagram.

L1 > L2

Pheasant Network has chosen a different mechanism for L1-to-L2 transfers from the L2-to-L1 design, which comes with a tradeoff of minor complexity because the L2-to-L1 model is not cost-effective enough for token transfers from Layer 1 to Layer 2 from the users’ perspective as it requires an escrow contract on Layer 1.

Default

1. A relayer deposits liquidity to the BondManager contract (Layer2 Bridge Contract).
2. A user sends assets directly to relayer’s EOA on Layer 1, which triggers the bridging process.
3. The relayer generates proof of the transaction made in 1 from its transactional hash and registers it and send asset through the PheasantNetworkBridgeChild contract.

In the event of fraud

Unlike processing from Layer 2 to Layer 1, in the case of processing from Layer 1 to Layer 2, if the relayer does not send assets to the user on Layer 2 after a certain period of time has elapsed since the user sent assets to the relayer, it is possible to execute a slash.

Click here to see the Sequence Diagram.

In the current implementation, the disputing process is executed by the disputer-service client, which detects suspicious transactions and compares the submitted proof to the actual transaction. The disputing process follows the steps below.

1. Examine the blockhash included in the submitted proof, comparing it to the blockhash acquired from BLOCKHASH opcode.
2. Check the validity of the data included in the proof and see if it is possible to get the blockhash from the registered transactional data.

After the verification process, if the disputer proves itself valid, the dishonest relayer will be slashed and the user’s compensation will be paid from the relayer’s bond, with the disputer receiving a reward for catching the malicious behavior.

Safe and Decentralized

The compartmentalized architecture and optimistic approach are the keys to Pheasant Network’s decentralized liquidity and safer, faster and more stable token transfers. We hope this article helps deepen your understanding of our network and optimistic bridges.

To achieve further decentralization, we would love your participation in the project. If you have any questions or suggestions, feel free to contact us via Twitter and Discord.

Pheasant Network offers an optimistic interoperability protocol designed to unify Layer 2 infrastructures with a comprehensive suite of solutions. Our optimistic Bridge-as-a-Service (BaaS) allows developers to seamlessly integrate native bridges and swap functionalities into their applications. A community-driven project, we focus on contributing long-term value to the Ethereum ecosystem and serving the public good.

Home | Website | Docs | Blog | GitHub | X | Discord | Telegram | L2 Learn