Technology

RSK platform is, at its core, the combination of:

A Turing-complete resource-accounted deterministic virtual machine (for smart contracts);

A two-way pegged Bitcoin Sidechain (for BTC denominated exchange) based on a Federation secured with custom Hardware Security Modules. Once the drivechain protocol becomes implemented on Bitcoin, the original plan is to move to a hybrid-drivechain mechanism;

A selfish-mining resistant merge-mining-based consensus protocol;

A low-latency block-propagation network (for fast payments).

Turing-Complete Virtual Machine

RSK virtual machine (RVM) is the core of the Smart-contract platform. Smart-contracts are executed by all network full nodes. The result of the execution of a smart-contract can be the processing of inter-contract messages, creating monetary transactions and changing the state of contract-persistent memory. The RVM is compatible with EVM at the op-code level, allowing Ethereum contracts to run flawlessly on RSK. Currently, the VM is executed by interpretation. In a future network upgrade, the RSK community is aiming to improve the VM performance substantially. One proposal is to emulate the EVM by dynamically retargeting EVM opcodes to a subset of Java-like bytecode, and a security-hardened and memory restricted Java-like VM will become the new VM (RVM2). This may bring RSK code execution to a performance close to native code.

Main features:

Independent VM, but highly compatible with EVM at the opcode level

Run Ethereum DApps with the security of the Bitcoin network

Performance improvement pipeline documented in numerous RSKIPs (RSK improvement proposals) created by the RSK community

Sidechain

A sidechain is an independent blockchain whose native currency is pegged to the value of another blockchain currency automatically by using proofs of payment. There is a two-way peg when two currencies can be exchanged freely, automatically, and without incurring in a price negotiation. In RSK, the Smart Bitcoin (RBTC) is two-way pegged to the BTC.

In practice, when BTC are exchanged for RBTC, no currency is “transferred” between blockchains in a single transaction. When a transfer occurs, some BTCs are locked in Bitcoin and the same amount of RBTC is unlocked in RSK. When RBTC needs to be converted back into BTC, the RBTC get locked again in RSK and the same amount of BTC are unlocked in Bitcoin.

Fully trust-minimized and third-party-free two-way pegs can be created if two platforms have Turing-complete smart-contracts. But since Bitcoin does not currently support smart-contracts nor native opcodes to validate external SPV proofs, part of the two-way peg system in RSK requires trust on a set of a semi-trusted third-party (STTP), that RSK team collectively calls the Federation. No single STTP can control the locked BTCs, but only a majority of them has the ability to release BTC funds. Each STTP has a key to protect the BTC that are locked, and upcon receiving commands from the RSK blockchain, it unlocks the BTC that need to be transferred back into Bitcoin. Note that if a user transfers BTC into RBTC and back, they will normally not receive bitcoins that are directly connected by UTXOs with the original BTC sent. Therefore, do not lock RBTC for specific users, but for the whole RSK network.

The locking and unlocking of funds is done by the Federation without any human intervention. A requirement for being part of the Federation is the ability to audit the proper behavior of the software that powers the node, especially regarding the correctness of the component that decides on releasing BTC funds. RSK Labs developed a firmware for a Hardware Security Module (HSM) that STTPs can use, in order to provide maximum security for their private keys and, in the future, to be able to enforce a transaction validation protocol to further improve security.

As of January 2019, the RSK Federation comprises 15 well-known, and highly-secure notaries. Leading Blockchain companies currently integrate the RSK Federation and participate in an autonomous protocol to securely lock Bitcoins. In exchange for their work, Federation members are awarded 1% of the transaction fees generated on RSK, in order to cover the hardware and maintenance costs. There is an automated process to modify the composition of the federation. Each federation member can either accept or reject a composition change. The process, which is infrequent, is commanded by a smart-contract, so it’s open to the public. The protocol has a consensus enforced delay of one week until the change is activated. This allows users to transfer the Bitcoins back to the Bitcoin network in case they do not trust the new Federation composition.

If Bitcoin adds special opcodes or extensibility to validate SPV proofs as a hard-fork, and once the new system is proven to be secure and trust-free, the Federation role as STTPs will no longer be necessary, and the RSK community may implement the changes to adapt RSK to the trust-free system. The RSK community have also proposed a drivechain BIP, which enables miners to participate in the securing of the Bitcoins in the peg, and decreases the trust required on the STTPs even more.

Merged Mining

Satoshi consensus, based on proof-of-work, is the only consensus system that prevents the rewrite of blockchain history at a low cost. The academic community is advancing the knowledge and study of proof-of-stake as an alternative, but currently PoW provides the highest proven security. Merge mining is a technique that allows Bitcoin miners to mine other cryptocurrencies simultaneously with nearly zero marginal cost. The same mining infrastructure and setup they use to mine Bitcoins is reused to mine RSK simultaneously. This means that, as RSK rewards the miners with additional transaction fees, the incentive for merged mining becomes high.

RSK team has identified three phases for RSK merge-mining growth:

- bootstrapping phase: merge-mining is below 30% of Bitcoin hashrate.

- Stable phase: merge-mining is between 30% and 60% of Bitcoin hashrate.

- Mature phase: merge-mining is higher than 60% of Bitcoin hashrate.

RSK has left behind its bootstrapping phase, when rogue merge-miners could revert RSK blockchain at a low cost. As of January 2019, more than 40% of Bitcoin miners are engaged in RSK merge-mining. But as RSK fees remain low compared to Bitcoin block reward, the cost to attack RSK by a double-spent is lower than Bitcoin’s.

RSK has some properties to reduce the risk of double-spend attacks, such as long miner rewards maturity. Still RSK Lab research team has developed several protections to prevent attacks during the stable and mature phases of the project:

Signed notifications: RSK clients can make use of signed notifications by notaries. Nodes can use these notifications to detect Sybil attacks and inform the user.

Transparent double-spend trails: this is a method where all RSK merge-mining tags are augmented with additional information that can be used to detect selfish RSK forks that are public in the Bitcoin blockchain. Selfish-fork proofs are automatically constructed and these proofs are presented to the RSK nodes, which spread them over the network. The proofs force nodes to enter a “safe mode” where no transaction is advertised as confirmed. The safe mode prevents merchants and exchanges from accepting payments that could be double-spent. Once the proven selfish-fork is outpaced by the RSK mainchain in accumulated PoW, the network reverts to its normal state. This method is a deterrent for any RSK double-spent attempt (where the malicious miner still tries to collect Bitcoin rewards when mining the selfish fork).

Once the platform enters the maturity phase, RSK team estimates the security of RSK will be enough to support the economy of worldwide financial inclusion.

Main features:

DECOR+ consensus protocol

one-day maturity for mining reward

No loss of efficiency in Bitcoin mining expected from merge mining (for late midstate switching)

Fast Payments and Low Latency Networks

RSK already enables second layer off-chain payment networks, but still RSK aims to provide a much better on-chain payment network compared to Bitcoin. To achieve this, RSK adopts the DECOR+ and FastBlock5 protocols, which allow reaching a fifteen second average block rate that does not create incentives for mining centralization and selfishmining.

Main features:

fifteen to thirty second block intervals (depending on the miner’s state switching efficiency)

Full network propagation of last competing blocks to prevent selfish mining and reduce stale block rate

New network command to spread block headers with time critical priority

DECOR+ protocol for reward sharing between competing blocks

GHOST protocol for chain weighting

Since the creation of Bitcoin there has been a race towards lower intervals for PoW blockchain based cryptocurrencies. But low block interval may impact the stability and capability of the cryptocurrency network, so several design factors must be considered. First of all, the most important factor that affects the viability of short confirmation intervals is the number of stale blocks generated. The main factor that affects the stale block rate is the block propagation protocol. For RSK the team has carefully analyzed this protocol and they have run simulations in order to verify the performance, usability and security of the network.

In Bitcoin, when two or more miners have solved blocks at equal height, there is a clear conflict of interest. Each competing miner wants his block to be selected by the remaining miners as the best-chain tip, while the remaining miners generally would not care which one is chosen from the two. However, all the remaining honest miners and users have a rational preference that the same block tip is chosen, because this reduces the reversal probability. The DECOR+ consensus protocol sets the right economic incentives for a convergent choice, without requiring further interaction between miners. The DECOR+ protocol is a reward sharing strategy that incentivizes resolving the conflict economically such that:

The conflict is resolved deterministically when all parties have access to the same blockchain state information The chosen resolution maximizes all miners’ revenue (collectively) and for both the miners in conflict in case block rewards differ by a high margin The chosen resolution maximizes censorship-resistance if competing blocks have approximately similar rewards Resolving the conflict takes negligible time

Transaction Privacy

RSK does not provide better transaction privacy by itself than Bitcoin and relies on pseudonyms. Nevertheless, the VM of RSK is Turing-complete, so anonymization technologies such as CoinJoin, ring Signatures or zCash can be implemented securely without third-party trust.

Scalability

RSK can scale far beyond Bitcoin in its current state. An RSK payment requires a fifth of the size of a standard Bitcoin payment. Using the proposed LTCP protocol, transaction size can be reduced to 1/50th of a Bitcoin transaction size. This immediately leads to a substantial increase in transaction volume capability. Besides, there are community proposals (RSKIPs) to enable user-selectable signature schemes: ECDSA, Schnorr and Ed25519. Because Ed25519 is more performant than Bitcoin ECDSA curve, using this scheme may lead to even more capacity.

Source.

2WP Designs

The most common 2WP designs are presented: sidechain, drivechain and multi-sig custody and hybrid designs. To simplify the explanations, we’ll call secoins to the bitcoins that have been transferred to the secondary blockchain.

Single Custodian

One possible option to implement the 2WP is having an exchange holding custody of the locked bitcoins and holding custody of unlocked equivalent tokens. The exchange would manually enforce the promise of locking bitcoins before unlocking secondary tokens either manually or by means of a protocol executed in software. This setup is depicted here:

Multi-sig federation

A better way to implement a 2WP is having an group of notaries control of a multi-signature, where the majority of them has to approve the unlock of funds. This setup is better than having a single controller of the funds, but may still centralize control. To achieve true decentralization, the notaries should be carefully selected so they are located in different jurisdictions, different geographies, and each having good reputation and good security. Also they must not be too few, nor too many.

This setup is depicted here:

Sidechains

Trying not to involve more third parties in the 2WP, each blockchain can enforce the premise by implementing a protocol validated by consensus. Each blockchain must understand the consensus system of other blockchain and can therefore automatically release bitcoins when given proof of a lock transaction in the other blockchain, as depicted here:

However, there are several problems when using sidechains for Bitcoin:

Most public blockchains do not have settlement finality. If the secondary blockchain does not have it, then the Bitcoin blockchain can never be sure if a secondary transaction has been accepted by the secondary network (e.g. locking secoins). All it can get is a probabilistic assurance: more proof-of-work confirming a transaction means it is more probable it has been accepted.

Even if the secondary blockchain has settlement finality, without blockchain entanglement (see next section) then the secondary blockchain suffers the same problem about the Bitcoin blockchain. If there is entanglement, then the secondary blockchain block rate cannot be higher than Bitcoin’s rate.

Sidechains in Bitcoin requires a soft-fork or hard-fork to add new complex opcodes. Blockstream proposal is currently incomplete and does not address the validation of proof-of-work of SPV proofs.

Entangled Blockchains

One way to overcome the lack of transaction finality for the 2WP is to entangle both blockchains such as the reversal of the lock transaction in the primary blockchain implies the reversal of the unlock transaction in the secondary blockchain. There are several ways to entangle blockchains:

The transactions of the secondary blockchain are embedded in transactions of the primary blockchain (e.g. in OP_RETURN payload, such as in Counterparty) Secondary blocks have two parents, one in the secondary blockchain and one in the primary blockchain. Secondary blockchain nodes verify that primary parents belong to the same Bitcoin best chain. Secondary blocks are anchored by cryptographic commitments in primary blockchain transactions.

The first two options allow the secondary chain to verify an SPV proof without requiring the prover to provide confirmation headers because the secondary blockchain client also maintains a copy of the Bitcoin blockchain (a full blockchain in the first option, and only the headers in the second option). The third option does not allow this.

The following diagram shows a sidechain transferring bitcoins into the secondary blockchain without additional confirmations (at the fastest possible Bitcoin speed):

Entangling blockchains have several drawbacks:

It prevents the secondary chain from creating blocks at a higher rate that Bitcoin because of the uncertainty in the acceptance of blockchain branches before anchoring. Should a short anchored branch be taken as the best chain over a longer non-anchored chain?

When embedding secondary transactions in Bitcoin transactions, all users of the secondary blockchain need to process the transactions of both chains.

Entangling solves one direction of the problem of settlement finality, but does not solve the problem of custody of the primary blockchain locked bitcoins.

Drivechains

A drivechain gives custody of the locked btc to the Bitcoins miners, and allows Bitcoin miners to vote when to unlock bitcoins and where to send them. The miners vote using the bitcoin blockchain, and votes are cast in some part of the block (e.g. the coinbase). The greater the participation of honest miners in the drivechain, the more secure it is. The following diagram depicts a drivechain:

Hybrid Models

All the designs presented so far are symmetric: the method used to unlock secoins is the same used to unlock bitcoins. But the primary and secondary blockchains are essentially different: the primary issues new native tokens and the secondary does not. This has huge consequences in terms of security and it suggests that a symmetric 2WP model may not be adequate. A hybrid 2WP is a 2WP using a different unlocking method for each side, such as using a sidechain on the secondary blockchain and using a drivechain on the primary network.

RSK Case

The case of RSK is special. RSK relies on a fundamental design choice: it must allow merge-mining with Bitcoin. Therefore RSK team must analyze which is the best design for such case. RSK team takes into consideration:

which parties control the locked bitcoins

what is the cost of an attack

what are the consequences of an attack

what incentives are at play

If the involvement of Bitcoin miners in merge-mining is almost total, RSK team found that the actors that have the highest incentive to be honest when being custodial are the Bitcoin miners, but only when almost all of them are engaged. In case of merge-mining, both drivechains and sidechains rely entirely on the honesty of Bitcoin miners, and both offer the same security. However sidechains are much more complex to implement on the Bitcoin side, so for the Bitcoin side, the best choice for RSK is using a drivechain. On the RSK side, RSK team implements a sidechain. So the RSK hybrid model at this point could be defined as Drivechain/Sidechain.

When the merge-mining engagement is low, drivechain/sidechain offer little security. Therefore, RSK team proposes a hybrid model where the security of locked bitcoins is based on a drivechain plus a set of notaries. The miners and the notaries vote (with different weights) on which bitcoins to unlock. Notaries vote with their digital signature, while miners vote by adding a special tag in their coinbase transactions. This is a trade-off between centralization and security. The final RSK 2WP design can be defined as Drivechain+Notaries/Sidechain. To set the votes weights, RSK team uses of a dynamic method based on the merge-mining engagement. At first, only the notaries will vote, in a classical multi-sig transaction. In the mid-term, when drivechains capabilities are added to Bitcoin, both the notaries and the miners will vote along each other. In the long-term, when the merge-mining engagement reaches 90%, the notaries will cease to vote, and only the miners will. This evolution is depicted in the following figure:

In essence RSK team proposes that the security of the locked bitcoins rests on the miners and a set of notaries, but the amount of power between these two groups is dynamically adjusted in relation to the amount of merge-mining engagement.

Source.