Introduction to Iris 3.0.0 network upgrades, powpeg security and flyover protocol.
On 16th July 2021, The RSK Ecosystem held its second community call. The aim of these community calls is to discuss the RSK Improvement Proposals — RSKIPs, get the community involved, gather feedback, discuss the RSK consensus protocol, the formal process for proposing improvements, and the upcoming network upgrades. For more info, read the RSKIP Purpose and Guidelines. It was live-streamed on several platforms, and we received quite a lot of questions and feedback from everyone who participated! For those of you who missed out on attending it live, we’ll catch you up in this article or read the detailed guide on What You Need To Know About RSK Upcoming Network Upgrade!
🎥 Watch the RSK Community Call July 2021 on Youtube (Replay).
🗣️ Propose your own RSKIPs
🔗 Join the RSK Research & Innovation Forum
🗣️ Suggest RSKIPs to discuss in the next community call
🔗Join our Open Slack Community and ask your questions in #research-and-innovation
The speakers on this call were:
- Sergio Demian Lerner
- Adrian Eidelman
- Jose Dahlquist
- John Light
- … and hosted by Brendan Graetz
In this call, we discussed:
- RSK Iris hard fork overview
- RSKIP process
- RSKIP-201, PowPeg Security
- RSKIP-170, Pegin to any address
- RSKIP-219, Pegin minimum reductions
- RSKIP-176, Flyover
All about RSKIPs
The live event began with Adrian Eidelman talking about the Iris Hard Fork, which release has been talked about for months, and the new features and major improvements are ready to be made public.
Iris is a network upgrade or a hard fork — a hard fork is a set of changes to the underlying RSK protocol and those changes introduce new rules to improve the platform. These new rules are coded into the RSK reference client which is RSKj, and if the protocol rules change, all the nodes in the network need to be updated, otherwise those nodes not updated will remain on an old change with the previous rules.
Everyone running an RSK node instance (either a testnet or mainnet node) should ensure to update it before the IRIS updates are activated. No special consideration is needed, simply update your node instance, and it can be done in under a few minutes.
Scheduled Dates for IRIS Activation
The activation of the IRIS network upgrades will take place around Aug 19, 2021for Mainnet and Aug 4, 2021 for Testnet, the number of block activation numbers for mainnet is 3,614,800 and 2,060,500 for testnet respectively.
Components of Iris network upgrade
- 18 RSKIPs
There are 18 RSKIPs included in IRIS. All of these RSKIPs can be found in the meta RSKIP (RSKIP-187), which is an index of all the changes that are individually described in the RSKIPs repository.
- Release
The tag name for this upcoming version upgrade is RSKj IRIS-3.0.0 which also contains both consensus and non-consensus improvements to RSKj. These include compatibility fixes at the JSON-RPC interface, performance enhancements of the node, et cetera. See the IRIS milestone on Github for a more detailed view of these changes.
The following are the included RSKIPs in RSKIP-187: Iris Network Upgrade.
- RSKIP 153: Add BLAKE2 compression function F precompile
- RSKIP 169: Rectify EXTCODEHASH implementation
- RSKIP 170: 2WP peg-in transactions to any address
- RSKIP 171: Arbitrary-length data return mechanism
- RSKIP 174: Preserve balance in contract creation
- RSKIP 176: Trustless fast BTC bridge
- RSKIP 179: BTC-RSK timestamp linking
- RSKIP 181: Add 2WP peg-in transactions reject events
- RSKIP 185: Add 2WP peg-out transactions events and refund support
- RSKIP 186: Preserve RSK PowPeg activation block height
- RSKIP 191: Remove non-Ethereum opcodes from the virtual machine
- RSKIP 197: Error Handling for Precompiled Contracts
- RSKIP 199: Bridge performance improvement
- RSKIP 200: ReceiveHeaders method limitations
- RSKIP 201: Time-locked Emergency Multisignature
- RSKIP 218: New fee rewards address for the RSK Core Developers Fund
- RSKIP 219: Minimum peg-in and peg-out values reduced
- RSKIP 220: Open Bitcoin blockchain oracle
IRIS Network Upgrade: Changes explained
RSKIP-170: Peg-in to a user-defined RSK address
The change in RSKIP-170 includes:
- Allow users to peg-in BTC to any address in RSK, EOA or contract.
- Output with an OP_RETURN op code and certain payload in the transaction
- Backwards compatible
- 2WP wallets/tools can provide a much more friendly experience.
These are changes to the peg-in protocol, a very simple change but it enables a better peg-in experience, the goal of this consensus change is to basically allow users to specify any address in RSK (EOA or contracts) where the RBTC will be delivered when doing a peg-in transaction. This enables developers to build solutions that use this feature, for example, any wallet that provides this feature needs to implement this new feature, these changes are also backwards compatible, so node changes needed for the tools implementing this feature can keep working without issues. Some teams are already working on implementing this feature which can be seen in the image above.
RSKIP-219: Reduced minimum peg-in and peg-out values
The changes include;
- Minimum required values for peg-in and peg-out have been halved.
- Peg-in minimum: 0.01 → 0.005
- Peg-out minimum: 0.008 → 0.004
- Peg-out BTC fees must be less than 20% of the peg-out value.
RSKIP-176: Flyover Protocol
Jose Dahlquist explained the changes in RSKIP-176;
- Converting BTC to RBTC in just a Bitcoin block is now possible
- A new market opportunity for liquidity providers
- Fully decentralized
- Business rules are written in solidity
- Bridge remarkable changes
- Register Bridge UTXOs from a derived powpeg Federation address
- Secured by the powpeg (HSM, ERP, etc)
The RSKIP Process
RSKIP-0
Sergio Lerner talked about the RSKIP-0, which is a document describing the RSKIP process, which will be discussed by the community before getting included in the RSKIPs. Essentially, how the RSK community initiates, discusses, and incorporates improvements. This process began in 2016, he said there are approximately 144 proposals published, and 20 proposals that have been abandoned or incomplete, he encouraged everyone who started a proposal to finish it, and that 40 proposals have been adopted and activated.
Sergio explained the process/workflow for submitting a proposal.
This starts with a draft which is a detailed document where you sketch your idea, the draft can be rejected if the community finds it of no value to the platform, or it contradicts some fundamental genesis of concepts of the platform. Or it can be activated — for e.g, if it is a change in consensus or if it is any other change that does not involve consensus, for e.g, a change in the interface of a node or CLI args or JSON-RPC then it is said to be adopted after several discussions have been had in the research forum, once accepted, it will be implemented in subsequent versions.
The below image shows the steps to follow, and how to get community feedback on your idea;
Do check out the RSKIP process. We encourage everyone from the RSK community to participate in this process, by creating new RSKIPs, discussing existing ones, and attending community calls like this one!
RSKIP-201: Powpeg Security
Time-locked Emergency Multisignature
A Timelock Emergency Multisig is a backup method to access the funds in the PowPeg that is only activated after one year of continued external attack.
- DOS Attack against the RSK Mining Network (Very low risk)
- DOS attack against the majority of the pegnatories (very low risk)
- Seizure of the majority of the PowHSM devices (low risk)
Additionally, some internal bug or vulnerability bricks the PowHSM.
Sergio also talked about the new bitcoin script for Powpeg address, which has two execution paths — the normal peg out script path and the emergency peg out script path, see image below;
The reason for a one-year time lock and what signatories will do in the case of an emergency. He also gave a brief history of the PwoPeg since 2020, the private key holders, the future of the emergency multisignature and the original security concerns that motivated an emergency multisig which were;
- Firmware bugs
- Flash Memory Failure
- Board Failure
- Censorship, Seizure and Ransom Demands.
For more info on RSKIP-201, read The RSK Emergency Multisig article by Sergio Lerner.
John Light from Sovryn expressed concerns about the potential degradation of the security of the PowPeg which could arise as a result of adding the emergency multisig, he suggested some improvements like expanding the number of signatories on the multisig, securing the private keys using PowHSM devices. Sergio responded to this by saying that future network upgrades will prioritise security. Adrian added to this by saying that discussions are already underway and that the next upgrade will see improvements like the one mentioned by John Light.
Q & A
For more details on these, please watch the live recording on Youtube.
Want to champion an RSKIP? Missed the first RSK Community Call? Watch the recording on Youtube. Also, leave a comment on this thread for the next community call!
The following questions were asked during the community call;
- Why is an Emergency and a Hard Fork?
Answer: Adrian responded by saying that though the term used calls for valid concerns, he said that there’s nothing to worry about especially with regards to their RBTC and that this is a planned hard fork and a consensus change to improve the features of the network.
- Does the user need to do anything? Will we end up with RBTC and the “old” hard forked RBTC as it happened with BTC’s hardfork?
Answer: Brendan responded by saying no, you generally don’t need to do anything unless you’re running an RSK node. If you are running an RSK node, do update it to the latest version of RSKj as soon as possible.
Resources
What do you want to discuss in our next community call?
The next RSK Community Call will happen on August 5th 2021 with discussions including the next hard fork.
- RSK Improvement Proposals — RSKIPs
- Discourse Forum
- RSK/RIF Developer’s Portal
- RSK Open Slack Community
- RSKj
Thanks for reading!
Top comments (0)