Recently, I wrote about having a second layer (not a payment channel, but a full blockchain with smart contracts) in my post One Second Layer to Rule Them All. Although that proposal don’t need to have special features (it could be based on simple Ethereum 1 nodes), it could have some features inherited from the first layer. And if the first layer would be RSK network, maybe it could be interesting migrate some of those features.

And although it is not in my to do list, sometimes I think about how to add some RSK features to my personal blockchain project. In this post, I want to share some of the thoughts I have when visiting these ideas.

Implementation Agnostic

First, if I had to reimplement RSK features, I will choose to have an agnostic approach. Some years ago, I proposed to develop a C# node, implementing RSK ideas, but it never happened to be a concrete project. My intention was to have an alternative implementation, using another programming language, as a “litmut-test”, only to be sure the main implementation keeps a healthy independence of any programming language (RSK current implementation is in Java, read my post Inside RSK Java Implementation).

Given the current status of Ethereum 1x development, my first choice today would be using Geth or Parity (the node name is now OpenEthereum) or both. Geth is written in Golang, OpenEtheruem is written in Rust. Both programming language have interesting features to be used in a blockchain development. For some Golang qualities in blockchain development read Why I am building a blockchain in Go (simplicity, compiled and portable code, efficiency, oriented to distributed systems, etc).

Key Features to Port

If I should choose the key features that makes RSK what it is, I will choose two:

I could add the rewards logic, and I will, but it looks to have less importance: if you have limited resources, maybe you could leave rewards logic to another occasion.

So, the big picture is:

From Ethereum to RSK

Implementation Ideas

If you read my posts in this blog, you know that I’m a big proponent of simplicity. Now, after working more than four years in RSK, I think I have a good idea of how to re-implement this features, to comply with my design inclination for simple solutions.

Merge mining could be the easy one. It’s only imply to expose two JSON RPC methods, and change the proof of work validation. But I think that the original proof of work could be ALSO live side to side with the new way of mining a block. Maybe, only use the merge-mining proof of work on designated heights (ie heights divisible by 10 or 100). It is a bit of flexibility added here (and I’m not sure about adding it), but it looks like an idea to be explored in more details.

My choice for bridge implementation: use smart contracts, maybe some precompiled smart contracts with specialized functionality, like validation of a bitcoin header. To me, writing the bridge in smart contracts is better than written a big precompiled contract. It allows a more flexible evolution. Also, as I pointed out in my post Syncing a sidechain, I would save only some fields of the bitcoin headers received, needed to verify the bridge bitcoin transactions. And instead of keeping a wallet with the available UTXOs in each node, I prefer to delegate the UTXO selection (to be used in the formation of new Bitcoin transactions) to the federated nodes.

Although to allow evolution I could use upgradeable smart contracts, in this case I would use deactivation logic for the main bridge smart contract A1, and then, switch to use another smart contract A2.

For the reward feature, again, I would use smart contract, and base it on simplicity. I would separate the collect logic from the distribution logic. The collect logic should be small and quick. It could be invoked at the end of each block, or after n blocks. I didn’t bother to have collect logic based on past events or blocks. A simple collect logic could be good enough for the main production use cases. The distribution logic could be invoked at any time, to distribute the funds between federation and other participants. As with the main bridge, the distribution logic could be in a smart contract, with planned deactivation logic, that can be replaced by new updated logic.

Internal Changes

Notably, to implement the above described features, no change in wire protocol (inter-node messages) is needed. So I could take leverage of any Ethereum improvement in that protocol.

The main change is the structure of the block. I think that the new proof of work produced with merge mining could be added to an extra data field in the Ethereum blockheader, to minimize serialization disruption.

Last Thoughts

Yes, all the above is like an “academic exercise”: thinking aloud some ideas, but it is not easy to justify passing from ideas to project. But at least to me, it serves as an exercise of “what if”: to push me to think about alternative solutions to the same problems (a common pattern in my code, if you follow my personal projects). And sometimes, following that path, you can discover new interesting and important things. Enjoy the journey!

Angel “Java” Lopez