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. According to IOV Labs Chief Scientist, Sergio Lerner “I’m not scared of having several VMs running on a node. They are easy to encapsulate. But I suppose that in 20 years there will be only one preferred VM, and the rest VM bytecodes will be transpiled into it”.

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.