FAQ
What are the system requirements for the canonical website?
The Pheasant Network's canonical website defines the following system requirements. Please note that operation is not guaranteed in other environments.
OS: macOS, iOS
Browser: Google Chrome
Wallet: MetaMask
What are the risks that you are aware of at this time?
Pheasant Network is deeply committed to decentralization, and our development team is continuously working to advance this goal. However, we recognize the importance and necessity of temporarily providing trusted functions as the network evolves towards full security and decentralization. This approach allows us to prioritize contributions to the ecosystem while ensuring gradual progress towards a robust and decentralized network.
The following are the current risks regarding the decentralization model and code that the Pheasant team is aware of, which will be addressed as development progresses:
Trusted Relayer / Single point of failure
Users currently have to trust the Pheasant development team to act honestly since they are the only relayer.
If any issues or problems arise with the relayer role operated by the Pheasant team, it can lead to transaction delays or disruptions since there is only one relayer.
Non-slashable networks
In certain Layer 2 networks, the communication function between Layer 1 and Layer 2 is not accessible to external parties, making it impossible for the Pheasant team to incorporate the slashing mechanism into the bridge protocol. Additionally, integrating the slashing mechanism into bridges may be challenging from a capital efficiency perspective, even when it’s technically feasible.
Arbitrary Deactivation Function
The bridges are equipped with a function to deactivate contracts in response to external threats such as hacks. The execution of this function is at the discretion of the development team.
Additionally, contract hacks could potentially lead to the exploitation of pending trades and deposits made by relayers. That said, we consider the potential damage to be relatively minor, especially when compared to other liquidity-based bridges. This is primarily due to our unique mechanism, intentionally designed to minimize overall network damage. For more detailed technical specifications, please refer to the ‘Technical Details’ section.
Do you have a roadmap for project development?
These are not commitments to a project roadmap. We will always repeat the best development process, taking into account various factors. If you have any proposals or feature improvement requests, please submit them using Discord.
Adding More Networks
As the popularity of Layer 2 solutions continues to grow, our platform has plans to incorporate more networks. The selection criteria for supporting these networks include the following factors:
Network Specifications: Whether the specifications and technical details of the network have been clearly established.
Ecosystem Vitality: Whether the network's ecosystem is thriving and demonstrating active growth.
Synergy with Pheasant Network: Whether the integration of the network creates synergy and fosters mutually beneficial interactions with the Pheasant Network.
Support for ERC-20 Tokens
Pheasant Network has plans to support ERC-20 tokens in addition to ETH.
In order to expand the ecosystem with more tokens, liquidity needs to be provided by relayers. However, relying solely on the Pheasant development team to provide liquidity for multiple different tokens may not be feasible.
If you have a token that you would like to see added, you have the opportunity to become a relayer yourself. If your project issues a token and you wish for Pheasant Network to support it, please reach out to us through Twitter or Discord. We are pleased to explore the possibility of integrating and supporting your token.
Bridges Between Layer 2s and the Dispute Process
We are planning to develop bridges between Layer 2 networks independently for each supported network. However, we are facing a challenge in implementing a decentralized slashing mechanism. This challenge arises from the absence of established standards for trustless communication between Ethereum's Layer 2 networks.
There are two types of messaging methods used for bridges: trusted and trustless. Trusted methods rely on external validators, such as multi-party computation (MPC) protocols, multisig wallets, or oracles, to facilitate communication. On the other hand, trustless approaches solely utilize the internal systems of blockchains, without relying on intermediaries. (Reference: Ethereum.org)
Pheasant Network places a high priority on decentralization in the medium to long term, which is why we have chosen to develop fully trustless bridges instead of relying on external validators for communication. While trusted methods have been established and utilized in various protocols, they do not align with our decentralized approach.
One potential avenue to achieve trustless messaging is by leveraging the existing trustless communication system between Layer 1 and Layer 2. This involves transmitting data from Layer 2 to Layer 1 and then forwarding it to another Layer 2 network, thereby enabling the connection of two Layer 2 networks through Layer 1. However, this approach comes with significant costs and time implications, which render it impractical considering the expected scale of Layer 2 networks in the future.
Given these considerations, Pheasant Network has concluded that implementing the slashing mechanism for bridges connecting two Layer 2 networks is currently not practical. However, we are actively exploring the potential implementation of a communication protocol between Layer 2 networks, utilizing information recorded on Layer 1 to enable trustless slashing for intra-Layer-2 transactions.
Dispute Against a Transaction More Than 256 Blocks Ago
On Pheasant Network, the specifications regarding blockhashes play a crucial role as they are essential for verifying challenged transactions, which is an integral process that ensures the security of the protocol.
Currently, Ethereum's smart contracts only allow users to obtain blockhashes for the last 256 blocks. This limitation restricts the timeframe within which disputers can challenge and slash the bond of a bad relayer to protect their assets from malicious actors. In other words, disputers need to challenge a suspicious transaction before the 256th block is appended.
However, there are services being developed to tackle this limitation. The Pheasant team is actively considering the possibility of incorporating such services to extend the timeframe within which disputers can raise challenges. This would provide a longer window for disputing fraudulent transactions on the network and slashing the bond.
Opening Up Relayer Role to Third Parties
Currently, the Pheasant Network development team serves as the only relayer, as we are still in the process of bootstrapping the relayer role. However, we are actively working towards decentralizing the relayer role. Simultaneously, we also plan to expand the involvement of third parties in the disputer role.
As the protocol evolves to support multiple relayers, the relayer functionality will be integrated into the client provided by the Pheasant team. The protocol will closely monitor the key metrics of the integrated relayers, and any significant changes will be communicated to users through announcements.
Is it possible to execute contracts directly?
For transactions from Layer 2 to Layer 1, it is indeed possible to execute contracts directly. However, the same cannot be done for transactions from Layer 1 to Layer 2. This is because specific code would need to be embedded in a relayer's EOA. If an invalid transaction is sent, relayers would be unable to respond to it, rendering the slashing mechanism ineffective.
Can I use a contract address and contract wallet?
Currently, you can only send tokens using an EOA and not a contract address or contract wallet.
Are there any limitations on the disputing process?
Due to the constraints of EVM opcodes, only transactions stored within the latest 256 blocks can be disputed at this time. This means that a disputer can only challenge a transaction within approximately one hour after its execution.
The incentive for disputers to challenge a suspicious transaction is the reward they receive for exposing malicious behavior. However, if the gas fees required for the disputing process exceed the reward amount, disputers might choose not to raise a dispute, deeming it not worth the effort.
How does the protocol decide the amount of a bond?
Relayers are required to deposit a certain percentage of the remittance amount as a bond on top of the original amount a user wishes to send. This bond serves as a security measure and will be slashed and shared between the disputer and user in case of fraudulent activity. However, it is worth noting that if the total amount transferred by a relayer exceeds their bond amount due to a large influx of transfer requests, there is a possibility for the relayer to exploit the situation and profit despite the slash. To address this, we are planning to implement measures on the client to prevent such occurrences.
Why was my transaction canceled halfway by the relayer?
In some cases, relayers might choose to revert and cancel a transaction midway to protect the user from a front-running attack executed by a malicious actor. These attacks could potentially occur under specific circumstances and timings. When the transaction is canceled at the discretion of relayers, the assets will be returned to the user.
Last updated