The Flyover protocol
By Javier Alvarez Cid-Fuentes & Sergio Demian Lerner
The RSK Powpeg is the bridging system that allows bitcoins to flow between the Bitcoin network and RSK. Transferring bitcoins from the Bitcoin network to RSK is usually called peg-in, while transferring bitcoins in the opposite direction is called peg-out. Peg-ins require the user to send bitcoins (BTC) to a special multi-signature address, while peg-outs require users to send smart bitcoins (RBTC) to a smart contract in RSK. Since both processes are final and cannot be reverted, the Powpeg requires 100 Bitcoin block confirmations for peg-ins and 4,000 RSK block confirmations (approximately 200 Bitcoin confirmations) for peg-outs. This is around 16 and 33 hours respectively.
In 2020, the Research and Innovation team at IOV Labs was challenged to find ways to reduce the peg time to improve usability. After months of research, we found a unique solution: the SyncChain. A Bitcoin SyncChain differs from a regular sidechain in that it requires running a Bitcoin node. This involved radical changes to RSK’s consensus code, which can be risky. For this reason, we began exploring other possible solutions, and came up with the Flyover protocol. The Flyover protocol is an add-on to the current RSK Powpeg that allows fast and trustless peg-ins and peg-outs.
In the Flyover protocol, a third party takes the risk to advance the payment in BTC or RBTC for the user. The Flyover protocol also enables transferring BTC directly to a smart contract in RSK. The outstanding feature of the Flyover protocol is that the funds are never in custody of a third party during the transfer. This is a unique security guarantee that protects the user and may be highly beneficial to the regulatory framing of the third party involvement.
The Flyover protocol
The main goal of the Flyover protocol is to accelerate the peg-in and peg-out processes between Bitcoin and RSK. In the case of peg-ins, the Flyover protocol can be used even by first-time users that do not have RBTC on their accounts to pay for gas. The Flyover protocol consists of one or more liquidity providers (LPs) that store their bitcoins in RSK and BTC. LPs are for-profit entities that provide advance payments in RSK and Bitcoin on behalf of users. LPs can be unidirectional or bidirectional, and offer their service in exchange for a fee. This fee is based on a controlled risk on the probability of a double-spend. The shorter the peg advancement time, the higher the risk. The way peg-ins and peg-outs are enacted differ. While peg-ins require an off-chain interaction between the user wallet and the LP, the fast peg-out process can be executed without such interaction. In this article, we will focus on peg-ins as peg-outs are still a work in progress.
LPs can serve their own user base, or they can register themselves into a decentralized smart-contract to compete in an open marketplace. An example of the former is a mobile wallet where the wallet software provider offers the Flyover system to their users, and acts as the default LP for their user base. An example of the latter are companies or individuals (that we call public LPs) that want to serve users through open-source desktop software. Any application can interact with public LPs using the open protocols of the LP marketplace.
In order to provide fast peg-ins, LPs must register in a Liquidity Bridge Contract (LBC) in RSK. As part of this registration, LPs deposit some collateral that can be slashed if they misbehave.
Peg-in workflow
The peg-in process begins with the user asking their wallet software to send an amount of BTC to RSK, or to make a call to a smart contract in RSK using BTC. Note that, at transaction level, these two actions are equivalent. The wallet software then contacts one or more LPs to get a quote for their service. In this off-chain interaction, the wallet sends to the LP the information about the call (i.e, contract or account address, contract arguments, value, and gas limit), and specifies two refund addresses (Bitcoin and RSK) that are used if the call is unsuccessful. The LP responds with a quote for the service that includes the amount of time that the user has to make a deposit in BTC, the number of confirmations required to accept this deposit, the amount of time that the LP has to make the call, and the service fee, and the penalty fee in case of misbehavior. If the user accepts, the LP signs the quote and provides the user with a special Bitcoin deposit address. The signature ties the LP to the quote and can be used as a proof in case of misbehavior. The deposit address is derived from the parameters that represent the service quote and is controlled by the RSK Powpeg.
The user then has a limited amount of time to make a deposit to the derived address. After this time, the quote expires and the LP cannot be penalized for not delivering the service. The user needs to deposit an amount of BTC greater or equal to the value that he wants to transfer to RSK plus the service fee. Once the deposit achieves the agreed number of block confirmations, the LP calls the Liquidity Bridge Contract’s callForUser function. This function registers the LP as the caller for this particular service, and makes the call on behalf of the user. The following sequence diagram illustrates the whole process.
At this point, the LP has advanced some value for the user in the form of a contract call or a direct transfer. To recover the advanced funds, the LP calls the LBC’s registerPegIn function. This function calls the native Bridge contract on RSK to retrieve the amount of RBTC deposited by the user in BTC. The LBC assigns the corresponding amount of RBTC to the LP and transfers any remaining RBTC to the RSK refund address specified by the user. Note that the Bridge requires the usual amount of 100 confirmations on the BTC deposit before paying the LBC. The following diagram shows the interactions between LP, LBC and Bridge contract during the peg-in.
In case the LP does not deliver the service, the user can still recover his funds through the LBC after the regular amount of confirmations required by the Bridge contract (i.e., 100). To achieve this, the user or any other entity (e.g., another LP) can present the signed quote of the service to the LBC as a proof of misbehavior. The LBC then slashes the collateral of the misbehaving LP, and pays the user the corresponding amount of RBTC. This means that in the worst case, the Flyover protocol reverts to a regular Powpeg peg-in, and that the user is not at risk of losing funds.
The Flyover protocol provides faster transfers while maintaining the same liveness guarantees as the Powpeg. The following diagram shows the peg-in process in the event of the LP misbehaving.
Finally, the Flyover protocol also contemplates various scenarios that deviate from the typical peg-in workflow. In the following we describe these scenarios and how the Flyover protocol handles them.
The LP does not call callForUser on time (or does not call it at all)
The user (or anyone) can call the LBC’s registerPegIn function after 100 block confirmations on the BTC deposit to get fully refunded at the specified RSK refund address. The LBC penalizes the LP by slashing part of its collateral.
The user does not make the BTC deposit on the agreed time
The LP might decide to abort the process without being penalized. In this case, the user (or anyone) can call the LBC’s registerPegIn function to get fully refunded after 100 block confirmations at the specified RSK refund address.
The call on behalf of the user fails
The registerPegIn function of the LBC pays the service fee to the LP but refunds the rest of the RBTC to the user’s RSK refund address.
The BTC deposit causes the Powpeg to exceed its locking cap
The locking cap is the limit of BTC that the Powpeg is allowed to control at a given time. If the user deposit causes the Powpeg to exceed this locking cap, the process is the same as in a regular peg-in but the Bridge refunds either the user or the LP to their Bitcoin addresses.
Conclusion
The Flyover protocol reduces the amount of time required to transfer bitcoins between the Bitcoin and the RSK networks by introducing a trustless intermediary. This intermediary, or liquidity provider, takes up the risk of advancing the funds for the user.
In addition, the Flyover protocol allows users to make smart contract calls on RSK without the need for RBTC. The Flyover design incentivizes liquidity providers to behave by means of collateral, and provides the same security guarantees as the Powpeg. In the worst case, the Flyover protocol falls back to a regular Powpeg transfer, thus ensuring that users are never at risk of losing their funds.
