On this post, we get the April 2019 AMA answers from RSK & RIF Chief Scientist, Sergio Lerner.

What real world use case projects are under development? Do you have any examples?

There has been an acceleration of developers choosing to build their solution on top of RSK. Some of the solutions/implementations already available on the RSK platform are Circle of Angels, Bitgive and Blockchain for Humanity (all of them charity initiatives), dexFreight which is a logistics platform; Watafan, a dapp for fans,  Tokkenit a loyalty app & Insuretech, an insurance protection solution. We also have Chronologic for decentralized scheduling and new ones that are under development such as Investoland (a global decentralized investment platform), Money On Chain (a solution aimed at managing the volatility of crypto assets) and Gasnor from Grupo Sabra which provides a solution for gas distribution. These are just a few examples.

 

There was a mention on Twitter a while back about possibly implementing Chainlink as an answer to your Oracles: http://bit.ly/2H7z8uV. Could you please provide an update on the progression (if any yet)?

RIF Data Gateways service is designed to support different Oracle-Services. One proposed implementation is a decentralized Oracle service based on the Chainlink Core oracle-network node. We’re evaluating a Chainlink-based service provider for RIF Data Gateways. It uses a modified Chainlink node so that node operators can accept either LINK or RIF tokens as payment for their Oracle services. Node operators would then be able to serve requests coming from the RSK network (paid in RIF Token ) and the original requests coming from the Ethereum network (paid in LINK token)

 

Are you considering to implement some solution related to decentralized identities as a service in RIF? Maybe some kind of decentralized identity management layer, decentralized PKI, decentralized web of trust or Self Sovereign Identities. Are you working or in contact with some other organizations or foundations working on that particular area? I think that it could be a major value and advantage over other smart contract platforms.

Yes. RIF Identity is one of the most important components of RIF Libraries. 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.

 

Could you explain something about storage services in RIF?  Would it be like IPFS? Will it use IPFS or some other similar 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 RIF Data Storage protocol. For a first network provider, we looked at the existing solutions (Swarm, IPFS, Storj, Sia, etc.) and decided to base it on Swarm. Most of these protocols implement a variation of following: an uploaded file splits into chunks and gets 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. The innovation we are bringing at this point, is simplifying the incentive model and proof mechanisms. Of course, RIF Data Storage will integrate with other RIF services like RNS (to retrieve named files and allow mutability) or RIF Payments for incentivization. Additionally, in future we’ll foster the integration of all successful storage networks under the same RIF 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.

 

What has changed after the Orchid v0.6.0 Network Upgrade. Do you have any more upgrades planned?

RSK Labs periodically releases new versions of RSK client including new features, bug fixes and security updates. Orchid Version 0.6.0 was the latest network upgrade, mainly containing changes to STATICCALL opcode to enable support for Solidity 0.5.x contracts. We released two new versions after 0.6.0, both containing minor bug fixes, performance improvements and blockchain storage requisites reductions. Orchid 0.6.2 has also major code base refactors, in preparation for RSK’s next network upgrade version 1.0.0. The 1.0.0 version is on its final testing stage, so its release is close. This network upgrade includes the Unitrie (new design for the internal data structure that maintains the world state), new shift opcodes (for Ethereum compatibility) and Federation security improvements, among other things. Our releases are always communicated through our blog (https://blog.rootstock.io/noticias/) and there is a more detailed list of each release’s features in our Github’s milestones page (https://github.com/rsksmart/rskj/milestones).

 

How does rootstock compare with similar bitcoin sidechain projects?

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 upcoming RSK network upgrades, we may see two important developments implemented: the LTCP protocol (see RSKIP53) and parallel transaction processing (see RSKIP04). These improvements together, enable a 30x transaction throughput increase on 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 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.

 

Why is RBTC listed on exchanges?

We listed RBTC in exchanges to make it easier to the less technical users to get access to it. As I said, 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. We expect more demand of RBTC as more users start using the platform.

 

Ethereum is going to change a lot in the next couple of years. What do you think about Ethereum 2.0 and specially about their plans to use eWASM instead of EVM. What is RSK strategy?

I think 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 on 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. Hence, 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.

 

What is RSK scaling strategy? Do you plan anything sharding-like or you think that RSK already is scalable enough so people can just build Plasma-like child chains and state channel stuff for their apps. If RSK is already scalable enough, how many tx/s you plan to support after implementing Unitrie?

On RSK Research Lab, we evaluate new proposals and work on scaling methods frequently.  The scaling long term strategy has still not changed much since RSK was launched. The main priority is to reduce resources consumed by onchain transactions as much as possible. Why? Because all layer-2 solutions require emergency procedures where users must go onchain for arbitration in case of disputes. In case of Payment Channel Networks, publishing the last states in limited time-windows is critical. If the onchain capacity is too low or if transaction costs are too high, then the poorer users (which are transacting lower amounts), will risk losing their locked deposits. This is because the cost of arbitration will be higher than the amounts locked.

So we developed a generic and innovative framework to scale blockchains: shrinking-chain scaling. It’s based on the insight that the blockchains can be compressed, and also that the compression technique used can involve interactions with the users to rewrite past parts of the blockchain. This means that a block can be compressed after it has been mined. This is specially powerful for blockchains with VMs, when compressing transactions means providing proofs of executions that are expensive to generate. Two interesting protocols are MimbleWimble and Coda: both attempt to compress the blockchain during mining. MimbleWimble is extremely lightweight because it’s based on aggregatable cryptography, it does a great job to compress a block before its mined. Coda, on the contrary, requires a lot of processing by the miners, and the consequence is that average block intervals must be long.  Shrinking-chain scaling can delay this processing and compression can be market based, the blockchain provides monetary incentives for compression. It can also be mandatory: blocks are compressed after some predefined time. A special case that is simple yet powerful is signature aggregation. Signatures take 70% of the transaction space in RSK. Therefore, we developed the LTCP protocol, that fits in the shrinking-chain framework. LTCP removes unnecessary signatures and also compresses transactions using user-defined presets. If RSK applies LTCP in a network upgrade, we could enable the RIF payments network to serve a 10M users today, 100M users in two years and a billion users in five years, using some reasonable projections on usage patterns for 2nd layer networks. And this could be accomplished while still enabling standard PCs to run full nodes.

To advance towards this long term plan, we’ve proposed for the next network upgrade several new features: storage rent (see RSKIP113), parallel transaction processing (RSKIP04), and for the following one, LTCP and a new faster VM. Each one of them enables a decrease in the cost of payments. Since RSK is focused on financial inclusion, secure, fast and cheap payments is our priority.

Now what about scaling contract execution? RSK-Sidechains (or shards) and verifiable computation (and zero-knowledge proofs in particular) are two techniques for smart-contract executing scaling that are being evaluated by many blockchain development teams, and I’m sure the best solution has not yet been created. If the onchain VM is expressive and fast enough, we create the conditions for these solutions to be built on top of RSK. Other networks may implode because onchain scaling was not correctly addressed, or was addressed too late. With a good onchain layer, everything is possible. So we are now focusing in having the cheapest onchain infrastructure to enable financial inclusion. Plus, the Lumino 2nd layer payment solution for RIF payments and other projects, will take the lead bringing more 2nd layer scaling solutions.

 

Can you compare Ethereum and RSK blockchain size? I mean is RSK chain growing at the same speed as Ethereum?

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. With the advent of the Unitrie that 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.

 

Solidity is not the best language (especially in terms of security). Do you have any plans about adding other languages (i.e. Vyper)?

We’re evaluating the use of the Java toolchain, and becoming compatible with the AVM (AION virtual machine). Java is the language of choice by enterprises because it’s typed and easy to audit. It’s a great choice to write secure smart contracts.

 

Guys from IOHK are working on KEVM type of sidechains. They promote that with K framework, it’s much easier to formally verify correctness of a smart contract code. Now, Ethereum 2.0 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 better than Ethereum implementation. Which are your thoughts about this?

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. And I can continue debating on the pros and cons of each VM at the opcode level. But it’s clearly too early to pick a winner!

RSK is here for the long term. It was created to use the best available technology, and that technology may not come from 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. 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.

 

I want to ask a few questions about your “The Return of the Deniers and the Revenge of Patoshi” post:

A – How long it took you to do this research?

If you mean the whole research about Satoshi blocks, it started back in 2013 (and still continues) but adding up, I suppose I have dedicated not more than months’ work.

B – How did you discover the “three privacy-related flaws” to correlate the blocks? Just reading the early client or is there something else?

Just reading the original source code, and by asking the right questions. Also many members of the community collaborated with me providing good hypotheses. I was never alone.

C – After this research, do you think that this was fair or this could make us think different about Satoshi? Why?

I think it was the fairest it could be. Patoshi mined the minimum amount of coins required to keep the network going. The amount of coins collected, is only the result of the time it took the world to know and trust Bitcoin.  As soon as the network sustained itself, it seems that he stopped mining. Also, the almost undeniable fact that Patoshi spent no more than 5 USD (at the historic value), has a profound meaning of humility. In fact, I always thought the Patoshi blocks are marked on purpose. And the purpose is to transmit that message to future generations.

D – In the Nonce Restriction in all Patoshi Blocks paragraph, you talked about a proof that you found to check the pattern by other ways. Could you please comment on how you got the proof?

There is enough mathematical proof. If people still want to disbelieve, then there is no rational thing one can do to change that.

E – At the end of the article, you stated that “there is evidence that links the Patoshi patterns to Satoshi, based on public information sources and the blockchain”. Could you comment on this? How you can link the pattern with Satoshi?

Just follow the blocks.

 

How does the $RIF token accrue value? My understanding is that people can use RBTC to pay for third-party services on the RSK network. Hence, $RIF token feels somewhat unnecessary.

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 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’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 the 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, etc). In that context, having a portable/neutral token is a benefit.