RSK “Iris” Network Upgrade is Coming
The Iris network upgrade is coming to RSK in the near future. The RSKIPs that will be included have been discussed by the RSK community and, apart from one RSKIP whose addition still depends on code readiness, no further change will occur. You can check the meta-RSKIP here. Meanwhile, the RSKj development team is improving integration tests and security audits are ongoing. Soon, the deployment and activation dates will be defined.
In this blog post, I will explain which changes, in my opinion, are the most interesting features that will provide immediate benefits to RSK users.
Powpeg and the Time-locked Emergency Multisignature
For many years, the federated model for securing the two-way-peg of a sidechain was generally considered the model that provided the highest possible security without requiring a Bitcoin hard fork. All other potential solutions, involving SNARK proofs, or SPV-proofs, or fraud-proofs, or drivechains, require soft-forking Bitcoin. However, RSK uses a two-way-peg technology that is far more secure than the standard multi-signature protocol. In most existing federations, each one of the functionaries of an elected group, runs a node in a server computer to maintain one of the multisig private keys. These keys are held in hot storage, because peg-in and peg-out processes are automated. But since 2018, RSK uses HSMs, hardware devices exclusively dedicated to protect the private keys against external attackers and even from malicious functionaries.
In December 2020, RSK advanced the state-of-the-art of two-way-pegs’ security by introducing the Powpeg. The Powpeg is an evolution of a federated system where the HSMs (now called PowHSMs) run the blockchain validation part of an RSK node, in SPV mode. This means that the PowHSM validates the proof-of-work of the RSK blockchain, and it cannot be tricked into signing a peg-out transaction if the peg-out commands were not originated in the consensus of the RSK blockchain, which has the highest proof-of-work. So even if all pegnatories (the term we use for the functionaries in the PowPeg) turn malicious and try to steal the private keys, or sign peg-out transactions that benefit them, they can’t do it, under reasonable assumptions that the HSMs were not tampered with in a supply-chain attack.
In a Powpeg, the pegnatories have almost no power over the bitcoin funds. However, if the majority of pegnatories decide to (or are forced to) turn off their PowHSM devices, then the bitcoins will be locked forever. Also, if for any reason, all the hardware devices get bricked, there is currently no recourse to recover the funds in the peg. That is why, starting from Iris, the scriptPub contains a subscript which represents a time-locked emergency signature, specified in RSKIP201. The time-lock expires after one year of complete inactivity of the UTXO, and UTXOs are periodically renewed, extending the timelock. The renewal protocol is defined in RSKIP207.
The Liquid sidechain already has a similar system, but with much shorter times, which may encourage DoS-attacks from the emergency multisig owners to steal the bitcoins. Due to the very long time-lock in RSK, this risk in RSK is almost negligible.
The new scriptPub looks like this:
You can read more information about the powpeg here.
Two-way-peg Bridge Improvements
Iris brings 3 major improvements to the Two-way peg Bridge with Bitcoin. The first is that it will be possible to perform a peg-in from Bitcoin to any RSK address. Currently a user can only peg-in to RSK addresses that are under their control (you cannot use the peg-in process to perform a payment to an RSK address that does not belong to you). After the activation of Iris, the possibility to send payments to other users over the bridge will be enabled (RSKIP-170). There is only one important distinction: currently the pegnatories help all users by working as watch towers and submitting the peg-in information to the RSK bridge smart contract for processing. In the future, pegnatories may choose not to provide the watchtower service for payments between different users. Therefore the user will need to be prepared for submitting the peg-in proof to the Bridge. I expect that mobile wallets will start providing a watch tower service directly to their user base. We believe that same-person transfers will always be facilitated by pegnatories acting as watch towers.
Second, it will be possible to execute smart contracts directly from Bitcoin using a system called FastBTCBridge (RSKIP-176). The FastBTCBridge system is a combination of consensus changes to the bridge contract and a set of smart-contracts that enable flexible peg-ins in only a few Bitcoin confirmations. Therefore you’ll be able to perform loans, participate in crowdsales, or add liquidity to any protocol in RSK directly from Bitcoin. More information about how this system works will be posted soon.
Third, also using the new FastBTCBridge system, it will be possible to perform a peg-in with a low number of confirmations. Currently a peg-in takes 100 Bitcoin block confirmations (about 16 hours). The reason is that peg-ins transactions in Bitcoin are considered final by the RSK sidechain, and RSK has no recourse to revert a peg-in if the peg-in transaction is reverted in Bitcoin. The FastBTCBridge enables peg-ins with a reduced number of Bitcoin confirmations. This is possible by introducing third parties that can trustlessly advance the payments exactly as the user wants to, and then they are reimbursed the bitcoins by the bridge contract when the standard peg-in process finishes with 100 Bitcoin confirmations. The third parties can decide for themselves the number of block confirmations to wait, and can freely negotiate with the user different rates for different confirmation speeds. In the future, the FastBTCBridge smart-contracts could be extended to enable submarine swaps to accept peg-ins paying bitcoin through the lightning network.
The security of the FastBTCBridge is entirely trustless. First, the user wallet and the third party sign an off-chain agreement containing all payment arguments, including destination address, calldata and gas limit. Second, the user performs the bitcoin transaction. Next, the third party waits for confirmations and then executes the transaction by himself. If the third party breaks the agreement, and does not advance the payment, or does not use the exact arguments, or does it but not within the agreed time, then the third party will not be able to be reimbursed, and after the 100-block confirmation period passes, the payment will be executed correctly, and the third party will be penalized by burning an amount of his stake. The FastBTCBridge also provides a similar functionality for peg-outs, although the peg-out functionality, which is entirely implemented with on smart-contracts, will be added later.
Open Bitcoin Blockchain Oracle
Many decentralized applications can benefit from reading the Bitcoin blockchain. For instance, atomic swaps are simple if you can program a contract to release bitcoins in RSK only if it detects that the inverse transaction has occurred in Bitcoin. You can also use data from the Bitcoin blockchain to create derivative contracts based on Bitcoin block attributes, such as the hashrate, or the transaction fees. A miner could hedge against variations and make their mining business more predictable. RSK has an embedded Bitcoin oracle, but until now this oracle has been disabled from being called by smart contracts. When the Iris network upgrade is activated, Bitcoin headers of the best chain will be available to be consumed by any contract. The benefit of having an embedded and subsidized oracle is that it becomes cheap for smart contracts on the platform. There once was a Bitcoin blockchain oracle called btcrelay in Ethereum, but it ceased to be updated from 2017 on because it was too expensive.
Fork-aware merge mining (FAMM)
Fork-aware merged mining is a fundamental improvement to merged mining as it allows a sidechain to acquire 100% of Bitcoin’s hashrate to protect it from long reorganizations even if the overall miner engagement is substantially lower. In 2020, the RSK hashrate oscillated between 50% and 70%, so it’s currently secure. The electricity cost to reverse RSK is therefore generally higher than the cost to revert Ethereum (assuming RSK’s Armadillo alerts are activated for a node). However, we wanted to be one step ahead of the potential attackers, and we proposed an improvement for RSK to reach Bitcoin-levels of security. Fork-aware merged mining is specified in 3 RSKIPs. They are “External Confirmation Hashrate” (RSKIP178), “BTC-RSK timestamp linking” (RSKIP179) , and the yet unmerged “Timestamp-adjusted block difficulty transfer”). The “BTC-RSK timestamp linking” proposal provides cryptoeconomic protection against Bitcoin miners trying to build an RSK fork with fake old timestamps. This RSKIP will be activated in Iris because the protection it provides is attained independently from the Fork-aware combo. Meanwhile, the FAMM will continue to be discussed by the community and we may see an agreement of the benefits compared to its complexity that may establish future inclusion of the remaining RSKIPs.
Compatibility with the upcoming Ethereum Berlin Hard-fork
Iris incorporates the improvements proposed for the next Ethereum hard fork. In fact, it is possible that, due to the delay in the Berlin hard fork release, RSK deploys the improvements even before Ethereum. Two improvements should be highlighted. The first one is the addition of subroutines for the EVM (RSKIP-172 / EIP-2515). This RSKIP adds new opcodes that reduce compiler and compiled code complexity, and it improves static analysis of code. Second, the addition of BLS12–381 elliptic curve operations with a precompiled contract (RSKIP-188 / EIP-2537) enables better and cost-efficient 2nd layer payment solutions with privacy, such as ZK-Rollups.
Summary
The RSK Iris network upgrade is coming soon, bringing innovative features that directly benefit RSK users. By looking at the number of RSKIPs and amount of code added, it is clear to me that the component that has been improved most in this upgrade is the two-way-peg bridge with Bitcoin, with additions that improve both usability and security. Compatibility with Ethereum has also been prioritized: in the past, Ethereum improvements took months to be activated in RSK while this time RSK may activate the improvements even before Ethereum does. I am excited about the Iris upgrade, and I cannot avoid thinking about the improvements to RSK we will see in the next one :)
