I'm always interested in what other ways one can use their blockchain and Solidity skills. While many projects are still only in the planning or in testnet status, with Rootstock (RSK) you can transfer mainnet Bitcoins to an EVM sidechain and vice-versa already today. Utilizing the power of the EVM allows you to deploy Solidity contracts and use existing Ethereum infrastructure and tooling around it.

Let's see how to use it...

Bitcoiners

What is RSK?

RSK is a sidechain for the Bitcoin blockchain with full EVM support. This means you can deploy Solidity contracts here, while leverage the security of Bitcoin mining. Most tools will also have support for the RSK chain given its EVM capability.

All details can be seen in the Whitepaper.

What is the RSK sidechain?

Sidechains generally are EVM-compatible, separate blockchains with their own consensus models. Sidechains are designed to easily allow transfer of value and arbitrary state with the main chain. RSK is special as it's not connecting towards the Ethereum mainnet, but rather the Bitcoin blockchain.

+ allow you to run fully functioning smart contracts
+ value exchange with Bitcoin main chain

Historical context: The notary discussion concerns the BTC bridge, not the Rootstock block-producing consensus, which uses merged mining. The membership count and federation design below describe the historical setup; consult the current PowPeg security model for the live bridge.

- security currently still relies on a set of 15 trusted notaries

How is the sidechain secured?

In merged mining, a Bitcoin mining attempt commits to the Rootstock block as well. If its hash meets the Bitcoin target, it can also be submitted for Rootstock when it meets Rootstock’s target and validity rules; finding a Bitcoin block does not require discarding the Rootstock result. If it meets only Rootstock’s target, it can still produce a Rootstock block. The two chains validate their own blocks and rewards.

How is the transfer between Bitcoin and RSK secured?

Historical context: This comparison describes the former federation. Rootstock moved to PowPeg in December 2020, using hardware-enforced signing tied to cumulative proof of work. Read the current PowPeg design for its operational and trust assumptions.

The current 2-way peg design in RSK allows to transfer Bitcoins from the Bitcoin blockchain to the RSK chain and vice-versa.

Current Design: Transfers are secured by 15 public and well-known, trusted notaries. Once you lock Bitcoins in the main chain, they will control those funds. Only once you burn the funds in the RSK chain, will the notaries return your funds on the main chain.

The obvious advantage here is that the system is not fully decentralized.

Notary Bridge

Future Design: In the future RSK may change the design to a so-called drive-chain. In this design the locked funds are solely controlled by the Bitcoin miners. Unlocking funds happens in a voting period. For this to work however, a new OPCODE in Bitcoin would be required and thus a soft fork introducing the new capability. An existing proposal for a BIP (the Bitcoin equivalent of EIP) is here.

Hybrid: This future design could be added in a hybrid model depending on miner participation. If the miner participation is low, keep the current design with notaries. But as participation increases, give more and more power to the miners. Eventually only miners will control the funds.

You can find more details about the two peg design here.

Dynamic Hybrid RSK
Hybrid RSK

PowPeg is now live. Rootstock switched to PowPeg in December 2020, shortly after the original version of this article. Peg functionaries keep specialized signing hardware and nodes available; that role is separate from producing Rootstock blocks. The current PowPeg documentation explains the bridge, its security assumptions and supported user workflows.

Existing projects on RSK

But not only that, many projects or forks of those already exist inside RSK. Some highlights include:

Uniswap Fork Another One

How to deploy to RSK

Deploying to the RSK sidechain is very simple. If you're using Truffle, simply add the network configuration like this:

Truffle's built in HDWalletProvider, as well as the bundled Web3Provider, were previously using hard coded values that are OK for Ethereum, but not OK for RSK. This was due to larger block times, the resulting rate limits configured on our public nodes.

You can now override these defaults - to make Truffle work better with RSK.

javascript
// Legacy Truffle configuration. HDWalletProvider and mnemonic are defined by the surrounding project.
module.exports = {
  networks: {
    rsk_testnet: {
      provider: () => new HDWalletProvider(mnemonic, "https://public-node.testnet.rsk.co"),
      network_id: 31,
    },
  },
};

Without the above, you're likely to run into intermittent failures for truffle migrate, and intermittent warnings when you leave truffle console running.

You'll also need funds in the sidechain of course. For the testnet, just use the available faucet here. For mainnet you need to use the bridge as described below and further use the config:

  • provider: () => new HDWalletProvider(mnemonic, 'https://public-node.rsk.co')
  • network_id: 30

Be aware that for production services you may not want to rely on a public node, but rather run your own RSK node.

Onboarding users

MetaMask

Use the official Rootstock wallet settings: mainnet uses chain ID 30 and RBTC; testnet uses chain ID 31 and tRBTC. Choose the endpoint for the intended network. The Truffle configuration above is a legacy tool example.

RSK MetaMask

Value transfer from and to RSK

1. Getting the native RSK (BTC <-> R-BTC)

Use the maintained PowPeg app and user guide for BTC-to-rBTC peg-ins. They describe the currently supported wallet, address, amount and confirmation requirements. The old MyCrypto/private-key conversion sequence has been retired from this guide; do not reuse its address-conversion steps as a current bridge recipe.

For rBTC-to-BTC peg-outs, follow the current PowPeg user guide. A peg-out has network-specific wallet, amount, fee and confirmation requirements; it is not an immediate transfer completed merely by sending to the address printed in an old tutorial.

2. Moving Ethereum ERC-20 tokens to RSK (e.g. DAI <-> r-DAI)

RSK Token Bridge

Historical context: The Ethereum token-bridge walkthrough below used historical test networks, including Kovan. It has not been validated against today’s deployments. The BTC/rBTC PowPeg is a different bridge; use its current documentation for Bitcoin transfers.

Since RSK is an EVM compatible chain, it makes sense that they further offer to transfer Ethereum tokens to it. To move a token between RSK chain and Ethereum mainnet, there is a bridging system that is very easy to use. You can use the following services:

  1. For the mainnet use https://tokenbridge.rsk.co/.
  2. For the testnet (BTC testnet <-> Kovan testnet) use https://testnet.tokenbridge.rsk.co/.

Future RSK Development

The obvious next step for RSK would be integrating the described drivechain design. However since it's relying on a Bitcoin soft fork, we have no idea when or even if this is will be coming in the future. If you have further details about it, I'd love to hear it and please leave a comment.

Otherwise the team is working on bring meta-transactions to the system:

The Research & Innovation team is developing a solution for meta-transactions named Enveloping. The main goal is to allow users to submit transactions to the network through a service provider (Sponsor) and pay for this service in tokens, removing the need to get native currency to operate with our blockchain network.

Horacio S. Caceres (Qubistry)


Have you used RSK before? Maybe even on Mainnet? Let me know in the comments.

Next week we will look at everything one needs to know about ERC-1155, so stay tuned!