Similarities and Differences between RSK and Ethereum

Published in

RootstockLabs: Research & Technology

18 min readJan 11, 2021

The RSK project started as a fork of an Ethereum codebase in 2016 and it was developed for 2 years until it was finally launched in 2018. During those years, crucial data structures were upgraded, and precompiled contracts and new opcodes were added. Since Ethereum compatibility has always been one of the priorities of the RSK community, most changes are invisible to developers and users. When developers look at RSK and Ethereum, they see them as twin brothers.

However, under the hood, RSK has been optimized to scale and process more transactions faster, while Ethereum has devoted overwhelming work to decrease the blockchain synchronization time, mainly due to its large blockchain and state size. Therefore, in reality RSK and Ethereum are more like two compatible controllers for the same game console, but each built by a different engineering team and optimizing for different games.

RSK/Ethereum compatibility and internals

This blog post is not an exhaustive list of the differences between the two platforms. My intention is to present the major (or most interesting) ones. To introduce the differences, it’s important to understand that RSK can improve upon Ethereum but at the same time needs to stay compatible. RSK researchers and core developers frequently analyze compatibility in several categories, which I have listed here. The higher the category is on the list, the greater the importance to maintain compatibility is.

Developer tools compatibility: compilers, debuggers, front-ends, APIs
User interface compatibility: terminology, addresses and concepts such as gas and transaction fees.
Infrastructure services compatibility: applications that access an RSK node through the JSON-RPC interface such as block explorers, online and mobile wallets, core dApps, public nodes.
Network node compatibility: applications that access RSK though the p2p network such as network monitors, peer to peer communication, new p2p protocols, network data crawlers.
Execution cost compatibility: SLOAD, SSTORE, calldata cost, etc.
Internal Data Structures compatibility: applications that access internal RSK data structures such as new full node implementations or internals explorers.

First and most important are the developers. RSK has achieved a high level of developer compatibility as currently most Ethereum development tools can be used for RSK out-of-the-box or with minimum configuration. For example, RSK supports key tools such as web3, Solidity compiler, ganache, metamask, nifty and DeFi dApps.

Next, to provide user interface compatibility, RSK uses the same terminology as Ethereum, the main difference being the unit of account (BTC replacing Ether). Many wallets such as Defiant and Beexo support both RSK and Ethereum thanks to the similarities. Wallet developers need only to make minor changes to the UI in order to support the BTC ticker. Standard concepts such as gas, smart-wallets, ERC-20 tokens, also exist on RSK. RSK further provides user interface compatibility by implementing an address scheme that looks similar to Ethereum’s, while preventing Ethereum addresses from being mistakenly used in the context of RSK smart contracts and vice-versa. However, the RSK ecosystem has matured so much in Latam that some wallets, such as Defiant, started supporting RSK before considering support for Ethereum. On the opposite end, some known wallets, such as in Metamask, force the user to manually configure RSK as a custom network in order to work as an RSK wallet, which degrades the user experience.

Infrastructure service compatibility with the Ethereum network is achieved by supporting standard JSON-RPC commands (commonly referred as web3) that developers and wallets require for issuing, broadcasting, communicating and confirming transactions with RSK nodes. In this regard, the compatibility between RSK and Ethereum covers just enough methods so that most standard tools work. Geth and Parity have a high number of debug methods that are rarely used that are not supported by RSK nodes.

The next category is network node compatibility. As I see it, this is only a minor requirement and I wouldn’t invest time to tweak the RSK node to support the same network messages or protocols. While other members of the RSK community think differently, for me it’s a no brainer: Ethereum is abandoning the Eth 1.0 network standard, so the Ethereum 1.0 network layer will not be maintained and improved after Ethereum 2.0 is ready. There is no point in being compatible with a dead project. Also, since many RSK internal data structures were improved, implementing a new RSK full node- by porting an existing Ethereum node in 2020 is not an easy task. For example, the RSK block headers differ on some fields compared to the Ethereum block header, and also RSK has additional non-trivial precompiled contracts. Some network tools still can be made to support both networks: for example, adding RSK support to an Ethereum block explorer requires only changing the UI to show the modified header fields.

Finally, in the past the RSK community has not shown interest in providing gas-equivalent costs of execution. Even if somebody wanted to, the inherited gas costs would not match the actual resource consumption of an RSK node. This is because the RSK node itself is optimized differently than a Ethereum node: certain operations that are very slow on an Ethereum node are very fast in RSK (i.e. EXTCODESIZE). RSK is moving towards a model that adds storage and access rent at the storage cell level. This update will better protect the node against unforeseen resource-related DoS attacks. Therefore the continuous re-pricing of I/O opcodes that the Ethereum community performs in each net hard fork will not be required for RSK.

Consensus

Nakamoto consensus is a genius idea that combines many different functions into a single protocol, including: money issuance, money distribution, sybil-attack resistance, proof-of-work verification and transaction finality. Over the years, other blockchains have separated these functions into independent subprotocols to optimize certain use cases. Ethereum, for example, seeking a much lower block interval, introduced uncle block rewards to compensate miners with suboptimal connectivity. However uncle block rewards were created by minting new coins, which intervenes with the money supply function and makes it much less predictable. RSK, on the other hand, decided to split the block reward between sibling blocks, which does not introduce a money supply anomaly. A characteristic of Ethereum consensus is that it does not attempt to reduce the incentives for fee sniping (miners deciding to mine a sibling block instead of a child block to steal high-fee transactions from the mined block). Ethereum designers thought this wouldn’t cause problems in Ethereum because the community commitment to maintaining a high miners’ subsidy with infinite issuance over a capped money supply function. However, currently transaction fees have reached the levels of the subsidy, creating an unforeseen risk. RSK does not have a subsidy (and, as a sidechain, it cannot mint bitcoins), so it has been protected from fee sniping from its genesis by smoothing block rewards over many miners. The following table shows the main consensus features of each blockchain.

EVM Similarities and Differences

Almost all Ethereum EIPs were implemented in RSK except for a few where the RSK community was strongly opposed to. The oldest one is EIP161 or “state trie clearing”. This EIP was introduced in Ethereum to clean the trie after an attacker filled the world state with millions of empty accounts abusing a bug in the SUICIDE opcode. Since RSK was launched after that attack, it was born with protections in place. Therefore, all the logic required to automatically and dynamically prune the world state of empty accounts is unnecessary.

Next is EIP114 embedded in EIP150. It relates to a forced lock of 1/64th of the available gas on every contract CALL. I have extensively written about why this change will bring to Ethereum many problems in the future. I have succeeded in convincing the RSK community not to adopt this EIP. If the article is too long for you to read, these are the takeaways: each time the user calls eth_estimageGas() on an Infura node, the node executes the transaction 24 times in a binary search of the gas limit. This not only increases the cost of running nodes but it’s not suitable for Ethereum 2.0 because stateless clients must outsource gas estimation, and Ethereum makes estimation especially expensive, reducing the chances that nodes provide transaction gas estimation as a free service. It is true that Ganache implements an exactimator (an algorithm that computes the gas limit executing the transaction only once), however this requires instrumenting the EVM. RSK eth_estimageGas() allows an exactimator, and therefore needs to execute the transaction only once. A minor difference is that RSK has a fixed maximum stack depth of 400 calls where Ethereum supports approximately 1024, depending on the block gas limit.

Other key differences include the high number of EIPs that try to re-price opcodes to match I/O costs (some already deployed, some being discussed). The most prominent are:

EIP150: Gas cost changes for IO-heavy operations
EIP-1884: Repricing for trie-size-dependent opcodes
EIP-2200: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change
EIP-2035: Stateless Clients — Repricing SLOAD and SSTORE to pay for block proofs
EIP- 2929: Gas cost increases for state access opcodes
EIP- 2200: Structured Definitions for Net Gas Metering
EIP-1153: Transient storage opcodes
EIP-2930: Optional access lists

None of these re-pricings are necessary in RSK because the RSK community has agreed to implement storage/access rent. The RSK community focused on adopting a single platform modification that enables the easy adaptation to changes of the underlying memory technologies without periodic review of gas costs. The proposal is to add storage and access rent at the core of the gas metering. While it took more than 6 iterations to get the storage rent proposal right, the RSK community avoided the endless discussions about resource costs and potential denial of service attacks.

As for the future opcodes that Ethereum is activating in Berlin, such as EIP-2315: Simple Subroutines for the EVM or EIP-2537: BLS12–381 curve operations, both were also implemented in RSK and they are waiting to be activated in Iris RSK network upgrade.

New RSK opcodes: failures or improvements ahead of time ?

When RSK was launched, we knew of several limitations of the EVM, and we expanded the EVM instruction set to support several missing features, such as DUPN/SWAPN opcodes for arbitrary stack position access, REPLACECODE for secure contract code upgrades, TXINDEX for linking events, SEND to transfer coins without call-backs, and more. Although in practice, things turned out to be quite different. The Solidity compiler did not support user-defined opcodes, and the RSK community clearly valued more Ethereum compatibility over the RSK security improvements. As a consequence, no team in the community showed interest in cloning and maintaining a Solidity compiler, as of 2018 the programming language was yet immature, and cloning required continuously rebasing the main project bug fixing commits. Therefore, our community agreed to remove our shiny new opcodes in subsequent network upgrades, hopefully waiting for Ethereum to, sometime, take the lead. The day will come where the RSK community vigorously decides to depart from the EVM standard in the cases where the standard is unable to ensure code safety.

Nevertheless, some of the removed functionality was later re-proposed via precompiled contracts. For example, the dropped TXINDEX opcode, is now re-proposed in RSKIP192.

BLOCKHASH as a source of cryptoeconomic randomness

Many decentralized applications require the generation of random numbers with a certain amount of entropy. This requirement occurs in simple lotteries and in complex smart-contracts that verify given proofs interactively using challenge-response protocols. It has been proven that a certain amount of entropy can be obtained from block hashes in a blockchain with Nakamoto consensus and proof-of-work. Many Ethereum smart-contracts use the BLOCKHASH opcode to obtain the hash of the previous block at a predefined block number. These contracts assume that the block hash carries the proof of work, and therefore it cannot be controlled by an attacker without incurring in losses of unrealized block rewards. However, in RSK, the block hash does not carry the proof of work, as the proof of work is given by the associated merge-mined Bitcoin header. I wrote another extensive article about the options available on RSK to obtain random numbers. Key takeaway: do not use BLOCKHASH on RSK to obtain random numbers. Luckily in the coming Iris upgrade the Bitcoin blockchain oracle will be opened for smart-contracts to query, reaching 200K USD of cryptoeconomic cost per block hash query. This surpasses the cryptoeconomic security of using BLOCKHASH in Ethereum, which is around 4K USD per query.

The use of BLOCKHASH for cryptoeconomic randomness

Precompiled Contracts

RSK supports all of Ethereum active precompiles except BLAKE2 (EIP-152), which is planned to be included in the Iris network upgrade. RSK provides additional precompiles, not currently supported in Ethereum:

BRIDGE, “0..1000006”. Allows contracts to register peg-ins and also to query the Bitcoin headers in the best chain.
REMASC, “0..1000008”. Distributes rewards to miners. Called once per block.
HD_WALLET_UTILS, “0..1000009”. Provides utilities to develop a BTO (Bitcoin Token Offering).
BLOCK_HEADER, “0..1000010”. Enables contracts to query the RSK blockchain for information regarding the past 4000 blocks.

The last contract (BLOCK_HEADER) is very interesting in that many dApps require accessing the blockchain history for proving that certain transactions have been executed. For example, certain insured meta-transactions systems require accessing the transaction history in case of disputes. If the relayer cannot prove transaction inclusion at an agreed time, it has to pay a penalty to the user. Recently, the paper “Adaptive layer-two dispute periods in blockchains” proposes accessing past block headers to prove that there was no congestion in order to end a dispute. For that use, 256 block headers provided by BLOCKHASH is not enough for a sufficiently large dispute period, while the 4000 blocks provided by the BLOCK_HEADER contract is.

Average Block Rate

RSK’s currently average block interval is 33 seconds, while Ethereum’s average block interval is currently 14 seconds. Smart contracts should not rely on the average block interval for computing distant deadlines if high precision is desired, as the block interval fluctuates during periods of steep difficulty adjustment and because the RSK community may decide to shorten this interval in future network upgrades. For distant deadlines, smart contracts should query the block timestamp. This is also true for Ethereum, whose average block interval has oscillated between 14 seconds and 30 seconds over the years.

It’s also important to note that RSK targets a specific block density (or blocks over time) including mainchain blocks and uncles. This means that if the rate of uncle blocks decreases, so will the average block interval. Absent of uncles, the RSK blockchain produces a 15-seconds average block interval.

Uncles Per Block

Ethereum is designed so that uncles are exceptional, and a healthy network is characterized by a low number of uncles, close to 4%. On the contrary RSK is designed so that miners are not pressed to create a new block template each time a new RSK block is added to the blockchain, and this leads to a much higher rate of uncles. Having one uncle per block is common in RSK. This is intentional, as RSK tries not to interfere with the efficiency of Bitcoin mining. To counteract this naturally occurring high rate of uncles, the RSK network shares the block reward with all miners that mine the same block height. This design choice, together with block reward smoothing, turns the highly competitive game of Bitcoin mining (in terms of template creation latency, and block propagation) into a more cooperative game.

Block Difficulty Adjustment

RSK adjusts the block difficulty by a factor of 1/400 per block, while Ethereum does it at a factor of 1/2048 per block. While RSK had a plan to switch to a smoother algorithm (see RSKIP77), the need for such change was never strong enough to drive the inclusion of the RSKIP in a network upgrade.

Block Header

The RSK block header is similar to Ethereum’s, with the exception of certain fields related to merge-mining. These differences are presented in the following table.

Fields that exists only in RSK:

paidFees specifies the amount of fees paid by the transactions on this block, expressed in BTC wei.
minimumGasPrice is the minimum gas price that transactions in this block can pay. This value is chosen by the majority of the miners with an onchain voting mechanism.
ummRoot represents a hash of a tree to reference other merge-mined blockchains in the bitcoin block. It enables the Universal Merge Mining subsystem in RSK.
bitcoinMergedMiningHeader is the Bitcoin header that contains the merge-mining proof.
bitcoinMergedMiningMerkleProof is the Merkle inclusion proof of the Bitcoin block coinbase transaction into the header. This is used to prove merge-mining.
bitcoinMergedMiningCoinbaseTransaction is the tail of the block coinbase transaction, where the RSKBLOCK tag, which indicates merge-mining, is located.

Fields that exists only in Ethereum:

mixHash: used for ETHash mining, not required in RSK because RSK is merge-mined with SHA256.
nonce: used for ETHash mining. RSK uses the nonce field in the Bitcoin header.
baseFee (EIP-1559): this represents the base fee described in EIP-1559. It has a similar role as minimumGasPrice in RSK, but Ethereum adjusts this value automatically, where RSK does based on miner’s votes.

Universal Merge Mining (UMM) subsystem in RSK

Universal Merge Mining allows RSK to share its merge-mining hashrate with child blockchains. UMM builds on the concept of Blind Merge Mining and extends it by supporting flexible and per-chain block auction policies. While no other blockchain or RSK sidechain has taken advantage of this feature, the UMM subsystem waits patiently in RSK. The UMM system was added to RSK to support RSK sidechains similar to shards, but secured by proof of work. The design is based on an innovation called Syncchains. Still, the maximum transaction capacity of RSK has not been reached and there is still no need to build RSK sidechains.

The UMM system is really versatile. Last year (2020), while the Ethereum Classic Blockchain was being periodically 51%-attacked, we proposed an ECIP to use the UMM system in RSK to transfer Bitcoin hashing power to ETC to prevent long regorganizations.

I’m anxious to see demand for UMM in the upcoming years.

Block Proof of Work Computation

RSK block proof of work computation differs from Ethereum because RSK is merge-mined with Bitcoin. The following diagrams compare how both chains obtain proof-of-work. The diagrams also show how the block identification hash is computed on each chain.

RSK’s apparent complexity of the proof-of-work verification comes from the fact that RSK has to understand Bitcoin block headers to extract its proof of work. However, Ethereum’s proof-of-work verification is by design far more resource intensive, both in space and time. All of the complexity is hidden within a single box called “Hashimoto Mixer”. The reason for this complexity is that Ethereum chose to use a PoW-function aimed to be ASIC-unfriendly and GPU-friendly. Those objectives were met for some years, but currently efficient Ethereum ASICs exist, so Ethereum has to carry with the resource-intensive PoW verification without any benefit. In fact, the heavyweight PoW limits the possibilities to create efficient NiPoPow or FlyClient-based light clients. On the contrary, RSK requires relatively low resources for the PoW verification. The following table highlights the differences:

Ethereum vs RSK in relation to the PoW function

Finally, it’s worth mentioning that Ethereum has an embedded proof-of-work “time-bomb”, often called difficulty-bomb, that forces developers to periodically hard-fork Ethereum to prevent the network from stalling. The objective was to force the community to move to proof-of-stake when ready, although due to the delay of Ethereum 2.0 such time-bomb lost its main purpose.

Block Transactions and REMASC

Block content is slightly different in RSK blocks since RSK mandates that the last transaction of a block is a special transaction that calls the precompiled REMASC contract, which distributes rewards according to a formula that is different from Ethereum’s. Ethereum pays all block reward to the miner of the block. RSK distributes the rewards smoothly over time to all the miners, based on a shared miners’ account that collects rewards. All revenue goes to the shared account and each miner takes only 10% of their share of accumulated rewards per block. One key difference compared to Ethereum is that RSK rewards are not paid immediately, but they have a maturity period of 4000 blocks. You can learn more about REMASC here.

World State Storage

RSK uses a new memory-efficient authenticated binary trie for storing all account and contract information. This data structure, called Unitrie, has special features that enable storage rent, parallel transaction execution, in-memory compression, easy garbage collection, stateless clients, shorter membership proofs and simplified witnesses.

The Unitrie combines all individual contract tries in the global account trie, and this reduces the complexity of the full node when handling blockchain reorgs. More information on this topic can be found here. I will only summarize the main differences.

First, the Unitrie is a single data structure, unlike the Ethereum world state, which is composed of millions of different tries, connected by hashes. The following diagram compares Ethereum and RSK tries:

Ethereum and RSK world state organization

In RSK, the contract storage cells are child nodes of the account node. Removing a contract is as simple as removing the account node: all dependent nodes are removed altogether when the garbage collector passes. Code is also a child node of the account node, which means that the account does not need to store an additional code hash, saving more than 50% of the account space and adding millions of potential additional account records that the trie can support in-memory.

Another fundamental difference is how the account and storage addresses are converted to build the trie keys. The following diagram illustrates those differences:

In Ethereum, the account address is hashed to index the account trie, and then the cell address is hashed independently to index the storage trie corresponding to the account. In RSK, both account and storage addresses are concatenated, but the original keys are not lost! The addresses are also hashed to prevent the degeneration of the binary tree, but only 80-bits of the hash are used for element position randomization. This leads to both shorter keys, and also the ability to recover all keys and avoid storing an additional pre-image map to support debugging with a node.

Finally, deep inside, the RSK trie is different from Ethereum’s. The RSK trie is a very simple binary tree, having a single kind of node. Ethereum data structure is Radix-16, and has 3 types of nodes, which not only increases the implementation complexity but also requires more space and time for the verification of membership proofs. The following diagram illustrates those differences:

Mining

RSK does not use a new native cryptocurrency, but relies on Bitcoin. This had a profound effect on the design of RSK. RSK economics is unique among the existing blockchains. RSK is merge-mined with Bitcoin, which means that it shares the same mining infrastructure as Bitcoin, and does not rely on a different mining network, as in Ethereum. You can read more about how RSK merge-mining works here.

RSK is a Bitcoin sidechain and therefore it does not mint a new native cryptocurrency. Blocks do not provide subsidy for the miners. Miners only earn transaction fees. Transaction fees are not directly paid to miners, but they enter a shared account. Each miner takes 10% of their share from this account spread over several block intervals. This prevents the fee-sniping attack that can affect Ethereum, among other attacks. You can read all about how blocks rewards are distributed here.

Integrated Two-Way Peg with Bitcoin

While Ethereum tried to create a bridge with Bitcoin with the btcrelay project, the once functioning system was abandoned due to high maintenance costs and lack of applications willing to pay for that cost. RSK, on the contrary, has an embedded and efficient SPV bridge with Bitcoin that enables not only peg-ins and peg-outs, but also provides Bitcoin blockchain oracling services to smart-contracts at a low cost. This feature enables interesting decentralized applications such as trustless RSK-BTC swaps, Bitcoin hashrate derivatives, Bitcoin transaction inclusion insurance, and surely many more applications yet to come.

Summary

RSK and Ethereum look alike, but internally are quite different. The RSK developers past and present dedicated many months to make sure the design was capable of scaling without any major technical redesigns. On the contrary, the initial Ethereum developers were in a hurry to deliver a working product. They planned to create a blockchain that could be useful to test certain social and technical hypotheses, but ultimately the blockchain 1.0 was designed to be discarded for a new version of Ethereum (2.0) based on proof-of-stake. The need to extend the life of Ethereum 1.0 led to very valuable community efforts in reducing blockchain synchronization time, and lately with the release of Turbo-geth, execution time. However, key internal components of Ethereum remain outdated. RSK, which launched two years after Ethereum, had the opportunity to learn from some of Ethereum’s faults and start with better internal data structures, among other improvements. The improved RSK core may be key to the long term sustainability of the RSK blockchain without the risks, both technical and regulatory, of a full blockchain migration.