Are RIF and RSK going to become one organization?
IOV Labs operates as a purpose driven organization focused on promoting and developing the next generation of open blockchain-based infrastructure that will enable worldwide financial inclusion and bridge the gap between this nascent technology and mass adoption and is the main contributor to the development of RSK and RIF platforms.
For more information visit: IOV Labs
RSK is the first general purpose smart contract platform secured by the Bitcoin Network.
Smart contracts are contracts whose terms are encoded in computer language instead of legal language. Smart contracts can be executed by a computing network such as RSK, so that the terms of the contracts are automatically enforced by a protocol that all nodes in the network follow.
A smart contract can be fully autonomous if all the objects referred (such as currency, payments, obligations, property titles, assets, licenses) have a digital representation in the platform. When there is no such digital representation for an object, a smart contract can also refer to itself and react to changes in its state through special gateway nodes called oracles that provide external information to the blockchain. A smart contract also has access to time with minute precision, so time-restricted conditions can be represented.
A few examples of smart contracts are:
RSK MainNet network was released in early January 2018. The latest major version is called Wasabi.
Live statistics about the entire RSK network is available at RSK Stats.
All the necessary source code can be found at RSK GitHub organisation:
All the project information, including a getting started guide, can be found on the RSK & RIF Developer Portal.
For latest news and updates, check out RSK Blog.
RSK currently supports all the opcodes and precompiles contracts of Ethereum, and therefore it can support any language that compiles to the EVM. This includes Solidity, Julia, and new or experimental programming languages such as Vyper.
The first drivechain proposal was created by us in 2016 and presented to the Bitcoin mailing list for evaluation. See BIP: Drivechain using OP_COUNT_ACKS. Those were turbulent times for the Bitcoin community, as the different subgroups were fighting either to increase the block size or to add SegWit. In that context, it was very difficult to achieve consensus about sidechain integration. Later in 2018, we renewed our efforts with an Improved proposal presented at Building on Bitcoin 2018.
We think that the ecosystem has to mature for trust-minimized Bitcoin sidechains to flourish.
The RSK blockchain is highly decentralised. RSK is merge-mined with Bitcoin, and has a hashpower that is second only to Bitcoin. As such, we believe it to be the most secure and censorship resistant smart contract platform; and the second most secure blockchain platform. Refer to RSK Stats for the live value of the RSK hash rate.
The conversion between Bitcoin (BTC) and Smart Bitcoin (RBTC) is accomplished through a 2-way peg mechanism. This 2-way peg was bootstrapped using a federation of nodes managing a Bitcoin multisignature. However, RSK has transitioned its federation to a PowPeg.
A PowPeg is a multi-signature management system where participants’ nodes have no direct access or control over private keys. Keys are controlled by tamper-proof HSMs. These HSMs internally run lightweight RSK nodes which obey commands originating from an RSK smart-contract called the Bridge that orchestrate peg-outs. Only when such commands are confirmed by thousands of blocks produced by the mining network does the HSM proceed to sign peg-out requests. The PowPeg is a new security protection layered on top of the previous federation. It is unique in the crypto ecosystem and radically reduces the attack surface for the most frequent security breaches. The RSK community has collectively decided on a strategy for increasing the security of the peg based on defence-in-depth: Adding more security layers on top of existing ones, protecting the system from the failure of any of them. The ultimate goal is the complete decentralisation of the peg. Refer to the Security Model for the details around the security model of the 2-way peg.
RSK is the most secure smart contracts platform in the world. Security has been and will continue to be one of RSK’s key competitive advantages and we will keep working at it. Secondly, scalability which is one of the obstacles for blockchain mass adoption has been and will be one of RSK’s key strategic objectives. While independent groups are porting Ethereum scaling solutions to RSK, The IOVLabs innovation & research lab is working on layer 1 proposals to increase its transaction capacity, such as transaction compression, and signature aggregation. On top of this, the RIF payments protocols, such as the RIF Lumino Network also contributes towards this.
How many nodes does a healthy protocol need?
Decentralization should not be measured only by the number of nodes but also about the diversity and independence of nodes. A few hundred independent RSK nodes is enough to serve a global cryptocurrency network at this stage, but we must not feel confident by that metric alone. The RSK platform’s objective is that full nodes are run by a diverse set of individuals, organizations and companies. That is the true meaning of decentralization: Don’t trust, verify yourself. IOVLabs’ innovation and research area has developed several decentralized incentivizations mechanisms that may one day be integrated into full nodes. Also, we’ve put great effort to reduce the resource consumption of full nodes, such as the Unitrie proposal so that individuals can run nodes in standard laptops. Finally, there have been proposals for a new technique for light clients RSK Improvement Proposal, to onboard those users running nodes in mobile phones. In summary, we’re making sure that the RSK network remains healthy and decentralized in the future, both in node quantity and quality.
During the development process, public nodes can be used. DApps in production environments are recommended to run their own infrastructure.
The main reasons why developers choose RSK Smart Contract Network over other networks are security and scalability.
RSK is the most secure smart contracts platform. For up to the minute hashing power stats, please visit: RSK Stats.
RSK has less onchain activity than Ethereum, which is something you would expect for a blockchain that is one year and a half old. Therefore, the blockchain is much smaller than Ethereum. However, prior to the 1.0.0 release the RSK blockchain could grow as fast as Ethereum for equal transaction volumes. Now the blockchain state is ten times smaller.
More information about the Unitrie in Towards Higher Onchain Scalability with Unitrie
From the perspective of programming capabilities, RSK Network is on par with Ethereum as both natively supports Solidity Smart Contracts and the same APIs. These levels of compatibility make it seamless for developers to port their dApps to the RSK Network and leverage on their acquired abilities / knowledge.
From a perspective of security, RSK Network is protected by over 40% of the Bitcoin Network computing power and uses the same hashing mechanism as Bitcoin; which is the safest decentralized network in the world. Although other security models like EOS’ DPoS or Ethereum’s PoW based on general purpose hardware might bring some benefits, none of those networks have been battle tested; neither have they held as much value in custody, compared to the Bitcoin Network.
RSK combines the best of Bitcoin and Ethereum under a single platform.
RIF token info including support for wallets and exchanges at RIF Token
SmartBitcoins, identified with the RBTC ticker are pegged 1 : 1 to BTC (1 RBTC = 1 BTC).
RSK is currently supported in a number of different software hardware wallets. Check RBTC for more info.
RBTC is listed in exchanges to make it easier for less technical users to get access to it. It takes almost a day to transfer BTC to RBTC using the peg. Users at least need small amounts of RBTC to pay for transaction fees, required for smart contract execution. Exchanges help to to cater to the expected growth in demand for RBTC.
RSK is currently supported in a number of different hardware wallets. Check Wallets for more info.
RSK Infrastructure Framework Open Standard (RIF OS) is a suite of open and decentralized infrastructure protocols that enable faster, easier and scalable development of distributed applications (dApps) within a unified environment. RIF OS includes support for decentralized, third-party, off-chain payment networks; a set of APIs for seamless and secure communications between decentralized applications; and easy-to-use interfaces for developers. Access and payment for RIF OS services are based on the RIF Token, which allows developers to access the suite of services built on top of RIF protocols such as Identity, Payments, Gateways, Storage and Communications including third party-developed infrastructure services, and any other apps that might be deployed on RIF’s framework that agrees to accept RIF Tokens as a means of accessing / consuming the service or app. RBTC is the native token of the RSK Live Mainnet and is pegged 1:1 to BTC. It’s used as gas to pay for Smart Contract execution in the same way as ETH is used as gas for Ethereum. Technical users can obtain in a decentralized way by converting to and from BTC by using the bridge between the Bitcoin and RSK protocols. Less technical users can obtain RBTC from supporting exchanges like Huobi and Bitfinex among others. In order to use the RSK and all of the applications that run on RSK and RIF OS.
Is it a Smart Contract? Do exchanges deal with this in real time? Can end-users also interact with this smart-contract directly, without having to go through an exchange? If so, how? If not, why not?
RSK native currency, smartBitcoin (RBTC), is tethered to bitcoin 1 to 1 so the only way to create RBTC is by sending BTC (“or peg-in”) to a multisig address in the Bitcoin blockchain that is managed by the RSK PowPeg. The bitcoins that arrive at that address get locked, and a proof of that transfer (SPV proof) is fed to a special smart contract on the RSK blockchain called the Bridge contract. Currently, the PowPeg Federation is doing this process of communicating new transfers to the Bridge contract but this process is fully decentralized and anyone can feed this information to the contract. Once the bridge contract gets this proof it sends the equivalent amount of RBTC to what was received in BTC to an RSK address that corresponds to the BTC address that started the process on the Bitcoin blockchain. With that, the crossing from Bitcoin to RSK is finished in a fully decentralized / trust minimized way.
To redeem RBTC for BTC (or “peg-out”) first you have to send the RBTC to a special address of the Bridge on the RSK Blockchain but since Bitcoin cannot verify transactions on a secondary blockchain because its scripting capabilities are limited on purpose to reduce its surface of attack, we need the RSK Powpeg to assist in the signing of the release transaction on the Bitcoin side. So as the RSK Powpeg nodes acknowledge and validate that a new BTC release transaction was created, they sign it. The main difference between a federation and RSK’s Powpeg is that the Powpeg nodes run a Hardware Security Module (HSM), so RSK Powpeg nodes do not have access to the private keys and therefore, even if they collude, they cannot steal the funds in the peg. The highest damage they can do is to unplug the HSM and stall the peg. There is a community proposal to add a 6-month time-locked transfer of the peg funds to a backup multisig to protect from a generalized Powpeg malfunction. Internally, when the Bridge contract commands a peg-out, the peg-out transaction is given to the HSM, and the HSM validates the validity based on cumulative proof of work and then signs it. When enough signatures from HSMs are collected (remember that the BTC address is a multisig address so it needs M of N signatures to release the funds) then the BTCs are sent to the BTC address specified in the peg-out request.
Since 2016, the RSK community has been working on an extension of the Bitcoin protocol called Drivechain, that would enable even higher decentralization and security for the peg-out process.
The peg-in process takes around 15 hours (100 Bitcoin blocks) to avoid losing funds due to a reorganization of either blockchain. The peg-out process has an even longer delay of 4000 RSK blocks (about 33 hours) for maximum security.
Due to the technical nature of using the peg, the friction created by the waiting period, many exchanges offer RBTC so developers and users can easily access it. Also a number of fast coin-swap solutions, such as Coinswap enables fast transfers for low amounts without registration.
For more information you could read this in depth article by our Chief Scientist, Sergio Lerner on Sidechains in general and RSK Powpeg.
RSK addresses are similar to Ethereum addresses. To avoid situations where users mistakenly send funds to Ethereum addresses or vice versa, we’ve implemented an address checksum mechanism that distinguishes between chains. This is currently in use by many Ethereum-like networks. Although this is not enforced in the node itself, it’s important to consider it at the client level (e.g.: wallets). The checksum mechanism is described in the following RSK Improvement Proposal.
The native mechanism for transferring bitcoins to RSK (“peg-in”) and vice versa (“peg-out”) is provided by the 2-Way Peg. In practice, when a user pegs-in, the user funds are locked in the Bitcoin blockchain and the same amount of BTC is unlocked in the RSK blockchain. When a user requests a peg-out the bitcoins on RSK get locked in the RSK blockchain and the same amount of BTC is unlocked in the Bitcoin blockchain. A security protocol ensures that the same bitcoins cannot be unlocked on both blockchains at the same time. This requires transaction finality, and that’s the reason the peg required hundreds of block confirmations for transactions that unlock bitcoins.
Since not every user is willing to wait for the required number of block confirmations, exchanges offer a faster mechanism of getting BTC/RBTC, while charging users with exchanges fees.
This blog post explains in detail: RSK’s Pow Peg design
Additionally, for more information, visit the Powpeg mechanism.
We understand people can use bitcoins on RSK to pay for the 3rd party services on the RSK network, hence RIF token feels somewhat unnecessary.
While the RSK Live Mainnet requires - and will always require - Smart Contract execution to be paid in bitcoin, maintaining full incentive alignment with the Bitcoin Ecosystem, RIF OS Protocols aim to create and off-chain layer of infrastructure that initially is built on top of the RSK Ecosystem but will be integrated in the future with other Smart Contract enabled platforms. In order to do so, it is important to have a token that is neutral to any of those networks and for which price is defined in connection with the supply and demand of infrastructure services regardless of the particular price of the native cryptocurrency of the network (RBTC, ETH, EOS, etc). From a user perspective it doesn’t pose any additional friction as we expect that in the near future DEXs (Decentralized Exchanges) will provide instant conversion between the native currencies of the Networks where RIF OS Protocols are integrated and RIF Token. The portability of the RIF Token will create economies of scale and strengthen the antifragility of the Decentralized Ecosystem as a whole bringing the Internet of Value one step closer to realization. The main reason is that we envision RIF OS, in the long term, as a unified Marketplace for off-chain infrastructure services that can be consumed by every Smart Contract enabled crypto-economy (i.e. RSK, Ethereum, EOS). In that context having a portable / neutral token is a benefit.
There is no whitelisting process any more. The RSK blockchain is completely permissionless. We implemented a whitelisting process during the bootstrapping phase until we were sure that it was secure enough to be open to the general public.
Why issue RIF tokens? Why not use RBTC uniformly?
RSK Infrastructure Framework Open Standard (RIF OS) is a suite of open and decentralized infrastructure protocols that enables faster, easier and scalable development of distributed applications (dApps) within a unified environment. RIF OS includes support for decentralized, third-party, off-chain payment networks; a set of APIs for seamless and secure communications between decentralized applications; and easy-to-use interfaces for developers. Access and payment for RIF OS services are based on the RIF Token, which allows developers to access the suite of services built on top of RSK Infrastructure Framework protocols such as Identity, Payments, Gateways, Storage and Communications including third party-developed infrastructure services, and any other apps that might be deployed on RIF’s framework that agrees to accept RIF Tokens as a means of accessing / consuming the service or app. RBTC is the native token of the RSK Live Mainnet and is pegged 1:1 to BTC. It’s used as gas to pay for Smart Contract execution in the same way as ETH is used as gas for Ethereum. Technical users can obtain in a decentralized way by converting to and from BTC by using the bridge between the Bitcoin and RSK protocols. Less technical users can obtain RBTC from supporting exchanges like Huobi and Bitfinex among others in order to use the RSK and all of the applications that run on RSK (including RIFOS once it launches).
While the RSK Live Mainnet requires, -and will always do-, Smart Contract execution to be paid in smartBitcoins (RBTC) maintaining full incentive alignment with the Bitcoin Ecosystem, RIF OS Protocols aim to create and off-chain layer of infrastructure that initially is built on top of the RSK Ecosystem but will be integrated in the future with other Smart Contract enabled platforms like Ethereum & EOS. In order to do so, it’s important to have a token that is neutral to any of those networks and for which price is defined in connection with the offer and demand of infrastructure services regardless of the particular price of the native cryptocurrency of the network (RBTC, ETH, EOS, etc). From a user’s perspective, it doesn’t pose any additional friction as we expect that in the near future DEXs (Decentralized Exchanges) will provide instant conversion between the native currencies of the Networks where RIF OS Protocols are integrated and RIF Token. The portability of the RIF Token will create economies of scale and strengthen the antifragility of the Decentralized Ecosystem as a whole bringing the Internet of Value one step closer to realization. The main reason is that we envision RIF OS, in the long term, as a unified Marketplace for off-chain infrastructure services that can be consumed by every Smart Contract enabled crypto-economy (i.e. RSK, Ethereum, EOS). In that context, having a portable / neutral token is a must.
RSK uses DECOR+, a unique variant of Nakamoto Consensus, with the capability to merge-mine with Bitcoin or any other blockchain sharing the Bitcoin block format and proof-of-work.
Merge-mining is a protocol that allows miners to mine on two or more blockchains at the same time with exactly the same hardware. RSK is designed such that merge-mining with Bitcoin does not pose any performance penalty to bitcoin miners. Therefore merge-miners can earn rewards on both RSK and Bitcoin simultaneously. RSK has improved several open-source mining-pool software to enable merge-mining. Currently more than 40% of Bitcoin hashrate is merge-mining RSK, making RSK the most secure Turing-complete smart-contract platform in the world in terms of cumulative energy spent to secure it. The RSK community is evaluating the upgrade to a recently developed variant of merge-mining called Strong Fork-aware Merge-Mining (SFAMM) that can increase the cumulative energy spent to secure RSK to 100% of Bitcoin’s hashrate.
In the Bitcoin network, when two or more miners have solved blocks at equal height, there is a conflict of interests. Each competing miner wants his block to be selected by the remaining miners as the best-chain tip. All the remaining honest miners and users would prefer that everyone chooses the same block tip, because this reduces the block reversal probability. DECOR+ sets the right economic incentives for a convergent choice, without requiring further interaction between miners. The conflict is resolved so that:
RSK uses the DECOR+ consensus protocol. DECOR+ is incentive-compatible and protects the network from selfish-mining when the rate of honest uncle blocks produced by the network is low. If the uncle rate is high, then a selfish incentive may arise, as described by Camacho-Lerner. To improve it, several fixes have been proposed, such as, the “sticky” rule, delaying the transfer of the weight of uncles in GHOST, or allowing referencing uncle-children in the same way as uncles. With any of these fixes, RSK consensus protocol becomes incentive-compatible assuming that transaction fees are stable, and there are no off-chain payments or bribes to miners.
Is it a matter of utility, and if so, what exactly is that utility? If a token was useful for selling coins that couldn’t be sold with RBTC alone.
This question has two sides as RIF is both a set of protocol standards and a token. RIF OS (RSK Infrastructure Framework Open Standard) is a suite of open decentralized infrastructure protocols that rely on blockchain based smart contracts to enable faster, easier and scalable development of distributed applications (dApps).
The initial protocols include Directory (a naming service protocol), Payments (an offchain payment protocol), Data (a data storage and streaming protocol), Communications (a secure routing, session and encrypted communications protocol) and Gateways (an interoperability protocol that includes cross chain transfers and oracling services). The standards also define interfaces that can be implemented as APIs and libraries that abstract and simplify the use of decentralized infrastructure (both blockchain and P2P) for any developer even if they don’t know inner workings or low level functioning of decentralized protocols.
This suite of protocols aim to solve the major problems that stop decentralized blockchain networks (ie: Bitcoin, RSK, Ethereum, etc.) from reaching mass adoption. From our point of view, the two main impediments are sustainable scaling (onchain scaling is possible but leads to higher maintenance cost for validation nodes and therefore to centralization) and developer usability (it can take several months for developers to learn how to use the technology and even mastering the tech, it’s very inefficient to build decentralized apps for the lack of a higher level protocol and reusable components).
Following the guidelines of RIF OS, a series of blockchain based P2P platforms are being built using RNS; an implementation of RIF Directory on RSK, the first to be launched. RIF Lumino, the first implementation of RIF Payments is launched, for more information and how to set up a Lumino node, visit RIF Lumino. We wish to emphasise the utility of the RIF token within the RIF OS ecosystem. The first and obvious use is to access all the services provided in the RIF OS ecosystem. To comply with the RSK Infrastructure Framework, providers have to at least accept RIF tokens in exchange for their services. On top of that, certain protocols use RIF token as the collateral that all service providers need to stake in order to offer services on the RIF Marketplace. This is key given the decentralized nature of these platforms, without an embed insurance mechanism, it would be impossible to ensure quality of service to the end users. Additionally, on some protocols the ratio between the collateral and the amount of contracts a service provider has will be used to dynamically distribute new service contracts among registered providers.
We also envision that in the not so distant future, other uses of the RIF token will arise surrounding the RIF marketplace. Two of the most relevant ones are the use of RIF token as collateral for the issuance of counterparty risk-free stable assets (ie: RIFUSD, RIFARS, etc) which can be used to denominate service prices in stable assets and the use of RIF token to settle transactions between RIF Payment Hubs without assets in common or sufficient liquidity.
We envision RIF OS in the long term, as a unified Marketplace for off-chain infrastructure services that can be consumed by every major Smart Contract enabled crypto-economy so although the RIF Token was initially created on the RSK Network, in the future it will be portable to other platforms like Ethereum or EOS. This will create economies of scale and strengthen the antifragility of the Decentralized Ecosystem as a whole, bringing our vision of the Internet of Value one step closer to realization.
Yes. Together with the RIF Wallet library RIF Identity is one of the most important components of RIF OS. It provides the basics to anchor identities on the RSK Network and later sign and exchange event attestations that later can be used to build reputational models. We are in talks with the top experts in this field (Sovrin, uPort and others) to define a joint standard.
Also, we have a working relationship with Microsoft who is part of the ID2020 endeavor and we’re partnering with the NGO Bitcoin Argentina, the Inter-American Development Bank and Accenture (another ID2020 member) to create and implement the first inclusive financial ecosystem built around reputational identity in the slums of Buenos Aires.
Would it be like IPFS? Will it use IPFS or some other similar and already working solution?
IOV Labs is working to have a unified API for storing and retrieving files, and support several storage networks. This is the RSK Data Storage protocol. For a first network provider, we looked at the existing solutions (Swarm, IPFS, Storj, Sia…) and decided to base it on Swarm and IPFS. Most of these protocols implement a variation of the following: a file uploaded is split into chunks and distributed in the network. When the file is requested, all the chunks are retrieved and assembled. Each node participating in this network is keeping track of data stored/provided for payment purposes. Of course RSK Data Storage will integrate with other RIF services like RNS to retrieve named files and allow mutability or RSK Payments for incentivisation. And in the future we’ll foster the integration of all successful storage networks under the same RSK Storage API and UI, so the user may be able to switch between storage network backends just by selecting the provider from a list, or even store a single file on several networks at the same time.
There was a mention on twitter a while back about possibly implementing Chainlink as an answer to Oracles.
Anyone that registers a domain in RNS can sell the domain directly or using a third party secondary market.
RIF Name Service (RNS) was designed to make the user experience more friendly by providing an architecture which enables the identification of blockchain addresses by human-readable names or aliases. It can be used to identify other personal resources, such as payment or communication addresses.
Centralizing the access to multiple resources associated with a human-readable name, improves the blockchain platform user experience. Along with the “ease of use” by adding a name resolution service, or “alias”, the probability of errors is significantly reduced. As resource names may change over time, the system needs to be flexible to support frequent changes. Up until now, RIF Name Service only supported addresses built on the RSK Network but currently, users can manage multiple types of coins and assets.
Visit the RIF Name Service for more information.
Although it doesn’t happen very often, we do planned fresh restarts of the RSK Testnet blockchain. This means that all account balances go to zero. A Testnet reset has been recently executed, so there is no way to recover Testnet funds once this is done. RSK Faucet still exists and you can get Testnet RBTCs and also Testnet RIF - tRIF.
General information: Lumino
The RIF Lumino network is already available to the general public. For more information visit: RIF Payments.
Having said this, making Lumino a user-friendly internet of value is one of RIF’s main priorities. For that reason, Lumino has already been integrated with the RIF Naming Service (RNS) which simplifies significantly the usability for non-technical users.
Also, the Lumino light-client is ready and we are working on the Development libraries to facilitate the integrations with wallets and exchanges.
The IOV Labs team is also working on developing solutions for banks and organizations willing to use RIF Lumino for their business needs.
Blocks per second, time to finality, tps and cost per transaction? Can people build on Lumino already? Which projects are building on top of it?
The number of transactions per second that Lumino can achieve depends mainly on the actual network topology and the amount of coins participants lock in their channels. Also, from the tech perspective, the bandwidth and latency of the computers participating in the network are also key for providing a responsive system. Additionally, the capabilities of the network will depend on the network usage patterns of its users. It seems that there are still too many unknowns. However we can simulate certain expected patterns from small networks to larger and larger networks and get useful metrics about the network growth and number of successful payments, the payments settlement times, and the average costs. Taking into account the merging of the scalability improvement proposals already developed by RSK Labs for RSK, the obtained metrics shows us that Lumino can scale to 60M active users without problems, with costs and response times that are competitive with other payment networks. To scale more, we see resource bottlenecks that would need to be addressed.
There are several projects integrating their wallets and solutions with Lumino which will be announced once ready in the following months.
If you want to be part of the network, the Lumino repository is open and in the repository you can find instructions about node configuration and management.
We are working on new RIF Payments components to be launched soon as well as RIF Storage Protocol. By the end of the year we plan to count with a full suite of RIF OS services that will showcase how the full stack will work together.
The RSK platform was launched with a federation of well-known and respected community members (blockchain companies with high security standards) (the Federation). Each federation member, also referred to as a functionary or notary, is identified by a set of public keys, one used for Bitcoin multi-signatures, and others used for authentication and private communications. The conditions to become a Federation member have been established, including security policies, backup procedures, and legal requirements. In 2020, the Federation migrated to a new security model called PowPeg. Under this system, a functionary does not have access to their multisig private key, which is controlled by an HSM, while they do maintain control of other authentication private keys.
How is it valuable?
Currently the PowPeg Federation’s only role is to secure the two-way-peg. Each functionary has the responsibility to keep the HSM physically secured and connected to the RSK network. The federation does not participate in production of new blockchain blocks. In the future, the functionaries may provide additional services to the network. Some of the services that have shown to be valuable to the community are:
A requirement for being part of the PowPeg Federation is the ability to audit the proper behaviour of the software that powers the node, especially regarding the correctness of the component that decides on releasing BTC funds.
There have been proposals for alternative solutions to the sidechain two-way-peg problem, but currently no other satisfactory solution is available, either because it requires a Bitcoin soft or hard fork or because it requires the creation of a new token to use as security bonds. The RSK community is committed to decentralize the federation if a satisfactory solution is found, and the intention to do so is clearly stated in the RSK foundational whitepaper.
The PowPeg Federation has no means of “issuing more BTC”. Transferring BTC to the RSK platform is an open process. In the beginning of RSK, the RSK developers established a hard limit on the amount of Bitcoins that could be transferred to RSK, to reduce risks until the network reached maturity. Later, the limit was replaced by a cap that can be increased, but not decreased.
Bitcoin does not support smart contracts nor native opcodes to validate external SPV proofs. Part of the 2-Way Peg system in RSK requires trust on a set of notaries. In RSK, the notaries that protect the locked funds are the members of the PowPeg Federation. The PowPeg Federation members are respected community actors, such as important blockchain companies, and they also have the technical ability to maintain a secure network node. A requirement for being part of the PowPeg Federation is the ability to audit the proper behaviour of the software that powers the node, specially regarding the correctness of the component that decides on releasing BTC funds.
Nakamoto consensus can be proven secure as long as there is an honest majority of miners. In case of a dishonest majority, malicious miners may find cheating a rational or irrational strategy depending on assumptions on how the market and the community would react to a 51% attack. RSK is no different from Bitcoin in theory, but in practice not all Bitcoin miners participate in merge-mining, so the requirement of honest hashrate would be higher. A ad-hoc monitoring system, called Armadillo, lowers the requirement by warning nodes if more than 50% of the miners turn malicious before malicious miners can do harm. In terms of cryptographic security, RSK merge-mining uses both SHA256 and Keccak. Since there are no known practical attacks on these hashing functions, RSK is currently as secure as Bitcoin mining. In particular RSK assumes a stronger property from SHA256, which is that, it must not allow a “freestart collision” at a cost lower than 2^80 operations. This is because the RSK network uses a property of the Merkle–Damgård construction to compress the size of the SPV proof.
Miners earn 80% of the transaction fees from every RSK block they mine. These incentives will become more and more attractive while the RSK platform drives adoption, and the number of transactions in the network increases. Since merge mining RSK does not require any additional cost to the one required to mine Bitcoin, RSK provides an additional revenue stream for the Bitcoin miners using the same hardware and electricity. More information about RSK merge mining can be found here: Merged Mining Is Here To Stay.
We are currently looking for other ways to incentivize all RSK key players -including mining pools- to better align incentives while the network is bootstrapped. We’ll keep the community posted on any update about this.
Below is a list of useful links for users willing to understand more about merged mining and setting up mining nodes:
By running an RSK node, you not only check the validity of your own transactions, but also that the rules of the system cannot be changed by any minority group. Therefore, it’s in RSK users best interest to run full nodes of their own. Having said that, we’ve designed -and we’re currently developing the first decentralized system for proving you’re a full node, so in the future we’ll be able to incentivize full nodes (see our Devcon3 presentation on Proof of Unique Blockchain storage). This technology will allow the economic reward of full nodes in the future which could be used to reward RSK and Lumino full nodes.
Merge-mining is a process by which Bitcoin miners can mine both Bitcoin and RSK at the same time, with the same hardware and consuming the same electricity. RSK merge-mining uses the same cryptographic hash function as Bitcoin (SHA256).
The number of transactions per second executable on the RSK platform is determined by the block gas limit and the average block rate. The current average block rate is one block every 30 seconds. At each mined block, the miner can vote to increase the block gas limit. Currently the block gas limit is 6.8M gas units per block. A simple RBTC transaction consumes 21K gas, so the RSK platform can execute 11 transactions per second today. This limit could increase in the future as there are several improvement proposals that lower the resources required to process transactions on the RSK network.
For example, RSKIP04 enables parallel processing of transactions. If the proposal is accepted by the community, the block gas limit could easily double.
Both the LTCP protocol, as described in the white-paper and in RSKIP53, and the shrinking-chain scaling technique could result in a ten-fold reduction in the amount of space required.
If these proposals are accepted by the community, transaction speeds could be expected to reach 100 transactions per second.
Beta releases of improved RSK nodes have been tested to accommodate 100 tx/s without incident. As the technology improves, transactions per second may similarly increase. The goal of RSK Labs is to reach up to 20,000 tx/sec using its Lumino technology, which is a second layer off-chain payment network that will be embedded on RSK’s reference node in the following release.
On average, the network currently generates a block every 30 seconds. Miners can reduce the average block time to 15 seconds by optimizing their merge-mining operations. Systems that receive payments over RSK in exchange for a good or service outside the RSK blockchain should wait a variable number of confirmation blocks, depending on the amount involved in the payments. A minimum of 12 confirmations is recomended, which corresponds to an average delay of 6 minutes.
The RSK network is highly compatible with the Ethereum network at various layers:
RSK Virtual Machine (RSKVM) is highly compatible with the Ethereum Virtual Machine (EVM), but the RSKVM offers additional features not present in the EVM. To make use of these improvements, some changes to the smart contract source code are required. Furthermore, the RSKVM has specific precompiled contracts that provide the bridging functionality with Bitcoin. Approximately once a year, the Ethereum community performs a hard-fork to add new functionality. The RSK community has, in the past, incorporated these changes through corresponding hard forks on the RSK network. These trends are expected to continue in the future.
The RSK blockchain is secured by merge-mining, with some additional security measures. The RSK blockchain is mined by the Bitcoin miners, which are part of the largest and most reliable blockchain network in the world. Currently, more than 35% percent of the Bitcoin hash rate is simultaneously merge-mining RSK.
The 2-Way peg is said to be a method to transfer BTC into RBTC and vice-versa. In practice, when BTC is exchanged for RBTC, no currency is “transferred” between the two blockchains. There is no single transaction that does the job. This is because Bitcoin miners cannot verify the authenticity of balances on another blockchain. When a user intends to convert BTC to RBTC, some BTC are locked in the Bitcoin blockchain and the same amount of RBTC is unlocked in the RSK blockchain. When RBTC needs to be converted back into BTC, the RBTC gets locked again in the RSK blockchain and the same amount of BTC is unlocked in the Bitcoin blockchain. A security protocol ensures that the same Bitcoins cannot be unlocked on both blockchains at the same time. This requires transaction finality, and that’s the reason the peg required hundreds of block confirmations for transactions that unlock BTC or RBTC.
When a Bitcoin user wants to use the 2-Way Peg, he sends a transaction to a multisig wallet whose funds are secured by the PowPeg Federation. The same public key associated with the source bitcoins in this transaction is used on the RSK chain to control the Smart Bitcoins. This means that the private key that controlled the Bitcoins in the Bitcoin blockchain can be used to control an account on the RSK chain. Although both public and private keys are similar, each blockchain encodes the address in a different format. This means that the addresses on both blockchains are different.
Currently the funds in the peg are secured by a threshold signature managed by the HSMs protected by functionaries of the PowPeg Federation. At least 51% percent of the functionaries HSM PowPeg signatures are required to transfer bitcoins out of the peg wallet. The process to unlock bitcoins is controlled by a smart contract running in the RSK blockchain. All coordination actions are open for every user to see.
The original RSK roadmap proposed to add drive-chain support to enhance the security of the funds in the peg. This requires a Bitcoin soft-fork, which may or may not occur. RSK Labs created a BIP and working code to implement this drive-chain in Bitcoin. If Bitcoin soft-forks to support the drivechain BIP RSK proposed, unlocking funds from the peg will also require 51% percent acknowledgement by the merge-mining hashing power. With the hybrid PowPeg Federation/drivechain proposed by RSK Labs, both the majority of PowPeg federation members and the merge-miners must acknowledge a release transaction, increasing the overall security of the peg.
The RSK blockchain is secured by proof-of-work based on the SHA256D algorithm like Bitcoin. If all the RSK miners collude, they can censor one or all of RSK transactions but they cannot steal RBTC or Bitcoins.
The security of the RSK network will depend on the amount of merge-mining engagement and the number and quality (security compliance) of the PowPeg Federation members. More than 50% of the Bitcoin miners are currently merge-mining RSK (as of 2020) and another 30% are planning to merge-mine in the future. Furthermore, the RSK network could theoretically reach a higher hash rate than Bitcoin, by combining merge-mining hash rates from other bitcoin clones.
Are 6 confirmations on the RSK platform sufficient for a transaction to be considered confirmed?
A recent paper established that in the context of transaction reversal probability, 6 Bitcoin confirmations (average 1 hour) would be equivalent to approximately 12 RSK confirmations (average 6 minutes). While Bitcoin has the concept of 0-confirmations (the transaction has been broadcast without Replace-by-fee), there is no similar concept in RSK. The fastest real confirmation in RSK is “1.5” confirmations, or 1 confirmation plus 5 seconds without a block reversal, or an average of 35 seconds.
The RSK “gas system” prevents an attacker from creating, spreading and including resource-intensive transactions in blocks without paying the associated fees. Every resource, including CPU, bandwidth and storage is accounted for by consumption of an amount of gas. Every block has a gas limit, so the resources a block can consume are limited, making a resource exhaustion attack ineffective.
In Ethereum a miner can include transactions specifying zero gas price, thus acquiring persistent contract state memory almost for free (if no transaction backlog). In RSK a high percentage of the transaction fees go into a reward pool for future miners, a small fraction of the transaction fees are burned and there is a minimum gas price negotiated by the miners. Therefore, rogue miners cannot get platform resources at no cost.
An RSK address is an identifier of 40 hexadecimal characters while the Bitcoin address is an identifier of 26-35 alphanumeric characters.
For use cases informations, see Use Cases.
There are only two other Bitcoin sidechain projects that are currently active: Liquid and Truthcoin’s drivechain. Liquid is a federated sidechain, somehow similar to RSK. Liquid aims to be an inter-exchange settlement network linking together cryptocurrency exchanges, enabling faster Bitcoin transactions. It’s optimized for a single use case. RSK is much more generic and programmable, having stateful smart-contracts. Also RSK is highly compatible with Ethereum applications, libraries and toolchains. It has a large ecosystem and trained developers. Liquid applications currently depend on a single library provided by Blockstream, and has a niche ecosystem.
Another key difference is that Liquid uses its Federation for block consensus, while RSK uses merge-mining, and currently it has about 40% of Bitcoin’s hashrate. Therefore RSK has actual “thermodynamic” security. Anyone can participate in RSK merge-mining, so anyone can receive transaction fees.
Regarding onchain transaction throughput, RSK can achieve a higher volume than Liquid because essentially RSK’s payment transactions are smaller than Liquid’s. However, currently the transaction throughput in RSK is limited by its miners, which can increase or decrease the block gas limit. In following RSK network upgrades we may see the two important developments implemented: The LTCP protocol (see RSKIP53) and parallel transaction processing (see RSKIP04). These improvements together enable 30x transaction throughput increase in RSK. Another key difference between RSK and Liquid is that the RSK peg is open. It can be used by individual users without going through an exchange, and a KYC process. However, the fastest way to get RBTC is still exchanging BTC at a crypto exchange, because it takes a day to transfer bitcoins to RSK using the peg. In terms of PowPeg Federation security, Liquid uses a 11-out-of-15 multisig with a 2-of-3 time-locked emergency spend, and RSK uses a 8-out-of-15 multisig, so each sidechain has different trade offs between availability and security.
Truthcoin’s drivechain is only running as a testnet because it requires a Bitcoin soft-fork to run on mainnet, so it’s not really a project one can build applications for now. However we share with Truthcoin the long term vision that sidechains should move from the federated model to a more decentralized one.
First, Lightning would be more comparable to RIF Lumino Payments on top of RSK than to RSK itself. Having clarified that, we don’t see Lightning as a competitor but as a complement. With dual Lightning / Lumino nodes, people will be able to do atomic swaps of bitcoins for smartBitcoins greatly simplifying the use of the RSK Network.
On the other hand, Lightning is bitcoin only at the moment while RIF Lumino Payments will enable offchain payments for any token living on the RSK Network. Imagine the potential of having instant payments of stable assets tethered to fiat currency fully integrated with Bitcoin and costing a fraction of a cent. That can create the perfect playground for FinTechs all over the world and will enable competition on the financial system in a whole new level.
Ethereum is going to change a lot in the next couple of years. What is RSK’s strategy?
“Supporting an improved VM is a good long term strategy, not because Ethereum (or any blockchain) should be a “world-computer” (it shouldn’t) but because certain cryptographic primitives that are cornerstones of more scalable and private 2nd layer payment protocols need more onchain processing than what the EVM can provide. EVM should remain either interpreted or transpiled for backwards compatibility”.
EWASM aims to be a consensus-enforced and resource-accounted deterministic WASM JIT compiler, and that’s a difficult thing to do. The design is still being modified, it needs peer review, a clear specification and several security audits. EWASM is still far away from reaching a beta-state milestone.
RSK strategy detailed in its foundational whitepaper was to provide EVM compatibility while implementing a java bytecode based VM, with dynamic transpiling of EVM codes into java bytecodes. We researched and developed our prototype VM, but when RSK launched Ethereum-compatibility was the top priority, so the new VM was postponed. Meanwhile, the AION team did a great job and launched their java-based AVM, which is in production state. Now we’re evaluating the possibility to propose to the RSK community using the AVM as the new VM, and we may collaborate with the AION team in standardizing the AVM.
Is the RSK chain growing at the same speed as Ethereum? (if transaction count is the same)
RSK has less onchain activity than Ethereum, which is something you would expect for a younger blockchain. Therefore the blockchain is much smaller than Ethereum. However, prior to the 1.0.0 release the RSK blockchain could grow as fast as Ethereum for equal transaction volumes. With the advent of the Unitrie, which is part of the 1.0.0 release, the blockchain state is ten times smaller. For example, the last world-state consumes no more than 50 Mbytes. The current Ethereum state consumes about 130 GB. That’s 2600 times more.
Ethereum is RSK’s closest relative. It’s proof of work based, as RSK, and it shares a similar virtual machine and application interface. There are however key differences.
From the economic point of view, Ethereum has a native speculative token, Ether, and network effects are currently pushing for Bitcoin to become a single strong cryptocurrency that can serve as a store of value for the ecosystem. If this trend of market consolidation continues, the value of Ether may degrade.
Also, Ethereum is a generic smart-contract layer tailored for dApps having their own tokens. These dApps can only grow to be used by millions by removing the friction imposed by Ether as an intermediate token. This force in the community will push Ethereum (and any other smart-contract platform) to a dynamic where transactions are paid in tokens, and users connect to third party relayers that receive micro-payments in tokens to pay the transaction gas in ether for them, something known as de-facto economic abstraction. Therefore the value of ether may be in jeopardy. While smart contract staking is an opposed force, some of the largest Ethereum projects, like MakerDAO, are now allowing staking in tokens, so ether is also losing the exclusivity as a staking mechanism. RSK, on the contrary, uses Bitcoin as its native token, and does not need to incentivize its users to hoard the coin.
Finally, Ethereum is rebuilding itself as a PoS blockchain, mainly because it has reached its end-of-life in terms of scaling capacity. The migration to Ethereum 2.0 carries an enormous technical risk, and the migration, if successful, will take several years. Meanwhile, its user base will strive to run applications in a costly environment that has already priced-out standard PCs as full nodes. RSK has a different scaling plan that is based on the conservative expansion of its onchain layer using compression and aggregation techniques, together with better resource allocation using storage rent. This layer will be ideal for 2nd layer scaling solutions, and we are encouraging these developments on our platform. There are many teams working on 2nd layer networks who need a stable onchain layer that they can rely on today and tomorrow.
IOTA tries to solve the consensus centralization problem by making every user a miner that provides proof-of-work embedded in their transactions, and these little proofs in mass secure the past transactions of the ledger. Therefore, IOTA security depends heavily on its continuous use as a payment mechanism. Decentralization is a noble goal but more important is having a solid strategy to achieve it. Satoshi created a positive feedback loop when he added a block subsidy to the blockchain. On the contrary, IOTA has an unsolved bootstrapping problem. It could not bootstrap even adding a centralized coordinator during years. It could not achieve a minimum level of thermodynamic security. Recently, they implemented a completely new consensus protocol to fix this. Maybe it works, but analyzing the project technical track record can’t be counted on. From a technical point of view, the use of partial order consensus precludes the “tangle” to be used for stateful smart contracts, so it has limited functionality. Finally, using PoW in every transaction precluded the possibility of SPV-based public verifiability, like FlyClient or NiPowPow methods, as you need all transactions to verify the blockchain proof-of-work.
The people at IOHK are working on KEVM type of sidechains. They promote that with the K framework it’s much easier to formally verify correctness of smart contract code. Now, when Ethereum 2.0 anyway will go out of EVM, maybe it’s a good idea not to try to be 100% compatible with them and implement changes which may make EVM type of blockchains be better than Ethereum implementation. What’s your take?
IOHK is working on IELE, a virtual machine which facilitates formal verification. It’s still an ongoing work, but it has the benefit that it integrates with the LLVM Compiler toolchain. The AVM enables a vast ecosystem of existing Java libraries and tools. EWASM has the benefit of being the language of choice by web browsers, so it will be fast.
RSK is here for the long term. It was created to use the best available technology, and that technology may not come from the RSK development team, but from other teams. It means that if we see there is traction and a community that builds solutions around IELE or AVM or EWASM, we may also propose integrating it into RSK. RSK is not opposed to having several VMs running on a node in the future, as they are easy to encapsulate. There may even be one preferred VM with the bytecode for other VMs transpiled to the bytecode for the preferred one.
We created the RSK-LTC working group, with members of the RSK and Litecoin community, to evaluate the possibility of proposing a bridge between the two platforms. However, there is no finalized community proposal or reference code for integrating a Litecoin bridge in RSK at this moment.
Visit the links below for information about the fund and innovation studio
The SF Innovation Studio was officially launched in early June 2019 and is currently focused on developing some much-needed tools for developers, including the developers website. In August we demoed a Ganache integration at Trufflecon, and we will soon launch our own set of web3 libraries. In addition, we will soon launch an open-sourced wallet based on these libraries.
In parallel to this, the studio engages with developers and startups to work collaboratively on innovative tools and dApps that can bring value to the RSK ecosystem. We also work closely with the Ecosystem Fund, which is run from the same office as the Studio in SF. If you want to contact us, feel free to drop us a line at firstname.lastname@example.org.
Go to top