Introduction to Iris 3.0.0 network upgrades, powpeg security and flyover protocol. by Owanate Amachree, Content Developer, IOV labs. On 16th July 2021, The RSK Ecosystem held its second community call. The aim of these community calls is to discuss the , 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 RSK Improvement Proposals - RSKIPs 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 on Youtube (Replay). RSK Community Call July 2021 🗣️ Propose your own RSKIPs 🔗 Join the RSK Research & Innovation Forum 🗣️ in the next community call Suggest RSKIPs to discuss 🔗Join our and ask your questions in #research-and-innovation Open Slack Community 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, 2021 for Mainnet and Aug 4, 2021 for Testnet, the number of block activation numbers for mainnet is and for testnet respectively. 3,614,800 2,060,500 Components of Iris network upgrade There are 18 RSKIPs included in IRIS. All of these RSKIPs can be found in the meta RSKIP ( ), which is an index of all the changes that are individually described in the RSKIPs repository. 18 RSKIPs RSKIP-187 The tag name for this upcoming version upgrade is 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. Release RSKj IRIS-3.0.0 The following are the included RSKIPs in . RSKIP-187: Iris Network Upgrade : Add BLAKE2 compression function F precompile RSKIP 153 : Rectify EXTCODEHASH implementation RSKIP 169 : 2WP peg-in transactions to any address RSKIP 170 : Arbitrary-length data return mechanism RSKIP 171 RSKIP 174: Preserve balance in contract creation : Trustless fast BTC bridge RSKIP 176 : BTC-RSK timestamp linking RSKIP 179 : Add 2WP peg-in transactions reject events RSKIP 181 : Add 2WP peg-out transactions events and refund support RSKIP 185 : Preserve RSK PowPeg activation block height RSKIP 186 : Remove non-Ethereum opcodes from the virtual machine RSKIP 191 : Error Handling for Precompiled Contracts RSKIP 197 : Bridge performance improvement RSKIP 199 : ReceiveHeaders method limitations RSKIP 200 : Time-locked Emergency Multisignature RSKIP 201 : New fee rewards address for the RSK Core Developers Fund RSKIP 218 : Minimum peg-in and peg-out values reduced RSKIP 219 : Open Bitcoin blockchain oracle RSKIP 220 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 ( 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. EOA 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 , which is a document describing the RSKIP process, which will be discussed by the community before getting included in the RSKIPs. Essentially, it deals with how the RSK community initiates, discusses, and incorporates improvements. This process began in 2016, and is said to have approximately 144 proposals published, 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. RSKIP-0 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 - e.g, if it is a change in consensus or if it is any other change that does not involve consensus. 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, through 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 by Sergio Lerner. The RSK Emergency Multisig article John Light from 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 and 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 mentioned by John Light. Sovryn 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 . Also, leave a comment on ! recording on Youtube this thread for the next community call The following questions were asked during the community call; Why is an Emergency and a Hard Fork? 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. Answer: 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? 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. Answer: Resources What do you in our next community call? want to discuss The next RSK Community Call will happen on August 5th 2021 with discussions including the hard fork. next RSK Improvement Proposals - RSKIPs Discourse Forum RSK/RIF Developer’s Portal RSK Open Slack Community RSKj Thanks for reading!
